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

Merge branch 'develop' into rheo

Browse Source
This commit is contained in:
Axel Kohlmeyer
2025-06-24 20:29:18 -04:00
parent 08d81a5ac2 8dad9a0f68
commit db244166ca
277 changed files with 111194 additions and 3918 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
.github/release_steps.md vendored
View File

@ -110,7 +110,7 @@ git clone -b release --depth 10 https://github.com/lammps/lammps.git lammps-rele
cmake -S lammps-release/cmake -B build-release -G Ninja -D CMAKE_INSTALL_PREFIX=$PWD/lammps-static -D CMAKE_TOOLCHAIN_FILE=/usr/musl/share/cmake/linux-musl.cmake -C lammps-release/cmake/presets/most.cmake -C lammps-release/cmake/presets/kokkos-openmp.cmake -D DOWNLOAD_POTENTIALS=OFF -D BUILD_MPI=OFF -D BUILD_TESTING=OFF -D CMAKE_BUILD_TYPE=Release -D PKG_ATC=ON -D PKG_AWPMD=ON -D PKG_MANIFOLD=ON -D PKG_MESONT=ON -D PKG_MGPT=ON -D PKG_ML-PACE=ON -D PKG_ML-RANN=ON -D PKG_MOLFILE=ON -D PKG_PTM=ON -D PKG_QTB=ON -D PKG_SMTBQ=ON
cmake --build build-release --target all
cmake --build build-release --target install
/usr/musl/bin/x86_64-linux-musl-strip lammps-static/bin/*
/usr/musl/bin/x86_64-linux-musl-strip -g lammps-static/bin/*
tar -czvvf ../lammps-linux-x86_64-4Feb2025.tar.gz lammps-static
exit # fedora 41 container
cd ..

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

@ -55,8 +55,8 @@ jobs:
uses: actions/cache@v4
with:
path: ${{ env.CCACHE_DIR }}
key: linux-cpp23-ccache-${{ github.sha }}
restore-keys: linux-cpp23-ccache-
key: linux-cpp23-ccache-${{ matrix.idx }}-${{ github.sha }}
restore-keys: linux-cpp23-ccache-${{ matrix.idx }}
- name: Building LAMMPS via CMake
shell: bash

11
cmake/CMakeLists.txt
View File

@ -244,15 +244,6 @@ option(CMAKE_POSITION_INDEPENDENT_CODE "Create object compatible with shared lib
option(BUILD_TOOLS "Build and install LAMMPS tools (msi2lmp, binary2txt, chain)" 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,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()
file(GLOB ALL_SOURCES CONFIGURE_DEPENDS ${LAMMPS_SOURCE_DIR}/[^.]*.cpp)
file(GLOB MAIN_SOURCES CONFIGURE_DEPENDS ${LAMMPS_SOURCE_DIR}/main.cpp)
list(REMOVE_ITEM ALL_SOURCES ${MAIN_SOURCES})
@ -277,6 +268,7 @@ option(CMAKE_VERBOSE_MAKEFILE "Generate verbose Makefiles" OFF)
set(STANDARD_PACKAGES
ADIOS
AMOEBA
APIP
ASPHERE
ATC
AWPMD
@ -476,6 +468,7 @@ pkg_depends(ELECTRODE KSPACE)
pkg_depends(EXTRA-MOLECULE MOLECULE)
pkg_depends(MESONT MOLECULE)
pkg_depends(RHEO BPM)
pkg_depends(APIP ML-PACE)
# detect if we may enable OpenMP support by default
set(BUILD_OMP_DEFAULT OFF)

8
cmake/Modules/Packages/ML-PACE.cmake
View File

@ -53,7 +53,13 @@ else()
add_library(yaml-cpp::yaml-cpp ALIAS yaml-cpp)
endif()
add_subdirectory(${lib-pace} build-pace)
# fixup yaml-cpp/emitterutils.cpp for GCC 15+ until patch is applied
file(READ ${lib-pace}/yaml-cpp/src/emitterutils.cpp yaml_emitterutils)
string(REPLACE "#include <sstream>" "#include <sstream>\n#include <cinttypes>" yaml_tmp_emitterutils "${yaml_emitterutils}")
string(REPLACE "#include <cinttypes>\n#include <cinttypes>" "#include <cinttypes>" yaml_emitterutils "${yaml_tmp_emitterutils}")
file(WRITE ${lib-pace}/yaml-cpp/src/emitterutils.cpp "${yaml_emitterutils}")
add_subdirectory(${lib-pace} build-pace EXCLUDE_FROM_ALL)
set_target_properties(pace PROPERTIES CXX_EXTENSIONS ON OUTPUT_NAME lammps_pace${LAMMPS_MACHINE})
if(CMAKE_PROJECT_NAME STREQUAL "lammps")

4
cmake/Modules/Tools.cmake
View File

@ -6,6 +6,10 @@ if(BUILD_TOOLS)
add_executable(stl_bin2txt ${LAMMPS_TOOLS_DIR}/stl_bin2txt.cpp)
install(TARGETS stl_bin2txt DESTINATION ${CMAKE_INSTALL_BINDIR})
add_executable(reformat-json ${LAMMPS_TOOLS_DIR}/json/reformat-json.cpp)
target_include_directories(reformat-json PRIVATE ${LAMMPS_SOURCE_DIR})
install(TARGETS reformat-json DESTINATION ${CMAKE_INSTALL_BINDIR})
include(CheckGeneratorSupport)
if(CMAKE_GENERATOR_SUPPORT_FORTRAN)
include(CheckLanguage)

1
cmake/presets/all_off.cmake
View File

@ -4,6 +4,7 @@
set(ALL_PACKAGES
ADIOS
AMOEBA
APIP
ASPHERE
ATC
AWPMD

1
cmake/presets/all_on.cmake
View File

@ -6,6 +6,7 @@
set(ALL_PACKAGES
ADIOS
AMOEBA
APIP
ASPHERE
ATC
AWPMD

3
cmake/presets/kokkos-cuda.cmake
View File

@ -1,9 +1,8 @@
# preset that enables KOKKOS and selects CUDA compilation with OpenMP
# enabled as well. The GPU architecture *must* match your hardware
# enabled as well. The GPU architecture *must* match your hardware (If not manually set, Kokkos will try to autodetect it).
set(PKG_KOKKOS ON CACHE BOOL "" FORCE)
set(Kokkos_ENABLE_SERIAL ON CACHE BOOL "" FORCE)
set(Kokkos_ENABLE_CUDA ON CACHE BOOL "" FORCE)
set(Kokkos_ARCH_PASCAL60 ON CACHE BOOL "" FORCE)
set(BUILD_OMP ON CACHE BOOL "" FORCE)
get_filename_component(NVCC_WRAPPER_CMD ${CMAKE_CURRENT_SOURCE_DIR}/../lib/kokkos/bin/nvcc_wrapper ABSOLUTE)
set(CMAKE_CXX_COMPILER ${NVCC_WRAPPER_CMD} CACHE FILEPATH "" FORCE)

1
cmake/presets/nolib.cmake
View File

@ -3,6 +3,7 @@
set(PACKAGES_WITH_LIB
ADIOS
APIP
ATC
AWPMD
COMPRESS

6
doc/Makefile
View File

@ -99,8 +99,6 @@ html: xmlgen globbed-tocs $(VENV) $(SPHINXCONFIG)/conf.py $(ANCHORCHECK) $(MATHJ
@(\
. $(VENV)/bin/activate ; env PYTHONWARNINGS= PYTHONDONTWRITEBYTECODE=1 \
sphinx-build -E $(SPHINXEXTRA) -b html -c $(SPHINXCONFIG) -d $(BUILDDIR)/doctrees $(RSTDIR) html ;\
touch $(RSTDIR)/Fortran.rst ; env PYTHONWARNINGS= PYTHONDONTWRITEBYTECODE=1 \
sphinx-build $(SPHINXEXTRA) -b html -c $(SPHINXCONFIG) -d $(BUILDDIR)/doctrees $(RSTDIR) html ;\
ln -sf Manual.html html/index.html;\
rm -f $(BUILDDIR)/doxygen/xml/run.stamp;\
echo "############################################" ; env PYTHONWARNINGS= PYTHONDONTWRITEBYTECODE=1 \
@ -162,8 +160,6 @@ epub: xmlgen globbed-tocs $(VENV) $(SPHINXCONFIG)/conf.py $(ANCHORCHECK)
@(\
. $(VENV)/bin/activate ; env PYTHONWARNINGS= PYTHONDONTWRITEBYTECODE=1 \
sphinx-build -E $(SPHINXEXTRA) -b epub -c $(SPHINXCONFIG) -d $(BUILDDIR)/doctrees $(RSTDIR) epub ;\
touch $(RSTDIR)/Fortran.rst ; env PYTHONWARNINGS= PYTHONDONTWRITEBYTECODE=1 \
sphinx-build $(SPHINXEXTRA) -b epub -c $(SPHINXCONFIG) -d $(BUILDDIR)/doctrees $(RSTDIR) epub ;\
rm -f $(BUILDDIR)/doxygen/xml/run.stamp;\
deactivate ;\
)
@ -183,8 +179,6 @@ pdf: xmlgen globbed-tocs $(VENV) $(SPHINXCONFIG)/conf.py $(ANCHORCHECK)
@(\
. $(VENV)/bin/activate ; env PYTHONWARNINGS= PYTHONDONTWRITEBYTECODE=1 \
sphinx-build -E $(SPHINXEXTRA) -b latex -c $(SPHINXCONFIG) -d $(BUILDDIR)/doctrees $(RSTDIR) latex ;\
touch $(RSTDIR)/Fortran.rst ; env PYTHONWARNINGS= PYTHONDONTWRITEBYTECODE=1 \
sphinx-build $(SPHINXEXTRA) -b latex -c $(SPHINXCONFIG) -d $(BUILDDIR)/doctrees $(RSTDIR) latex ;\
rm -f $(BUILDDIR)/doxygen/xml/run.stamp;\
echo "############################################" ; env PYTHONWARNINGS= PYTHONDONTWRITEBYTECODE=1 \
rst_anchor_check src/*.rst ;\

4
doc/lammps.1
View File

@ -1,7 +1,7 @@
.TH LAMMPS "1" "2 April 2025" "2025-04-02"
.TH LAMMPS "1" "12 June 2025" "2025-06-12"
.SH NAME
.B LAMMPS
\- Molecular Dynamics Simulator. Version 2 April 2025
\- Molecular Dynamics Simulator. Version 12 June 2025
.SH SYNOPSIS
.B lmp

22
doc/src/Build_development.rst
View File

@ -28,28 +28,6 @@ variable VERBOSE set to 1:
----------
.. _clang-tidy:
Enable static code analysis with clang-tidy (CMake only)
--------------------------------------------------------
The `clang-tidy tool <https://clang.llvm.org/extra/clang-tidy/>`_ is a
static code analysis tool to diagnose (and potentially fix) typical
programming errors or coding style violations. It has a modular framework
of tests that can be adjusted to help identifying problems before they
become bugs and also assist in modernizing large code bases (like LAMMPS).
It can be enabled for all C++ code with the following CMake flag
.. code-block:: bash
-D ENABLE_CLANG_TIDY=value # value = no (default) or yes
With this flag enabled all source files will be processed twice, first to
be compiled and then to be analyzed. Please note that the analysis can be
significantly more time-consuming than the compilation itself.
----------
.. _iwyu_processing:
Report missing and unneeded '#include' statements (CMake only)

29
doc/src/Build_extras.rst
View File

@ -35,6 +35,7 @@ This is the list of packages that may require additional steps.
:columns: 6
* :ref:`ADIOS <adios>`
* :ref:`APIP <apip>`
* :ref:`ATC <atc>`
* :ref:`AWPMD <awpmd>`
* :ref:`COLVARS <colvar>`
@ -1272,6 +1273,34 @@ systems.
----------
.. _apip:
APIP package
-----------------------------
The APIP package depends on the library of the
:ref:`ML-PACE <ml-pace>` package.
The code for the library can be found
at: `https://github.com/ICAMS/lammps-user-pace/ <https://github.com/ICAMS/lammps-user-pace/>`_
.. tabs::
.. tab:: CMake build
No additional settings are needed besides ``-D PKG_APIP=yes``
and ``-D PKG_ML-PACE=yes``.
One can use a local version of the ML-PACE library instead of
automatically downloading the library as described :ref:`here <ml-pace>`.
.. tab:: Traditional make
You need to install the ML-PACE package *first* and follow
the instructions :ref:`here <ml-pace>` before installing
the APIP package.
----------
.. _atc:
ATC package

4
doc/src/Commands_fix.rst
View File

@ -22,6 +22,7 @@ OPT.
* :doc:`append/atoms <fix_append_atoms>`
* :doc:`atc <fix_atc>`
* :doc:`atom/swap <fix_atom_swap>`
* :doc:`atom_weight/apip <fix_atom_weight_apip>`
* :doc:`ave/atom <fix_ave_atom>`
* :doc:`ave/chunk <fix_ave_chunk>`
* :doc:`ave/correlate <fix_ave_correlate>`
@ -91,6 +92,8 @@ OPT.
* :doc:`imd <fix_imd>`
* :doc:`indent <fix_indent>`
* :doc:`ipi <fix_ipi>`
* :doc:`lambda/apip <fix_lambda_apip>`
* :doc:`lambda_thermostat/apip <fix_lambda_thermostat_apip>`
* :doc:`langevin (k) <fix_langevin>`
* :doc:`langevin/drude <fix_langevin_drude>`
* :doc:`langevin/eff <fix_langevin_eff>`
@ -113,7 +116,6 @@ OPT.
* :doc:`mvv/tdpd <fix_mvv_dpd>`
* :doc:`neb <fix_neb>`
* :doc:`neb/spin <fix_neb_spin>`
* :doc:`neighbor/swap <fix_neighbor_swap>`
* :doc:`nonaffine/displacement <fix_nonaffine_displacement>`
* :doc:`nph (ko) <fix_nh>`
* :doc:`nph/asphere (o) <fix_nph_asphere>`

2
doc/src/Commands_kspace.rst
View File

@ -31,3 +31,5 @@ OPT.
* :doc:`pppm/dielectric <kspace_style>`
* :doc:`pppm/electrode (i) <kspace_style>`
* :doc:`scafacos <kspace_style>`
* :doc:`zero <kspace_style>`

8
doc/src/Commands_pair.rst
View File

@ -96,7 +96,9 @@ OPT.
* :doc:`eam/cd <pair_eam>`
* :doc:`eam/cd/old <pair_eam>`
* :doc:`eam/fs (gikot) <pair_eam>`
* :doc:`eam/fs/apip <pair_eam_apip>`
* :doc:`eam/he <pair_eam>`
* :doc:`eam/apip <pair_eam_apip>`
* :doc:`edip (o) <pair_edip>`
* :doc:`edip/multi <pair_edip>`
* :doc:`edpd (g) <pair_mesodpd>`
@ -124,6 +126,9 @@ OPT.
* :doc:`ilp/tmd (t) <pair_ilp_tmd>`
* :doc:`kolmogorov/crespi/full <pair_kolmogorov_crespi_full>`
* :doc:`kolmogorov/crespi/z <pair_kolmogorov_crespi_z>`
* :doc:`lambda/input/apip <pair_lambda_input_apip>`
* :doc:`lambda/input/csp/apip <pair_lambda_input_apip>`
* :doc:`lambda/zone/apip <pair_lambda_zone_apip>`
* :doc:`lcbop <pair_lcbop>`
* :doc:`lebedeva/z <pair_lebedeva_z>`
* :doc:`lennard/mdf <pair_mdf>`
@ -237,6 +242,9 @@ OPT.
* :doc:`oxrna2/coaxstk <pair_oxrna2>`
* :doc:`pace (k) <pair_pace>`
* :doc:`pace/extrapolation (k) <pair_pace>`
* :doc:`pace/apip <pair_pace_apip>`
* :doc:`pace/fast/apip <pair_pace_apip>`
* :doc:`pace/precise/apip <pair_pace_apip>`
* :doc:`pedone (o) <pair_pedone>`
* :doc:`pod (k) <pair_pod>`
* :doc:`peri/eps <pair_peri>`

2
doc/src/Commands_removed.rst
View File

@ -15,7 +15,7 @@ with the direct alternative (if available) and print a warning.
GJF formulation in fix langevin
-------------------------------
.. deprecated:: TBD
.. deprecated:: 12Jun2025
The *gjf* keyword in fix langevin is deprecated and will be removed
soon. The GJF functionality has been moved to its own fix style

42
doc/src/Developer_plugins.rst
View File

@ -68,24 +68,25 @@ Members of ``lammpsplugin_t``
* - author
- String with the name and email of the author
* - creator.v1
- Pointer to factory function for pair, bond, angle, dihedral, improper, kspace, or command styles
- Pointer to factory function for pair, bond, angle, dihedral, improper, kspace, command, or minimize styles
* - creator.v2
- Pointer to factory function for compute, fix, or region styles
- Pointer to factory function for compute, fix, region, or run styles
* - handle
- Pointer to the open DSO file handle
Only one of the two alternate creator entries can be used at a time and
which of those is determined by the style of plugin. The "creator.v1"
element is for factory functions of supported styles computing forces
(i.e. pair, bond, angle, dihedral, or improper styles) or command styles
and the function takes as single argument the pointer to the LAMMPS
instance. The factory function is cast to the ``lammpsplugin_factory1``
type before assignment. The "creator.v2" element is for factory
functions creating an instance of a fix, compute, or region style and
takes three arguments: a pointer to the LAMMPS instance, an integer with
the length of the argument list and a ``char **`` pointer to the list of
arguments. The factory function pointer needs to be cast to the
``lammpsplugin_factory2`` type before assignment.
(i.e. pair, bond, angle, dihedral, or improper styles), command styles,
or minimize styles and the function takes as single argument the pointer
to the LAMMPS instance. The factory function is cast to the
``lammpsplugin_factory1`` type before assignment. The "creator.v2"
element is for factory functions creating an instance of a fix, compute,
region, or run style and takes three arguments: a pointer to the LAMMPS
instance, an integer with the length of the argument list and a ``char
**`` pointer to the list of arguments. The factory function pointer
needs to be cast to the ``lammpsplugin_factory2`` type before
assignment.
Pair style example
^^^^^^^^^^^^^^^^^^
@ -247,8 +248,8 @@ DSO handle. The registration function is called with a pointer to the address
of this struct and the pointer of the LAMMPS class. The registration function
will then add the factory function of the plugin style to the respective
style map under the provided name. It will also make a copy of the struct
in a list of all loaded plugins and update the reference counter for loaded
plugins from this specific DSO file.
in a global list of all loaded plugins and update the reference counter for
loaded plugins from this specific DSO file.
The pair style itself (i.e. the PairMorse2 class in this example) can be
written just like any other pair style that is included in LAMMPS. For
@ -263,6 +264,21 @@ the plugin will override the existing code. This can be used to modify
the behavior of existing styles or to debug new versions of them without
having to re-compile or re-install all of LAMMPS.
.. versionchanged:: 12Jun2025
When using the :doc:`clear <clear>` command, plugins are not unloaded
but restored to their respective style maps. This also applies when
multiple LAMMPS instances are created and deleted through the library
interface. The :doc:`plugin load <plugin>` load command may be issued
again, but for existing plugins they will be skipped. To replace
plugins they must be explicitly unloaded with :doc:`plugin unload
<plugin>`. When multiple LAMMPS instances are created concurrently, any
loaded plugins will be added to the global list of plugins, but are not
immediately available to any LAMMPS instance that was created before
loading the plugin. To "import" such plugins, the :doc:`plugin restore
<plugin>` may be used. Plugins are only removed when they are explicitly
unloaded or the LAMMPS interface is "finalized".
Compiling plugins
^^^^^^^^^^^^^^^^^

2
doc/src/Developer_updating.rst
View File

@ -615,7 +615,7 @@ This change is **required** or else the code will not compile.
FLERR as first argument to minimum image functions in Domain class
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. versionchanged:: TBD
.. versionchanged:: 12Jun2025
The ``Domain::minimum_image()`` and ``Domain::minimum_image_big()``
functions were changed to take the ``FLERR`` macros as first argument.

225
doc/src/Errors_common.rst
View File

@ -1,124 +1,149 @@
Common problems
===============
Common issues that are often regarded as bugs
=============================================
If two LAMMPS runs do not produce the exact same answer on different
machines or different numbers of processors, this is typically not a
bug. In theory you should get identical answers on any number of
processors and on any machine. In practice, numerical round-off can
cause slight differences and eventual divergence of molecular dynamics
phase space trajectories within a few 100s or few 1000s of timesteps.
However, the statistical properties of the two runs (e.g. average
energy or temperature) should still be the same.
The list below are some random notes on behavior of LAMMPS that is
sometimes unexpected or even considered a bug. Most of the time, these
are just issues of understanding how LAMMPS is implemented and
parallelized. Please also have a look at the :doc:`Error details
discussions page <Errors_details>` that contains recommendations for
tracking down issues and explanations for error messages that may
sometimes be confusing or need additional explanations.
If the :doc:`velocity <velocity>` command is used to set initial atom
velocities, a particular atom can be assigned a different velocity
when the problem is run on a different number of processors or on
different machines. If this happens, the phase space trajectories of
the two simulations will rapidly diverge. See the discussion of the
*loop* option in the :doc:`velocity <velocity>` command for details and
options that avoid this issue.
- A LAMMPS simulation typically has two stages, 1) issuing commands
and 2) run or minimize. Most LAMMPS errors are detected in stage 1),
others at the beginning of stage 2), and finally others like a bond
stretching too far may or lost atoms or bonds may not occur until the
middle of a run.
Similarly, the :doc:`create_atoms <create_atoms>` command generates a
lattice of atoms. For the same physical system, the ordering and
numbering of atoms by atom ID may be different depending on the number
of processors.
- If two LAMMPS runs do not produce the exact same answer on different
machines or different numbers of processors, this is typically not a
bug. In theory you should get identical answers on any number of
processors and on any machine. In practice, numerical round-off can
cause slight differences and eventual divergence of molecular dynamics
phase space trajectories within a few 100s or few 1000s of timesteps.
This can be triggered by different ordering of atoms due to different
domain decompositions, but also through different CPU architectures,
different operating systems, different compilers or compiler versions,
different compiler optimization levels, different FFT libraries.
However, the statistical properties of the two runs (e.g. average
energy or temperature) should still be the same.
Some commands use random number generators which may be setup to
produce different random number streams on each processor and hence
will produce different effects when run on different numbers of
processors. A commonly-used example is the :doc:`fix langevin <fix_langevin>` command for thermostatting.
- If the :doc:`velocity <velocity>` command is used to set initial atom
velocities, a particular atom can be assigned a different velocity
when the problem is run on a different number of processors or on
different machines. If this happens, the phase space trajectories of
the two simulations will rapidly diverge. See the discussion of the
*loop* option in the :doc:`velocity <velocity>` command for details
and options that avoid this issue.
A LAMMPS simulation typically has two stages, setup and run. Most
LAMMPS errors are detected at setup time; others like a bond
stretching too far may not occur until the middle of a run.
- Similarly, the :doc:`create_atoms <create_atoms>` command generates a
lattice of atoms. For the same physical system, the ordering and
numbering of atoms by atom ID may be different depending on the number
of processors.
LAMMPS tries to flag errors and print informative error messages so
you can fix the problem. For most errors it will also print the last
input script command that it was processing. Of course, LAMMPS cannot
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 <https://www.lammps.org/authors.html>`_ or create an new
topic on the dedicated `MatSci forum section <https://matsci.org/lammps/>`_.
- Some commands use random number generators which may be setup to
produce different random number streams on each processor and hence
will produce different effects when run on different numbers of
processors. A commonly-used example is the :doc:`fix langevin
<fix_langevin>` command for thermostatting.
If you get an error message about an invalid command in your input
script, you can determine what command is causing the problem by
looking in the log.lammps file or using the :doc:`echo command <echo>`
to see it on the screen. If you get an error like "Invalid ...
style", with ... being fix, compute, pair, etc, it means that you
mistyped the style name or that the command is part of an optional
package which was not compiled into your executable. The list of
available styles in your executable can be listed by using
:doc:`the -h command-line switch <Run_options>`. The installation and
compilation of optional packages is explained on the
:doc:`Build packages <Build_package>` doc page.
- LAMMPS tries to flag errors and print informative error messages so
you can fix the problem. For most errors it will also print the last
input script command that it was processing or even point to the
keyword that is causing troubles. Of course, LAMMPS cannot 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! Also, LAMMPS does not know what you *intend* to
do, but very strictly applies the syntax as described in the
documentation. If you run into errors that LAMMPS does not catch that
you think it should flag, please send an email to the `developers
<https://www.lammps.org/authors.html>`_ or create an new topic on the
dedicated `MatSci forum section <https://matsci.org/lammps/>`_.
For a given command, LAMMPS expects certain arguments in a specified
order. If you mess this up, LAMMPS will often flag the error, but it
may also simply read a bogus argument and assign a value that is
valid, but not what you wanted. E.g. trying to read the string "abc"
as an integer value of 0. Careful reading of the associated doc page
for the command should allow you to fix these problems. In most cases,
where LAMMPS expects to read a number, either integer or floating point,
it performs a stringent test on whether the provided input actually
is an integer or floating-point number, respectively, and reject the
input with an error message (for instance, when an integer is required,
but a floating-point number 1.0 is provided):
- If you get an error message about an invalid command in your input
script, you can determine what command is causing the problem by
looking in the log.lammps file or using the :doc:`echo command <echo>`
to see it on the screen. If you get an error like "Invalid ...
style", with ... being fix, compute, pair, etc, it means that you
mistyped the style name or that the command is part of an optional
package which was not compiled into your executable. The list of
available styles in your executable can be listed by using
:doc:`the -h command-line switch <Run_options>`. The installation and
compilation of optional packages is explained on the :doc:`Build
packages <Build_package>` doc page.
.. parsed-literal::
- For a given command, LAMMPS expects certain arguments in a specified
order. If you mess this up, LAMMPS will often flag the error, but it
may also simply read a bogus argument and assign a value that is
valid, but not what you wanted. E.g. trying to read the string "abc"
as an integer value of 0. Careful reading of the associated doc page
for the command should allow you to fix these problems. In most cases,
where LAMMPS expects to read a number, either integer or floating
point, it performs a stringent test on whether the provided input
actually is an integer or floating-point number, respectively, and
reject the input with an error message (for instance, when an integer
is required, but a floating-point number 1.0 is provided):
.. parsed-literal::
ERROR: Expected integer parameter instead of '1.0' in input script or data file
Some commands allow for using variable references in place of numeric
constants so that the value can be evaluated and may change over the
course of a run. This is typically done with the syntax *v_name* for a
parameter, where name is the name of the variable. On the other hand,
immediate variable expansion with the syntax ${name} is performed while
reading the input and before parsing commands,
- Some commands allow for using variable references in place of numeric
constants so that the value can be evaluated and may change over the
course of a run. This is typically done with the syntax *v_name* for
a parameter, where name is the name of the variable. On the other
hand, immediate variable expansion with the syntax ${name} is
performed while reading the input and before parsing commands,
.. note::
.. note::
Using a variable reference (i.e. *v_name*) is only allowed if
the documentation of the corresponding command explicitly says it is.
Otherwise, you will receive an error message of this kind:
.. parsed-literal::
.. parsed-literal::
ERROR: Expected floating point parameter instead of 'v_name' in input script or data file
Generally, LAMMPS will print a message to the screen and logfile and
exit gracefully when it encounters a fatal error. Sometimes it will
print a WARNING to the screen and logfile and continue on; you can
decide if the WARNING is important or not. A WARNING message that is
generated in the middle of a run is only printed to the screen, not to
the logfile, to avoid cluttering up thermodynamic output. If LAMMPS
crashes or hangs without spitting out an error message first then it
could be a bug (see :doc:`this section <Errors_bugs>`) or one of the following
cases:
- Generally, LAMMPS will print a message to the screen and logfile and
exit gracefully when it encounters a fatal error. When running in
parallel this message may be stuck in an I/O buffer and LAMMPS will be
terminated before that buffer is printed. In that case you can try
adding the ``-nonblock`` or ``-nb`` command-line flag to turn off that
buffering. Please note that this should not be used for production
runs, since turning off buffering usually has a significant negative
impact on performance (even worse than :doc:`thermo_modify flush yes
<thermo_modify>`). Sometimes LAMMPS will print a WARNING to the
screen and logfile and continue on; you can decide if the WARNING is
important or not, but as a general rule do not ignore warnings that
you not understand. A WARNING message that is generated in the middle
of a run is only printed to the screen, not to the logfile, to avoid
cluttering up thermodynamic output. If LAMMPS crashes or hangs
without generating an error message first then it could be a bug
(see :doc:`this section <Errors_bugs>`).
LAMMPS runs in the available memory a processor allows to be
allocated. Most reasonable MD runs are compute limited, not memory
limited, so this should not be a bottleneck on most platforms. Almost
all large memory allocations in the code are done via C-style malloc's
which will generate an error message if you run out of memory.
Smaller chunks of memory are allocated via C++ "new" statements. If
you are unlucky you could run out of memory just when one of these
small requests is made, in which case the code will crash or hang (in
parallel), since LAMMPS does not trap on those errors.
- LAMMPS runs in the available memory a processor allows to be
allocated. Most reasonable MD runs are compute limited, not memory
limited, so this should not be a bottleneck on most platforms. Almost
all large memory allocations in the code are done via C-style malloc's
which will generate an error message if you run out of memory.
Smaller chunks of memory are allocated via C++ "new" statements. If
you are unlucky you could run out of memory just when one of these
small requests is made, in which case the code will crash or hang (in
parallel).
Illegal arithmetic can cause LAMMPS to run slow or crash. This is
typically due to invalid physics and numerics that your simulation is
computing. If you see wild thermodynamic values or NaN values in your
LAMMPS output, something is wrong with your simulation. If you
suspect this is happening, it is a good idea to print out
thermodynamic info frequently (e.g. every timestep) via the
:doc:`thermo <thermo>` so you can monitor what is happening.
Visualizing the atom movement is also a good idea to ensure your model
is behaving as you expect.
- Illegal arithmetic can cause LAMMPS to run slow or crash. This is
typically due to invalid physics and numerics that your simulation is
computing. If you see wild thermodynamic values or NaN values in your
LAMMPS output, something is wrong with your simulation. If you
suspect this is happening, it is a good idea to print out
thermodynamic info frequently (e.g. every timestep) via the
:doc:`thermo <thermo>` so you can monitor what is happening.
Visualizing the atom movement is also a good idea to ensure your model
is behaving as you expect.
In parallel, one way LAMMPS can hang is due to how different MPI
implementations handle buffering of messages. If the code hangs
without an error message, it may be that you need to specify an MPI
setting or two (usually via an environment variable) to enable
buffering or boost the sizes of messages that can be buffered.
- When running in parallel with MPI, one way LAMMPS can hang is because
LAMMPS has come across an error condition, but only on one or a few
MPI processes and not all of them. LAMMPS has two different "stop
with an error message" functions and the correct one has to be called
or else it will hang.

40
doc/src/Errors_details.rst
View File

@ -51,8 +51,11 @@ Parallel versus serial
^^^^^^^^^^^^^^^^^^^^^^
Issues where something is "lost" or "missing" often exhibit that issue
only when running in parallel. That doesn't mean there is no problem,
only the symptoms are not triggering an error quickly. Correspondingly,
*only* when running in parallel. That doesn't mean there is no problem
when running in serial, only the symptoms are not triggering an error.
This may be because there is no domain decomposition with just one
processor and thus all atoms are accessible, or it may be because the
problem will manifest faster with smaller subdomains. Correspondingly,
errors may be triggered faster with more processors and thus smaller
sub-domains.
@ -244,6 +247,25 @@ equal style (or similar) variables can only be expanded before the box
is defined if they do not reference anything that cannot be defined
before the box (e.g. a compute or fix reference or a thermo keyword).
.. _hint13:
Illegal ... command
^^^^^^^^^^^^^^^^^^^
These are a catchall error messages that used to be used a lot in LAMMPS
(also programmers are sometimes lazy). They usually include the name of
the source file and the line where the error happened. This can be used
to track down what caused the error (most often some form of syntax error)
by looking at the source code. However, this has two disadvantages: 1. one
has to check the source file from the exact same LAMMPS version, or else
the line number would be different or the core may have been rewritten and
that specific error does not exist anymore.
The LAMMPS developers are committed to replace these too generic error
messages with more descriptive errors, e.g. listing *which* keyword was
causing the error, so that it will be much simpler to look up the
correct syntax in the manual (and without referring to the source code).
------
.. _err0001:
@ -1029,13 +1051,15 @@ Even though the LAMMPS error message recommends to increase the "one"
parameter, this may not always be the correct solution. The neighbor
list overflow can also be a symptom for some other error that cannot be
easily detected. For example, a frequent reason for an (unexpected)
high density are incorrect box boundaries (since LAMMPS wraps atoms back
high density are incorrect box dimensions (since LAMMPS wraps atoms back
into the principal box with periodic boundaries) or coordinates provided
as fractional coordinates. In both cases, LAMMPS cannot easily know
whether the input geometry has such a high density (and thus requiring
more neighbor list storage per atom) by intention. Rather than blindly
increasing the "one" parameter, it is thus worth checking if this is
justified by the combination of density and cutoff.
as fractional coordinates (LAMMPS does not support this for data files).
In both cases, LAMMPS cannot easily know whether the input geometry has
such a high density (and thus requiring more neighbor list storage per
atom) on purpose or by accident. Rather than blindly increasing the
"one" parameter, it is thus worth checking if this is justified by the
combination of density and cutoff. This is particularly recommended
when using some tool(s) to convert input or data files.
When boosting (= increasing) the "one" parameter, it is recommended to
also increase the value for the "page" parameter to maintain the ratio

31
doc/src/Fortran.rst
View File

@ -69,10 +69,11 @@ statement. Internally, it will call either
:cpp:func:`lammps_open_fortran` or :cpp:func:`lammps_open_no_mpi` from
the C library API to create the class instance. All arguments are
optional and :cpp:func:`lammps_mpi_init` will be called automatically
if it is needed. Similarly, a possible call to
:cpp:func:`lammps_mpi_finalize` is integrated into the :f:func:`close`
function and triggered with the optional logical argument set to
``.TRUE.``. Here is a simple example:
if it is needed. Similarly, optional calls to
:cpp:func:`lammps_mpi_finalize`, :cpp:func:`lammps_kokkos_finalize`,
:cpp:func:`lammps_python_finalize`, and :cpp:func:`lammps_plugin_finalize`
are integrated into the :f:func:`close` function and triggered with the
optional logical argument set to ``.TRUE.``. Here is a simple example:
.. code-block:: fortran
@ -521,8 +522,8 @@ Procedures Bound to the :f:type:`lammps` Derived Type
This method will close down the LAMMPS instance through calling
:cpp:func:`lammps_close`. If the *finalize* argument is present and
has a value of ``.TRUE.``, then this subroutine also calls
:cpp:func:`lammps_kokkos_finalize` and
:cpp:func:`lammps_mpi_finalize`.
:cpp:func:`lammps_kokkos_finalize`, :cpp:func:`lammps_mpi_finalize`,
:cpp:func:`lammps_python_finalize`, and :cpp:func:`lammps_plugin_finalize`.
:o finalize: shut down the MPI environment of the LAMMPS
library if ``.TRUE.``.
@ -530,6 +531,8 @@ Procedures Bound to the :f:type:`lammps` Derived Type
:to: :cpp:func:`lammps_close`
:to: :cpp:func:`lammps_mpi_finalize`
:to: :cpp:func:`lammps_kokkos_finalize`
:to: :cpp:func:`lammps_python_finalize`
:to: :cpp:func:`lammps_plugin_finalize`
--------
@ -2096,7 +2099,7 @@ Procedures Bound to the :f:type:`lammps` Derived Type
--------
.. f:subroutine:: create_atoms([id,] type, x, [v,] [image,] [bexpand])
.. f:function:: create_atoms([id,] type, x, [v,] [image,] [bexpand])
This method calls :cpp:func:`lammps_create_atoms` to create additional atoms
from a given list of coordinates and a list of atom types. Additionally,
@ -2125,6 +2128,8 @@ Procedures Bound to the :f:type:`lammps` Derived Type
will be created, not dropped, and the box dimensions will be extended.
Default is ``.FALSE.``
:otype bexpand: logical,optional
:r atoms: number of created atoms
:rtype atoms: integer(c_int)
:to: :cpp:func:`lammps_create_atoms`
.. note::
@ -2149,6 +2154,18 @@ Procedures Bound to the :f:type:`lammps` Derived Type
--------
.. f:subroutine:: create_molecule(id, jsonstr)
Add molecule template from string with JSON data
.. versionadded:: TBD
:p character(len=\*) id: desired molecule-ID
:p character(len=\*) jsonstr: string with JSON data defining the molecule template
:to: :cpp:func:`lammps_create_molecule`
--------
.. f:function:: find_pair_neighlist(style[, exact][, nsub][, reqid])
Find index of a neighbor list requested by a pair style.

1
doc/src/Howto.rst
View File

@ -93,6 +93,7 @@ Packages howto
Howto_manifold
Howto_rheo
Howto_spins
Howto_apip
Tutorials howto
===============

225
doc/src/Howto_apip.rst Normal file
View File

@ -0,0 +1,225 @@
Adaptive-precision interatomic potentials (APIP)
================================================
The :ref:`PKG-APIP <PKG-APIP>` enables use of adaptive-precision potentials
as described in :ref:`(Immel) <Immel2025_1>`.
In the context of this package, precision refers to the accuracy of an interatomic
potential.
Modern machine-learning (ML) potentials translate the accuracy of DFT
simulations into MD simulations, i.e., ML potentials are more accurate
compared to traditional empirical potentials.
However, this accuracy comes at a cost: there is a considerable performance
gap between the evaluation of classical and ML potentials, e.g., the force
calculation of a classical EAM potential is 100-1000 times faster compared
to the ML-based ACE method.
The evaluation time difference results in a conflict between large time and
length scales on the one hand and accuracy on the other.
This conflict is resolved by an APIP model for simulations, in which the highest precision
is required only locally but not globally.
An APIP model uses a precise but
expensive ML potential only for a subset of atoms, while a fast
potential is used for the remaining atoms.
Whether the precise or the fast potential is used is determined
by a continuous switching parameter :math:`\lambda_i` that can be defined for each
atom :math:`i`.
The switching parameter can be adjusted dynamically during a simulation or
kept constant as explained below.
The potential energy :math:`E_i` of an atom :math:`i` described by an
adaptive-precision
interatomic potential is given by :ref:`(Immel) <Immel2025_1>`
.. math::
E_i = \lambda_i E_i^\text{(fast)} + (1-\lambda_i) E_i^\text{(precise)},
whereas :math:`E_i^\text{(fast)}` is the potential energy of atom :math:`i`
according to a fast interatomic potential,
:math:`E_i^\text{(precise)}` is the potential energy according to a precise
interatomic potential and :math:`\lambda_i\in[0,1]` is the
switching parameter that decides how the potential energies are weighted.
Adaptive-precision saves computation time when the computation of the
precise potential is not required for many atoms, i.e., when
:math:`\lambda_i=1` applies for many atoms.
The currently implemented potentials are:
.. list-table::
:header-rows: 1
* - Fast potential
- Precise potential
* - :doc:`ACE <pair_pace_apip>`
- :doc:`ACE <pair_pace_apip>`
* - :doc:`EAM <pair_eam_apip>`
-
In theory, any short-range potential can be used for an adaptive-precision
interatomic potential. How to implement a new (fast or precise)
adaptive-precision
potential is explained in :ref:`here <implementing_new_apip_styles>`.
The switching parameter :math:`\lambda_i` that combines the two potentials
can be dynamically calculated during a
simulation.
Alternatively, one can set a constant switching parameter before the start
of a simulation.
To run a simulation with an adaptive-precision potential, one needs the
following components:
.. tabs::
.. tab:: dynamic switching parameter
#. :doc:`atom_style apip <atom_style>` so that the switching parameter :math:`\lambda_i` can be stored.
#. A fast potential: :doc:`eam/apip <pair_eam_apip>` or :doc:`pace/fast/apip <pair_pace_apip>`.
#. A precise potential: :doc:`pace/precise/apip <pair_pace_apip>`.
#. :doc:`pair_style lambda/input/apip <pair_lambda_input_apip>` to calculate :math:`\lambda_i^\text{input}`, from which :math:`\lambda_i` is calculated.
#. :doc:`fix lambda/apip <fix_lambda_apip>` to calculate the switching parameter :math:`\lambda_i`.
#. :doc:`pair_style lambda/zone/apip <pair_lambda_zone_apip>` to calculate the spatial transition zone of the switching parameter.
#. :doc:`pair_style hybrid/overlay <pair_hybrid>` to combine the previously mentioned pair_styles.
#. :doc:`fix lambda_thermostat/apip <fix_lambda_thermostat_apip>` to conserve the energy when switching parameters change.
#. :doc:`fix atom_weight/apip <fix_atom_weight_apip>` to approximate the load caused by every atom, as the computations of the pair_styles are only required for a subset of atoms.
#. :doc:`fix balance <fix_balance>` to perform dynamic load balancing with the calculated load.
.. tab:: constant switching parameter
#. :doc:`atom_style apip <atom_style>` so that the switching parameter :math:`\lambda_i` can be stored.
#. A fast potential: :doc:`eam/apip <pair_eam_apip>` or :doc:`pace/fast/apip <pair_pace_apip>`.
#. A precise potential: :doc:`pace/precise/apip <pair_pace_apip>`.
#. :doc:`set <set>` command to set the switching parameter :math:`\lambda_i`.
#. :doc:`pair_style hybrid/overlay <pair_hybrid>` to combine the previously mentioned pair_styles.
#. :doc:`fix atom_weight/apip <fix_atom_weight_apip>` to approximate the load caused by every atom, as the computations of the pair_styles are only required for a subset of atoms.
#. :doc:`fix balance <fix_balance>` to perform dynamic load balancing with the calculated load.
----------
Example
"""""""
.. note::
How to select the values of the parameters of an adaptive-precision
interatomic potential is discussed in detail in :ref:`(Immel) <Immel2025_1>`.
.. tabs::
.. tab:: dynamic switching parameter
Lines like these would appear in the input script:
.. code-block:: LAMMPS
atom_style apip
comm_style tiled
pair_style hybrid/overlay eam/fs/apip pace/precise/apip lambda/input/csp/apip fcc cutoff 5.0 lambda/zone/apip 12.0
pair_coeff * * eam/fs/apip Cu.eam.fs Cu
pair_coeff * * pace/precise/apip Cu.yace Cu
pair_coeff * * lambda/input/csp/apip
pair_coeff * * lambda/zone/apip
fix 2 all lambda/apip 2.5 3.0 time_averaged_zone 4.0 12.0 110 110 min_delta_lambda 0.01
fix 3 all lambda_thermostat/apip N_rescaling 200
fix 4 all atom_weight/apip 100 eam ace lambda/input lambda/zone all
variable myweight atom f_4
fix 5 all balance 100 1.1 rcb weight var myweight
First, the :doc:`atom_style apip <atom_style>` and the communication style are set.
.. note::
Note, that :doc:`comm_style <comm_style>` *tiled* is required for the style *rcb* of
:doc:`fix balance <fix_balance>`, but not for APIP.
However, the flexibility offered by the balancing style *rcb*, compared to the
balancing style *shift*, is advantageous for APIP.
An adaptive-precision EAM-ACE potential, for which the switching parameter
:math:`\lambda` is calculated from the CSP, is defined via
:doc:`pair_style hybrid/overlay <pair_hybrid>`.
The fixes ensure that the switching parameter is calculated, the energy conserved,
the weight for the load balancing calculated and the load-balancing itself is done.
.. tab:: constant switching parameter
Lines like these would appear in the input script:
.. code-block:: LAMMPS
atom_style apip
comm_style tiled
pair_style hybrid/overlay eam/fs/apip pace/precise/apip
pair_coeff * * eam/fs/apip Cu.eam.fs Cu
pair_coeff * * pace/precise/apip Cu.yace Cu
# calculate lambda somehow
variable lambda atom ...
set group all apip/lambda v_lambda
fix 4 all atom_weight/apip 100 eam ace lambda/input lambda/zone all
variable myweight atom f_4
fix 5 all balance 100 1.1 rcb weight var myweight
First, the :doc:`atom_style apip <atom_style>` and the communication style are set.
.. note::
Note, that :doc:`comm_style <comm_style>` *tiled* is required for the style *rcb* of
:doc:`fix balance <fix_balance>`, but not for APIP.
However, the flexibility offered by the balancing style *rcb*, compared to the
balancing style *shift*, is advantageous for APIP.
An adaptive-precision EAM-ACE potential is defined via
:doc:`pair_style hybrid/overlay <pair_hybrid>`.
The switching parameter :math:`\lambda_i` of the adaptive-precision
EAM-ACE potential is set via the :doc:`set command <set>`.
The parameter is not updated during the simulation.
Therefore, the potential is conservative.
The fixes ensure that the weight for the load balancing is calculated
and the load-balancing itself is done.
----------
.. _implementing_new_apip_styles:
Implementing new APIP pair styles
"""""""""""""""""""""""""""""""""
One can introduce adaptive-precision to an existing pair style by modifying
the original pair style.
One should calculate the force
:math:`F_i = - \nabla_i \sum_j E_j^\text{original}` for a fast potential or
:math:`F_i = - (1-\nabla_i) \sum_j E_j^\text{original}` for a precise
potential from the original potential
energy :math:`E_j^\text{original}` to see where the switching parameter
:math:`\lambda_i` needs to be introduced in the force calculation.
The switching parameter :math:`\lambda_i` is known for all atoms :math:`i`
in force calculation routine.
One needs to introduce an abortion criterion based on :math:`\lambda_i` to
ensure that all not required calculations are skipped and compute time can
be saved.
Furthermore, one needs to provide the number of calculations and measure the
computation time.
Communication within the force calculation needs to be prevented to allow
effective load-balancing.
With communication, the load balancer cannot balance few calculations of the
precise potential on one processor with many computations of the fast
potential on another processor.
All changes in the pair_style pace/apip compared to the pair_style pace
are annotated and commented.
Thus, the pair_style pace/apip can serve as an example for the implementation
of new adaptive-precision potentials.
----------
.. _Immel2025_1:
**(Immel)** Immel, Drautz and Sutmann, J Chem Phys, 162, 114119 (2025)

16
doc/src/Howto_spc.rst
View File

@ -8,6 +8,18 @@ the two O-H bonds and the H-O-H angle rigid. A bond style of
*harmonic* and an angle style of *harmonic* or *charmm* should also be
used.
One suitable pair style with cutoff Coulomb would for instance be:
* :doc:`pair_style lj/cut/coul/cut <pair_lj_cut_coul>`
These commands are examples for a long-range Coulomb model:
* :doc:`pair_style lj/cut/coul/long <pair_lj_cut_coul>`
* :doc:`pair_style lj/cut/coul/long/soft <pair_fep_soft>`
* :doc:`kspace_style pppm <kspace_style>`
* :doc:`pair_style lj/long/coul/long <pair_lj_long>`
* :doc:`kspace_style pppm/disp <kspace_style>`
These are the additional parameters (in real units) to set for O and H
atoms and the water molecule to run a rigid SPC model.
@ -39,7 +51,9 @@ the SPC and SPC/E models.
Below is the code for a LAMMPS input file and a molecule file
(``spce.mol``) of SPC/E water for use with the :doc:`molecule command
<molecule>` demonstrating how to set up a small bulk water system for
SPC/E with rigid bonds.
SPC/E with rigid bonds. For simplicity and speed the example uses a
cutoff Coulomb. Most production simulations require long-range Coulomb
instead.
.. code-block:: LAMMPS

15
doc/src/Howto_tip3p.rst
View File

@ -5,17 +5,24 @@ The TIP3P water model as implemented in CHARMM :ref:`(MacKerell)
<howto-tip3p>` specifies a 3-site rigid water molecule with charges and
Lennard-Jones parameters assigned to each of the three atoms.
A suitable pair style with cutoff Coulomb would be:
One suitable pair style with cutoff Coulomb would for instance be:
* :doc:`pair_style lj/cut/coul/cut <pair_lj_cut_coul>`
or these commands for a long-range Coulomb model:
These commands are examples for a long-range Coulomb model:
* :doc:`pair_style lj/cut/coul/long <pair_lj_cut_coul>`
* :doc:`pair_style lj/cut/coul/long/soft <pair_fep_soft>`
* :doc:`kspace_style pppm <kspace_style>`
* :doc:`pair_style lj/long/coul/long <pair_lj_long>`
* :doc:`kspace_style pppm/disp <kspace_style>`
And these pair styles are compatible with the CHARMM force field:
* :doc:`pair_style lj/charmm/coul/charmm <pair_charmm>`
* :doc:`pair_style lj/charmm/coul/long <pair_charmm>`
* :doc:`pair_style lj/charmmfsw/coul/long <pair_charmm>`
In LAMMPS the :doc:`fix shake or fix rattle <fix_shake>` command can be
used to hold the two O-H bonds and the H-O-H angle rigid. A bond style
of :doc:`harmonic <bond_harmonic>` and an angle style of :doc:`harmonic
@ -100,7 +107,9 @@ ignored.
Below is the code for a LAMMPS input file and a molecule file
(``tip3p.mol``) of TIP3P water for use with the :doc:`molecule command
<molecule>` demonstrating how to set up a small bulk water system for
TIP3P with rigid bonds.
TIP3P with rigid bonds. For simplicity and speed the example uses a
cutoff Coulomb. Most production simulations require long-range Coulomb
instead.
.. code-block:: LAMMPS

4
doc/src/Howto_tip4p.rst
View File

@ -167,7 +167,9 @@ cutoffs are set in the :doc:`pair_style lj/cut/tip4p/long
Below is the code for a LAMMPS input file using the implicit method and
the :ref:`TIP3P molecule file <tip3p_molecule>`. Because the TIP4P
charges are different from TIP3P they need to be reset (or the molecule
file changed):
file changed). For simplicity and speed the example uses a cutoff
Coulomb. Most production simulations require long-range Coulomb
instead.
.. code-block:: LAMMPS

4
doc/src/Howto_tip5p.rst
View File

@ -87,7 +87,9 @@ atom style full or use :doc:`fix property/atom mol <fix_property_atom>`
so that fix rigid/small can identify rigid bodies by their molecule ID.
Also a :doc:`neigh_modify exclude <neigh_modify>` command is added to
exclude computing intramolecular non-bonded interactions, since those
are removed by the rigid fix anyway:
are removed by the rigid fix anyway. For simplicity and speed the
example uses a cutoff Coulomb. Most production simulations require
long-range Coulomb instead.
.. code-block:: LAMMPS

4
doc/src/Install_git.rst
View File

@ -21,8 +21,8 @@ You can follow the LAMMPS development on 4 different git branches:
* **develop** : this branch follows the ongoing development and is
updated with every merge commit of a pull request
* **release** : this branch is updated with every "feature release";
updates are always "fast-forward" merges from *develop*
* **release** : this branch is updated with every "feature release"
and updates are always "fast-forward" merges from *develop*
* **maintenance** : this branch collects back-ported bug fixes from the
*develop* branch to the *stable* branch. It is used to update the
*stable* branch for "stable update releases".

6
doc/src/Library_create.rst
View File

@ -11,6 +11,7 @@ This section documents the following functions:
- :cpp:func:`lammps_mpi_finalize`
- :cpp:func:`lammps_kokkos_finalize`
- :cpp:func:`lammps_python_finalize`
- :cpp:func:`lammps_plugin_finalize`
- :cpp:func:`lammps_error`
--------------------
@ -119,5 +120,10 @@ calling program.
-----------------------
.. doxygenfunction:: lammps_plugin_finalize
:project: progguide
-----------------------
.. doxygenfunction:: lammps_error
:project: progguide

5
doc/src/Library_scatter.rst
View File

@ -27,6 +27,7 @@ It documents the following functions:
- :cpp:func:`lammps_scatter`
- :cpp:func:`lammps_scatter_subset`
- :cpp:func:`lammps_create_atoms`
- :cpp:func:`lammps_create_molecule`
-----------------------
@ -103,4 +104,8 @@ It documents the following functions:
.. doxygenfunction:: lammps_create_atoms(void *handle, int n, const int *id, const int *type, const double *x, const double *v, const int *image, int bexpand)
:project: progguide
-----------------------
.. doxygenfunction:: lammps_create_molecule
:project: progguide

55
doc/src/Packages_details.rst
View File

@ -28,6 +28,7 @@ gives those details.
* :ref:`ADIOS <PKG-ADIOS>`
* :ref:`AMOEBA <PKG-AMOEBA>`
* :ref:`APIP <PKG-APIP>`
* :ref:`ASPHERE <PKG-ASPHERE>`
* :ref:`ATC <PKG-ATC>`
* :ref:`AWPMD <PKG-AWPMD>`
@ -186,6 +187,60 @@ provided by the Ponder group in their
----------
.. _PKG-APIP:
APIP package
------------
**Contents:**
This package provides adaptive-precision interatomic potentials (APIP) as
described in:
D. Immel, R. Drautz and G. Sutmann, "Adaptive-precision potentials for
large-scale atomistic simulations", J. Chem. Phys. 162, 114119 (2025)
`link <immel2025_doi_>`_
Adaptive-precision means, that a fast interatomic potential, such as EAM,
is coupled to a precise interatomic potential, such as ACE.
This package provides the required pair_styles and fixes to run an efficient,
energy-conserving adaptive-precision simulation.
In the context of this package, precision refers to the accuracy of an interatomic
potential.
.. _immel2025_doi: https://doi.org/10.1063/5.0245877
**Authors:**
This package was written by David Immel^1,
Ralf Drautz^2 and Godehard Sutmann^1^2.
^1: Forschungszentrum Juelich, Juelich, Germany
^2: Ruhr-University Bochum, Bochum, Germany
**Install:**
The APIP package requires also the installation of ML-PACE, which has
:ref:`specific installation instructions <ml-pace>` on the
:doc:`Build extras <Build_extras>` page.
**Supporting info:**
* ``src/APIP``: filenames -> commands
* :doc:`Howto APIP <Howto_apip>`
* ``examples/PACKAGES/apip``
* :doc:`fix atom_weight/apip <fix_atom_weight_apip>`
* :doc:`fix lambda/apip <fix_lambda_apip>`
* :doc:`fix lambda_thermostat/apip <fix_lambda_thermostat_apip>`
* :doc:`pair_style eam/apip <pair_eam_apip>`
* :doc:`pair_style lambda/zone/apip <pair_lambda_zone_apip>`
* :doc:`pair_style lambda/input/apip <pair_lambda_input_apip>`
* :doc:`pair_style pace/apip <pair_pace_apip>`
----------
.. _PKG-ASPHERE:
ASPHERE package

5
doc/src/Packages_list.rst
View File

@ -38,6 +38,11 @@ whether an extra library is needed to build and use the package:
- :doc:`AMOEBA and HIPPO howto <Howto_amoeba>`
- amoeba
- no
* - :ref:`APIP <PKG-APIP>`
- adaptive-precision interatomic potentials
- :doc:`Howto APIP <Howto_apip>`
- ``PACKAGES/apip``
- ext
* - :ref:`ASPHERE <PKG-ASPHERE>`
- aspherical particle models
- :doc:`Howto spherical <Howto_spherical>`

20
doc/src/Python_call.rst
View File

@ -5,18 +5,28 @@ LAMMPS has several commands which can be used to invoke Python
code directly from an input script:
* :doc:`python <python>`
* :doc:`variable python <variable>`
* :doc:`python-style variables <variable>`
* :doc:`equal-style and atom-style variables with formulas containing Python function wrappers <variable>`
* :doc:`fix python/invoke <fix_python_invoke>`
* :doc:`pair_style python <pair_python>`
The :doc:`python <python>` command which can be used to define and
execute a Python function that you write the code for. The Python
function can also be assigned to a LAMMPS python-style variable via
the :doc:`variable <variable>` command. Each time the variable is
The :doc:`python <python>` command can be used to define and execute a
Python function that you write the code for. The Python function can
also be assigned to a LAMMPS python-style variable via the
:doc:`variable <variable>` command. Each time the variable is
evaluated, either in the LAMMPS input script itself, or by another
LAMMPS command that uses the variable, this will trigger the Python
function to be invoked.
The Python function can also be referenced in the formula used to
define an :doc:`equal-style or atom-style variable <variable>`, using
the syntax for a :doc:`Python function wrapper <variable>`. This make
it easy to pass LAMMPS-related arguments to the Python function, as
well as to invoke it whenever the equal- or atom-style variable is
evaluated. For an atom-style variable it means the Python function
can be invoked once per atom, using per-atom properties as arguments
to the function.
The Python code for the function can be included directly in the input
script or in an auxiliary file. The function can have arguments which
are mapped to LAMMPS variables (also defined in the input script) and

86
doc/src/Tools.rst
View File

@ -92,6 +92,7 @@ Miscellaneous tools
* :ref:`LAMMPS coding standards <coding_standard>`
* :ref:`emacs <emacs>`
* :ref:`i-PI <ipi>`
* :ref:`JSON support <json>`
* :ref:`kate <kate>`
* :ref:`LAMMPS-GUI <lammps_gui>`
* :ref:`LAMMPS magic patterns for file(1) <magic>`
@ -364,7 +365,7 @@ These tools were provided by Aidan Thompson at Sandia
.. _fep:
fep tool
------------------
--------
The tools/fep directory contains Python scripts useful for
post-processing results from performing free-energy perturbation
@ -379,7 +380,7 @@ See README file in the tools/fep directory.
.. _ipi:
i-PI tool
-------------------
---------
.. versionchanged:: 27June2024
@ -432,6 +433,87 @@ tools/createatoms tool's input file.
----------
.. _json:
JSON support files
------------------
.. versionadded:: 12June2025
The ``tools/json`` directory contains files and tools to support
using `JSON format <https://www.json.org/>`_ files in LAMMPS.
Currently only the :doc:`molecule command <molecule>` supports
files in JSON format directly, but this is planned to be expanded
in the future.
JSON file validation
^^^^^^^^^^^^^^^^^^^^
The JSON syntax is independent of its content, and thus the data in the
file must follow suitable conventions to be correctly parsed during
input. This can be done in a portable fashion using a `JSON schema file
<https://json-schema.org/>`_ (which is in JSON format as well) to define
those conventions. A suitable JSON validator software can then validate
JSON files against the requirements. Validating a particular JSON file
against a schema ensures that both, the syntax *and* the conventions
are followed. This is useful when writing or editing JSON files in a
text editor or when writing a pre-processing script or tool to create
JSON files for a specific purpose in LAMMPS. It **cannot** check
whether the file contents are physically meaningful, though.
One such validator tool is `check-jsonschema
<https://check-jsonschema.readthedocs.io/>`_ which is written in Python
and can be installed using the `pip Python package manager
<https://pypi.org/>`_, best in a virtual environment as shown below (for
a Bourne Shell command line):
.. code-block:: sh
python -m venv validate-json
source validate-json/bin/activate
pip install --upgrade pip
pip install check-jsonschema
To validate a specific JSON file against a provided schema (here for
a :doc:`molecule command file <molecule>` you would then run for example:
.. code-block:: sh
check-jsonschema --schemafile molecule-schema.json tip3p.json
The latest schema files are also maintained and available for download
at https://download.lammps.org/json . This enables validation of JSON
files even if the LAMMPS sources are not locally available. Example:
.. code-block:: sh
check-jsonschema --schemafile https://download.lammps.org/json/molecule-schema.json tip3p.json
JSON file format normalization
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
There are extensions to the strict JSON format that allow for comments
or ignore additional (dangling) commas. The ``reformat-json.cpp`` tool
will read JSON files in relaxed format, but write it out in strict format.
It is also possible to change the level of indentation from -1 (all data
one long line) to any positive integer value. The original file will be
backed up (.bak added to file name) and then overwritten.
Manual compilation (it will be automatically included in the CMake build
if building tools is requested during CMake configuration):
.. code-block:: sh
g++ -I <path/to/lammps/src> -o reformat-json reformat-json.cpp
Usage:
.. parsed-literal::
reformat-json <indent-width> <json-file-1> [<json-file-2> ...]
----------
.. _kate:
kate tool

6
doc/src/atom_style.rst
View File

@ -10,7 +10,7 @@ Syntax
atom_style style args
* style = *amoeba* or *angle* or *atomic* or *body* or *bond* or *charge* or *dielectric* or *dipole* or *dpd* or *edpd* or *electron* or *ellipsoid* or *full* or *line* or *mdpd* or *molecular* or *oxdna* or *peri* or *smd* or *sph* or *sphere* or *bpm/sphere* or *spin* or *tdpd* or *tri* or *template* or *wavepacket* or *hybrid*
* style = *amoeba* or *angle* or *apip* or *atomic* or *body* or *bond* or *charge* or *dielectric* or *dipole* or *dpd* or *edpd* or *electron* or *ellipsoid* or *full* or *line* or *mdpd* or *molecular* or *oxdna* or *peri* or *smd* or *sph* or *sphere* or *bpm/sphere* or *spin* or *tdpd* or *tri* or *template* or *wavepacket* or *hybrid*
.. parsed-literal::
@ -117,6 +117,10 @@ the Additional Information section below.
- *bond* + "angle data"
- :ref:`MOLECULE <PKG-MOLECULE>`
- bead-spring polymers with stiffness
* - *apip*
- *atomic* + apip_lambda, apip_lambda_required, apip_lambda_input, apip_lambda_const, apip_lambda_input_ta, apip_e_fast, apip_e_precise, apip_f_const_lambda, apip_f_dyn_lambda
- :ref:`APIP <PKG-APIP>`
- adaptive-precision interatomic potentials(APIP), see :doc:`APIP howto <Howto_apip>`
* - *atomic*
- tag, type, x, v, f, image, mask
-

17
doc/src/compute_angle_local.rst
View File

@ -53,15 +53,17 @@ The value *eng* is the interaction energy for the angle.
The value *v_name* can be used together with the *set* keyword to
compute a user-specified function of the angle theta. The *name*
specified for the *v_name* value is the name of an :doc:`equal-style variable <variable>` which should evaluate a formula based on a
specified for the *v_name* value is the name of an :doc:`equal-style
variable <variable>` which should evaluate a formula based on a
variable which will store the angle theta. This other variable must
be an :doc:`internal-style variable <variable>` defined in the input
script; its initial numeric value can be anything. It must be an
internal-style variable, because this command resets its value
directly. The *set* keyword is used to identify the name of this
other variable associated with theta.
be an :doc:`internal-style variable <variable>` specified by the *set*
keyword. It is an internal-style variable, because this command
resets its value directly. The internal-style variable does not need
to be defined in the input script (though it can be); if it is not
defined, then the *set* option creates an :doc:`internal-style
variable <variable>` with the specified name.
Note that the value of theta for each angle which stored in the
Note that the value of theta for each angle which is stored in the
internal variable is in radians, not degrees.
As an example, these commands can be added to the bench/in.rhodo
@ -70,7 +72,6 @@ system and output the statistics in various ways:
.. code-block:: LAMMPS
variable t internal 0.0
variable cos equal cos(v_t)
variable cossq equal cos(v_t)*cos(v_t)

19
doc/src/compute_bond_local.rst
View File

@ -64,7 +64,7 @@ All these properties are computed for the pair of atoms in a bond,
whether the two atoms represent a simple diatomic molecule, or are part
of some larger molecule.
.. versionchanged:: TBD
.. versionchanged:: 12Jun2025
The sign of *dx*, *dy*, *dz* is no longer determined by the atom IDs
of the bonded atoms but by their order in the bond list to be
@ -130,13 +130,15 @@ moving apart.
The value *v_name* can be used together with the *set* keyword to
compute a user-specified function of the bond distance. The *name*
specified for the *v_name* value is the name of an :doc:`equal-style variable <variable>` which should evaluate a formula based on a
variable which will store the bond distance. This other variable must
be an :doc:`internal-style variable <variable>` defined in the input
script; its initial numeric value can be anything. It must be an
internal-style variable, because this command resets its value
directly. The *set* keyword is used to identify the name of this
other variable associated with theta.
specified for the *v_name* value is the name of an :doc:`equal-style
variable <variable>` which should evaluate a formula based on a
variable which stores the bond distance. This other variable must be
the :doc:`internal-style variable <variable>` specified by the *set*
keyword. It is an internal-style variable, because this command
resets its value directly. The internal-style variable does not need
to be defined in the input script (though it can be); if it is not
defined, then the *set* option creates an :doc:`internal-style
variable <variable>` with the specified name.
As an example, these commands can be added to the bench/in.rhodo
script to compute the length\ :math:`^2` of every bond in the system and
@ -144,7 +146,6 @@ output the statistics in various ways:
.. code-block:: LAMMPS
variable d internal 0.0
variable dsq equal v_d*v_d
compute 1 all property/local batom1 batom2 btype

43
doc/src/compute_dihedral_local.rst
View File

@ -45,30 +45,31 @@ interactions. The number of datums generated, aggregated across all
processors, equals the number of dihedral angles in the system, modified
by the group parameter as explained below.
The value *phi* (:math:`\phi`) is the dihedral angle, as defined in the diagram
on the :doc:`dihedral_style <dihedral_style>` doc page.
The value *phi* (:math:`\phi`) is the dihedral angle, as defined in
the diagram on the :doc:`dihedral_style <dihedral_style>` doc page.
The value *v_name* can be used together with the *set* keyword to compute a
user-specified function of the dihedral angle :math:`\phi`. The *name*
specified for the *v_name* value is the name of an
:doc:`equal-style variable <variable>` which should evaluate a formula based on
a variable which will store the angle :math:`\phi`. This other variable must
be an :doc:`internal-style variable <variable>` defined in the input
script; its initial numeric value can be anything. It must be an
internal-style variable, because this command resets its value
directly. The *set* keyword is used to identify the name of this
other variable associated with :math:`\phi`.
The value *v_name* can be used together with the *set* keyword to
compute a user-specified function of the dihedral angle :math:`\phi`.
The *name* specified for the *v_name* value is the name of an
:doc:`equal-style variable <variable>` which should evaluate a formula
based on a variable which will store the angle :math:`\phi`. This
other variable must be an :doc:`internal-style variable <variable>`
specified by the *set* keyword. It is an internal-style variable,
because this command resets its value directly. The internal-style
variable does not need to be defined in the input script (though it
can be); if it is not defined, then the *set* option creates an
:doc:`internal-style variable <variable>` with the specified name.
Note that the value of :math:`\phi` for each angle which stored in the internal
variable is in radians, not degrees.
Note that the value of :math:`\phi` for each angle which stored in the
internal variable is in radians, not degrees.
As an example, these commands can be added to the bench/in.rhodo
script to compute the :math:`\cos\phi` and :math:`\cos^2\phi` of every dihedral
angle in the system and output the statistics in various ways:
script to compute the :math:`\cos\phi` and :math:`\cos^2\phi` of every
dihedral angle in the system and output the statistics in various
ways:
.. code-block:: LAMMPS
variable p internal 0.0
variable cos equal cos(v_p)
variable cossq equal cos(v_p)*cos(v_p)
@ -100,10 +101,10 @@ no consistent ordering of the entries within the local vector or array
from one timestep to the next. The only consistency that is
guaranteed is that the ordering on a particular timestep will be the
same for local vectors or arrays generated by other compute commands.
For example, dihedral output from the
:doc:`compute property/local <compute_property_local>` command can be combined
with data from this command and output by the :doc:`dump local <dump>`
command in a consistent way.
For example, dihedral output from the :doc:`compute property/local
<compute_property_local>` command can be combined with data from this
command and output by the :doc:`dump local <dump>` command in a
consistent way.
Here is an example of how to do this:

7
doc/src/compute_msd.rst
View File

@ -49,8 +49,6 @@ proportional to the diffusion coefficient of the diffusing atoms.
The displacement of an atom is from its reference position. This is
normally the original position at the time
the compute command was issued, unless the *average* keyword is set to *yes*\ .
The value of the displacement will be
0.0 for atoms not in the specified compute group.
If the *com* option is set to *yes* then the effect of any drift in
the center-of-mass of the group of atoms is subtracted out before the
@ -111,7 +109,10 @@ distance\ :math:`^2` :doc:`units <units>`.
Restrictions
""""""""""""
Compute *msd* cannot be used with a dynamic group.
Compute *msd* cannot be used with a dynamic group and the number of
atoms in the compute group must not be changed by some fixes like,
for example, :doc:`fix deposit <fix_deposit>` or
:doc:`fix evaporate <fix_evaporate>`.
Related commands
""""""""""""""""

2
doc/src/compute_pair_local.rst
View File

@ -56,7 +56,7 @@ force cutoff distance for that interaction, as defined by the
:doc:`pair_style <pair_style>` and :doc:`pair_coeff <pair_coeff>`
commands.
.. versionchanged:: TBD
.. versionchanged:: 12Jun2025
The sign of *dx*, *dy*, *dz* is no longer determined by the value of
their atom-IDs but by their order in the neighbor list to be

25
doc/src/compute_property_atom.rst
View File

@ -34,6 +34,8 @@ Syntax
i_name, d_name, i2_name[I], d2_name[I],
vfrac, s0, espin, eradius, ervel, erforce,
rho, drho, e, de, cv, buckling,
apip_lambda, apip_lambda_input, apip_e_fast,
apip_e_precise
.. parsed-literal::
@ -70,6 +72,13 @@ Syntax
*i2_name[I]* = Ith column of custom integer array with name
*d2_name[I]* = Ith column of custom floating-point array with name
.. parsed-literal::
APIP package per-atom properties:
*apip_lambda* = switching parameter
*apip_lambda_input* = input used to calculate the switching parameter
*apip_e_fast,apip_e_precise* = potential energies mixed by the adaptive-precision potential
.. parsed-literal::
PERI package per-atom properties:
@ -162,6 +171,22 @@ segment particles and define the end points of each line segment.
*corner2z*, *corner3x*, *corner3y*, *corner3z*, are defined for
triangular particles and define the corner points of each triangle.
The accessible quantities from the :doc:`APIP package <Howto_apip>` are
explained in the doc pages of this package in detail.
In short: *apip_lambda* is the switching parameter :math:`\lambda\in[0,1]`,
that is calculated from *apip_lambda_input* and that mixes the energies
of a fast (*apip_e_fast*) and a precise (*apip_e_precise*) potential
into an adaptive-precision energy.
.. note::
The energy according to the fast and the precise potential are only
computed for the subset of atoms, for which it is required, i.e.,
for an atom :math:`i` with :math:`\lambda_i=1` one does not need
:math:`E_i^\text{precise}` and with :math:`\lambda_i=0` one does
not need :math:`E_i^\text{fast}`.
In addition, the various per-atom quantities listed above for specific
packages are only accessible by this command.

27
doc/src/create_atoms.rst
View File

@ -396,7 +396,7 @@ correct number of particles are inserted, in a perfectly random
fashion. Which lattice sites are selected will change with the number
of processors used.
.. versionadded:: TBD
.. versionadded:: 12Jun2025
The *group* keyword adds the newly created atoms to the named
:doc:`group <group>`. If the group does not yet exist it will be
@ -416,24 +416,23 @@ atom, based on its coordinates. They apply to all styles except
*single*. The *name* specified for the *var* keyword is the name of
an :doc:`equal-style variable <variable>` that should evaluate to a
zero or non-zero value based on one or two or three variables that
will store the *x*, *y*, or *z* coordinates of an atom (one variable per
coordinate). If used, these other variables must be
:doc:`internal-style variables <variable>` defined in the input
script; their initial numeric value can be anything. They must be
internal-style variables, because this command resets their values
directly. The *set* keyword is used to identify the names of these
other variables, one variable for the *x*-coordinate of a created atom,
one for *y*, and one for *z*.
will store the *x*, *y*, or *z* coordinates of an atom (one variable
per coordinate). If used, these other variables must be specified by
the *set* keyword. They are internal-style variable, because this
command resets their values directly. The internal-style variables do
not need to be defined in the input script (though they can be); if
one (or more) is not defined, then the *set* option creates an
:doc:`internal-style variable <variable>` with the specified name.
.. figure:: img/sinusoid.jpg
:figwidth: 50%
:align: right
:target: _images/sinusoid.jpg
When an atom is created, its :math:`(x,y,z)` coordinates become the values for
any *set* variable that is defined. The *var* variable is then
evaluated. If the returned value is 0.0, the atom is not created. If
it is non-zero, the atom is created.
When an atom is about to be created, its :math:`(x,y,z)` coordinates
become the values for any *set* variable that is defined. The *var*
variable is then evaluated. If the returned value is 0.0, the atom is
not created. If it is non-zero, the atom is created.
As an example, these commands can be used in a 2d simulation, to
create a sinusoidal surface. Note that the surface is "rough" due to
@ -456,8 +455,6 @@ converts lattice spacings to distance.
region box block 0 $x 0 $y -0.5 0.5
create_box 1 box
variable xx internal 0.0
variable yy internal 0.0
variable v equal "(0.2*v_y*ylat * cos(v_xx/xlat * 2.0*PI*4.0/v_x) + 0.5*v_y*ylat - v_yy) > 0.0"
create_atoms 1 box var v set x xx set y yy
write_dump all atom sinusoid.lammpstrj

4
doc/src/fix.rst
View File

@ -201,6 +201,7 @@ accelerated styles exist.
* :doc:`append/atoms <fix_append_atoms>` - append atoms to a running simulation
* :doc:`atc <fix_atc>` - initiates a coupled MD/FE simulation
* :doc:`atom/swap <fix_atom_swap>` - Monte Carlo atom type swapping
* :doc:`atom_weight/apip <fix_atom_weight_apip>` - compute atomic load of an :doc:`APIP potential <Howto_apip>` for load balancing
* :doc:`ave/atom <fix_ave_atom>` - compute per-atom time-averaged quantities
* :doc:`ave/chunk <fix_ave_chunk>` - compute per-chunk time-averaged quantities
* :doc:`ave/correlate <fix_ave_correlate>` - compute/output time correlations
@ -270,6 +271,7 @@ accelerated styles exist.
* :doc:`imd <fix_imd>` - implements the "Interactive MD" (IMD) protocol
* :doc:`indent <fix_indent>` - impose force due to an indenter
* :doc:`ipi <fix_ipi>` - enable LAMMPS to run as a client for i-PI path-integral simulations
* :doc:`lambda/apip <fix_lambda_apip>` - compute switching parameter, that controls the precision of an :doc:`APIP potential <Howto_apip>`
* :doc:`langevin <fix_langevin>` - Langevin temperature control
* :doc:`langevin/drude <fix_langevin_drude>` - Langevin temperature control of Drude oscillators
* :doc:`langevin/eff <fix_langevin_eff>` - Langevin temperature control for the electron force field model
@ -278,6 +280,7 @@ accelerated styles exist.
* :doc:`lb/momentum <fix_lb_momentum>` - :doc:`fix momentum <fix_momentum>` replacement for use with a lattice-Boltzmann fluid
* :doc:`lb/viscous <fix_lb_viscous>` - :doc:`fix viscous <fix_viscous>` replacement for use with a lattice-Boltzmann fluid
* :doc:`lineforce <fix_lineforce>` - constrain atoms to move in a line
* :doc:`lambda_thermostat/apip <fix_lambda_thermostat_apip>` - apply energy conserving correction for an :doc:`APIP potential <Howto_apip>`
* :doc:`manifoldforce <fix_manifoldforce>` - restrain atoms to a manifold during minimization
* :doc:`mdi/qm <fix_mdi_qm>` - LAMMPS operates as a client for a quantum code via the MolSSI Driver Interface (MDI)
* :doc:`mdi/qmmm <fix_mdi_qmmm>` - LAMMPS operates as client for QM/MM simulation with a quantum code via the MolSSI Driver Interface (MDI)
@ -292,7 +295,6 @@ accelerated styles exist.
* :doc:`mvv/tdpd <fix_mvv_dpd>` - constant temperature DPD using the modified velocity-Verlet algorithm
* :doc:`neb <fix_neb>` - nudged elastic band (NEB) spring forces
* :doc:`neb/spin <fix_neb_spin>` - nudged elastic band (NEB) spring forces for spins
* :doc:`neighbor/swap <fix_neighbor_swap>` - kinetic Monte Carlo (kMC) atom swapping
* :doc:`nonaffine/displacement <fix_nonaffine_displacement>` - calculate nonaffine displacement of atoms
* :doc:`nph <fix_nh>` - constant NPH time integration via Nose/Hoover
* :doc:`nph/asphere <fix_nph_asphere>` - NPH for aspherical particles

2
doc/src/fix_adapt.rst
View File

@ -440,7 +440,7 @@ this fix uses to reset theta0 needs to generate values in radians.
----------
.. versionadded:: TBD
.. versionadded:: 12Jun2025
The *dihedral* keyword uses the specified variable to change the value of
a dihedral coefficient over time, very similar to how the *angle* keyword

143
doc/src/fix_atom_weight_apip.rst Normal file
View File

@ -0,0 +1,143 @@
.. index:: fix atom_weight/apip
fix atom_weight/apip command
============================
Syntax
""""""
.. code-block:: LAMMPS
fix ID group-ID atom_weight/apip nevery fast_potential precise_potential lambda_input lambda_zone group_lambda_input [no_rescale]
* ID, group-ID are documented in :doc:`fix <fix>` command
* atom_weight/apip = style name of this fix command
* nevery = perform load calculation every this many steps
* fast_potential = *eam* or *ace* for time measurements of the corresponding pair_style or float for constant time
* precise_potential = *ace* for a time measurement of the pair_style pace/apip or float for constant time
* lambda_input = *lambda/input* for a time measurement of pair_style lambda/input/apip or float for constant time
* lambda_zone = *lambda/zone* for a time measurement of pair_style lambda/zone/apip or float for constant time
* group_lambda_input = group-ID of the group for which lambda_input is computed
* no_rescale = do not rescale the work per processor to the measured total force-computation time
Examples
""""""""
.. code-block:: LAMMPS
fix 2 all atom_weight/apip 50 eam ace lambda/input lambda/zone all
fix 2 all atom_weight/apip 50 1e-05 0.0004 4e-06 4e-06 all
fix 2 all atom_weight/apip 50 ace ace 4e-06 4e-06 all no_rescale
Description
"""""""""""
This command approximates the load every atom causes when an
adaptive-precision interatomic potential (APIP) according to
:ref:`(Immel) <Immel2025_2>` is used.
This approximated load can be saved as atomic variable and
used as input for the dynamic load balancing via the
:doc:`fix balance <fix_balance>` command.
An adaptive-precision potential like :doc:`eam/apip <pair_eam_apip>`
and :doc:`pace/apip <pair_pace_apip>` is calculated only
for a subset of atoms.
The switching parameter that determines per atom, which potential energy is
used, can be also calculated by
:doc:`pair_style lambda/input/apip <pair_lambda_input_apip>`.
A spatial switching zone, that ensures a smooth transition between two
different interatomic potentials, can be calculated by
:doc:`pair_style lambda/zone/apip <pair_lambda_zone_apip>`.
Thus, there are up to four force-subroutines, that are computed only for a
subset of atoms and combined via the pair_style :doc:`hybrid/overlay <pair_hybrid>`.
For all four force-subroutines, the average work per atom is be measured
per processor by the corresponding pair_style.
This fix extracts these measurements of the pair styles every *nevery*
steps. The average compute times are used to calculates a per-atom vector with
the approximated atomic weight, whereas the average compute time of the four
subroutines contributes only to the load of atoms, for which the corresponding
subroutine was calculated.
If not disabled via *no_rescale*, the so calculated load is
rescaled per processor so that the total atomic compute time matches the
also measured total compute time of the whole pair_style.
This atomic weight is intended to be used
as input for :doc:`fix balance <fix_balance>`:
.. code-block:: LAMMPS
variable nevery equal 10
fix weight_atom all atom_weight/apip ${nevery} eam ace lambda/input lambda/zone all
variable myweight atom f_weight_atom
fix balance all balance ${nevery} 1.1 rcb weight var myweight
Furthermore, this fix provides the over the processors averaged compute time of the
four pair_styles, which are used to approximate the atomic weight, as vector.
----------
Restart, fix_modify, output, run start/stop, minimize info
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
No information about this fix is written to
:doc:`binary restart files <restart>`. None of the
:doc:`fix_modify <fix_modify>` options are relevant to this fix.
This fix produces a per-atom vector that contains the atomic
weight of each atom.
The per-atom vector can only be accessed on timesteps that are multiples
of *nevery*.
Furthermore, this fix computes a global vector of length 4 with
statistical information about the four different (possibly)
measured compute times per force subroutine. The four
values in the vector are as follows:
#. average compute time for one atom using the fast pair_style
#. average compute time for one atom using the precise pair_style
#. average compute time of lambda/input/apip for one atom
#. average compute time of lambda/zone/apip for one atom
The compute times are computed as average of all processors that
measured at least one computation of the corresponding style.
The vector values calculated by this fix are "intensive" and
updated whenever the per-atom vector is computed, i.e., in
timesteps that are multiples of *nevery*.
The vector and the per-atom vector can be accessed by various
:doc:`output commands <Howto_output>`.
No parameter of this fix can be used with the *start/stop* keywords of
the :doc:`run <run>` command. This fix is not invoked during
:doc:`energy minimization <minimize>`.
----------
Restrictions
""""""""""""
This fix is part of the APIP package. It is only enabled if
LAMMPS was built with that package. See the :doc:`Build package
<Build_package>` page for more info.
Related commands
""""""""""""""""
:doc:`fix balance <fix_balance>`,
:doc:`fix lambda/apip <fix_lambda_apip>`,
:doc:`fix lambda_thermostat/apip <fix_lambda_thermostat_apip>`,
:doc:`pair_style lambda/zone/apip <pair_lambda_zone_apip>`,
:doc:`pair_style lambda/input/apip <pair_lambda_input_apip>`,
:doc:`pair_style eam/apip <pair_eam_apip>`,
:doc:`pair_style pace/apip <pair_pace_apip>`,
Default
"""""""
*no_rescale* is not used by default.
----------
.. _Immel2025_2:
**(Immel)** Immel, Drautz and Sutmann, J Chem Phys, 162, 114119 (2025)

2
doc/src/fix_ave_moments.rst
View File

@ -50,7 +50,7 @@ Examples
Description
"""""""""""
.. versionadded:: TBD
.. versionadded:: 12Jun2025
Using one or more values as input, calculate the moments of the underlying
(population) distributions based on samples collected every few time

100
doc/src/fix_controller.rst
View File

@ -98,52 +98,53 @@ the following dynamic equation:
\frac{dc}{dt} = -\alpha (K_p e + K_i \int_0^t e \, dt + K_d \frac{de}{dt} )
where *c* is the continuous time analog of the control variable,
*e* =\ *pvar*\ -\ *setpoint* is the error in the process variable, and
:math:`\alpha`, :math:`K_p`, :math:`K_i` , and :math:`K_d` are constants
set by the corresponding
keywords described above. The discretized version of this equation is:
where *c* is the continuous time analog of the control variable, *e*
=\ *pvar*\ -\ *setpoint* is the error in the process variable, and
:math:`\alpha`, :math:`K_p`, :math:`K_i` , and :math:`K_d` are
constants set by the corresponding keywords described above. The
discretized version of this equation is:
.. math::
c_n = c_{n-1} -\alpha \left( K_p \tau e_n + K_i \tau^2 \sum_{i=1}^n e_i + K_d (e_n - e_{n-1}) \right)
where :math:`\tau = \mathtt{Nevery} \cdot \mathtt{timestep}` is the time
interval between updates,
and the subscripted variables indicate the values of *c* and *e* at
successive updates.
where :math:`\tau = \mathtt{Nevery} \cdot \mathtt{timestep}` is the
time interval between updates, and the subscripted variables indicate
the values of *c* and *e* at successive updates.
From the first equation, it is clear that if the three gain values
:math:`K_p`, :math:`K_i`, :math:`K_d` are dimensionless constants,
then :math:`\alpha` must have
units of [unit *cvar*\ ]/[unit *pvar*\ ]/[unit time] e.g. [ eV/K/ps
]. The advantage of this unit scheme is that the value of the
constants should be invariant under a change of either the MD timestep
size or the value of *Nevery*\ . Similarly, if the LAMMPS :doc:`unit style <units>` is changed, it should only be necessary to change
the value of :math:`\alpha` to reflect this, while leaving :math:`K_p`,
:math:`K_i`, and :math:`K_d` unaltered.
then :math:`\alpha` must have units of [unit *cvar*\ ]/[unit *pvar*\
]/[unit time] e.g. [ eV/K/ps ]. The advantage of this unit scheme is
that the value of the constants should be invariant under a change of
either the MD timestep size or the value of *Nevery*\ . Similarly, if
the LAMMPS :doc:`unit style <units>` is changed, it should only be
necessary to change the value of :math:`\alpha` to reflect this, while
leaving :math:`K_p`, :math:`K_i`, and :math:`K_d` unaltered.
When choosing the values of the four constants, it is best to first
pick a value and sign for :math:`\alpha` that is consistent with the
magnitudes and signs of *pvar* and *cvar*\ . The magnitude of :math:`K_p`
should then be tested over a large positive range keeping :math:`K_i = K_d =0`.
A good value for :math:`K_p` will produce a fast response in *pvar*,
without overshooting the *setpoint*\ . For many applications, proportional
feedback is sufficient, and so :math:`K_i = K_d =0` can be used. In cases
where there is a substantial lag time in the response of *pvar* to a change
in *cvar*, this can be counteracted by increasing :math:`K_d`. In situations
magnitudes and signs of *pvar* and *cvar*\ . The magnitude of
:math:`K_p` should then be tested over a large positive range keeping
:math:`K_i = K_d =0`. A good value for :math:`K_p` will produce a
fast response in *pvar*, without overshooting the *setpoint*\ . For
many applications, proportional feedback is sufficient, and so
:math:`K_i = K_d =0` can be used. In cases where there is a
substantial lag time in the response of *pvar* to a change in *cvar*,
this can be counteracted by increasing :math:`K_d`. In situations
where *pvar* plateaus without reaching *setpoint*, this can be
counteracted by increasing :math:`K_i`. In the language of Charles Dickens,
:math:`K_p` represents the error of the present, :math:`K_i` the error of
the past, and :math:`K_d` the error yet to come.
counteracted by increasing :math:`K_i`. In the language of Charles
Dickens, :math:`K_p` represents the error of the present, :math:`K_i`
the error of the past, and :math:`K_d` the error yet to come.
Because this fix updates *cvar*, but does not initialize its value,
the initial value :math:`c_0` is that assigned by the user in the input script via
the :doc:`internal-style variable <variable>` command. This value is
used (by every other LAMMPS command that uses the variable) until this
fix performs its first update of *cvar* after *Nevery* timesteps. On
the first update, the value of the derivative term is set to zero,
because the value of :math:`e_{n-1}` is not yet defined.
the initial value :math:`c_0` is that assigned by the user in the
input script via the :doc:`internal-style variable <variable>`
command. This value is used (by every other LAMMPS command that uses
the variable) until this fix performs its first update of *cvar* after
*Nevery* timesteps. On the first update, the value of the derivative
term is set to zero, because the value of :math:`e_{n-1}` is not yet
defined.
----------
@ -154,21 +155,23 @@ must produce a global quantity, not a per-atom or local quantity.
If *pvar* begins with "c\_", a compute ID must follow which has been
previously defined in the input script and which generates a global
scalar or vector. See the individual :doc:`compute <compute>` doc page
for details. If no bracketed integer is appended, the scalar
scalar or vector. See the individual :doc:`compute <compute>` doc
page for details. If no bracketed integer is appended, the scalar
calculated by the compute is used. If a bracketed integer is
appended, the Ith value of the vector calculated by the compute is
used. Users can also write code for their own compute styles and :doc:`add them to LAMMPS <Modify>`.
used. Users can also write code for their own compute styles and
:doc:`add them to LAMMPS <Modify>`.
If *pvar* begins with "f\_", a fix ID must follow which has been
previously defined in the input script and which generates a global
scalar or vector. See the individual :doc:`fix <fix>` page for
details. Note that some fixes only produce their values on certain
timesteps, which must be compatible with when fix controller
references the values, or else an error results. If no bracketed integer
is appended, the scalar calculated by the fix is used. If a bracketed
integer is appended, the Ith value of the vector calculated by the fix
is used. Users can also write code for their own fix style and :doc:`add them to LAMMPS <Modify>`.
references the values, or else an error results. If no bracketed
integer is appended, the scalar calculated by the fix is used. If a
bracketed integer is appended, the Ith value of the vector calculated
by the fix is used. Users can also write code for their own fix style
and :doc:`add them to LAMMPS <Modify>`.
If *pvar* begins with "v\_", a variable name must follow which has been
previously defined in the input script. Only equal-style variables
@ -182,19 +185,21 @@ variable.
The target value *setpoint* for the process variable must be a numeric
value, in whatever units *pvar* is defined for.
The control variable *cvar* must be the name of an :doc:`internal-style variable <variable>` previously defined in the input script. Note
that it is not specified with a "v\_" prefix, just the name of the
variable. It must be an internal-style variable, because this fix
updates its value directly. Note that other commands can use an
equal-style versus internal-style variable interchangeably.
The control variable *cvar* must be the name of an
:doc:`internal-style variable <variable>` previously defined in the
input script. Note that it is not specified with a "v\_" prefix, just
the name of the variable. It must be an internal-style variable,
because this fix updates its value directly. Note that other commands
can use an equal-style versus internal-style variable interchangeably.
----------
Restart, fix_modify, output, run start/stop, minimize info
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
Currently, no information about this fix is written to :doc:`binary restart files <restart>`. None of the :doc:`fix_modify <fix_modify>` options
are relevant to this fix.
Currently, no information about this fix is written to :doc:`binary
restart files <restart>`. None of the :doc:`fix_modify <fix_modify>`
options are relevant to this fix.
This fix produces a global vector with 3 values which can be accessed
by various :doc:`output commands <Howto_output>`. The values can be
@ -211,7 +216,8 @@ variable is in. The vector values calculated by this fix are
"extensive".
No parameter of this fix can be used with the *start/stop* keywords of
the :doc:`run <run>` command. This fix is not invoked during :doc:`energy minimization <minimize>`.
the :doc:`run <run>` command. This fix is not invoked during
:doc:`energy minimization <minimize>`.
Restrictions
""""""""""""

48
doc/src/fix_deposit.rst
View File

@ -225,22 +225,25 @@ rotated configuration of the molecule.
.. versionadded:: 21Nov2023
The *var* and *set* keywords can be used together to provide a criterion
for accepting or rejecting the addition of an individual atom, based on its
coordinates. The *name* specified for the *var* keyword is the name of an
:doc:`equal-style variable <variable>` that should evaluate to a zero or
non-zero value based on one or two or three variables that will store the
*x*, *y*, or *z* coordinates of an atom (one variable per coordinate). If
used, these other variables must be :doc:`internal-style variables
<variable>` defined in the input script; their initial numeric value can be
anything. They must be internal-style variables, because this command
resets their values directly. The *set* keyword is used to identify the
names of these other variables, one variable for the *x*-coordinate of a
created atom, one for *y*, and one for *z*. When an atom is created, its
:math:`(x,y,z)` coordinates become the values for any *set* variable that
is defined. The *var* variable is then evaluated. If the returned value
is 0.0, the atom is not created. If it is non-zero, the atom is created.
For an example of how to use these keywords, see the
The *var* and *set* keywords can be used together to provide a
criterion for accepting or rejecting the addition of an individual
atom, based on its coordinates. The *name* specified for the *var*
keyword is the name of an :doc:`equal-style variable <variable>` that
should evaluate to a zero or non-zero value based on one or two or
three variables that will store the *x*, *y*, or *z* coordinates of an
atom (one variable per coordinate). If used, these other variables
must be :doc:`internal-style variables <variable>` specified by the
*set* keyword. They must be internal-style variables, because this
command resets their values directly. The internal-style variables do
not need to be defined in the input script (though they can be); if
one (or more) is not defined, then the *set* option creates an
:doc:`internal-style variable <variable>` with the specified name.
When an atom is about to be created, its :math:`(x,y,z)` coordinates
become the values for any *set* variable that is defined. The *var*
variable is then evaluated. If the returned value is 0.0, the atom is
not created. If it is non-zero, the atom is created. For an example
of how to use the set/var keywords in a similar context, see the
:doc:`create_atoms <create_atoms>` command.
The *rate* option moves the insertion volume in the z direction (3d)
@ -304,12 +307,13 @@ units of distance or velocity.
Restart, fix_modify, output, run start/stop, minimize info
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
This fix writes the state of the deposition to :doc:`binary restart files <restart>`. This includes information about how many
particles have been deposited, the random number generator seed, the
next timestep for deposition, etc. See the
:doc:`read_restart <read_restart>` command for info on how to re-specify
a fix in an input script that reads a restart file, so that the
operation of the fix continues in an uninterrupted fashion.
This fix writes the state of the deposition to :doc:`binary restart
files <restart>`. This includes information about how many particles
have been deposited, the random number generator seed, the next
timestep for deposition, etc. See the :doc:`read_restart
<read_restart>` command for info on how to re-specify a fix in an
input script that reads a restart file, so that the operation of the
fix continues in an uninterrupted fashion.
.. note::

2
doc/src/fix_gjf.rst
View File

@ -39,7 +39,7 @@ Examples
Description
"""""""""""
.. versionadded:: TBD
.. versionadded:: 12Jun2025
Apply a Langevin thermostat as described in :ref:`(Gronbech-Jensen-2020) <Gronbech-Jensen-2020>`
to a group of atoms which models an interaction with a background

262
doc/src/fix_lambda_apip.rst Normal file
View File

@ -0,0 +1,262 @@
.. index:: fix lambda/apip
fix lambda/apip command
=======================
Syntax
""""""
.. code-block:: LAMMPS
fix ID group-ID lambda/apip thr_lo thr_hi keyword args ...
* ID, group-ID are documented in :doc:`fix <fix>` command
* lambda/apip = style name of this fix command
* thr_lo = value below which :math:`\lambda_i^\text{input}` results in a switching parameter of 1
* thr_hi = value above which :math:`\lambda_i^\text{input}` results in a switching parameter of 0
* zero or one keyword/args pairs may be appended
* keyword = *time_averaged_zone* or *min_delta_lambda* or *lambda_non_group* or *store_atomic_stats* or *dump_atomic_history* or *group_fast* or *group_precise* or *group_ignore_lambda_input*
.. parsed-literal::
*time_averaged_zone* args = cut_lo cut_hi history_len_lambda_input history_len_lambda
cut_lo = distance at which the radial function decreases from 1
cut_hi = distance from which on the radial function is 0
history_len_lambda_input = number of time steps for which lambda_input is averaged
history_len_lambda = number of time steps for which the switching parameter is averaged
*min_delta_lambda* args = delta
delta = value below which changes of the switching parameter are neglected (>= 0)
*lambda_non_group* args = lambda_ng
lambda_ng = *precise* or *fast* or float
*precise* = assign a constant switching parameter of 0 to atoms, that are not in the group specified by group-ID
*fast* = assign a constant switching parameter of 1 to atoms, that are not in the group specified by group-ID
float = assign this constant switching parameter to atoms, that are not in the group specified by group-ID (0 <= float <= 1)
*group_fast* args = group-ID-fast
group-ID-fast = the switching parameter of 1 is used instead of the one computed by lambda_input for atoms in the group specified by group-ID-fast
*group_precise* args = group-ID-precise
group-ID-precise = the switching parameter of 0 is used instead of the one computed by lambda_input for atoms in the group specified by group-ID-precise
*group_ignore_lambda_input* args = group-ID-ignore-lambda-input
group-ID-ignore-lambda-input = the switching parameter of lambda_ng is used instead of the one computed by lambda_input for atoms in the group specified by group-ID-ignore-lambda-input
*store_atomic_stats* args = none
*dump_atomic_history* args = none
Examples
""""""""
.. code-block:: LAMMPS
fix 2 all lambda/apip 3.0 3.5 time_averaged_zone 4.0 12.0 110 110 min_delta_lambda 0.01
fix 2 mobile lambda/apip 3.0 3.5 time_averaged_zone 4.0 12.0 110 110 min_delta_lambda 0.01 group_ignore_lambda_input immobile lambda_non_group fast
Description
"""""""""""
The potential energy :math:`E_i` of an atom :math:`i` of an adaptive-precision
potential according to :ref:`(Immel) <Immel2025_3>` is given by
.. math::
E_i = \lambda_i E_i^\text{(fast)} + (1-\lambda_i) E_i^\text{(precise)},
whereas :math:`E_i^\text{(fast)}` is the potential energy of atom :math:`i`
according to a fast interatomic potential like EAM,
:math:`E_i^\text{(precise)}` is the potential energy according to a precise
interatomic potential such as ACE and :math:`\lambda_i\in[0,1]` is the
switching parameter that decides which potential energy is used.
This fix calculates the switching parameter :math:`\lambda_i` based on the
input provided from :doc:`pair_style lambda/input/apip <pair_lambda_input_apip>`.
The calculation of the switching parameter is described in detail in
:ref:`(Immel) <Immel2025_3>`.
This fix calculates the switching parameter for all atoms in the
:doc:`group <group>`
described by group-ID, while the value of *lambda_non_group* is used
as switching parameter for all other atoms.
First, this fix calculates per atom :math:`i` the time averaged input
:math:`\lambda^\text{input}_{\text{avg},i}` from
:math:`\lambda^\text{input}_{i}`, whereas the number of averaged timesteps
can be set via *time_averaged_zone*.
.. note::
:math:`\lambda^\text{input}_{i}` is calculated by
:doc:`pair_style lambda/input/apip <pair_lambda_input_apip>`, which needs to be included
in the input script as well.
The time averaged input :math:`\lambda^\text{input}_{\text{avg},i}` is then
used to calculate the switching parameter
.. math::
\lambda_{0,i}(t) = f^\text{(cut)} \left(\frac{\lambda_{\text{avg},i}^\text{input}(t) - \lambda_\text{lo}^\text{input}}{\lambda_\text{hi}^\text{input} - \lambda_\text{lo}^\text{input}} \right)\,,
whereas the thresholds :math:`\lambda_\text{hi}^\text{input}`
and :math:`\lambda_\text{lo}^\text{input}` are set by the
values provided as *thr_lo* and *thr_hi* and :math:`f^\text{(cut)}(x)` is a cutoff function
that is 1 for :math:`x\leq 0`, decays from 1 to 0 for :math:`x\in[0,1]`, and
is 0 for :math:`x\geq 1`.
If the *group_precise* argument is used, :math:`\lambda_{0,i}=0` is used for all
atoms :math:`i` assigned to the corresponding :doc:`group <group>`.
If the *group_fast* argument is used, :math:`\lambda_{0,i}=1` is used for all
atoms :math:`i` assigned to the corresponding :doc:`group <group>`.
If an atom is in the groups *group_fast* and *group_precise*,
:math:`\lambda_{0,i}=0` is used.
If the *group_ignore_lambda_input* argument is used,
:math:`\lambda_i^\text{input}` is not computed for all atoms :math:`i` assigned
to the corresponding :doc:`group <group>`; instead, if the value is not already
set by *group_fast* or *group_precise*, the value of *lambda_non_group* is
used.
.. note::
The computation of :math:`\lambda_i^\text{input}` is not required for
atoms that are in the groups *group_fast* and *group_precise*.
Thus, one should use *group_ignore_lambda_input* and prevent the
computation of :math:`\lambda_i^\text{input}` for all atoms, for
which a constant input is used.
A spatial transition zone between the fast and the precise potential is
introduced via
.. math::
\lambda_{\text{min},i}(t) = \text{min}\left(\left\{1 - (1 -\lambda_{0,j}(t)) f^\text{(cut)}\left(\frac{r_{ij}(t)-r_{\lambda,\text{lo}}}{r_{\lambda,\text{hi}} - r_{\lambda,\text{lo}}}\right) : j \in \Omega_{\lambda,i} \right\}\right)\,,
whereas the thresholds :math:`r_{\lambda,\text{lo}}` and
:math:`r_{\lambda,\text{hi}}`
of the cutoff function are set via *time_averaged_zone* and
:math:`\Omega_{\lambda,i}` is the set of
neighboring atoms of atom :math:`i`.
.. note::
:math:`\lambda_{\text{min},i}` is calculated by
:doc:`pair_style lambda/zone/apip <pair_lambda_zone_apip>`, which needs to be included
in the input script as well.
The switching parameter is smoothed by the calculation of the time average
.. math::
\lambda_{\text{avg},i}(t) = \frac{1}{N_{\lambda,\text{avg}}} \sum_{n=1}^{N_{\lambda,\text{avg}}} \lambda_{\text{min},i}(t - n \Delta t)\,,
whereas :math:`\Delta t` is the :doc:`timestep <timestep>` and
:math:`N_{\lambda,\text{avg}}` is the number of averaged timesteps, that
can be set via *time_averaged_zone*.
Finally, numerical fluctuations of the switching parameter are suppressed by the usage of
.. math::
\lambda_{i}(t) = \left\{
\begin{array}{ll}
\lambda_{\text{avg},i}(t) & \text{ for } \left|\lambda_{\text{avg},i}(t) - \lambda_{i}(t-\Delta t)\right|\geq \Delta\lambda_\text{min} \text{ or } \lambda_{\text{avg},i}(t)\in\{0,1\}, \\
\lambda_{i}(t-\Delta t) & \text{ otherwise}\,,
\end{array}
\right.
whereas the minimum change :math:`\Delta\lambda_\text{min}` is set by the
*min_delta_lambda* argument.
.. note::
*group_fast* affects only :math:`\lambda_{0,i}(t)`. The switching parameter
of atoms in this :doc:`group <group>` may change due to the calculation of the
spatial switching zone.
A switching parameter of 1 can be enforced by excluding the corresponding
atoms from the :doc:`group <group>` described by group-ID and using *lambda_non_group* 1
as argument.
----------
A code example for the calculation of the switching parameter for an
adaptive-precision potential is given in the following:
The adaptive-precision potential is created
by combining :doc:`pair_style eam/fs/apip <pair_eam_apip>`
and :doc:`pair_style pace/precise/apip <pair_pace_apip>`.
The input, from which the switching parameter is calculated, is provided
by :doc:`pair lambda/input/csp/apip <pair_lambda_input_apip>`.
The switching parameter is calculated by this fix, whereas the spatial
transition zone of the switching parameter is calculated by
:doc:`pair_style lambda/zone/apip <pair_lambda_zone_apip>`.
.. code-block:: LAMMPS
pair_style hybrid/overlay eam/fs/apip pace/precise/apip lambda/input/csp/apip fcc cutoff 5.0 lambda/zone/apip 12.0
pair_coeff * * eam/fs/apip Cu.eam.fs Cu
pair_coeff * * pace/precise/apip Cu_precise.yace Cu
pair_coeff * * lambda/input/csp/apip
pair_coeff * * lambda/zone/apip
fix 2 all lambda/apip 3.0 3.5 time_averaged_zone 4.0 12.0 110 110 min_delta_lambda 0.01
----------
Restart, fix_modify, output, run start/stop, minimize info
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
The saved history of the switching parameter :math:`\lambda_i`
and the saved history of
:math:`\lambda_i^\text{input}` are written to
:doc:`binary restart files <restart>` allow a smooth restart of a simulation.
None of the :doc:`fix_modify <fix_modify>` options are relevant to this fix.
If the *store_atomic_stats* argument is used, basic statistics is provided as
per-atom array:
#. :math:`\lambda_i^\text{input}(t)`
#. :math:`\lambda_{\text{avg},i}^\text{input}(t)`
#. :math:`\lambda_{0,i}(t)`
#. :math:`\lambda_{\text{min},i}(t)`
#. :math:`\lambda_{i}(t)`
If the *dump_atomic_history* argument is used, the whole saved history
of :math:`\lambda_i^\text{input}(t)` is appended to the previously
mentioned array per atom.
The per-atom vector can be accessed by various
:doc:`output commands <Howto_output>`.
No parameter of this fix can be used with the *start/stop* keywords of
the :doc:`run <run>` command. This fix is not invoked during
:doc:`energy minimization <minimize>`.
----------
Restrictions
""""""""""""
This fix is part of the APIP package. It is only enabled if
LAMMPS was built with that package. See the :doc:`Build package
<Build_package>` page for more info.
Related commands
""""""""""""""""
:doc:`pair_style lambda/zone/apip <pair_lambda_zone_apip>`,
:doc:`pair_style lambda/input/apip <pair_lambda_input_apip>`,
:doc:`pair_style eam/apip <pair_eam_apip>`,
:doc:`pair_style pace/apip <pair_pace_apip>`,
:doc:`fix atom_weight/apip <fix_atom_weight_apip>`
:doc:`fix lambda_thermostat/apip <fix_lambda_thermostat_apip>`,
Default
"""""""
*min_delta_lambda* = 0,
*lambda_non_group* = 1,
*cut_lo* = 4.0,
*cut_hi* = 12.0,
*history_len_lambda_input* = 100,
*history_len_lambda* = 100,
*store_atomic_stats* is not used,
*dump_atomic_history* is not used,
*group_fast* is not used,
*group_precise* is not used,
*group_ignore_lambda_input* is not used
----------
.. _Immel2025_3:
**(Immel)** Immel, Drautz and Sutmann, J Chem Phys, 162, 114119 (2025)

176
doc/src/fix_lambda_thermostat_apip.rst Normal file
View File

@ -0,0 +1,176 @@
.. index:: fix lambda_thermostat/apip
fix lambda_thermostat/apip command
==================================
Syntax
""""""
.. code-block:: LAMMPS
fix ID group-ID lambda_thermostat/apip keyword values ...
* ID, group-ID are documented in :doc:`fix <fix>` command
* lambda_thermostat/apip = style name of this fix command
* zero or more keyword/value pairs may be appended
* keyword = *seed* or *store_atomic_forces* or *N_rescaling*
.. parsed-literal::
*seed* value = integer
integer = integer that is used as seed for the random number generator (> 0)
*store_atomic_forces* value = nevery
nevery = provide per-atom output every this many steps
*N_rescaling* value = groupsize
groupsize = rescale this many neighboring atoms (> 1)
Examples
""""""""
.. code-block:: LAMMPS
fix 2 all lambda_thermostat/apip
fix 2 all lambda_thermostat/apip N_rescaling 100
fix 2 all lambda_thermostat/apip seed 42
fix 2 all lambda_thermostat/apip seed 42 store_atomic_forces 1000
Description
"""""""""""
This command applies the local thermostat described in
:ref:`(Immel) <Immel2025_4>`
to conserve the energy when the switching parameters of an
:doc:`adaptive-precision interatomic potential <Howto_apip>` (APIP)
are updated while the gradient
of the switching parameter is neglected in the force calculation.
.. warning::
The temperature change caused by this fix is only the means to the end of
conserving the energy. Thus, this fix is not a classical thermostat, that
ensures a given temperature in the system.
All available thermostats are listed :doc:`here <Howto_thermostat>`.
The potential energy :math:`E_i` of an atom :math:`i` is given by the formula from
:ref:`(Immel) <Immel2025_4>`
.. math::
E_i = \lambda_i E_i^\text{(fast)} + (1-\lambda_i) E_i^\text{(precise)},
whereas :math:`E_i^\text{(fast)}` is the potential energy of atom :math:`i`
according to a fast interatomic potential like EAM,
:math:`E_i^\text{(precise)}` is the potential energy according to a precise
interatomic potential such as ACE and :math:`\lambda_i\in[0,1]` is the
switching parameter that decides which potential energy is used.
This potential energy and the corresponding forces are conservative when
the switching parameter :math:`\lambda_i` is constant in time for all atoms
:math:`i`.
For a conservative force calculation and dynamic switching parameters,
the atomic force on an atom is given by
:math:`F_i = -\nabla_i \sum_j E_j` and includes the derivative of the switching
parameter :math:`\lambda_i`.
The force contribution of this gradient of the switching function can cause
large forces which are not similar to the forces of the fast or the precise
interatomic potential as discussed in :ref:`(Immel) <Immel2025_4>`.
Thus, one can neglect the gradient of the switching parameter in the force
calculation and compensate for the violation of energy conservation by
the application of the local thermostat implemented in this fix.
One can compute the violation of the energy conservation :math:`\Delta H_i`
for all atoms :math:`i` as discussed in :ref:`(Immel) <Immel2025_4>`.
To locally correct this energy violation :math:`\Delta H_i`, one
can rescale the velocity of atom :math:`i` and of neighboring atoms.
The rescaling is done relative to the center-of-mass velocity of the
group and, thus, conserves the momentum.
.. note::
This local thermostat provides the NVE ensemble rather than the NVT
ensemble as
the energy :math:`\Delta H_i` determines the rescaling factor rather than
a temperature.
Velocities :math:`v` are updated by the integrator according to
:math:`\Delta v_i = (F_i/m_i)\Delta t`, whereas `m` denotes the mass of atom
:math:`i` and :math:`\Delta t` is the time step.
One can interpret the velocity difference :math:`\Delta v` caused by the
rescaling as the application of an additional force which is given by
:math:`F^\text{lt}_i = (v^\text{unscaled}_i - v^\text{rescaled}_i) m_i
/ \Delta t` :ref:`(Immel) <Immel2025_4>`.
This additional force is computed when the *store_atomic_forces* option
is used.
The local thermostat is not appropriate for simulations at a temperature of 0K.
.. note::
The maximum decrease of the kinetic energy is achieved with a rescaling
factor of 0, i.e., the relative velocity of the group of rescaled atoms
is set to zero. One cannot decrease the energy further. Thus, the
local thermostat can fail, which is, however, reported by the returned
vector.
----------
Restart, fix_modify, output, run start/stop, minimize info
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
No information about this fix is written to
:doc:`binary restart files <restart>`. None of the
:doc:`fix_modify <fix_modify>` options are relevant to this fix.
If the *store_atomic_forces* option is used, this fix produces every
*nevery* time steps a per-atom array that contains the theoretical force
applied by the local thermostat in all three spatial dimensions in the first
three components. :math:`\Delta H_i` is the fourth component of the per-atom
array.
The per-atom array can only be accessed on timesteps that are multiples
of *nevery*.
Furthermore, this fix computes a global vector of length 6 with
information about the rescaling:
#. number of atoms whose energy changed due to the last :math:`\lambda` update
#. contribution of the potential energy to the last computed :math:`\Delta H`
#. contribution of the kinetic energy to the last computed :math:`\Delta H`
#. sum over all atoms of the absolute energy change caused by the last rescaling step
#. energy change that could not be compensated accumulated over all timesteps
#. number of atoms whose energy change could not be compensated accumulated over all timesteps
The vector and the per-atom vector can be accessed by various
:doc:`output commands <Howto_output>`.
No parameter of this fix can be used with the *start/stop* keywords of
the :doc:`run <run>` command. This fix is not invoked during
:doc:`energy minimization <minimize>`.
----------
Restrictions
""""""""""""
This fix is part of the APIP package. It is only enabled if
LAMMPS was built with that package. See the :doc:`Build package
<Build_package>` page for more info.
Related commands
""""""""""""""""
:doc:`fix lambda/apip <fix_lambda_apip>`,
:doc:`pair_style lambda/zone/apip <pair_lambda_zone_apip>`,
:doc:`pair_style lambda/input/apip <pair_lambda_input_apip>`,
:doc:`pair_style eam/apip <pair_eam_apip>`,
:doc:`pair_style pace/apip <pair_pace_apip>`,
:doc:`fix atom_weight/apip <fix_atom_weight_apip>`
Default
"""""""
seed = 42, N_rescaling = 200, *store_atomic_forces* is not used
----------
.. _Immel2025_4:
**(Immel)** Immel, Drautz and Sutmann, J Chem Phys, 162, 114119 (2025)

264
doc/src/fix_neighbor_swap.rst
View File

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

2
doc/src/fix_set.rst
View File

@ -27,6 +27,8 @@ Examples
Description
"""""""""""
.. versionadded:: 12Jun2025
Reset one or more properties of one or more atoms once every *Nfreq*
steps during a simulation.

12
doc/src/kspace_style.rst
View File

@ -32,6 +32,7 @@
.. index:: kspace_style msm/cg/omp
.. index:: kspace_style msm/dielectric
.. index:: kspace_style scafacos
.. index:: kspace_style zero
kspace_style command
====================
@ -43,7 +44,7 @@ Syntax
kspace_style style value
* style = *none* or *ewald* or *ewald/dipole* or *ewald/dipole/spin* or *ewald/disp* or *ewald/disp/dipole* or *ewald/omp* or *ewald/electrode* or *pppm* or *pppm/cg* or *pppm/disp* or *pppm/tip4p* or *pppm/stagger* or *pppm/disp/tip4p* or *pppm/gpu* or *pppm/intel* or *pppm/disp/intel* or *pppm/kk* or *pppm/omp* or *pppm/cg/omp* or *pppm/disp/tip4p/omp* or *pppm/tip4p/omp* or *pppm/dielectic* or *pppm/disp/dielectric* or *pppm/electrode* or *pppm/electrode/intel* or *msm* or *msm/cg* or *msm/omp* or *msm/cg/omp* or *msm/dielectric* or *scafacos*
* style = *none* or *ewald* or *ewald/dipole* or *ewald/dipole/spin* or *ewald/disp* or *ewald/disp/dipole* or *ewald/omp* or *ewald/electrode* or *pppm* or *pppm/cg* or *pppm/disp* or *pppm/tip4p* or *pppm/stagger* or *pppm/disp/tip4p* or *pppm/gpu* or *pppm/intel* or *pppm/disp/intel* or *pppm/kk* or *pppm/omp* or *pppm/cg/omp* or *pppm/disp/tip4p/omp* or *pppm/tip4p/omp* or *pppm/dielectic* or *pppm/disp/dielectric* or *pppm/electrode* or *pppm/electrode/intel* or *msm* or *msm/cg* or *msm/omp* or *msm/cg/omp* or *msm/dielectric* or *scafacos* or *zero*
.. parsed-literal::
@ -121,6 +122,7 @@ Syntax
*scafacos* values = method accuracy
method = fmm or p2nfft or p3m or ewald or direct
accuracy = desired relative error in forces
*zero* value = none
Examples
""""""""
@ -132,6 +134,7 @@ Examples
kspace_style msm 1.0e-4
kspace_style scafacos fmm 1.0e-4
kspace_style none
kspace_style zero
Used in input scripts:
@ -375,6 +378,13 @@ other ScaFaCoS options currently exposed to LAMMPS.
----------
.. versionadded:: 12Jun2025
The *zero* style does not do any calculations, but is compatible
with all pair styles that require some version of a kspace style.
----------
The specified *accuracy* determines the relative RMS error in per-atom
forces calculated by the long-range solver. It is set as a
dimensionless number, relative to the force that two unit point

410
doc/src/molecule.rst
View File

@ -34,7 +34,7 @@ Syntax
*ioff* value = Ioff
Ioff = offset to add to improper types
*scale* value = sfactor
sfactor = scale factor to apply to the size and mass of the molecule
sfactor = scale factor to apply to the size, mass, and dipole of the molecule
Examples
""""""""
@ -42,6 +42,7 @@ Examples
.. code-block:: LAMMPS
molecule 1 mymol.txt
molecule water tip3p.json
molecule 1 co2.txt h2o.txt
molecule CO2 co2.txt boff 3 aoff 2
molecule 1 mymol.txt offset 6 9 18 23 14
@ -65,7 +66,7 @@ templates include:
* :doc:`atom_style template <atom_style>`
The ID of a molecule template can only contain alphanumeric characters
and underscores.
and underscores, same as other IDs in LAMMPS.
A single template can contain multiple molecules, listed one per file.
Some of the commands listed above currently use only the first
@ -74,6 +75,13 @@ contains multiple molecules. The :doc:`atom_style template
<atom_style>` command allows multiple-molecule templates to define a
system with more than one templated molecule.
The molecule file can be either in a *native* format or in `JSON format
<https://www.json.org/>`_. JSON formal filenames **must** have the
extension ".json". Files with any other name will be assumed to be in
the "native" format. The details of the two formats are described
below. When referencing multiple molecule files in a single *molecule*
command, each of those files may be either format.
Each filename can be followed by optional keywords which are applied
only to the molecule in the file as used in this template. This is to
make it easy to use the same molecule file in different molecule
@ -95,40 +103,45 @@ use that attribute (e.g. no bonds).
labels will determine the actual types directly depending on the
current :doc:`labelmap <labelmap>` settings.
The *scale* keyword scales the size of the molecule. This can be
useful for modeling polydisperse granular rigid bodies. The scale
factor is applied to each of these properties in the molecule file, if
they are defined: the individual particle coordinates (Coords
section), the individual mass of each particle (Masses section), the
individual diameters of each particle (Diameters section), the total
mass of the molecule (header keyword = mass), the center-of-mass of
the molecule (header keyword = com), and the moments of inertia of the
molecule (header keyword = inertia).
The *scale* keyword scales the size of the molecule. This can be useful
for modeling polydisperse granular rigid bodies. The scale factor is
applied to each of these properties in the molecule file, if they are
defined: the individual particle coordinates (Coords or "coords"
section), the individual mass of each particle (Masses or "masses"
section), the individual diameters of each particle (Diameters or
"diameters" section), the per-atom dipoles (Dipoles or "dipoles"
section) the total mass of the molecule (header keyword = mass), the
center-of-mass of the molecule (header keyword = com), and the moments
of inertia of the molecule (header keyword = inertia).
.. note::
The molecule command can be used to define molecules with bonds,
angles, dihedrals, impropers, or special bond lists of neighbors
angles, dihedrals, impropers, and special bond lists of neighbors
within a molecular topology, so that you can later add the molecules
to your simulation, via one or more of the commands listed above.
Since this topology-related information requires that suitable storage
is reserved when LAMMPS creates the simulation box (e.g. when using
the :doc:`create_box <create_box>` command or the
:doc:`read_data <read_data>` command) suitable space has to be reserved
so you do not overflow those pre-allocated data structures when adding
molecules later. Both the :doc:`create_box <create_box>` command and
the :doc:`read_data <read_data>` command have "extra" options which
ensure space is allocated for storing topology info for molecules that
are added later.
Since this topology-related information requires that suitable
storage is reserved when LAMMPS creates the simulation box (e.g. when
using the :doc:`create_box <create_box>` command or the
:doc:`read_data <read_data>` command) suitable space has to be
reserved at that step so you do not overflow those pre-allocated data
structures when adding molecules later. Both the :doc:`create_box
<create_box>` command and the :doc:`read_data <read_data>` command
have "extra" options which ensure extra space is allocated for
storing topology info for molecules that are added later. This
feature is *not* available for the :doc:`read_restart command
<read_restart>`, thus binary restart files need to be converted
to data files first.
----------
Format of a molecule file
"""""""""""""""""""""""""
Format of a native molecule file
""""""""""""""""""""""""""""""""
The format of an individual molecule file looks similar but is
different than that of a data file read by the :doc:`read_data <read_data>`
commands. Here is a simple example for a TIP3P water molecule:
The format of an "native" individual molecule file looks similar but is
*different* from that of a data file read by the :doc:`read_data
<read_data>` commands. Here is a simple example for a TIP3P water
molecule:
.. code-block::
@ -196,7 +209,7 @@ defining a *body* particle, which requires setting the number of
.. list-table::
:header-rows: 1
:widths: 20 13 42 15
:widths: 21 12 47 20
* - Number(s)
- Keyword
@ -205,7 +218,7 @@ defining a *body* particle, which requires setting the number of
* - N
- atoms
- # of atoms N in molecule
- 0
- keyword is *required*
* - Nb
- bonds
- # of bonds Nb in molecule
@ -228,8 +241,8 @@ defining a *body* particle, which requires setting the number of
- 0
* - Ninteger Ndouble
- body
- # of integer and floating-point values in body particle
- 0
- # of integer and floating-point values in :doc:`body particle <Howto_body>`
- 0 0
* - Mtotal
- mass
- total mass of molecule
@ -669,6 +682,343 @@ the file format.
----------
Format of a JSON molecule file
""""""""""""""""""""""""""""""
.. versionadded:: 12Jun2025
The format of a JSON format individual molecule file must follow the
`JSON format <https://www.json.org/>`_, which evolved from the
JavaScript programming language as a programming-language-neutral data
interchange language. The JSON syntax is independent of its content,
and thus the data in the file must follow suitable conventions to be
correctly processed. LAMMPS provides a `JSON schema file
<https://json-schema.org/>`_ for JSON format molecule files in the
:ref:`tools/json folder <json>` to represent those conventions. Using
the schema file any JSON format molecule files can be validated. Please
note that the format requirement for JSON are very strict and the JSON
reader in LAMMPS does not accept files with extensions like comments.
Validating a particular JSON format molecule file against this schema
ensures that both, the JSON syntax requirement *and* the LAMMPS
conventions for molecule template files are followed. LAMMPS should be
able to read and parse any JSON file that passes the schema check. This
is a formal check only and thus it **cannot** check whether the file
contents are consistent or physically meaningful.
Here is a simple example for the same TIP3P water molecule from above in
JSON format and also using :doc:`type labels <labelmap>` instead of
numeric types:
.. code-block:: json
{
"application": "LAMMPS",
"format": "molecule",
"revision": 1,
"title": "Water molecule. TIP3P geometry",
"schema": "https://download.lammps.org/json/molecule-schema.json",
"units": "real",
"coords": {
"format": ["atom-id", "x", "y", "z"],
"data": [
[1, 0.00000, -0.06556, 0.00000],
[2, 0.75695, 0.52032, 0.00000],
[3, -0.75695, 0.52032, 0.00000]
]
},
"types": {
"format": ["atom-id", "type"],
"data": [
[1, "OW"],
[2, "HO1"],
[3, "HO1"]
]
},
"charges": {
"format": ["atom-id", "charge"],
"data": [
[1, -0.834],
[2, 0.417],
[3, 0.417]
]
},
"bonds": {
"format": ["bond-type", "atom1", "atom2"],
"data": [
["OW-HO1", 1, 2],
["OW-HO1", 1, 3]
]
},
"angles": {
"format": ["angle-type", "atom1", "atom2", "atom3"],
"data": [
["HO1-OW-HO1", 2, 1, 3]
]
}
}
Unlike with the native molecule file format, there are no header or body
sections, just a list of keywords with associated data. JSON format
data is read, parsed, and stored in an internal dictionary data
structure in one step and thus the order of keywords is not relevant.
Data for keywords is either provided directly following the keyword or
as a *data block*. A *data block* is a list that has to include two
keywords, "format" and "data", where the former lists keywords of the
properties that are stored in the columns of the "data" lists. The
names and order of entries in the "format" list (and thus how the data
is interpreted) are currently fixed.
Since the length of the various lists can be easily obtained from the
internal data structure, several header keywords of the "native" molecule
file are not needed. On the other hand, some additional keywords are
required to identify the conventions applied to the generic JSON file
format. The structure of the data itself mostly follows what is used
for the "native" molecule file format.
.. list-table::
:header-rows: 1
* - Keyword
- Argument(s)
- Required
- Description
* - application
- "LAMMPS"
- yes
- indicates a LAMMPS JSON file; files from other applications may be accepted in the future
* - format
- "molecule"
- yes
- indicates a molecule template file
* - revision
- an integer
- yes
- currently 1, to facility backward compatibility on changes to the conventions
* - title
- a string
- no
- information about the template which will echoed to the screen and log
* - schema
- URL as string
- no
- location of a JSON schema file for validating the molecule file format
* - units
- a string
- no
- indicates :doc:`units settings <units>` for this molecule template
* - com
- list with 3 doubles
- no
- overrides the auto-computed center-of-mass for the template
* - masstotal
- double
- no
- overrides the auto-computed total mass for the template
* - inertia
- list with 6 doubles
- no
- overrides the auto-computed moments of inertia
* - coords
- a data block
- no
- contains atom positions with the format "atom-id", "x", "y", "z" (same as Coords)
* - types
- a data block
- yes
- assigns atom types to atoms with the format "atom-id", "type" (same as Types)
* - molecule
- a data block
- no
- assigns molecule-IDs to atoms with the format "atom-id", "molecule-id" (same as Molecules)
* - fragments
- a data block
- no
- assigns atom-ids to fragment-IDs with the format "fragment-id", "atom-id-list" (same as Fragments)
* - charges
- a data block
- no
- assigns charges to atoms with the format "atom-id", "charge" (same as Charges)
* - dipoles
- a data block
- no
- assigns point dipoles to atoms with the format "atom-id", "mux", "muy", "muz" (same as Dipoles)
* - diameters
- a data block
- no
- assigns diameters to atoms with the format "atom-id", "diameter" (same as Diameters)
* - masses
- a data block
- no
- assigns per-atom masses to atoms with the format "atom-id", "mass" (same as Masses)
* - bonds
- a data block
- no
- defines bonds in the molecule template with the format "bond-type", "atom1", "atom2" (same as Bonds without bond-ID)
* - angles
- a data block
- no
- defines angles in the molecule template with the format "angle-type", "atom1", "atom2", "atom3" (same as Angles without angle-ID)
* - dihedrals
- a data block
- no
- defines dihedrals in the molecule template with the format "dihedral-type", "atom1", "atom2", "atom3", "atom4" (same as Dihedrals without dihedral-ID)
* - impropers
- a data block
- no
- defines impropers in the molecule template with the format "improper-type", "atom1", "atom2", "atom3", "atom4" (same as Impropers without improper-ID)
* - shake
- 3 JSON objects
- no
- contains the sub-sections "flags", "atoms", "bonds" described below
* - special
- 2 JSON objects
- no
- contains the sub-sections "counts" and "bonds" described below
* - body
- 2 JSON objects
- no
- contains the "integers" and "doubles" sub-sections with arrays with the same data as Body Integers and Body Doubles, respectively
The following table describes the sub-sections for the "special" entry from above:
.. list-table::
:header-rows: 1
* - Subsection
- Argument(s)
- Required
- Description
* - counts
- a data block
- yes
- contains the counts of 1-2, 1-3, and 1-4 special neighbors with the format "atom-id", "n12", "n13", "n14" (same as Special Bond Counts)
* - bonds
- a data block
- yes
- contains the lists of special neighbors to atoms with the format "atom-id", "atom-id-list" (same as Special Bonds)
The following table describes the sub-sections for the "shake" entry from above:
.. list-table::
:header-rows: 1
* - Subsection
- Argument(s)
- Required
- Description
* - flags
- a data block
- yes
- contains the counts shake flags for atoms with the format "atom-id", "flag" (same as Shake Flags)
* - atoms
- a data block
- yes
- contains the lists of shake cluster atom-ids for atoms with the format "atom-id", "atom-id-list" (same as Shake Atoms)
* - bonds
- a data block
- yes
- contains the lists of shake bond or angle types for atoms with the format "atom-id", "type-list" (same as Shake Bonds)
The "special" and "shake" sections are usually not needed, since the
data can be auto-generated as soon as the simulation box is defined.
Below is an example for what would have to be *added* to the example
JSON file above in case the molecule command needs to be issued earlier.
.. code-block:: json
"special": {
"counts": {
"format": ["atom-id", "n12", "n13", "n14"],
"data": [
[1, 2, 0, 0],
[2, 1, 1, 0],
[3, 1, 1, 0]
]
},
"bonds": {
"format": ["atom-id", "atom-id-list"],
"data": [
[1, [2, 3]],
[2, [1, 3]],
[3, [1, 2]]
]
}
},
"shake": {
"flags": {
"format": ["atom-id", "flag"],
"data": [
[1, 1],
[2, 1],
[3, 1]
]
},
"atoms": {
"format": ["atom-id", "atom-id-list"],
"data": [
[1, [1, 2, 3]],
[2, [1, 2, 3]],
[3, [1, 2, 3]]
]
},
"types": {
"format": ["atom-id", "type-list"],
"data": [
[1, ["OW-HO1", "OW-HO1", "HO1-OW-HO1"]],
[2, ["OW-HO1", "OW-HO1", "HO1-OW-HO1"]],
[3, ["OW-HO1", "OW-HO1", "HO1-OW-HO1"]]
]
}
}
Below is a minimal example of a JSON format molecule template for a body
particle for :doc:`pair style body/nparticle
<pair_body_nparticle>`. Molecule templates for body particles must
contain only one atom:
.. code-block:: json
{
"application": "LAMMPS",
"format": "molecule",
"revision": 1,
"title": "Square body for body/nparticles",
"schema": "https://download.lammps.org/json/molecule-schema.json",
"units": "real",
"coords": {
"format": ["atom-id", "x", "y", "z"],
"data": [
[1, 0.00000, 0.00000, 0.00000]
]
},
"types": {
"format": ["atom-id", "type"],
"data": [
[1, 1]
]
},
"masses": {
"format": ["atom-id", "mass"],
"data": [
[1, 1.0]
]
},
"body": {
"integers": [4],
"doubles": [
1.0, 1.0, 4.0, 0.0, 0.0, 0.0,
-0.70710678118654752440, -0.70710678118654752440, 0.0,
-0.70710678118654752440, 0.70710678118654752440, 0.0,
0.70710678118654752440, 0.70710678118654752440, 0.0,
0.70710678118654752440, -0.70710678118654752440, 0.0
]
}
}
----------
Restrictions
""""""""""""

127
doc/src/pair_eam_apip.rst Normal file
View File

@ -0,0 +1,127 @@
.. index:: pair_style eam/apip
.. index:: pair_style eam/fs/apip
pair_style eam/apip command
=============================
Constant precision variant: *eam*
pair_style eam/fs/apip command
================================
Constant precision variant: *eam/fs*
Syntax
""""""
.. code-block:: LAMMPS
pair_style eam/apip
pair_style eam/fs/apip
Examples
""""""""
.. code-block:: LAMMPS
pair_style hybrid/overlay eam/fs/apip pace/precise/apip lambda/input/csp/apip fcc cutoff 5.0 lambda/zone/apip 12.0
pair_coeff * * eam/fs/apip Cu.eam.fs Cu
pair_coeff * * pace/precise/apip Cu_precise.yace Cu
pair_coeff * * lambda/input/csp/apip
pair_coeff * * lambda/zone/apip
Description
"""""""""""
Style *eam* computes pairwise interactions for metals and metal alloys
using embedded-atom method (EAM) potentials :ref:`(Daw) <Daw2>`. The total
energy :math:`E_i` of an atom :math:`i` is given by
.. math::
E_i^\text{EAM} = F_\alpha \left(\sum_{j \neq i}\ \rho_\beta (r_{ij})\right) +
\frac{1}{2} \sum_{j \neq i} \phi_{\alpha\beta} (r_{ij})
where :math:`F` is the embedding energy which is a function of the atomic
electron density :math:`\rho`, :math:`\phi` is a pair potential interaction,
and :math:`\alpha` and :math:`\beta` are the element types of atoms
:math:`i` and :math:`j`. The multi-body nature of the EAM potential is a
result of the embedding energy term. Both summations in the formula are over
all neighbors :math:`j` of atom :math:`i` within the cutoff distance.
EAM is documented in detail in :doc:`pair_style eam <pair_eam>`.
The potential energy :math:`E_i` of an atom :math:`i` of an adaptive-precision
interatomic potential (APIP) according to :ref:`(Immel) <Immel2025_5>` is given by
.. math::
E_i^\text{APIP} = \lambda_i E_i^\text{(fast)} + (1-\lambda_i) E_i^\text{(precise)}\,,
whereas the switching parameter :math:`\lambda_i` is computed
dynamically during a simulation by :doc:`fix lambda/apip <fix_lambda_apip>`
or set prior to a simulation via :doc:`set <set>`.
The pair style *eam/fs/apip* computes the potential energy
:math:`\lambda_i E_i^\text{EAM}` and the
corresponding force and should be combined
with a precise potential like
:doc:`pair_style pace/precise/apip <pair_pace_apip>` that computes the
potential energy :math:`(1-\lambda_i) E_i^\text{(precise)}` and the
corresponding force via :doc:`pair_style hybrid/overlay <pair_hybrid>`.
Mixing, shift, table, tail correction, restart, rRESPA info
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
For atom type pairs I,J and I != J, where types I and J correspond to
two different element types, mixing is performed by LAMMPS as
described above with the individual styles. You never need to specify
a pair_coeff command with I != J arguments for the eam/apip styles.
This pair style does not support the :doc:`pair_modify <pair_modify>`
shift, table, and tail options.
The eam/apip pair styles do not write their information to :doc:`binary
restart files <restart>`, since it is stored in tabulated potential
files. Thus, you need to re-specify the pair_style and pair_coeff
commands in an input script that reads a restart file.
The eam/apip pair styles can only be used via the *pair* keyword of the
:doc:`run_style respa <run_style>` command. They do not support the
*inner*, *middle*, *outer* keywords.
----------
Restrictions
""""""""""""
This pair styles are part of the APIP package. It is only enabled if
LAMMPS was built with that package. See the :doc:`Build package
<Build_package>` page for more info.
Related commands
""""""""""""""""
:doc:`pair_style eam <pair_eam>`,
:doc:`pair_style hybrid/overlay <pair_hybrid>`,
:doc:`fix lambda/apip <fix_lambda_apip>`,
:doc:`fix lambda_thermostat/apip <fix_lambda_thermostat_apip>`,
:doc:`pair_style lambda/zone/apip <pair_lambda_zone_apip>`,
:doc:`pair_style lambda/input/apip <pair_lambda_input_apip>`,
:doc:`pair_style pace/apip <pair_pace_apip>`,
:doc:`fix atom_weight/apip <fix_atom_weight_apip>`
Default
"""""""
none
----------
.. _Immel2025_5:
**(Immel)** Immel, Drautz and Sutmann, J Chem Phys, 162, 114119 (2025)
.. _Daw2:
**(Daw)** Daw, Baskes, Phys Rev Lett, 50, 1285 (1983).
Daw, Baskes, Phys Rev B, 29, 6443 (1984).

151
doc/src/pair_lambda_input_apip.rst Normal file
View File

@ -0,0 +1,151 @@
.. index:: pair_style lambda/input/apip
.. index:: pair_style lambda/input/csp/apip
pair_style lambda/input/apip command
====================================
Syntax
""""""
.. code-block:: LAMMPS
pair_style lambda/input/apip cutoff
* lambda/input/apip = style name of this pair style
* cutoff = global cutoff (distance units)
pair_style lambda/input/csp/apip command
========================================
Syntax
""""""
.. code-block:: LAMMPS
pair_style lambda/input/csp/apip lattice keyword args
* lambda/input/csp/apip = style name of this pair style
* lattice = *fcc* or *bcc* or integer
.. parsed-literal::
*fcc* = use 12 nearest neighbors to calculate the CSP like in a perfect fcc lattice
*bcc* = use 8 nearest neighbors to calculate the CSP like in a perfect bcc lattice
integer = use N nearest neighbors to calculate the CSP
* zero or more keyword/args pairs may be appended
* keyword = *cutoff* or *N_buffer*
.. parsed-literal::
*cutoff* args = cutoff
cutoff = distance in which neighboring atoms are considered (> 0)
*N_buffer* args = N_buffer
N_buffer = number of additional neighbors, which are included in the j-j+N/2 calculation
Examples
""""""""
.. code-block:: LAMMPS
pair_style lambda/input/csp/apip fcc
pair_style lambda/input/csp/apip fcc cutoff 5.0
pair_style lambda/input/csp/apip bcc cutoff 5.0 N_buffer 2
pair_style lambda/input/csp/apip 14
Description
"""""""""""
This pair_styles calculates :math:`\lambda_i^\text{input}(t)`, which
is required for :doc:`fix lambda/apip <fix_lambda_apip>`.
The pair_style lambda_input sets :math:`\lambda_i^\text{input}(t) = 0`.
The pair_style lambda_input/csp calculates
:math:`\lambda_i^\text{input}(t) = \text{CSP}_i(t)`.
The centro-symmetry parameter (CSP) :ref:`(Kelchner) <Kelchner_2>` is described
in :doc:`compute centro/atom <compute_centro_atom>`.
The lattice argument is described in
:doc:`compute centro/atom <compute_centro_atom>` and determines
the number of neighboring atoms that are used to compute the CSP.
The *N_buffer* argument allows to include more neighboring atoms in
the calculation of the contributions from the pair j,j+N/2 to the CSP as
discussed in :ref:`(Immel) <Immel2025_6>`.
The computation of :math:`\lambda_i^\text{input}(t)` is done by this
pair_style instead of by :doc:`fix lambda/apip <fix_lambda_apip>`, as this computation
takes time and this pair_style can be included in the load-balancing via
:doc:`fix atom_weight/apip <fix_atom_weight_apip>`.
A code example for the calculation of the switching parameter for an adaptive-
precision potential is given in the following:
The adaptive-precision potential is created
by combining :doc:`pair_style eam/fs/apip <pair_eam_apip>`
and :doc:`pair_style pace/precise/apip <pair_pace_apip>`.
The input, from which the switching parameter is calculated, is provided
by this pair_style.
The switching parameter is calculated by :doc:`fix lambda/apip <fix_lambda_apip>`,
whereas the spatial
transition zone of the switching parameter is calculated by
:doc:`pair_style lambda/zone/apip <pair_lambda_zone_apip>`.
.. code-block:: LAMMPS
pair_style hybrid/overlay eam/fs/apip pace/precise/apip lambda/input/csp/apip fcc cutoff 5.0 lambda/zone/apip 12.0
pair_coeff * * eam/fs/apip Cu.eam.fs Cu
pair_coeff * * pace/precise/apip Cu_precise.yace Cu
pair_coeff * * lambda/input/csp/apip
pair_coeff * * lambda/zone/apip
fix 2 all lambda/apip 3.0 3.5 time_averaged_zone 4.0 12.0 110 110 min_delta_lambda 0.01
----------
Mixing, shift, table, tail correction, restart, rRESPA info
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
The cutoff distance for this pair style can be mixed. The default mix
value is *geometric*\ . See the "pair_modify" command for details.
This pair style does not support the :doc:`pair_modify <pair_modify>`
shift, table, and tail options.
This pair style writes no information to :doc:`binary restart files <restart>`, so pair_style and pair_coeff commands need
to be specified in an input script that reads a restart file.
This pair style does not support the use of the *inner*, *middle*,
and *outer* keywords of the :doc:`run_style respa <run_style>` command.
----------
Restrictions
""""""""""""
This fix is part of the APIP package. It is only enabled if
LAMMPS was built with that package. See the :doc:`Build package
<Build_package>` page for more info.
Related commands
""""""""""""""""
:doc:`compute centro/atom <compute_centro_atom>`,
:doc:`fix lambda/apip <fix_lambda_apip>`,
:doc:`fix lambda_thermostat/apip <fix_lambda_thermostat_apip>`,
:doc:`pair_style lambda/zone/apip <pair_lambda_zone_apip>`,
:doc:`pair_style eam/apip <pair_eam_apip>`,
:doc:`pair_style pace/apip <pair_pace_apip>`,
:doc:`fix atom_weight/apip <fix_atom_weight_apip>`
Default
"""""""
N_buffer=0, cutoff=5.0
----------
.. _Kelchner_2:
**(Kelchner)** Kelchner, Plimpton, Hamilton, Phys Rev B, 58, 11085 (1998).
.. _Immel2025_6:
**(Immel)** Immel, Drautz and Sutmann, J Chem Phys, 162, 114119 (2025)

106
doc/src/pair_lambda_zone_apip.rst Normal file
View File

@ -0,0 +1,106 @@
.. index:: pair_style lambda/zone/apip
pair_style lambda/zone/apip command
===================================
Syntax
""""""
.. code-block:: LAMMPS
pair_style lambda/zone/apip cutoff
* lambda/zone/apip = style name of this pair style
* cutoff = global cutoff (distance units)
Examples
""""""""
.. code-block:: LAMMPS
pair_style lambda/zone/apip 12.0
Description
"""""""""""
This pair_style calculates :math:`\lambda_{\text{min},i}`, which
is required for :doc:`fix lambda/apip <fix_lambda_apip>`.
The meaning of :math:`\lambda_{\text{min},i}` is documented in
:doc:`fix lambda/apip <fix_lambda_apip>`, as this pair_style is for use with
:doc:`fix lambda/apip <fix_lambda_apip>` only.
This pair_style requires only the global cutoff as argument.
The remaining quantities, that are required to calculate
:math:`\lambda_{\text{min},i}` are extracted from
:doc:`fix lambda/apip <fix_lambda_apip>` and, thus,
do not need to be passed to this pair_style as arguments.
.. warning::
The cutoff given as argument to this pair style is only relevant for the
neighbor list creation. The radii, which define :math:`r_{\lambda,\text{hi}}` and :math:`r_{\lambda,\text{lo}}` are defined by :doc:`fix lambda/apip <fix_lambda_apip>`.
The computation of :math:`\lambda_{\text{min},i}` is done by this
pair_style instead of by :doc:`fix lambda/apip <fix_lambda_apip>`, as this computation
takes time and this pair_style can be included in the load-balancing via
:doc:`fix atom_weight/apip <fix_atom_weight_apip>`.
A code example for the calculation of the switching parameter for an
adaptive-precision interatomic potential (APIP) is given in the following:
The adaptive-precision potential is created
by combining :doc:`pair_style eam/fs/apip <pair_eam_apip>`
and :doc:`pair_style pace/precise/apip <pair_pace_apip>`.
The input, from which the switching parameter is calculated, is provided
by :doc:`pair lambda/input/csp/apip <pair_lambda_input_apip>`.
The switching parameter is calculated by :doc:`fix lambda/apip <fix_lambda_apip>`,
whereas the spatial transition zone of the switching parameter is calculated
by this pair style.
.. code-block:: LAMMPS
pair_style hybrid/overlay eam/fs/apip pace/precise/apip lambda/input/csp/apip fcc cutoff 5.0 lambda/zone/apip 12.0
pair_coeff * * eam/fs/apip Cu.eam.fs Cu
pair_coeff * * pace/precise/apip Cu_precise.yace Cu
pair_coeff * * lambda/input/csp/apip
pair_coeff * * lambda/zone/apip
fix 2 all lambda/apip 3.0 3.5 time_averaged_zone 4.0 12.0 110 110 min_delta_lambda 0.01
----------
Mixing, shift, table, tail correction, restart, rRESPA info
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
The cutoff distance for this pair style can be mixed. The default mix
value is *geometric*\ . See the "pair_modify" command for details.
This pair style does not support the :doc:`pair_modify <pair_modify>`
shift, table, and tail options.
This pair style writes no information to :doc:`binary restart files <restart>`, so pair_style and pair_coeff commands need
to be specified in an input script that reads a restart file.
This pair style does not support the use of the *inner*, *middle*,
and *outer* keywords of the :doc:`run_style respa <run_style>` command.
----------
Restrictions
""""""""""""
This fix is part of the APIP package. It is only enabled if
LAMMPS was built with that package. See the :doc:`Build package
<Build_package>` page for more info.
Related commands
""""""""""""""""
:doc:`fix lambda/apip <fix_lambda_apip>`,
:doc:`fix atom_weight/apip <fix_atom_weight_apip>`
:doc:`pair_style lambda/input/apip <pair_lambda_input_apip>`,
:doc:`pair_style eam/apip <pair_eam_apip>`,
:doc:`pair_style pace/apip <pair_pace_apip>`,
:doc:`fix lambda_thermostat/apip <fix_lambda_thermostat_apip>`,
Default
"""""""
none

2
doc/src/pair_lj_pirani.rst
View File

@ -27,7 +27,7 @@ Examples
Description
"""""""""""
.. versionadded:: TBD
.. versionadded:: 12Jun2025
Pair style *lj/pirani* computes pairwise interactions from an Improved
Lennard-Jones (ILJ) potential according to :ref:`(Pirani) <Pirani>`.

147
doc/src/pair_pace_apip.rst Normal file
View File

@ -0,0 +1,147 @@
.. index:: pair_style pace/apip
.. index:: pair_style pace/fast/apip
.. index:: pair_style pace/precise/apip
pair_style pace/apip command
============================
pair_style pace/fast/apip command
=================================
pair_style pace/precise/apip command
====================================
Constant precision variant: *pace*
Syntax
""""""
.. code-block:: LAMMPS
pair_style pace/apip ... keyword values ...
pair_style pace/fast/apip ... keyword values ...
pair_style pace/precise/apip ... keyword values ...
* one or more keyword/value pairs may be appended
.. parsed-literal::
keyword = keywords of :doc:`pair pace <pair_pace>`
Examples
""""""""
.. code-block:: LAMMPS
pair_style hybrid/overlay pace/fast/apip pace/precise/apip lambda/input/csp/apip fcc cutoff 5.0 lambda/zone/apip 12.0
pair_coeff * * pace/fast/apip Cu_fast.yace Cu
pair_coeff * * pace/precise/apip Cu_precise.yace Cu
pair_coeff * * lambda/input/csp/apip
pair_coeff * * lambda/zone/apip
pair_style hybrid/overlay eam/fs/apip pace/precise/apip lambda/input/csp/apip fcc cutoff 5.0 lambda/zone/apip 12.0
pair_coeff * * eam/fs/apip Cu.eam.fs Cu
pair_coeff * * pace/precise/apip Cu_precise.yace Cu
pair_coeff * * lambda/input/csp/apip
pair_coeff * * lambda/zone/apip
Description
"""""""""""
Pair style :doc:`pace <pair_pace>` computes interactions using the Atomic
Cluster Expansion (ACE), which is a general expansion of the atomic energy in
multi-body basis functions :ref:`(Drautz19) <Drautz2019_2>`. The *pace*
pair style provides an efficient implementation that is described in
this paper :ref:`(Lysogorskiy21) <Lysogorskiy20211_2>`.
The potential energy :math:`E_i` of an atom :math:`i` of an adaptive-precision
interatomic potential (APIP) according to
:ref:`(Immel25) <Immel2025_7>` is given by
.. math::
E_i^\text{APIP} = \lambda_i E_i^\text{(fast)} + (1-\lambda_i) E_i^\text{(precise)}\,,
whereas the switching parameter :math:`\lambda_i` is computed
dynamically during a simulation by :doc:`fix lambda/apip <fix_lambda_apip>`
or set prior to a simulation via :doc:`set <set>`.
The pair style *pace/precise/apip* computes the potential energy
:math:`(1-\lambda_i) E_i^\text{(pace)}` and the
corresponding force and should be combined
with a fast potential that computes the potential energy
:math:`\lambda_i E_i^\text{(fast)}` and the corresponding force
via :doc:`pair_style hybrid/overlay <pair_hybrid>`.
The pair style *pace/fast/apip* computes the potential energy
:math:`\lambda_i E_i^\text{(pace)}` and the
corresponding force and should be combined
with a precise potential that computes the potential energy
:math:`(1-\lambda_i) E_i^\text{(precise)}` and the corresponding force
via :doc:`pair_style hybrid/overlay <pair_hybrid>`.
The pair_styles *pace/fast/apip* and *pace/precise/apip*
commands may be followed by the optional keywords of
:doc:`pair_style pace <pair_pace>`, which are described
:doc:`here <pair_pace>`.
Mixing, shift, table, tail correction, restart, rRESPA info
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
For atom type pairs I,J and I != J, where types I and J correspond to
two different element types, mixing is performed by LAMMPS with
user-specifiable parameters as described above. You never need to
specify a pair_coeff command with I != J arguments for this style.
This pair styles does not support the :doc:`pair_modify <pair_modify>`
shift, table, and tail options.
This pair styles does not write its information to :doc:`binary restart
files <restart>`, since it is stored in potential files. Thus, you need
to re-specify the pair_style and pair_coeff commands in an input script
that reads a restart file.
This pair styles can only be used via the *pair* keyword of the
:doc:`run_style respa <run_style>` command. It does not support the
*inner*, *middle*, *outer* keywords.
----------
Restrictions
""""""""""""
This pair styles are part of the APIP package. It is only enabled if
LAMMPS was built with that package. See the :doc:`Build package
<Build_package>` page for more info.
Related commands
""""""""""""""""
:doc:`pair_style pace <pair_pace>`,
:doc:`pair_style hybrid/overlay <pair_hybrid>`,
:doc:`fix lambda/apip <fix_lambda_apip>`,
:doc:`fix lambda_thermostat/apip <fix_lambda_thermostat_apip>`,
:doc:`pair_style lambda/zone/apip <pair_lambda_zone_apip>`,
:doc:`pair_style lambda/input/apip <pair_lambda_input_apip>`,
:doc:`pair_style eam/apip <pair_eam_apip>`,
:doc:`fix atom_weight/apip <fix_atom_weight_apip>`
Default
"""""""
See :doc:`pair_style pace <pair_pace>`.
----------
.. _Drautz2019_2:
**(Drautz19)** Drautz, Phys Rev B, 99, 014104 (2019).
.. _Lysogorskiy20211_2:
**(Lysogorskiy21)** Lysogorskiy, van der Oord, Bochkarev, Menon, Rinaldi, Hammerschmidt, Mrovec, Thompson, Csanyi, Ortner, Drautz, npj Comp Mat, 7, 97 (2021).
.. _Immel2025_7:
**(Immel25)** Immel, Drautz and Sutmann, J Chem Phys, 162, 114119 (2025)

8
doc/src/pair_style.rst
View File

@ -188,7 +188,9 @@ accelerated styles exist.
* :doc:`eam/cd <pair_eam>` - concentration-dependent EAM
* :doc:`eam/cd/old <pair_eam>` - older two-site model for concentration-dependent EAM
* :doc:`eam/fs <pair_eam>` - Finnis-Sinclair EAM
* :doc:`eam/fs/apip <pair_eam_apip>` - :doc:`adaptive precision <Howto_apip>` version of FS EAM, used as fast potential
* :doc:`eam/he <pair_eam>` - Finnis-Sinclair EAM modified for Helium in metals
* :doc:`eam/apip <pair_eam_apip>` - :doc:`adaptive-precision <Howto_apip>` version of EAM, used as fast potential
* :doc:`edip <pair_edip>` - three-body EDIP potential
* :doc:`edip/multi <pair_edip>` - multi-element EDIP potential
* :doc:`edpd <pair_mesodpd>` - eDPD particle interactions
@ -217,6 +219,9 @@ accelerated styles exist.
* :doc:`kim <pair_kim>` - interface to potentials provided by KIM project
* :doc:`kolmogorov/crespi/full <pair_kolmogorov_crespi_full>` - Kolmogorov-Crespi (KC) potential with no simplifications
* :doc:`kolmogorov/crespi/z <pair_kolmogorov_crespi_z>` - Kolmogorov-Crespi (KC) potential with normals along z-axis
* :doc:`lambda/input/apip <pair_lambda_input_apip>` - constant as input for the precision calculation of an :doc:`adaptive-precision interatomic potential (APIP) <Howto_apip>`
* :doc:`lambda/input/csp/apip <pair_lambda_input_apip>` - CSP as input for the precision calculation of an :doc:`adaptive-precision interatomic potential (APIP) <Howto_apip>`
* :doc:`lambda/zone/apip <pair_lambda_zone_apip>` - transition zone of an :doc:`adaptive-precision interatomic potential <Howto_apip>`
* :doc:`lcbop <pair_lcbop>` - long-range bond-order potential (LCBOP)
* :doc:`lebedeva/z <pair_lebedeva_z>` - Lebedeva interlayer potential for graphene with normals along z-axis
* :doc:`lennard/mdf <pair_mdf>` - LJ potential in A/B form with a taper function
@ -330,6 +335,9 @@ accelerated styles exist.
* :doc:`oxrna2/xstk <pair_oxrna2>` -
* :doc:`pace <pair_pace>` - Atomic Cluster Expansion (ACE) machine-learning potential
* :doc:`pace/extrapolation <pair_pace>` - Atomic Cluster Expansion (ACE) machine-learning potential with extrapolation grades
* :doc:`pace/apip <pair_pace_apip>` - :doc:`adaptive-precision <Howto_apip>` version of ACE, used as precise potential
* :doc:`pace/fast/apip <pair_pace_apip>` - :doc:`adaptive-precision <Howto_apip>` version of ACE, used as fast potential
* :doc:`pace/precise/apip <pair_pace_apip>` - :doc:`adaptive-precision <Howto_apip>` version of ACE, used as precise potential
* :doc:`pedone <pair_pedone>` - Pedone (PMMCS) potential (non-Coulomb part)
* :doc:`pod <pair_pod>` - Proper orthogonal decomposition (POD) machine-learning potential
* :doc:`peri/eps <pair_peri>` - Peridynamic EPS potential

38
doc/src/plugin.rst
View File

@ -10,16 +10,17 @@ Syntax
plugin command args
* command = *load* or *unload* or *list* or *clear*
* command = *load* or *unload* or *list* or *clear* or *restore*
* args = list of arguments for a particular plugin command
.. parsed-literal::
*load* file = load plugin(s) from shared object in *file*
*unload* style name = unload plugin *name* of style *style*
*style* = *pair* or *bond* or *angle* or *dihedral* or *improper* or *kspace* or *compute* or *fix* or *region* or *command*
*style* = *pair* or *bond* or *angle* or *dihedral* or *improper* or *kspace* or *compute* or *fix* or *region* or *command* or *run* or *min*
*list* = print a list of currently loaded plugins
*clear* = unload all currently loaded plugins
*restore* = restore all loaded plugins
Examples
""""""""
@ -31,6 +32,7 @@ Examples
plugin unload command hello
plugin list
plugin clear
plugin restore
Description
"""""""""""
@ -40,22 +42,46 @@ commands into a LAMMPS binary from so-called dynamic shared object (DSO)
files. This enables to add new functionality to an existing LAMMPS
binary without having to recompile and link the entire executable.
.. admonition:: Plugins are a global, per-executable property
:class: Hint
Unlike most settings in LAMMPS, plugins are a per-executable global
property. Loading a plugin means that it is not only available for
the current LAMMPS instance but for all *future* LAMMPS instances.
After a :doc:`clear <clear>` command, all currently loaded plugins
will be restored and do not need to be loaded again.
When using the library interface or the Python or Fortran module
to create multiple concurrent LAMMPS instances, all plugins should
be loaded by the first created LAMMPS instance as all future instances
will inherit them. To import plugins that were loaded by a different
LAMMPS instance, use the *restore* command.
The *load* command will load and initialize all plugins contained in the
plugin DSO with the given filename. A message with information the
plugin style and name and more will be printed. Individual DSO files
may contain multiple plugins. More details about how to write and
plugin DSO with the given filename. A message with information about
the plugin style and name and more will be printed. Individual DSO
files may contain multiple plugins. If a plugin is already loaded
it will be skipped. More details about how to write and
compile the plugin DSO is given in programmer's guide part of the manual
under :doc:`Developer_plugins`.
The *unload* command will remove the given style or the given name from
the list of available styles. If the plugin style is currently in use,
that style instance will be deleted.
that style instance will be deleted and replaced by the default setting
for that style.
The *list* command will print a list of the loaded plugins and their
styles and names.
The *clear* command will unload all currently loaded plugins.
.. versionadded:: 12Jun2025
The *restore* command will restore all currently loaded plugins.
This allows to "import" plugins into a different LAMMPS instance.
.. admonition:: Automatic loading of plugins
:class: note

635
doc/src/python.rst
View File

@ -10,7 +10,7 @@ Syntax
python mode keyword args ...
* mode = *source* or name of Python function
* mode = *source* or *name* of Python function
if mode is *source*:
@ -18,35 +18,39 @@ Syntax
keyword = *here* or name of a *Python file*
*here* arg = inline
inline = one or more lines of Python code which defines func
inline = one or more lines of Python code which will be executed immediately
must be a single argument, typically enclosed between triple quotes
*Python file* = name of a file with Python code which will be executed immediately
* if *mode* is the name of a Python function, one or more keywords with/without arguments must be appended
* if *mode* is *name* of a Python function:
.. parsed-literal::
one or more keywords with/without arguments must be appended
keyword = *invoke* or *input* or *return* or *format* or *length* or *file* or *here* or *exists*
*invoke* arg = none = invoke the previously defined Python function
*invoke* arg = logreturn (optional)
invoke the previously-defined Python function
if logreturn is specified, print the return value of the invoked function to the screen and logfile
*input* args = N i1 i2 ... iN
N = # of inputs to function
i1,...,iN = value, SELF, or LAMMPS variable name
value = integer number, floating point number, or string
SELF = reference to LAMMPS itself which can be accessed by Python function
variable = v_name, where name = name of LAMMPS variable, e.g. v_abc
SELF = reference to LAMMPS itself which can then be accessed by Python function
variable = v_name, where name = name of a LAMMPS variable, e.g. v_abc
internal variable = iv_name, where name = name of a LAMMPS internal-style variable, e.g. iv_xyz
*return* arg = varReturn
varReturn = v_name = LAMMPS variable name which the return value of the Python function will be assigned to
*format* arg = fstring with M characters
M = N if no return value, where N = # of inputs
M = N+1 if there is a return value
fstring = each character (i,f,s,p) corresponds in order to an input or return value
fstring = each character (i,f,s,p) corresponds (in order) to an input or return value
'i' = integer, 'f' = floating point, 's' = string, 'p' = SELF
*length* arg = Nlen
Nlen = max length of string returned from Python function
*file* arg = filename
filename = file of Python code, which defines func
filename = file of Python code, which defines the Python function
*here* arg = inline
inline = one or more lines of Python code which defines func
inline = one or more lines of Python code which defines the Python function
must be a single argument, typically enclosed between triple quotes
*exists* arg = none = Python code has been loaded by previous python command
@ -56,7 +60,7 @@ Examples
.. code-block:: LAMMPS
python pForce input 2 v_x 20.0 return v_f format fff file force.py
python pForce invoke
python pForce invoke logreturn
python factorial input 1 myN return v_fac format ii here """
def factorial(n):
@ -87,75 +91,149 @@ Examples
Description
"""""""""""
The *python* command allows interfacing LAMMPS with an embedded Python
interpreter and enables either executing arbitrary python code in that
interpreter, registering a Python function for future execution (as a
python style variable, from a fix interfaced with python, or for direct
invocation), or invoking such a previously registered function.
The *python* command interfaces LAMMPS with an embedded Python
interpreter and enables executing arbitrary python code in that
interpreter. This can be done immediately, by using *mode* = *source*.
Or execution can be deferred, by registering a Python function for later
execution, by using *mode* = *name* of a Python function.
Arguments, including LAMMPS variables, can be passed to the function
from the LAMMPS input script and a value returned by the Python function
assigned to a LAMMPS variable. The Python code for the function can be included
directly in the input script or in a separate Python file. The function
can be standard Python code or it can make "callbacks" to LAMMPS through
its library interface to query or set internal values within LAMMPS.
This is a powerful mechanism for performing complex operations in a
LAMMPS input script that are not possible with the simple input script
and variable syntax which LAMMPS defines. Thus your input script can
operate more like a true programming language.
Later execution can be triggered in one of two ways. One is to use the
python command again with its *invoke* keyword. The other is to trigger
the evaluation of a python-style, equal-style, vector-style, or
atom-style variable. A python-style variable invokes its associated
Python function; its return value becomes the value of the python-style
variable. Equal-, vector-, and atom-style variables can use a Python
function wrapper in their formulas which encodes the python-style
variable name, and specifies arguments (which themselves can be numeric
formulas) to pass to the Python function associated with the
python-style variable.
As explained on the :doc:`variable <variable>` doc page, the definition
of a python-style variable associates a Python function name with the
variable. Its specification must match the *mode* argument of the
*python* command for the Python function name. For example these two
commands would be consistent:
.. code-block:: LAMMPS
variable foo python myMultiply
python myMultiply return v_foo format f file funcs.py
The two commands can appear in either order in the input script so long
as both are specified before the Python function is invoked for the
first time.
Note that python-style, equal-style, vector-style, and atom-style
variables can be used in many different ways within LAMMPS. They can be
evaluated directly in an input script, effectively replacing the
variable with its value. Or they can be passed to various commands as
arguments, so that the variable is evaluated multiple times during a
simulation run. See the :doc:`variable <variable>` command doc page for
more details on variable styles which enable Python function evaluation.
The Python code for a Python function can be included directly in the
input script or in a separate Python file. The function can be standard
Python code or it can make "callbacks" to LAMMPS through its library
interface to query or set internal values within LAMMPS. This is a
powerful mechanism for performing complex operations in a LAMMPS input
script that are not possible with the simple input script and variable
syntax which LAMMPS defines. Thus your input script can operate more
like a true programming language.
Use of this command requires building LAMMPS with the PYTHON package
which links to the Python library so that the Python interpreter is
embedded in LAMMPS. More details about this process are given below.
There are two ways to invoke a Python function once it has been
registered. One is using the *invoke* keyword. The other is to assign
the function to a :doc:`python-style variable <variable>` defined in
your input script. Whenever the variable is evaluated, it will execute
the Python function to assign a value to the variable. Note that
variables can be evaluated in many different ways within LAMMPS. They
can be substituted with their result directly in an input script, or
they can be passed to various commands as arguments, so that the
variable is evaluated during a simulation run.
A broader overview of how Python can be used with LAMMPS is given in the
:doc:`Use Python with LAMMPS <Python_head>` section of the
documentation. There also is an ``examples/python`` directory which
documentation. There is also an ``examples/python`` directory which
illustrates use of the python command.
----------
The first argument of the *python* command is either the *source*
keyword or the name of a Python function. This defines the mode
of the python command.
The first argument to the *python* command is the *mode* setting, which
is either *source* or the *name* of a Python function.
.. versionchanged:: 22Dec2022
If the *source* keyword is used, it is followed by either a file name or
the *here* keyword. No other keywords can be used. The *here* keyword
is followed by a string with python commands, either on a single line
enclosed in quotes, or as multiple lines enclosed in triple quotes.
These Python commands will be passed to the python interpreter and
executed immediately without registering a Python function for future
execution. The code will be loaded into and run in the "main" module of
the Python interpreter. This allows running arbitrary Python code at
any time while processing the LAMMPS input file. This can be used to
pre-load Python modules, initialize global variables, define functions
or classes, or perform operations using the python programming language.
The Python code will be executed in parallel on all MPI processes. No
arguments can be passed.
If *source* is used, it is followed by either the *here* keyword or a
file name containing Python code. The *here* keyword is followed by a
single *inline* argument which is a string containing one or more python
commands. The string can either be on the same line as the *python*
command, enclosed in quotes, or it can be multiple lines enclosed in
triple quotes.
In all other cases, the first argument is the name of a Python function
that will be registered with LAMMPS for future execution. The function
may already be defined (see *exists* keyword) or must be defined using
the *file* or *here* keywords as explained below.
In either case, the in-line code or the file contents are passed to the
python interpreter and executed immediately. The code will be loaded
into and run in the "main" module of the Python interpreter. This
allows running arbitrary Python code at any time while processing the
LAMMPS input file. This can be used to pre-load Python modules,
initialize global variables, define functions or classes, or perform
operations using the Python programming language. The Python code will
be executed in parallel on all the MPI processes being used to run
LAMMPS. Note that no arguments can be passed to the executed Python
code.
If the *invoke* keyword is used, no other keywords can be used, and a
If the *mode* setting is the *name* of a Python function, then it will
be registered with LAMMPS for future execution (or can already be
defined, see the *exists* keyword). One or more keywords must follow
the *mode* function name. One of the keywords must be *invoke*, *file*,
*here*, or *exists*, which specifies what Python code to load into the
Python interpreter. Note that only one of those 4 keywords is allowed
since their operations are mutually exclusive.
----------
If the *invoke* keyword is used, no other keywords can be used. A
previous *python* command must have registered the Python function
referenced by this command. This invokes the Python function with the
previously defined arguments and the return value is processed as
explained below. You can invoke the function as many times as you wish
in your input script.
referenced by this command, which can then be invoked multiple times in
an input script via the *invoke* keyword. Each invocation passes
current values for arguments to the Python function. A return value of
the Python function will be ignored unless the Python function is linked
to a :doc:`python style variable <variable>` with the *return* keyword.
This return value can be logged to the screen and logfile by adding the
optional *logreturn* argument to the *invoke* keyword. In that case a
message with the name of the python command and the return value is
printed. Note that return values of python functions are otherwise
*only* accessible when the function is invoked indirectly by evaluating
its associated :doc:`python style variable <variable>`, as described
below.
The *file* keyword gives the name of a file containing Python code,
which should end with a ".py" suffix. The code will be immediately
loaded into and run in the "main" module of the Python interpreter. The
Python code will be executed in parallel on all MPI processes. Note
that Python code which contains a function definition does NOT "execute"
the function when it is run; it simply defines the function so that it
can be invoked later.
The *here* keyword does the same thing, except that the Python code
follows as a single argument to the *here* keyword. This can be done
using triple quotes as delimiters, as in the examples above and below.
This allows Python code to be listed verbatim in your input script, with
proper indentation, blank lines, and comments, as desired. See the
:doc:`Commands parse <Commands_parse>` doc page, for an explanation of
how triple quotes can be used as part of input script syntax.
The *exists* keyword takes no argument. It simply means that Python
code containing the needed Python function has already been loaded into
the LAMMPS Python interpreter, for example by previous *python source*
command or in a file that was loaded previously with the *file*
keyword. This allows use of a single file of Python code which contains
multiple functions, any of which can be used in the same (or different)
input scripts (see below).
Note that the Python code that is loaded and run by the *file* or *here*
keyword must contain a function with the specified function *name*. To
operate properly when the function is later invoked, the code for the
function must match the *input* and *return* and *format* keywords
specified by the python command. Otherwise Python will generate an
error.
----------
The other keywords which can be used with the *python* command are
*input*, *return*, *format*, and *length*.
The *input* keyword defines how many arguments *N* the Python function
expects. If it takes no arguments, then the *input* keyword should not
@ -169,35 +247,63 @@ itself using the :doc:`LAMMPS Python module <Python_module>`. This
enables the function to call back to LAMMPS through its library
interface as explained below. This allows the Python function to query
or set values internal to LAMMPS which can affect the subsequent
execution of the input script. A LAMMPS variable can also be used as an
argument, specified as v_name, where "name" is the name of the variable.
Any style of LAMMPS variable returning a scalar or a string can be used,
as defined by the :doc:`variable <variable>` command. The *format*
keyword must be used to set the type of data that is passed to Python.
Each time the Python function is invoked, the LAMMPS variable is
evaluated and its value is passed to the Python function.
execution of the input script.
A LAMMPS variable can also be used as an *input* argument, specified as
v_name, where "name" is the name of the variable defined in the input
script. Any style of LAMMPS variable returning a scalar or a string can
be used, as defined by the :doc:`variable <variable>` command. The
style of variable must be consistent with the *format* keyword
specification for the type of data that is passed to Python. Each time
the Python function is invoked, the LAMMPS variable is evaluated and its
value is passed as an argument to the Python function. Note that a
python-style variable can be used as an argument, which means that the a
Python function can use arguments which invoke other Python functions.
A LAMMPS internal-style variable can also be used as an *input*
argument, specified as iv_name, where "name" is the name of the
internal-style variable. The internal-style variable does not have to
be defined in the input script (though it can be); if it is not defined,
this command creates an :doc:`internal-style variable <variable>` with
the specified name.
An internal-style variable must be used when an equal-style,
vector-style, or atom-style variable triggers the invocation of the
Python function defined by this command, by including a Python function
wrapper with arguments in its formula. Each of the arguments must be
specified as an internal-style variable via the *input* keyword.
In brief, the syntax for a Python function wrapper in a variable formula
is ``py_varname(arg1,arg2,...argN)``, where "varname" is the name of a
python-style variable associated with a Python function defined by this
command. One or more arguments to the function wrapper can themselves
be sub-formulas which the variable command will evaluate and pass as
arguments to the Python function. This is done by assigning the numeric
result for each argument to an internal-style variable; thus the *input*
keyword must specify the arguments as internal-style variables and their
format (see below) as "f" for floating point. This is because LAMMPS
variable formulas are calculated with floating point arithmetic (any
integer values are converted to floating point). Note that the Python
function can also have additional inputs, also specified by the *input*
keyword, which are NOT arguments in the Python function wrapper. See
the example below for the ``mixedargs`` Python function.
See the :doc:`variable <variable>` command doc page for full details on
formula syntax including for Python function wrappers. Examples using
Python function wrappers are shown below. Note that as explained above
with python-style variables, Python function wrappers can be nested; a
sub-formula for an argument can contain its own Python function wrapper
which invokes another Python function.
The *return* keyword is only needed if the Python function returns a
value. The specified *varReturn* must be of the form v_name, where
"name" is the name of a python-style LAMMPS variable, defined by the
value. The specified *varReturn* is of the form v_name, where "name" is
the name of a python-style LAMMPS variable, defined by the
:doc:`variable <variable>` command. The Python function can return a
numeric or string value, as specified by the *format* keyword.
As explained on the :doc:`variable <variable>` doc page, the definition
of a python-style variable associates a Python function name with the
variable. This must match the *Python function name* first argument of
the *python* command. For example these two commands would be
consistent:
.. code-block:: LAMMPS
variable foo python myMultiply
python myMultiply return v_foo format f file funcs.py
The two commands can appear in either order in the input script so
long as both are specified before the Python function is invoked for
the first time. Afterwards, the variable 'foo' is associated with
the Python function 'myMultiply'.
numeric or string value, as specified by the *format* keyword. This
return value is *only* accessible when its associated python-style
variable is evaluated. When the *invoke* keyword is used, the return
value of the python function is ignored unless the optional *logreturn*
argument is specified.
The *format* keyword must be used if the *input* or *return* keywords
are used. It defines an *fstring* with M characters, where M = sum of
@ -214,47 +320,16 @@ but only if the output of the Python function is flagged as a numeric
value ("i" or "f") via the *format* keyword.
If the *return* keyword is used and the *format* keyword specifies the
output as a string, then the default maximum length of that string is
63 characters (64-1 for the string terminator). If you want to return
a longer string, the *length* keyword can be specified with its *Nlen*
value set to a larger number (the code allocates space for Nlen+1 to
include the string terminator). If the Python function generates a
output as a string, then the default maximum length of that string is 63
characters (64-1 for the string terminator). If you want to return a
longer string, the *length* keyword can be specified with its *Nlen*
value set to a larger number. LAMMPS will then allocate Nlen+1 space to
include the string terminator. If the Python function generates a
string longer than the default 63 or the specified *Nlen*, it will be
truncated.
----------
Either the *file*, *here*, or *exists* keyword must be used, but only
one of them. These keywords specify what Python code to load into the
Python interpreter. The *file* keyword gives the name of a file
containing Python code, which should end with a ".py" suffix. The code
will be immediately loaded into and run in the "main" module of the
Python interpreter. The Python code will be executed in parallel on all
MPI processes. Note that Python code which contains a function
definition does not "execute" the function when it is run; it simply
defines the function so that it can be invoked later.
The *here* keyword does the same thing, except that the Python code
follows as a single argument to the *here* keyword. This can be done
using triple quotes as delimiters, as in the examples above. This
allows Python code to be listed verbatim in your input script, with
proper indentation, blank lines, and comments, as desired. See the
:doc:`Commands parse <Commands_parse>` doc page, for an explanation of
how triple quotes can be used as part of input script syntax.
The *exists* keyword takes no argument. It means that Python code
containing the required Python function with the given name has already
been executed, for example by a *python source* command or in the same
file that was used previously with the *file* keyword.
Note that the Python code that is loaded and run must contain a function
with the specified function name. To operate properly when later
invoked, the function code must match the *input* and *return* and
*format* keywords specified by the python command. Otherwise Python
will generate an error.
----------
This section describes how Python code can be written to work with
LAMMPS.
@ -275,16 +350,16 @@ keyword once to load several functions, and the *exists* keyword
thereafter in subsequent python commands to register the other functions
that were previously loaded with LAMMPS.
A Python function you define (or more generally, the code you load)
can import other Python modules or classes, it can make calls to other
A Python function you define (or more generally, the code you load) can
import other Python modules or classes, it can make calls to other
system functions or functions you define, and it can access or modify
global variables (in the "main" module) which will persist between
successive function calls. The latter can be useful, for example, to
prevent a function from being invoke multiple times per timestep by
different commands in a LAMMPS input script that access the returned
python-style variable associated with the function. For example,
consider this function loaded with two global variables defined
outside the function:
consider this function loaded with two global variables defined outside
the function:
.. code-block:: python
@ -308,32 +383,33 @@ previous value is simply returned, without re-computing it. The
"global" statement inside the Python function allows it to overwrite the
global variables from within the local context of the function.
Note that if you load Python code multiple times (via multiple python
commands), you can overwrite previously loaded variables and functions
if you are not careful. E.g. if the code above were loaded twice, the
global variables would be re-initialized, which might not be what you
want. Likewise, if a function with the same name exists in two chunks
of Python code you load, the function loaded second will override the
function loaded first.
Also note that if you load Python code multiple times (via multiple
python commands), you can overwrite previously loaded variables and
functions if you are not careful. E.g. if the code above were loaded
twice, the global variables would be re-initialized, which might not be
what you want. Likewise, if a function with the same name exists in two
chunks of Python code you load, the function loaded second will override
the function loaded first.
It's important to realize that if you are running LAMMPS in parallel,
each MPI task will load the Python interpreter and execute a local
copy of the Python function(s) you define. There is no connection
between the Python interpreters running on different processors.
This implies three important things.
each MPI task will load the Python interpreter and execute a local copy
of the Python function(s) you define. There is no connection between
the Python interpreters running on different processors. This implies
three important things.
First, if you put a print or other statement creating output to the
screen in your Python function, you will see P copies of the output,
when running on P processors. If the prints occur at (nearly) the same
time, the P copies of the output may be mixed together. When loading
the LAMMPS Python module into the embedded Python interpreter, it is
possible to pass the pointer to the current LAMMPS class instance and
via the Python interface to the LAMMPS library interface, it is possible
to determine the MPI rank of the current process and thus adapt the
Python code so that output will only appear on MPI rank 0. The
following LAMMPS input demonstrates how this could be done. The text
'Hello, LAMMPS!' should be printed only once, even when running LAMMPS
in parallel.
time, the P copies of the output may be mixed together.
It is possible to avoid this issue, by passing the pointer to the
current LAMMPS class instance to the Python function via the {input}
SELF argument described above. The Python function can then use the
Python interface to the LAMMPS library interface, and determine the MPI
rank of the current process. The Python code can then ensure output
will only appear on MPI rank 0. The following LAMMPS input demonstrates
how this could be done. The text 'Hello, LAMPS!' should be printed only
once, even when running LAMMPS in parallel.
.. code-block:: LAMMPS
@ -348,27 +424,26 @@ in parallel.
python python_hello invoke
If your Python code loads Python modules that are not pre-loaded by the
Python library, then it will load the module from disk. This may be a
bottleneck if 1000s of processors try to load a module at the same time.
On some large supercomputers, loading of modules from disk by Python may
be disabled. In this case you would need to pre-build a Python library
that has the required modules pre-loaded and link LAMMPS with that
library.
Second, if your Python code loads Python modules that are not pre-loaded
by the Python library, then it will load the module from disk. This may
be a bottleneck if 1000s of processors try to load a module at the same
time. On some large supercomputers, loading of modules from disk by
Python may be disabled. In this case you would need to pre-build a
Python library that has the required modules pre-loaded and link LAMMPS
with that library.
Third, if your Python code calls back to LAMMPS (discussed in the
next section) and causes LAMMPS to perform an MPI operation requires
global communication (e.g. via MPI_Allreduce), such as computing the
global temperature of the system, then you must ensure all your Python
Third, if your Python code calls back to LAMMPS (discussed in the next
section) and causes LAMMPS to perform an MPI operation requires global
communication (e.g. via MPI_Allreduce), such as computing the global
temperature of the system, then you must ensure all your Python
functions (running independently on different processors) call back to
LAMMPS. Otherwise the code may hang.
----------
Your Python function can "call back" to LAMMPS through its
library interface, if you use the SELF input to pass Python
a pointer to LAMMPS. The mechanism for doing this in your
Python function is as follows:
As mentioned above, a Python function can "call back" to LAMMPS through
its library interface, if the SELF input is used to pass Python a
pointer to LAMMPS. The mechanism for doing this is as follows:
.. code-block:: python
@ -393,15 +468,15 @@ appeared in your input script. In this case, LAMMPS should output
Hello from inside Python
to the screen and log file. Note that since the LAMMPS print command
itself takes a string in quotes as its argument, the Python string
must be delimited with a different style of quotes.
itself takes a string in quotes as its argument, the Python string must
be delimited with a different style of quotes.
The :doc:`Python_head` page describes the syntax
for how Python wraps the various functions included in the LAMMPS
library interface.
The :doc:`Python_head` page describes the syntax for how Python wraps
the various functions included in the LAMMPS library interface.
A more interesting example is in the ``examples/python/in.python`` script
which loads and runs the following function from ``examples/python/funcs.py``:
A more interesting example is in the ``examples/python/in.python``
script which loads and runs the following function from
``examples/python/funcs.py``:
.. code-block:: python
@ -416,7 +491,7 @@ which loads and runs the following function from ``examples/python/funcs.py``:
lmp.set_variable("cut",cut) # set a variable in LAMMPS
lmp.command("pair_style lj/cut ${cut}") # LAMMPS command
#lmp.command("pair_style lj/cut %d" % cut) # LAMMPS command option
#lmp.command("pair_style lj/cut %d" % cut) # alternate form of LAMMPS command
lmp.command("pair_coeff * * 1.0 1.0") # ditto
lmp.command("run 10") # ditto
@ -432,51 +507,160 @@ with these input script commands:
python loop invoke
This has the effect of looping over a series of 10 short runs (10
timesteps each) where the pair style cutoff is increased from a value
of 1.0 in distance units, in increments of 0.1. The looping stops
when the per-atom potential energy falls below a threshold of -4.0 in
energy units. More generally, Python can be used to implement a loop
with complex logic, much more so than can be created using the LAMMPS
timesteps each) where the pair style cutoff is increased from a value of
1.0 in distance units, in increments of 0.1. The looping stops when the
per-atom potential energy falls below a threshold of -4.0 in energy
units. More generally, Python can be used to implement a loop with
complex logic, much more so than can be created using the LAMMPS
:doc:`jump <jump>` and :doc:`if <if>` commands.
Several LAMMPS library functions are called from the loop function.
Get_natoms() returns the number of atoms in the simulation, so that it
can be used to normalize the potential energy that is returned by
extract_compute() for the "thermo_pe" compute that is defined by
default for LAMMPS thermodynamic output. Set_variable() sets the
value of a string variable defined in LAMMPS. This library function
is a useful way for a Python function to return multiple values to
LAMMPS, more than the single value that can be passed back via a
return statement. This cutoff value in the "cut" variable is then
substituted (by LAMMPS) in the pair_style command that is executed
next. Alternatively, the "LAMMPS command option" line could be used
in place of the 2 preceding lines, to have Python insert the value
into the LAMMPS command string.
extract_compute() for the "thermo_pe" compute that is defined by default
for LAMMPS thermodynamic output. Set_variable() sets the value of a
string variable defined in LAMMPS. This library function is a useful
way for a Python function to return multiple values to LAMMPS, more than
the single value that can be passed back via a return statement. This
cutoff value in the "cut" variable is then substituted (by LAMMPS) in
the pair_style command that is executed next. Alternatively, the
"alternate form of LAMMPS command" line could be used in place of the 2
preceding lines, to have Python insert the value into the LAMMPS command
string.
.. note::
When using the callback mechanism just described, recognize that
there are some operations you should not attempt because LAMMPS cannot
execute them correctly. If the Python function is invoked between
runs in the LAMMPS input script, then it should be OK to invoke any
LAMMPS input script command via the library interface command() or
file() functions, so long as the command would work if it were
executed in the LAMMPS input script directly at the same point.
there are some operations you should not attempt because LAMMPS
cannot execute them correctly. If the Python function is invoked
between runs in the LAMMPS input script, then it should be OK to
invoke any LAMMPS input script command via the library interface
command() or file() functions, so long as the command would work if
it were executed in the LAMMPS input script directly at the same
point.
However, a Python function can also be invoked during a run, whenever
an associated LAMMPS variable it is assigned to is evaluated. If the
variable is an input argument to another LAMMPS command (e.g. :doc:`fix setforce <fix_setforce>`), then the Python function will be invoked
inside the class for that command, in one of its methods that is
invoked in the middle of a timestep. You cannot execute arbitrary
input script commands from the Python function (again, via the
command() or file() functions) at that point in the run and expect it
to work. Other library functions such as those that invoke computes
or other variables may have hidden side effects as well. In these
cases, LAMMPS has no simple way to check that something illogical is
being attempted.
The same applies to Python functions called during a simulation run at
each time step using :doc:`fix python/invoke <fix_python_invoke>`.
----------
As noted above, a Python function can be invoked during a run, whenever
an associated python-style variable it is assigned to is evaluated.
If the variable is an input argument to another LAMMPS command
(e.g. :doc:`fix setforce <fix_setforce>`), then the Python function will
be invoked inside the class for that command, possibly in one of its
methods that is invoked in the middle of a timestep. You cannot execute
arbitrary input script commands from the Python function (again, via the
command() or file() functions) at that point in the run and expect it to
work. Other library functions such as those that invoke computes or
other variables may have hidden side effects as well. In these cases,
LAMMPS has no simple way to check that something illogical is being
attempted.
The same constraints apply to Python functions called during a
simulation run at each time step using the :doc:`fix python/invoke
<fix_python_invoke>` command.
----------
As noted above, a Python function can also be invoked within the formula
for an equal-style, vector-style, or atom-style variable. This means
the Python function will be invoked whenever that variable is invoked.
In the case of a vector-style variable, the Python function can be
invoked once per element of the global vector. In the case of an
atom-style variable, the Python function can be invoked once per atom.
Here are three simple examples using equal-, vector-, and atom-style
variables to trigger execution of a Python function:
.. code-block:: LAMMPS
variable foo python truncate
python truncate return v_foo input 1 iv_arg format fi here """
def truncate(x):
return int(x)
"""
variable ptrunc equal py_foo(press)
print "TRUNCATED pressure = ${ptrunc}"
The Python ``truncate`` function simply converts a floating-point value
to an integer value. When the LAMMPS print command evaluates the
equal-style ``ptrunc`` variable, the current thermodynamic pressure is
passed to the Python function. The truncated value is output to the
screen and logfile by the print command. Note that the *input* keyword
for the *python* command, specifies an internal-style variable named
"arg" as iv_arg which is required to invoke the Python function from a
Python function wrapper.
The last 2 lines can be replaced by these to define a vector-style
variable which invokes the same Python ``truncate`` function:
.. code-block:: LAMMPS
compute ke all temp
variable ke vector c_ke
variable ketrunc vector py_foo(v_ke)
thermo_style custom step temp epair v_ketrunc[*6]
The vector-style variable ``ketrunc`` invokes the Python ``truncate``
function on each of the 6 components of the global kinetic energy tensor
calculated by the :doc:`compute ke <compute_ke>` command. The 6
truncated values will be printed with thermo output to the screen and
log file.
Or the last 2 lines of the equal-style variable example can be replaced
by these to define atom-style variables which invoke the same Python
``truncate`` function:
.. code-block:: LAMMPS
variable xtrunc atom py_foo(x)
variable ytrunc atom py_foo(y)
variable ztrunc atom py_foo(z)
dump 1 all custom 100 tmp.dump id x y z v_xtrunc v_ytrunc v_ztrunc
When the dump command invokes the 3 atom-style variables, their
arguments x,y,z to the Python function wrapper are the current per-atom
coordinates of each atom. The Python ``truncate`` function is thus
invoked 3 times for each atom, and the truncated coordinate values for
each atom are written to the dump file.
Note that when using a Python function wrapper in a variable, arguments
can be passed to the Python function either from the variable formula or
by *input* keyword to the :doc:`python command <python>`. For example,
consider these (made up) commands:
.. code-block:: LAMMPS
variable foo python mixedargs
python mixedargs return v_foo input 6 7.5 v_myValue iv_arg1 iv_argy iv_argz v_flag &
format fffffsf here """
def mixedargs(a,b,x,y,z,flag):
...
return result
"""
variable flag string optionABC
variable myValue equal "2.0*temp*c_pe"
compute pe all pe
compute peatom all pe/atom
variable field atom py_foo(x+3.0,sqrt(y),(z-zlo)*c_peatom)
They define a Python ``mixedargs`` function with 6 arguments. Three of
them are internal-style variables, which the variable formula calculates
as numeric values for each atom and passes to the function. In this
example, these arguments are themselves small formulas containing the
x,y,z coordinates of each atom as well as a per-atom compute (c_peratom)
and thermodynamic keyword (zlo).
The other three arguments ``(7.5,v_myValue,v_flag)`` are defined by the
*python* command. The first and last are constant values ("7.5" and the
``optionABC`` string). The second argument (``myValue``) is the result
of an equal-style variable formula which accesses the system temperature
and potential energy.
The "result" returned by each invocation of the Python ``mixedargs``
function becomes the per-atom value in the atom-style "field" variable,
which could be output to a dump file or used elsewhere in the input
script.
----------
@ -485,12 +669,11 @@ interactively or by using Python to launch a Python script stored in a
file, and your code has an error, you will typically see informative
error messages. That is not the case when you run Python code from
LAMMPS using an embedded Python interpreter. The code will typically
fail silently. LAMMPS will catch some errors but cannot tell you
where in the Python code the problem occurred. For example, if the
Python code cannot be loaded and run because it has syntax or other
logic errors, you may get an error from Python pointing to the
offending line, or you may get one of these generic errors from
LAMMPS:
fail silently. LAMMPS will catch some errors but cannot tell you where
in the Python code the problem occurred. For example, if the Python
code cannot be loaded and run because it has syntax or other logic
errors, you may get an error from Python pointing to the offending line,
or you may get one of these generic errors from LAMMPS:
.. parsed-literal::
@ -504,16 +687,16 @@ you will typically get this generic error from LAMMPS:
Python function evaluation failed
Here are three suggestions for debugging your Python code while
running it under LAMMPS.
Here are three suggestions for debugging your Python code while running
it under LAMMPS.
First, don't run it under LAMMPS, at least to start with! Debug it
using plain Python. Load and invoke your function, pass it arguments,
check return values, etc.
Second, add Python print statements to the function to check how far
it gets and intermediate values it calculates. See the discussion
above about printing from Python when running in parallel.
Second, add Python print statements to the function to check how far it
gets and intermediate values it calculates. See the discussion above
about printing from Python when running in parallel.
Third, use Python exception handling. For example, say this statement
in your Python function is failing, because you have not initialized the
@ -523,8 +706,7 @@ variable foo:
foo += 1
If you put one (or more) statements inside a "try" statement,
like this:
If you put one (or more) statements inside a "try" statement, like this:
.. code-block:: python
@ -563,13 +745,15 @@ If you use Python code which calls back to LAMMPS, via the SELF input
argument explained above, there is an extra step required when building
LAMMPS. LAMMPS must also be built as a shared library and your Python
function must be able to load the :doc:`"lammps" Python module
<Python_module>` that wraps the LAMMPS library interface. These are the
same steps required to use Python by itself to wrap LAMMPS. Details on
these steps are explained on the :doc:`Python <Python_head>` doc page.
Note that it is important that the stand-alone LAMMPS executable and the
LAMMPS shared library be consistent (built from the same source code
files) in order for this to work. If the two have been built at
different times using different source files, problems may occur.
<Python_module>` that wraps the LAMMPS library interface.
These are the same steps required to use Python by itself to wrap
LAMMPS. Details on these steps are explained on the :doc:`Python
<Python_head>` doc page. Note that it is important that the stand-alone
LAMMPS executable and the LAMMPS shared library be consistent (built
from the same source code files) in order for this to work. If the two
have been built at different times using different source files,
problems may occur.
Another limitation of calling back to Python from the LAMMPS module
using the *python* command in a LAMMPS input is that both, the Python
@ -583,7 +767,8 @@ global variables will become invisible.
Related commands
""""""""""""""""
:doc:`shell <shell>`, :doc:`variable <variable>`, :doc:`fix python/invoke <fix_python_invoke>`
:doc:`shell <shell>`, :doc:`variable <variable>`,
:doc:`fix python/invoke <fix_python_invoke>`
Default
"""""""

3
doc/src/read_dump.rst
View File

@ -16,12 +16,13 @@ Syntax
.. parsed-literal::
field = *x* or *y* or *z* or *vx* or *vy* or *vz* or *q* or *ix* or *iy* or *iz* or *fx* or *fy* or *fz*
field = *x* or *y* or *z* or *vx* or *vy* or *vz* or *q* or *ix* or *iy* or *iz* or *fx* or *fy* or *fz* or *apip_lambda*
*x*,\ *y*,\ *z* = atom coordinates
*vx*,\ *vy*,\ *vz* = velocity components
*q* = charge
*ix*,\ *iy*,\ *iz* = image flags in each dimension
*fx*,\ *fy*,\ *fz* = force components
*apip_lambda* = switching parameter of an :doc:`adaptive-precision interatomic potential <Howto_apip>`
* zero or more keyword/value pairs may be appended
* keyword = *nfile* or *box* or *timestep* or *replace* or *purge* or *trim* or *add* or *label* or *scaled* or *wrapped* or *format*

15
doc/src/set.rst
View File

@ -23,8 +23,8 @@ Syntax
* one or more keyword/value pairs may be appended
* keyword = *angle* or *angmom* or *bond* or *cc* or *charge* or
*density* or *density/disc* or *diameter* or *dihedral* or *dipole*
* keyword = *angle* or *angmom* or *apip/lambda* or *bond* or *cc* or *charge*
or *density* or *density/disc* or *diameter* or *dihedral* or *dipole*
or *dipole/random* or *dpd/theta* or *edpd/cv* or *edpd/temp* or
*epsilon* or *image* or *improper* or *length* or *mass* or *mol* or
*omega* or *quat* or *quat/random* or *radius/electron* or *shape* or
@ -41,6 +41,10 @@ Syntax
*angmom* values = Lx Ly Lz
Lx,Ly,Lz = components of angular momentum vector (distance-mass-velocity units)
any of Lx,Ly,Lz can be an atom-style variable (see below)
*apip/lambda* value = fast or precise or float
fast = switching parameter of fast potential (1)
precise = switching parameter of fast potential (0)
float = constant float or atom-style variable (between 0 and 1)
*bond* value = numeric bond type or bond type label, for all bonds between selected atoms
*cc* values = index cc
index = index of a chemical species (1 to Nspecies)
@ -632,6 +636,13 @@ atoms.
Keywords *x*, *y*, *z* set the coordinates of all selected atoms.
Keyword *apip/lambda* sets the switching parameter of an
adaptive-precision interatomic potential (:doc:`APIP <Howto_apip>`).
The precise potential is used for an atom when its switching parameter
:math:`\lambda` is 0. The fast potential is used for an atom when its
switching parameter :math:`\lambda` is 1. Both potentials are partially
used for :math:`\lambda\in(0,1)`.
Keywords *i_name*, *d_name*, *i2_name*, *d2_name* refer to custom
per-atom integer and floating-point vectors or arrays that have been
added via the :doc:`fix property/atom <fix_property_atom>` command.

190
doc/src/variable.rst
View File

@ -45,7 +45,8 @@ Syntax
*universe* args = one or more strings
*world* args = one string for each partition of processors
*equal* or *vector* or *atom* args = one formula containing numbers, thermo keywords, math operations, built-in functions, atom values and vectors, compute/fix/variable references
*equal* or *vector* or *atom* args = one formula containing numbers, thermo keywords,
math operations, built-in functions, atom values and vectors, compute/fix/variable references
numbers = 0.0, 100, -5.4, 2.8e-4, etc
constants = PI, version, on, off, true, false, yes, no
thermo keywords = vol, ke, press, etc from :doc:`thermo_style <thermo_style>`
@ -67,8 +68,13 @@ Syntax
bound(group,dir,region), gyration(group,region), ke(group,reigon),
angmom(group,dim,region), torque(group,dim,region),
inertia(group,dimdim,region), omega(group,dim,region)
special functions = sum(x), min(x), max(x), ave(x), trap(x), slope(x), sort(x), rsort(x), gmask(x), rmask(x), grmask(x,y), next(x), is_file(name), is_os(name), extract_setting(name), label2type(kind,label), is_typelabel(kind,label), is_timeout()
feature functions = is_available(category,feature), is_active(category,feature), is_defined(category,id)
special functions = sum(x), min(x), max(x), ave(x), trap(x), slope(x), sort(x), rsort(x),
gmask(x), rmask(x), grmask(x,y), next(x), is_file(name), is_os(name),
extract_setting(name), label2type(kind,label),
is_typelabel(kind,label), is_timeout()
feature functions = is_available(category,feature), is_active(category,feature),
is_defined(category,id)
python function wrapper = py_varname(x,y,z,...)
atom value = id[i], mass[i], type[i], mol[i], x[i], y[i], z[i], vx[i], vy[i], vz[i], fx[i], fy[i], fz[i], q[i]
atom vector = id, mass, type, mol, radius, q, x, y, z, vx, vy, vz, fx, fy, fz
custom atom property = i_name, d_name, i_name[i], d_name[i], i2_name[i], d2_name[i], i2_name[i][j], d2_name[i][j]
@ -127,18 +133,21 @@ command), or used as input to an averaging fix (see the :doc:`fix
ave/time <fix_ave_time>` command). Variables of style *vector* store
a formula which produces a vector of such values which can be used as
input to various averaging fixes, or elements of which can be part of
thermodynamic output. Variables of style *atom* store a formula which
when evaluated produces one numeric value per atom which can be output
to a dump file (see the :doc:`dump custom <dump>` command) or used as
input to an averaging fix (see the :doc:`fix ave/chunk
<fix_ave_chunk>` and :doc:`fix ave/atom <fix_ave_atom>` commands).
Variables of style *atomfile* can be used anywhere in an input script
that atom-style variables are used; they get their per-atom values
from a file rather than from a formula. Variables of style *python*
can be hooked to Python functions using code you provide, so that the
variable gets its value from the evaluation of the Python code.
Variables of style *internal* are used by a few commands which set
their value directly.
thermodynamic output.
Variables of style *atom* store a formula which when evaluated
produces one numeric value per atom which can be output to a dump file
(see the :doc:`dump custom <dump>` command) or used as input to an
averaging fix (see the :doc:`fix ave/chunk <fix_ave_chunk>` and
:doc:`fix ave/atom <fix_ave_atom>` commands). Variables of style
*atomfile* can be used anywhere in an input script that atom-style
variables are used; they get their per-atom values from a file rather
than from a formula.
Variables of style *python* can be hooked to Python functions using
Python code you provide, so that the variable gets its value from the
evaluation of the Python code. Variables of style *internal* are used
by a few commands which set their value directly.
.. note::
@ -166,15 +175,16 @@ simulation.
.. note::
When an input script line is encountered that defines a variable
of style *equal* or *vector* or *atom* or *python* that contains a
formula or Python code, the formula is NOT immediately evaluated. It
will be evaluated every time when the variable is **used** instead. If
you simply want to evaluate a formula in place you can use as
so-called. See the section below about "Immediate Evaluation of
Variables" for more details on the topic. This is also true of a
*format* style variable since it evaluates another variable when it is
invoked.
When an input script line is encountered that defines a variable of
style *equal* or *vector* or *atom* or *python* that contains a
formula or links to Python code, the formula or Python code is NOT
immediately evaluated. Instead, it is evaluated each time the
variable is **used**. If you simply want to evaluate a formula in
place you can use a so-called immediate variable. as described in
the preceding note. Or see the section below about "Immediate
Evaluation of Variables" for more details on the topic. This is
also true of a *format* style variable since it evaluates another
variable when it is invoked.
Variables of style *equal* and *vector* and *atom* can be used as
inputs to various other commands which evaluate their formulas as
@ -183,12 +193,12 @@ this context, variables of style *timer* or *internal* or *python* can
be used in place of an equal-style variable, with the following two
caveats.
First, internal-style variables can be used except by commands that
set the value stored by the internal variable. When the LAMMPS
command evaluates the internal-style variable, it will use the value
set (internally) by another command. Second, python-style variables
can be used so long as the associated Python function, as defined by
the :doc:`python <python>` command, returns a numeric value. When the
First, internal-style variables require their values be set by code
elsewhere in LAMMPS. When a LAMMPS input script or command evaluates
an internal-style variable, it must have a current value set
(internally) via that mechanism. Second, python-style variables can
be used so long as the associated Python function, as defined by the
:doc:`python <python>` command, returns a numeric value. When the
LAMMPS command evaluates the python-style variable, the Python
function will be executed.
@ -388,13 +398,24 @@ using the :doc:`command-line switch -var <Run_options>`.
For the *internal* style a numeric value is provided. This value will
be assigned to the variable until a LAMMPS command sets it to a new
value. There are currently only two LAMMPS commands that require
*internal* variables as inputs, because they reset them:
:doc:`create_atoms <create_atoms>` and :doc:`fix controller
<fix_controller>`. As mentioned above, an internal-style variable can
be used in place of an equal-style variable anywhere else in an input
script, e.g. as an argument to another command that allows for
equal-style variables.
value.
Note however, that most commands which use internal-style variables do
not require them to be defined in the input script. They create one or
more internal-style variables if they do not already exist. Examples
are these commands:
* :doc:`create_atoms <create_atoms>`
* :doc:`fix deposit <fix_deposit>`
* :doc:`compute bond/local <compute_bond_local>`
* :doc:`compute angle/local <compute_angle_local>`
* :doc:`compute dihedral/local <compute_dihedral_local>`
* :doc:`python <python>` command in conjunction with Python function wrappers used in equal- and atom-style variable formulas
A command which does require an internal-style variable to be defined in
the input script is the :doc:`fix controller <fix_controller>` command,
because another (arbitrary) command typically also references the
variable.
----------
@ -439,6 +460,15 @@ python-style variable can be used in place of an equal-style variable
anywhere in an input script, e.g. as an argument to another command
that allows for equal-style variables.
A python-style variable can also be used within the formula for an
equal-style or atom-style formula in a Python function wrapper, as
explained below for variable formulas. In this context, the usage
syntax is py_varname(arg1,arg2,...), where varname is the name of the
python-style variable. When a Python wrapper function is used in an
atom-style formula, it can be invoked once per atom using arguments
specific to each atom. The resulting values in the atom-style
variable can thus be calculated by Python code.
----------
For the *string* style, a single string is assigned to the variable.
@ -528,9 +558,9 @@ is a valid (though strange) variable formula:
Specifically, a formula can contain numbers, constants, thermo
keywords, math operators, math functions, group functions, region
functions, special functions, feature functions, atom values, atom
vectors, custom atom properties, compute references, fix references, and references to other
variables.
functions, special functions, feature functions, Python function
wrappers, atom values, atom vectors, custom atom properties, compute
references, fix references, and references to other variables.
+------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Number | 0.2, 100, 1.0e20, -15.4, etc |
@ -551,6 +581,8 @@ variables.
+------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Feature functions | is_available(category,feature), is_active(category,feature), is_defined(category,id) |
+------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Python func wrapper | py_varname(x,y,z,...) |
+------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Atom values | id[i], mass[i], type[i], mol[i], x[i], y[i], z[i], vx[i], vy[i], vz[i], fx[i], fy[i], fz[i], q[i] |
+------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Atom vectors | id, mass, type, mol, x, y, z, vx, vy, vz, fx, fy, fz, q |
@ -1161,6 +1193,84 @@ variable name.
----------
Python Function wrapper
------------------------
A Python function wrapper enables the formula for an equal-style or
atom-style variable to invoke functions coded in Python. In the case
of an equal-style variable, the Python-coded function will be invoked
once. In the case of an atom-style variable, it can be invoked once
per atom, if one or more of its arguments include a per-atom quantity,
e.g. the position of an atom. As illustrated below, the reason to use
a Python function wrapper is to make it easy to pass LAMMPS-related
arguments to the Python-coded function associated with a python-style
variable.
The syntax for defining a Python function wrapper is
.. code-block:: LAMMPS
py_varname(arg1,arg2,...argN)
where *varname* is the name of a python-style variable which couples
to a Python-coded function. The function will be passed the zero or
more arguments listed in parentheses: *arg1*, *arg2*, ... *argN*. As
with Math Functions, each argument can itself be an arbitrarily
complex formula.
A Python function wrapper can be used in the following manner by an
input script:
.. code-block:: LAMMPS
variable foo python truncate
python truncate return v_foo input 1 v_arg format fi here """
def truncate(x):
return int(x)
"""
variable xtrunc atom py_foo(x)
variable ytrunc atom py_foo(y)
variable ztrunc atom py_foo(z)
dump 1 all custom 100 tmp.dump id x y z v_xtrunc v_ytrunc v_ztrunc
The first two commands define a python-style variable *foo* and couple
it to the Python-coded function *truncate()* which takes a single
floating point argument, and returns its truncated integer value. In
this case, the Python code for truncate() is included in the *python*
command; it could also be contained in a file. See the :doc:`python
<python>` command doc page for details.
The next three commands define atom-style variables *xtrunc*,
*ytrunc*, and *ztrunc*. Each of them include the same Python function
wrapper in their formula, with a different argument. The atom-style
variable *xtrunc* will invoke the python-style variable *foo*, which
will in turn invoke the Python-coded *truncate()* method. Because
*xtrunc* is an atom-style variable, and the argument *x* in the Python
function wrapper is a per-atom quantity (the x-coord of each atom),
each processor will invoke the *truncate()* method once per atom, for
the atoms it owns.
When invoked for the Ith atom, the value of the *arg* internal-style
variable, defined by the *python* command, is set to the x-coord of
the Ith atom. The call via python-style variable *foo* to the Python
*truncate()* function passes the value of the *arg* variable as the
function's first (and only) argument. Likewise, the return value of
the Python function is stored by the python-style variable *foo* and
used in the *xtrunc* atom-style variable formula for the Ith atom.
The resulting per-atom vector for *xtrunc* will thus contain the
truncated x-coord of every atom in the system. The dump command
includes the truncated xyz coords for each atom in its output.
See the :doc:`python <python>` command for more details on options the
*python* command can specify as well as examples of more complex Python
functions which can be wrapped in this manner. In particular, the
Python function can take a variety of arguments, some generated by the
*python* command, and others by the arguments of the Python function
wrapper.
----------
Atom Values and Vectors
-----------------------

2
doc/utils/requirements.txt
View File

@ -2,6 +2,7 @@ Sphinx >= 5.3.0, <8.3.0
sphinxcontrib-spelling
sphinxcontrib-jquery
sphinx-design
sphinx-toolbox
git+https://github.com/akohlmey/sphinx-fortran@parallel-read
sphinx-tabs>=3.4.1
breathe
@ -10,3 +11,4 @@ six
pyyaml
linkchecker
ipython
numpy

12
doc/utils/sphinx-config/conf.py.in
View File

@ -50,6 +50,7 @@ extensions = [
'sphinx.ext.mathjax',
'sphinx.ext.imgmath',
'sphinx.ext.autodoc',
'sphinx_toolbox.collapse',
'lammps_theme',
'sphinxcontrib.jquery',
'sphinxfortran.fortran_domain',
@ -370,6 +371,17 @@ latex_elements = {
{%
\hypersetup{pageanchor=false}% avoid duplicate destination warnings
\begin{titlepage}%
\sffamily\Large
The LAMMPS developers are thinking about dropping the PDF format version of
the LAMMPS manual. This would allow us to focus on the HTML version, use
HTML-only features, and skip checking if the documentation source files,
especially the embedded mathematical expressions, are compatible with \LaTeX{} output.
Please let us know how you feel about this change by sending an email to
\texttt{developers@lammps.org} stating whether you agree or disagree with
removing support for the PDF format version of the manual and optionally
provide arguments for your preference.
\clearpage
\sffamily\bfseries
\begingroup % for PDF information dictionary
\def\endgraf{ }\def\and{\& }%

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

@ -33,6 +33,7 @@ activationfunctions
acylindricity
addforce
Addington
addstep
addtorque
adf
Adhikari
@ -135,6 +136,8 @@ anton
Antonelli
anysize
api
apip
APIP
apolar
Apoorva
Appl
@ -230,6 +233,7 @@ Bagi
Bagnold
Baig
Bajaj
bak
Bal
balancer
Balankura
@ -529,6 +533,7 @@ civ
CKD
ckk
Clang
clearstep
clearstore
Cleary
Clebsch
@ -653,6 +658,7 @@ CSiC
csld
cslib
CSlib
csp
cstdio
cstdlib
cstring
@ -1383,6 +1389,7 @@ gmres
gname
gneb
GNEB
Godehard
Goerigk
Goga
Goldfarb
@ -1618,6 +1625,7 @@ Imageint
Imagemagick
imagename
imd
Immel
Impey
impl
improperlist
@ -3129,6 +3137,7 @@ Pxy
pxz
py
Py
pyargs
pydir
pylammps
PyLammps
@ -3845,6 +3854,7 @@ Thiaville
Thibaudeau
Thijsse
Thirumalai
thr
Threadripper
threebody
thrid
@ -4071,6 +4081,7 @@ Vaiwala
valent
Valeriu
valgrind
validator
Valone
valuev
Valuev
@ -4080,6 +4091,7 @@ Vanduyfhuys
varargs
varavg
variational
varname
Varshalovich
Varshney
vashishta

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

@ -79,6 +79,7 @@ liblammpsplugin_t *liblammpsplugin_load(const char *lib)
ADDSYM(mpi_finalize);
ADDSYM(kokkos_finalize);
ADDSYM(python_finalize);
ADDSYM(plugin_finalize);
ADDSYM(error);
ADDSYM(expand);
@ -140,6 +141,7 @@ liblammpsplugin_t *liblammpsplugin_load(const char *lib)
ADDSYM(scatter_subset);
ADDSYM(create_atoms);
ADDSYM(create_molecule);
ADDSYM(find_pair_neighlist);
ADDSYM(find_fix_neighlist);

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

@ -134,6 +134,7 @@ struct _liblammpsplugin {
void (*mpi_finalize)();
void (*kokkos_finalize)();
void (*python_finalize)();
void (*plugin_finalize)();
void (*error)(void *, int, const char *);
char *(*expand)(void *, const char *);
@ -206,6 +207,7 @@ struct _liblammpsplugin {
int (*create_atoms)(void *, int, const int64_t *, const int *, const double *, const double *,
const int64_t *, int);
#endif
int (*create_molecule)(void *, const char *, const char *);
int (*find_pair_neighlist)(void *, const char *, int, int, int);
int (*find_fix_neighlist)(void *, const char *, int);

34
examples/PACKAGES/apip/Cu-1.yace Normal file
View File

@ -0,0 +1,34 @@
NOTE: This is a simple potential for the example. Production usage without testing is not recommended. Provided by Yury Lysogorskiy (ICAMS, RUB, Germany).
elements: [Cu]
E0: [0]
deltaSplineBins: 0.001
embeddings:
0: {ndensity: 2, FS_parameters: [1, 1, 1, 0.5], npoti: FinnisSinclairShiftedScaled, rho_core_cutoff: 100000, drho_core_cutoff: 250}
bonds:
[0, 0]: {nradmax: 2, lmax: 2, nradbasemax: 15, radbasename: ChebPow, radparameters: [2], radcoefficients: [[[0.99440439385969503, -0.085048653403583918, -0.23248632054717755, -0.22732701549371864, 0.026354948476648921, 0.21853318667456997, 0.05745747498169812, -0.19717925712228765, -0.11474256770370879, 0.12738668745839368, 0.053777769435472259, -0.11094768379576209, 0.072620812391582482, -0.058715761632824881, 0.030359986427775303], [0.96259704765772924, -0.10129488003029259, -0.10345557604916655, -0.020393848425879282, 0.076671442494272601, 0.10318554794001746, 0.0555341702761026, 0.00083194423680727696, -0.018184436957498409, -0.021866885826555403, -0.020179969116479776, 0.021880011516616484, 0.053112509345249602, -0.083707026393616657, 0.020611714544479017], [1.001530579978529, -0.030080648426358471, -0.13318582671063051, -0.24371635685809706, -0.22760541127468878, -0.041144767051648642, 0.18080289144697201, 0.24543156067198274, 0.11014559411659355, -0.069512010077804498, -0.1172049950938457, -0.027509386703874331, 0.056985864219913585, 0.037536629112081353, -0.044222474537374087]], [[0.25716120576634355, 1.7485527550537943, 0.91889737965719875, 0.50902244208852199, -0.15895537149482841, -0.48109723575282892, -0.17843605933015286, 0.39450608859531944, 0.59293909285591195, 0.18268386912819001, -0.34706543720907351, -0.3210061634328315, 0.21678650779400246, 0.39500148786376449, -0.31820913370341625], [0.0079213202761679105, 1.0212489038630681, 0.011530454475879359, -0.049445152058907642, -0.15268524878755677, -0.2319378608755131, -0.20612580998548105, -0.067027395211212315, 0.08241096034972574, 0.11288597065081186, 0.01355948960244063, -0.074722461388416803, -0.022724332047049267, 0.088871664887057056, 0.031667459613258314], [-0.0069872405356639312, 0.9939655327342134, 0.035044055182587928, 0.099765277857093104, 0.11687607289674087, 0.030241996404391416, -0.12367698594314165, -0.22480900218170197, -0.17727517861619441, -0.015144941558075584, 0.11375495728241894, 0.090680932947050971, -0.041190210394591399, -0.10085768296286811, 0.055789864104988186]]], prehc: 0, lambdahc: 0, rcut: 3.8999999999999999, dcut: 0.01, rcut_in: 0, dcut_in: 0, inner_cutoff_type: density}
functions:
0:
- {mu0: 0, rank: 1, ndensity: 2, num_ms_combs: 1, mus: [0], ns: [1], ls: [0], ms_combs: [0], ctildes: [0.26072556900842869, -0.03073189825062177]}
- {mu0: 0, rank: 1, ndensity: 2, num_ms_combs: 1, mus: [0], ns: [2], ls: [0], ms_combs: [0], ctildes: [0.64429175483702295, -0.1630534353246999]}
- {mu0: 0, rank: 1, ndensity: 2, num_ms_combs: 1, mus: [0], ns: [3], ls: [0], ms_combs: [0], ctildes: [0.51856313423563594, -0.4259316875879266]}
- {mu0: 0, rank: 1, ndensity: 2, num_ms_combs: 1, mus: [0], ns: [4], ls: [0], ms_combs: [0], ctildes: [-0.078113533662468398, -0.70352070540668643]}
- {mu0: 0, rank: 1, ndensity: 2, num_ms_combs: 1, mus: [0], ns: [5], ls: [0], ms_combs: [0], ctildes: [-0.45633111544093646, -0.7859368117550467]}
- {mu0: 0, rank: 1, ndensity: 2, num_ms_combs: 1, mus: [0], ns: [6], ls: [0], ms_combs: [0], ctildes: [-0.19608401600520556, -0.59151667874441172]}
- {mu0: 0, rank: 1, ndensity: 2, num_ms_combs: 1, mus: [0], ns: [7], ls: [0], ms_combs: [0], ctildes: [0.30580228338697285, -0.29248216980800118]}
- {mu0: 0, rank: 1, ndensity: 2, num_ms_combs: 1, mus: [0], ns: [8], ls: [0], ms_combs: [0], ctildes: [0.40167461008815436, -0.15647925731818518]}
- {mu0: 0, rank: 1, ndensity: 2, num_ms_combs: 1, mus: [0], ns: [9], ls: [0], ms_combs: [0], ctildes: [0.053519057558225343, -0.25900906688118652]}
- {mu0: 0, rank: 1, ndensity: 2, num_ms_combs: 1, mus: [0], ns: [10], ls: [0], ms_combs: [0], ctildes: [-0.20446546815457517, -0.40019216010057629]}
- {mu0: 0, rank: 1, ndensity: 2, num_ms_combs: 1, mus: [0], ns: [11], ls: [0], ms_combs: [0], ctildes: [-0.070020661105060208, -0.33441939205411986]}
- {mu0: 0, rank: 1, ndensity: 2, num_ms_combs: 1, mus: [0], ns: [12], ls: [0], ms_combs: [0], ctildes: [0.15734064575001952, -0.055233119903794807]}
- {mu0: 0, rank: 1, ndensity: 2, num_ms_combs: 1, mus: [0], ns: [13], ls: [0], ms_combs: [0], ctildes: [0.10021406559793103, 0.18641744536767416]}
- {mu0: 0, rank: 1, ndensity: 2, num_ms_combs: 1, mus: [0], ns: [14], ls: [0], ms_combs: [0], ctildes: [-0.14066730990975543, 0.14711096149210373]}
- {mu0: 0, rank: 1, ndensity: 2, num_ms_combs: 1, mus: [0], ns: [15], ls: [0], ms_combs: [0], ctildes: [0.031100766650549283, -0.13720067925313634]}
- {mu0: 0, rank: 2, ndensity: 2, num_ms_combs: 1, mus: [0, 0], ns: [1, 1], ls: [0, 0], ms_combs: [0, 0], ctildes: [1.0984212008195524, 0.49756623164565855]}
- {mu0: 0, rank: 2, ndensity: 2, num_ms_combs: 2, mus: [0, 0], ns: [1, 1], ls: [1, 1], ms_combs: [0, 0, 1, -1], ctildes: [0.2591109116320176, 0.21348077494861176, -0.5182218232640351, -0.4269615498972234]}
- {mu0: 0, rank: 2, ndensity: 2, num_ms_combs: 3, mus: [0, 0], ns: [1, 1], ls: [2, 2], ms_combs: [0, 0, 1, -1, 2, -2], ctildes: [0.015905361441871636, 0.023783303055646809, -0.031810722883743273, -0.047566606111293624, 0.031810722883743286, 0.047566606111293638]}
- {mu0: 0, rank: 2, ndensity: 2, num_ms_combs: 1, mus: [0, 0], ns: [2, 1], ls: [0, 0], ms_combs: [0, 0], ctildes: [0.63958612617724186, 1.6623415103929948]}
- {mu0: 0, rank: 2, ndensity: 2, num_ms_combs: 2, mus: [0, 0], ns: [2, 1], ls: [1, 1], ms_combs: [0, 0, 1, -1], ctildes: [0.14199022782503917, 0.0069900458821809735, -0.28398045565007829, -0.013980091764361944]}
- {mu0: 0, rank: 2, ndensity: 2, num_ms_combs: 3, mus: [0, 0], ns: [2, 1], ls: [2, 2], ms_combs: [0, 0, 1, -1, 2, -2], ctildes: [0.028732470496968317, -0.037173039560267927, -0.05746494099393664, 0.074346079120535868, 0.057464940993936654, -0.074346079120535882]}
- {mu0: 0, rank: 2, ndensity: 2, num_ms_combs: 1, mus: [0, 0], ns: [2, 2], ls: [0, 0], ms_combs: [0, 0], ctildes: [0.056442895466964321, 0.0054387873274233034]}
- {mu0: 0, rank: 2, ndensity: 2, num_ms_combs: 2, mus: [0, 0], ns: [2, 2], ls: [1, 1], ms_combs: [0, 0, 1, -1], ctildes: [0.025326283180140272, -0.19511149476156769, -0.050652566360280531, 0.39022298952313533]}
- {mu0: 0, rank: 2, ndensity: 2, num_ms_combs: 3, mus: [0, 0], ns: [2, 2], ls: [2, 2], ms_combs: [0, 0, 1, -1, 2, -2], ctildes: [0.012754475331985416, -0.058934602152610385, -0.025508950663970836, 0.11786920430522078, 0.025508950663970843, -0.11786920430522081]}

6006
examples/PACKAGES/apip/Cu_300K_Immel_2023.eam.fs Normal file
View File

File diff suppressed because it is too large Load Diff

11
examples/PACKAGES/apip/README Normal file
View File

@ -0,0 +1,11 @@
The APIP package is based on the paper:
David Immel, Ralf Drautz, Godehard Sutmann; Adaptive-precision potentials for large-scale atomistic simulations. J. Chem. Phys. 14 March 2025; 162 (11): 114119. https://doi.org/10.1063/5.0245877
The pair_style pace/apip requires the installation of lib/pace of the ML-PACE package.
The installation of lib/pace is described in src/ML-PACE/README .
Examples of how to use an adaptive-precision potential are provided in examples/PACKAGES/apip .
in.vacancy contains a small example that can be used to visualize the transition region and get a visual impression of the selected parameters.
in.surface.balance in a more realistic example, in which a surface is simulated and the benefit of fix apip_atom_weight and fix balance for adaptive-precision interatomic potentials is demonstrated.

80418
examples/PACKAGES/apip/data.surface.balance Normal file
View File

File diff suppressed because it is too large Load Diff

4112
examples/PACKAGES/apip/data.vacancy Normal file
View File

File diff suppressed because it is too large Load Diff

80
examples/PACKAGES/apip/data.validate Normal file
View File

@ -0,0 +1,80 @@
LAMMPS data file via write_data, version 2 Apr 2025, timestep = 0, units = metal
31 atoms
1 atom types
0 7.23 xlo xhi
0 7.23 ylo yhi
0 7.23 zlo zhi
Masses
1 63.546
Atoms # apip
1 1 3.255649577011424 2.1469408310018205 1.596546647595962 0 0 0
2 1 5.312133977687514 0.2962629940541289 1.7986410677440656 0 0 0
3 1 0.3570136530341179 1.9589665444185802 1.8227120430766197 0 0 0
4 1 1.538770434276094 1.8506888783106994 3.5984777679252336 0 0 0
5 1 5.414379916412933 1.9802551521608864 3.5428423680157133 0 0 0
6 1 3.3396207511420926 0.34696444514694835 3.3284295847601864 0 0 0
7 1 0.04692381499727436 3.470558659189874 0.20838500420697273 0 0 0
8 1 3.5507628116865004 3.419576015011443 0.09808429731968064 0 0 0
9 1 3.4359438466091845 3.3442299605630015 3.344947182361245 0 0 0
10 1 3.262172986855113 1.8898900738753799 5.6074716235080135 0 0 0
11 1 5.616180533384058 0.24272458584617107 5.728614316596936 0 0 0
12 1 0.3320737270957668 2.133631298552561 5.648234772896504 0 0 0
13 1 7.193910458696732 0.040079315967661934 7.007063468494249 -1 0 -1
14 1 1.9428459507398523 2.008894084694746 6.974381464595852 0 0 -1
15 1 5.17195441765988 1.6398976096007498 7.144624559798802 0 0 -1
16 1 3.828212487222493 0.27427274843853566 7.084083006467942 0 0 -1
17 1 0.3576896118392189 3.5593061817506357 3.8539966829342287 0 0 0
18 1 5.549388330643712 3.3771731288636446 5.733276811271104 0 0 0
19 1 1.474782367736 3.311754538948766 5.203036111913638 0 0 0
20 1 3.353885621487343 5.483140337766679 1.559656844576661 0 0 0
21 1 1.4600851633288363 5.3693400677513985 0.16901869775192754 0 0 0
22 1 1.865319826459661 3.680823307523189 1.909829542233995 0 0 0
23 1 6.919428313555163 5.704165921616911 1.5626446154218376 -1 0 0
24 1 5.286111954406888 3.9741177165543746 1.894962129368895 0 0 0
25 1 5.661441532175263 5.770831269632481 0.2726487131030991 0 0 0
26 1 5.749451385769738 5.694440631979816 3.315201684766776 0 0 0
27 1 2.1656354707333425 5.630356615286487 3.525133119978771 0 0 0
28 1 3.4802512558478638 5.136357035041954 5.613687950103865 0 0 0
29 1 6.9476459434582605 5.669871702976 5.748711917622347 -1 0 0
30 1 0.3145319513743893 6.992506749359428 3.748936483911442 0 -1 0
31 1 2.0688280140984934 7.144932953378388 5.071647430554334 0 -1 0
Velocities
1 0 0 0
2 0 0 0
3 0 0 0
4 0 0 0
5 0 0 0
6 0 0 0
7 0 0 0
8 0 0 0
9 0 0 0
10 0 0 0
11 0 0 0
12 0 0 0
13 0 0 0
14 0 0 0
15 0 0 0
16 0 0 0
17 0 0 0
18 0 0 0
19 0 0 0
20 0 0 0
21 0 0 0
22 0 0 0
23 0 0 0
24 0 0 0
25 0 0 0
26 0 0 0
27 0 0 0
28 0 0 0
29 0 0 0
30 0 0 0
31 0 0 0

75
examples/PACKAGES/apip/in.surface.balance Normal file
View File

@ -0,0 +1,75 @@
##################################################
# parameters of the adaptive-precision potential #
##################################################
# We couple an EAM potential with an ACE potential.
variable eamfs_file string "Cu_300K_Immel_2023.eam.fs"
variable ace_file1 string "Cu-1.yace"
variable ace_file2 string "../../../potentials/Cu-PBE-core-rep.ace"
# The csp is used as detection mechanism for atoms of interest.
variable csp_lattice string "fcc"
variable csp_cutoff equal 6.0
# The range [r_sw_lo, r_sw_hi] determines where the switching parameter changes from 0 to 1.
variable r_sw_lo equal 4.0
variable r_sw_hi equal 12.0
# Thresholds between which the switching parameter changes from 1 to 0 based on the csp.
variable lambda_input_thr_lo equal 7.5
variable lambda_input_thr_hi equal 8.0
# Number of averaged steps.
variable lambda_input_histlen equal 110
variable lambda_histlen equal 110
# Minimum required change of the switching parameter
variable min_delta_lambda equal 1/${lambda_histlen}
# number of atoms rescaled by the lambda_thermostat
variable N_rescaling equal 600
# basic stuff
units metal
dimension 3
boundary p p s
atom_style apip # own atom style required for APIP
timestep 0.001
read_data data.surface.balance
fix nve all nve
comm_style tiled
# Only the upper surface should be treated precisely.
# Thus, we create group, for whose atoms the csp is ignored, as the corresponding
# argument of fix lambda is used.
region bottom block INF INF INF INF INF 0 units box
group group_ignore_csp region bottom
# use adaptive-precision eam-ace potential with lambda_thermostat
pair_style hybrid/overlay eam/fs/apip pace/apip lambda/input/csp/apip ${csp_lattice} cutoff ${csp_cutoff} lambda/zone/apip ${r_sw_hi}
pair_coeff * * eam/fs/apip ${eamfs_file} Cu
pair_coeff * * pace/apip ${ace_file2} Cu
pair_coeff * * lambda/input/csp/apip
pair_coeff * * lambda/zone/apip
fix lambda all lambda/apip ${lambda_input_thr_lo} ${lambda_input_thr_hi} time_averaged_zone ${r_sw_lo} ${r_sw_hi} ${lambda_input_histlen} ${lambda_histlen} min_delta_lambda ${min_delta_lambda} group_ignore_lambda_input group_ignore_csp
fix lambda_thermostat all lambda_thermostat/apip N_rescaling ${N_rescaling}
fix weight_atom all atom_weight/apip 10 eam ace lambda/input lambda/zone all
# store weight in variable
fix property_atom all property/atom d_usedweight
variable myweight atom f_weight_atom
#compute lambda all property/atom apip_lambda
#compute lambda_input all property/atom apip_lambda_input
#dump 1 all custom 10 dump/surface_ap_balance.dump.* id type x y z c_lambda c_lambda_input f_weight_atom proc d_usedweight
## apply load balancing
## no load-balancing
#fix balance all balance 10 0.9 report weight time 1.0 weight store usedweight
## load balancing with times per atom per processor
#fix balance all balance 10 0.9 rcb weight time 1.0 weight store usedweight
## load balancing with an approximated load per atom by fix apip_atom_weight
fix balance all balance 10 0.9 rcb weight var myweight weight store usedweight
thermo_style custom step f_balance spcpu f_weight_atom[*]
thermo 10
run 100

54
examples/PACKAGES/apip/in.vacancy.const.lambda Normal file
View File

@ -0,0 +1,54 @@
##################################################
# parameters of the adaptive-precision potential #
##################################################
# We couple an EAM potential with an ACE potential.
variable eamfs_file string "Cu_300K_Immel_2023.eam.fs"
variable ace_file1 string "Cu-1.yace"
variable ace_file2 string "../../../potentials/Cu-PBE-core-rep.ace"
## basic stuff
units metal
atom_style apip # own atom style required for APIP
timestep 0.001
# copper at room temperature with a vacancy
read_data data.vacancy
# set lambda
group vacancy id 145 147 148 149 150 994 997 995 1024 1026 1028 1922
group transition id 77 79 81 84 88 151 152 153 154 155 158 1089 188 189 192 1033 1039 1964 1022 1021 999 998 996 948 950 952 992 993 139 1025 1027 1029 1034 1035 1038 1088 1920 1921 1923 1924 1925 1930
group bulk subtract all vacancy transition
set group vacancy apip/lambda precise
set group transition apip/lambda 0.5
set group bulk apip/lambda fast
fix nve all nve
# Use adaptive-precision eam-ace potential with constant lambda.
# Calculate atomic weight that could be used for load balancing.
pair_style hybrid/overlay eam/fs/apip pace/apip
pair_coeff * * eam/fs/apip ${eamfs_file} Cu
pair_coeff * * pace/apip ${ace_file2} Cu
fix weight_atom all atom_weight/apip 50 eam ace 0.5 0 all
# get statistics about lambda
compute lambda all property/atom apip_lambda
compute lambda_input all property/atom apip_lambda_input
variable flag_simple atom c_lambda==1
variable flag_switch atom c_lambda<1&&c_lambda>0
variable flag_complex atom c_lambda==0
compute lambda_types all reduce sum v_flag_simple v_flag_switch v_flag_complex
thermo_style custom step etotal c_lambda_types[*]
thermo 1
run 100
# dump atoms
#write_dump all custom dump.vacancy.* id type x y z fx fy fz c_lambda c_lambda_input f_weight_atom

101
examples/PACKAGES/apip/in.vacancy.dynamic.lambda Normal file
View File

@ -0,0 +1,101 @@
##################################################
# parameters of the adaptive-precision potential #
##################################################
# We couple an EAM potential with an ACE potential.
variable eamfs_file string "Cu_300K_Immel_2023.eam.fs"
variable ace_file1 string "Cu-1.yace"
variable ace_file2 string "../../../potentials/Cu-PBE-core-rep.ace"
# The csp is used as detection mechanism for atoms of interest.
variable csp_lattice string "fcc"
variable csp_cutoff equal 6.0
# The range [r_sw_lo, r_sw_hi] determines where the switching parameter changes from 0 to 1.
variable r_sw_lo equal 2.0
variable r_sw_hi equal 3.0
# Thresholds between which the switching parameter changes from 1 to 0 based on the csp.
variable lambda_input_thr_lo equal 2.5
variable lambda_input_thr_hi equal 3.0
# Number of averaged steps.
variable lambda_input_histlen equal 110
variable lambda_histlen equal 110
# Minimum required change of the switching parameter
variable min_delta_lambda equal 1/${lambda_histlen}
# number of atoms rescaled by the lambda_thermostat
variable N_rescaling equal 600
## basic stuff
units metal
atom_style apip # own atom style required for APIP
timestep 0.001
# copper at room temperature with a vacancy
read_data data.vacancy
fix nve all nve
## Use adaptive-precision ace-ace potential without lambda_thermostat.
## Calculate atomic weight that could be used for load balancing.
#pair_style hybrid/overlay pace/fast/apip pace/precise/apip lambda/input/csp/apip ${csp_lattice} cutoff ${csp_cutoff} lambda/zone/apip ${r_sw_hi}
#pair_coeff * * pace/fast/apip ${ace_file1} Cu
#pair_coeff * * pace/precise/apip ${ace_file2} Cu
#pair_coeff * * lambda/input/csp/apip
#pair_coeff * * lambda/zone/apip
#fix lambda all lambda/apip ${lambda_input_thr_lo} ${lambda_input_thr_hi} time_averaged_zone ${r_sw_lo} ${r_sw_hi} ${lambda_input_histlen} ${lambda_histlen} min_delta_lambda ${min_delta_lambda}
#fix weight_atom all atom_weight/apip 100 ace ace lambda/input lambda/zone all
# Use adaptive-precision eam-ace potential without lambda_thermostat.
# Calculate atomic weight that could be used for load balancing.
pair_style hybrid/overlay eam/fs/apip pace/apip lambda/input/csp/apip ${csp_lattice} cutoff ${csp_cutoff} lambda/zone/apip ${r_sw_hi}
pair_coeff * * eam/fs/apip ${eamfs_file} Cu
pair_coeff * * pace/apip ${ace_file2} Cu
pair_coeff * * lambda/input/csp/apip
pair_coeff * * lambda/zone/apip
fix lambda all lambda/apip ${lambda_input_thr_lo} ${lambda_input_thr_hi} time_averaged_zone ${r_sw_lo} ${r_sw_hi} ${lambda_input_histlen} ${lambda_histlen} min_delta_lambda ${min_delta_lambda}
fix weight_atom all atom_weight/apip 100 eam ace lambda/input lambda/zone all
## One can comment out fix lambda_thermostat to see the energy change caused by the neglection of the
## gradient of the switching function. This neglection can be compensated by the local thermostat and the
## energy can be conserved within numerical precision.
fix lambda_thermostat all lambda_thermostat/apip N_rescaling ${N_rescaling} store_atomic_forces 100
# get statistics about lambda
compute lambda all property/atom apip_lambda
compute lambda_input all property/atom apip_lambda_input
variable flag_simple atom c_lambda==1
variable flag_switch atom c_lambda<1&&c_lambda>0
variable flag_complex atom c_lambda==0
compute lambda_types all reduce sum v_flag_simple v_flag_switch v_flag_complex
thermo_style custom step etotal c_lambda_types[*]
thermo 1
run 100
# dump atoms
#write_dump all custom dump/vacancy.dump.* id type x y z fx fy fz c_lambda c_lambda_input f_weight_atom f_lambda_thermostat[*]
## A smooth restart of the simulation is possible as the history of lambda and lambda_input is stored.
#write_restart vacancy_ap.restart
#clear
#read_restart vacancy_ap.restart
#pair_style hybrid/overlay eam/fs/apip pace/apip lambda/input/csp/apip fcc cutoff 6.0 lambda/zone/apip 12.0
#pair_coeff * * eam/fs/apip "Cu_300K_Immel_2023.eam.fs" Cu
#pair_coeff * * pace/apip "../../../potentials/Cu-PBE-core-rep.ace" Cu
#pair_coeff * * lambda/input/csp/apip
#pair_coeff * * lambda/zone/apip
#fix lambda all lambda/apip 2.5 3.0 time_averaged_zone 4.0 12.0 110 110 min_delta_lambda $(1/110)
#fix lambda_thermostat all lambda_thermostat/apip N_rescaling ${N_rescaling} store_atomic_forces 100
#fix nve all nve
#thermo_style custom step etotal
#thermo 1
#run 10
#shell rm vacancy_ap.restart

51
examples/PACKAGES/apip/in.validate Normal file
View File

@ -0,0 +1,51 @@
##################################################
# parameters of the adaptive-precision potential #
##################################################
# We couple an EAM potential with an ACE potential.
variable eamfs_file string "Cu_300K_Immel_2023.eam.fs"
variable ace_file string "Cu-1.yace"
## basic stuff
units metal
atom_style apip # own atom style required for APIP
timestep 0.001
## copper with a vacancy
#lattice fcc 3.615
#region box block 0 2 0 2 0 2 units lattice
#create_box 1 box
#create_atoms 1 box
#mass 1 63.546
#displace_atoms all random 0.1 0.1 0.1 42 units lattice
#delete_atoms random count 1 yes all NULL 42
#write_data data.validate
read_data data.validate
fix 1 all nve
thermo_style custom step pe fnorm fmax
# use ACE potential
pair_style pace
pair_coeff * * ${ace_file} Cu
run 0
# use adaptive-precision EAM-ACE potential with constant lambda
pair_style hybrid/overlay eam/fs/apip pace/apip
pair_coeff * * eam/fs/apip ${eamfs_file} Cu
pair_coeff * * pace/apip ${ace_file} Cu
# use ACE of adaptive-precision potential
set group all apip/lambda precise
run 0
# use EAM of adaptive-precision potential
set group all apip/lambda fast
run 0
# Use EAM potential
pair_style eam/fs
pair_coeff * * ${eamfs_file} Cu
run 0

108
examples/PACKAGES/apip/log.02Apr25.surface.balance.nolb.g++.4 Normal file
View File

@ -0,0 +1,108 @@
LAMMPS (2 Apr 2025 - Development - )
Reading data file ...
orthogonal box = (0 0 -1.1656272) to (36.15 36.15 362.81506)
1 by 1 by 4 MPI processor grid
reading atoms ...
40200 atoms
reading velocities ...
40200 velocities
read_data CPU = 0.135 seconds
200 atoms in group group_ignore_csp
ACE version: 2023.11.25
Recursive evaluator is used by ACE
Loading ../../../potentials/Cu-PBE-core-rep.ace
Total number of basis functions
Cu: 16 (r=1) 726 (r>1)
Mapping LAMMPS atom type #1(Cu) -> ACE species type #0
atomic load lambda:
fast potential: extract eam/apip:time_per_atom
precise potential: extract pace/apip:time_per_atom
lambda_input: extract lambda/input/apip:time_per_atom
lambda: extract lambda/zone/apip:time_per_atom
CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE
Your simulation uses code contributions which should be cited:
- fix lambda command: doi.org/10.1063/5.0245877
The log file lists these citations in BibTeX format.
CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE
Neighbor list info ...
update: every = 1 steps, delay = 0 steps, check = yes
max neighbors/atom: 2000, page size: 100000
master list distance cutoff = 14
ghost atom cutoff = 14
binsize = 7, bins = 6 6 52
5 neighbor lists, perpetual/occasional/extra = 5 0 0
(1) pair eam/fs/apip, perpetual
attributes: full, newton on
pair build: full/bin/atomonly
stencil: full/bin/3d
bin: standard
(2) pair pace/apip, perpetual, trim from (4)
attributes: full, newton on, cut 9.4
pair build: trim
stencil: none
bin: none
(3) pair lambda/input/csp/apip, perpetual, trim from (2)
attributes: full, newton on, cut 8
pair build: trim
stencil: none
bin: none
(4) pair lambda/zone/apip, perpetual
attributes: full, newton on, ghost, cut 14
pair build: full/bin/ghost
stencil: full/ghost/bin/3d
bin: standard
(5) fix lambda_thermostat/apip, perpetual, copy from (1)
attributes: full, newton on
pair build: copy
stencil: none
bin: none
Setting up Verlet run ...
Unit style : metal
Current step : 0
Time step : 0.001
Per MPI rank memory allocation (min/avg/max) = 297.9 | 306.9 | 315.9 Mbytes
Step f_balance S/CPU f_weight_atom[1] f_weight_atom[2] f_weight_atom[3] f_weight_atom[4]
0 1.0139303 0 0 0 0 0
10 2.6176099 0.23789922 3.4933844e-05 0.0018769787 2.0912678e-05 3.414976e-05
20 2.1242027 0.2259695 4.2800036e-05 0.0022124427 2.4613899e-05 4.0819606e-05
30 2.1197082 0.22281117 4.3885117e-05 0.0022416604 2.4808124e-05 4.081464e-05
40 2.1149313 0.2245266 4.3328755e-05 0.0022134411 2.4645468e-05 4.0892224e-05
50 2.1066618 0.22308398 4.3884622e-05 0.0022085846 2.464161e-05 4.0909229e-05
60 2.1000306 0.22186291 4.4839801e-05 0.0022299631 2.4816945e-05 4.1173119e-05
70 2.1062658 0.22406791 4.3740709e-05 0.0022049729 2.4693417e-05 4.0963037e-05
80 2.1072933 0.22241288 4.4160464e-05 0.0022245226 2.4854938e-05 4.2491144e-05
90 2.0981181 0.22412189 4.3990788e-05 0.0022086162 2.4710948e-05 4.09478e-05
100 2.1033304 0.2237968 4.3982714e-05 0.0022112815 2.4658851e-05 4.1060551e-05
Loop time of 444.499 on 4 procs for 100 steps with 40200 atoms
Performance: 0.019 ns/day, 1234.721 hours/ns, 0.225 timesteps/s, 9.044 katom-step/s
99.0% CPU use with 4 MPI tasks x no OpenMP threads
MPI task timing breakdown:
Section | min time | avg time | max time |%varavg| %total
---------------------------------------------------------------
Pair | 67.764 | 146.15 | 378.03 |1107.5 | 32.88
Neigh | 55.764 | 59.579 | 62.94 | 43.1 | 13.40
Comm | 0.6589 | 153.57 | 302.72 |1199.1 | 34.55
Output | 0.0032423 | 6.1068 | 24.01 | 418.3 | 1.37
Modify | 8.0892 | 16.162 | 38.588 | 322.6 | 3.64
Other | | 62.93 | | | 14.16
Nlocal: 10050 ave 10180 max 10000 min
Histogram: 2 1 0 0 0 0 0 0 0 1
Nghost: 27854.5 ave 30385 max 25525 min
Histogram: 2 0 0 0 0 0 0 0 0 2
Neighs: 0 ave 0 max 0 min
Histogram: 4 0 0 0 0 0 0 0 0 0
FullNghs: 9.49222e+06 ave 9.76687e+06 max 9.29466e+06 min
Histogram: 2 0 0 0 0 0 1 0 0 1
Total # of neighbors = 37968882
Ave neighs/atom = 944.49955
Neighbor list builds = 10
Dangerous builds = 0
Total wall time: 0:07:25

108
examples/PACKAGES/apip/log.02Apr25.surface.balance.rcb.myweight.g++.4 Normal file
View File

@ -0,0 +1,108 @@
LAMMPS (2 Apr 2025 - Development - )
Reading data file ...
orthogonal box = (0 0 -1.1656272) to (36.15 36.15 362.81506)
1 by 1 by 4 MPI processor grid
reading atoms ...
40200 atoms
reading velocities ...
40200 velocities
read_data CPU = 0.161 seconds
200 atoms in group group_ignore_csp
ACE version: 2023.11.25
Recursive evaluator is used by ACE
Loading ../../../potentials/Cu-PBE-core-rep.ace
Total number of basis functions
Cu: 16 (r=1) 726 (r>1)
Mapping LAMMPS atom type #1(Cu) -> ACE species type #0
atomic load lambda:
fast potential: extract eam/apip:time_per_atom
precise potential: extract pace/apip:time_per_atom
lambda_input: extract lambda/input/apip:time_per_atom
lambda: extract lambda/zone/apip:time_per_atom
CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE
Your simulation uses code contributions which should be cited:
- fix lambda command: doi.org/10.1063/5.0245877
The log file lists these citations in BibTeX format.
CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE
Neighbor list info ...
update: every = 1 steps, delay = 0 steps, check = yes
max neighbors/atom: 2000, page size: 100000
master list distance cutoff = 14
ghost atom cutoff = 14
binsize = 7, bins = 6 6 52
5 neighbor lists, perpetual/occasional/extra = 5 0 0
(1) pair eam/fs/apip, perpetual
attributes: full, newton on
pair build: full/bin/atomonly
stencil: full/bin/3d
bin: standard
(2) pair pace/apip, perpetual, trim from (4)
attributes: full, newton on, cut 9.4
pair build: trim
stencil: none
bin: none
(3) pair lambda/input/csp/apip, perpetual, trim from (2)
attributes: full, newton on, cut 8
pair build: trim
stencil: none
bin: none
(4) pair lambda/zone/apip, perpetual
attributes: full, newton on, ghost, cut 14
pair build: full/bin/ghost
stencil: full/ghost/bin/3d
bin: standard
(5) fix lambda_thermostat/apip, perpetual, copy from (1)
attributes: full, newton on
pair build: copy
stencil: none
bin: none
Setting up Verlet run ...
Unit style : metal
Current step : 0
Time step : 0.001
Per MPI rank memory allocation (min/avg/max) = 298.1 | 306.3 | 314.5 Mbytes
Step f_balance S/CPU f_weight_atom[1] f_weight_atom[2] f_weight_atom[3] f_weight_atom[4]
0 1 0 0 0 0 0
10 1.0018226 0.21929744 4.2082278e-05 0.0022147425 2.472285e-05 4.0694771e-05
20 1.002451 0.38193369 4.9389333e-05 0.0023722824 2.4776133e-05 2.168819e-05
30 1.0004234 0.39492198 4.8977088e-05 0.002249832 2.4610967e-05 2.1465621e-05
40 1.0012276 0.39068387 4.9886201e-05 0.0022529811 2.4663509e-05 2.1540032e-05
50 1.0013752 0.39170654 5.0527084e-05 0.002253323 2.4721079e-05 2.153442e-05
60 1.0007053 0.3758265 5.0935226e-05 0.0022581901 2.4772692e-05 2.1596641e-05
70 1.0003982 0.38524379 5.1685387e-05 0.002263544 2.495032e-05 2.1714264e-05
80 1.0022848 0.38409158 5.1897166e-05 0.0022557711 2.4755235e-05 2.1595246e-05
90 1.0012911 0.38122934 5.2440631e-05 0.0022574019 2.4795351e-05 2.1615786e-05
100 1.0005279 0.37983246 5.2871808e-05 0.0022583136 2.484618e-05 2.1569403e-05
Loop time of 279.389 on 4 procs for 100 steps with 40200 atoms
Performance: 0.031 ns/day, 776.081 hours/ns, 0.358 timesteps/s, 14.389 katom-step/s
98.6% CPU use with 4 MPI tasks x no OpenMP threads
MPI task timing breakdown:
Section | min time | avg time | max time |%varavg| %total
---------------------------------------------------------------
Pair | 148.19 | 155.34 | 175.77 | 94.7 | 55.60
Neigh | 87.542 | 87.924 | 88.444 | 3.6 | 31.47
Comm | 4.9019 | 18.932 | 33.429 | 322.2 | 6.78
Output | 0.01326 | 0.04615 | 0.075485 | 10.3 | 0.02
Modify | 9.5358 | 10.391 | 12.424 | 36.6 | 3.72
Other | | 6.756 | | | 2.42
Nlocal: 10050 ave 10283 max 9838 min
Histogram: 1 0 1 0 0 0 1 0 0 1
Nghost: 52763 ave 52975 max 52530 min
Histogram: 1 0 0 1 0 0 0 1 0 1
Neighs: 0 ave 0 max 0 min
Histogram: 4 0 0 0 0 0 0 0 0 0
FullNghs: 9.49222e+06 ave 9.71459e+06 max 9.29015e+06 min
Histogram: 1 0 1 0 0 0 1 0 0 1
Total # of neighbors = 37968882
Ave neighs/atom = 944.49955
Neighbor list builds = 10
Dangerous builds = 0
Total wall time: 0:04:48

108
examples/PACKAGES/apip/log.02Apr25.surface.balance.rcb.time.g++.4 Normal file
View File

@ -0,0 +1,108 @@
LAMMPS (2 Apr 2025 - Development - )
Reading data file ...
orthogonal box = (0 0 -1.1656272) to (36.15 36.15 362.81506)
1 by 1 by 4 MPI processor grid
reading atoms ...
40200 atoms
reading velocities ...
40200 velocities
read_data CPU = 0.134 seconds
200 atoms in group group_ignore_csp
ACE version: 2023.11.25
Recursive evaluator is used by ACE
Loading ../../../potentials/Cu-PBE-core-rep.ace
Total number of basis functions
Cu: 16 (r=1) 726 (r>1)
Mapping LAMMPS atom type #1(Cu) -> ACE species type #0
atomic load lambda:
fast potential: extract eam/apip:time_per_atom
precise potential: extract pace/apip:time_per_atom
lambda_input: extract lambda/input/apip:time_per_atom
lambda: extract lambda/zone/apip:time_per_atom
CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE
Your simulation uses code contributions which should be cited:
- fix lambda command: doi.org/10.1063/5.0245877
The log file lists these citations in BibTeX format.
CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE
Neighbor list info ...
update: every = 1 steps, delay = 0 steps, check = yes
max neighbors/atom: 2000, page size: 100000
master list distance cutoff = 14
ghost atom cutoff = 14
binsize = 7, bins = 6 6 52
5 neighbor lists, perpetual/occasional/extra = 5 0 0
(1) pair eam/fs/apip, perpetual
attributes: full, newton on
pair build: full/bin/atomonly
stencil: full/bin/3d
bin: standard
(2) pair pace/apip, perpetual, trim from (4)
attributes: full, newton on, cut 9.4
pair build: trim
stencil: none
bin: none
(3) pair lambda/input/csp/apip, perpetual, trim from (2)
attributes: full, newton on, cut 8
pair build: trim
stencil: none
bin: none
(4) pair lambda/zone/apip, perpetual
attributes: full, newton on, ghost, cut 14
pair build: full/bin/ghost
stencil: full/ghost/bin/3d
bin: standard
(5) fix lambda_thermostat/apip, perpetual, copy from (1)
attributes: full, newton on
pair build: copy
stencil: none
bin: none
Setting up Verlet run ...
Unit style : metal
Current step : 0
Time step : 0.001
Per MPI rank memory allocation (min/avg/max) = 298.1 | 306.3 | 314.5 Mbytes
Step f_balance S/CPU f_weight_atom[1] f_weight_atom[2] f_weight_atom[3] f_weight_atom[4]
0 1 0 0 0 0 0
10 1.000245 0.23168829 2.8965377e-05 0.0016346261 1.8194173e-05 2.8621987e-05
20 1.0001156 0.23012235 4.2703387e-05 0.0022174634 2.4522315e-05 4.0198928e-05
30 1.0003479 0.24170843 4.2900821e-05 0.0022358654 2.4496934e-05 4.0262644e-05
40 1.0000952 0.34743014 4.4687983e-05 0.0022336389 2.4626704e-05 2.8362965e-05
50 1.000399 0.23273413 4.4278568e-05 0.0022319529 2.4645291e-05 4.0394287e-05
60 1.000137 0.23531789 4.5212176e-05 0.0022671271 2.4758267e-05 4.0607561e-05
70 1.0001901 0.34359487 4.5647742e-05 0.0022386998 2.473236e-05 2.8357019e-05
80 1.0003173 0.23324348 4.5372627e-05 0.0022272881 2.4704053e-05 4.0760615e-05
90 1.0009828 0.2360927 4.5867574e-05 0.0022616272 2.4715122e-05 4.0548519e-05
100 1.0005337 0.34332801 4.6171376e-05 0.0022394199 2.4724815e-05 2.8552653e-05
Loop time of 385.695 on 4 procs for 100 steps with 40200 atoms
Performance: 0.022 ns/day, 1071.376 hours/ns, 0.259 timesteps/s, 10.423 katom-step/s
98.9% CPU use with 4 MPI tasks x no OpenMP threads
MPI task timing breakdown:
Section | min time | avg time | max time |%varavg| %total
---------------------------------------------------------------
Pair | 80.949 | 145.84 | 287.45 | 683.6 | 37.81
Neigh | 21.125 | 61.121 | 98.27 | 452.7 | 15.85
Comm | 23.839 | 129.54 | 261.28 | 833.4 | 33.59
Output | 0.10319 | 2.5231 | 8.6153 | 222.9 | 0.65
Modify | 5.3228 | 13.101 | 29.2 | 267.2 | 3.40
Other | | 33.57 | | | 8.70
Nlocal: 10050 ave 16825 max 3772 min
Histogram: 2 0 0 0 0 0 0 0 0 2
Nghost: 27618.8 ave 41748 max 12149 min
Histogram: 1 1 0 0 0 0 0 0 0 2
Neighs: 0 ave 0 max 0 min
Histogram: 4 0 0 0 0 0 0 0 0 0
FullNghs: 9.49222e+06 ave 1.58445e+07 max 3.337e+06 min
Histogram: 2 0 0 0 0 0 0 0 0 2
Total # of neighbors = 37968882
Ave neighs/atom = 944.49955
Neighbor list builds = 10
Dangerous builds = 0
Total wall time: 0:06:27

182
examples/PACKAGES/apip/log.02Apr25.vacancy.const.lambda.g++.1 Normal file
View File

@ -0,0 +1,182 @@
LAMMPS (2 Apr 2025 - Development - )
Reading data file ...
orthogonal box = (0 0 0) to (28.92 28.92 28.92)
1 by 1 by 1 MPI processor grid
reading atoms ...
2047 atoms
reading velocities ...
2047 velocities
read_data CPU = 0.009 seconds
12 atoms in group vacancy
42 atoms in group transition
1993 atoms in group bulk
Setting atom values ...
12 settings made for apip/lambda
Setting atom values ...
42 settings made for apip/lambda
Setting atom values ...
1993 settings made for apip/lambda
ACE version: 2023.11.25
Recursive evaluator is used by ACE
Loading ../../../potentials/Cu-PBE-core-rep.ace
Total number of basis functions
Cu: 16 (r=1) 726 (r>1)
Mapping LAMMPS atom type #1(Cu) -> ACE species type #0
atomic load lambda:
fast potential: extract eam/apip:time_per_atom
precise potential: extract pace/apip:time_per_atom
lambda_input: const 0.5
lambda: const 0
Neighbor list info ...
update: every = 1 steps, delay = 0 steps, check = yes
max neighbors/atom: 2000, page size: 100000
master list distance cutoff = 9.4
ghost atom cutoff = 9.4
binsize = 4.7, bins = 7 7 7
2 neighbor lists, perpetual/occasional/extra = 2 0 0
(1) pair eam/fs/apip, perpetual
attributes: full, newton on
pair build: full/bin/atomonly
stencil: full/bin/3d
bin: standard
(2) pair pace/apip, perpetual
attributes: full, newton on, cut 9.4
pair build: full/bin/atomonly
stencil: full/bin/3d
bin: standard
Setting up Verlet run ...
Unit style : metal
Current step : 0
Time step : 0.001
Per MPI rank memory allocation (min/avg/max) = 11.08 | 11.08 | 11.08 Mbytes
Step TotEng c_lambda_types[1] c_lambda_types[2] c_lambda_types[3]
0 -7408.6798 1993 42 12
1 -7408.6798 1993 42 12
2 -7408.6798 1993 42 12
3 -7408.6798 1993 42 12
4 -7408.6798 1993 42 12
5 -7408.6798 1993 42 12
6 -7408.6799 1993 42 12
7 -7408.6799 1993 42 12
8 -7408.6799 1993 42 12
9 -7408.6799 1993 42 12
10 -7408.6799 1993 42 12
11 -7408.68 1993 42 12
12 -7408.68 1993 42 12
13 -7408.68 1993 42 12
14 -7408.68 1993 42 12
15 -7408.68 1993 42 12
16 -7408.68 1993 42 12
17 -7408.6801 1993 42 12
18 -7408.6801 1993 42 12
19 -7408.6801 1993 42 12
20 -7408.6801 1993 42 12
21 -7408.6801 1993 42 12
22 -7408.6801 1993 42 12
23 -7408.6801 1993 42 12
24 -7408.6801 1993 42 12
25 -7408.6801 1993 42 12
26 -7408.6801 1993 42 12
27 -7408.6801 1993 42 12
28 -7408.6801 1993 42 12
29 -7408.6801 1993 42 12
30 -7408.6801 1993 42 12
31 -7408.6801 1993 42 12
32 -7408.68 1993 42 12
33 -7408.68 1993 42 12
34 -7408.68 1993 42 12
35 -7408.68 1993 42 12
36 -7408.68 1993 42 12
37 -7408.68 1993 42 12
38 -7408.68 1993 42 12
39 -7408.68 1993 42 12
40 -7408.6801 1993 42 12
41 -7408.6801 1993 42 12
42 -7408.6801 1993 42 12
43 -7408.6801 1993 42 12
44 -7408.6801 1993 42 12
45 -7408.6801 1993 42 12
46 -7408.6801 1993 42 12
47 -7408.6801 1993 42 12
48 -7408.6801 1993 42 12
49 -7408.6802 1993 42 12
50 -7408.6802 1993 42 12
51 -7408.6802 1993 42 12
52 -7408.6802 1993 42 12
53 -7408.6802 1993 42 12
54 -7408.6802 1993 42 12
55 -7408.6802 1993 42 12
56 -7408.6802 1993 42 12
57 -7408.6802 1993 42 12
58 -7408.6802 1993 42 12
59 -7408.6801 1993 42 12
60 -7408.6801 1993 42 12
61 -7408.6801 1993 42 12
62 -7408.6801 1993 42 12
63 -7408.6801 1993 42 12
64 -7408.68 1993 42 12
65 -7408.68 1993 42 12
66 -7408.68 1993 42 12
67 -7408.68 1993 42 12
68 -7408.68 1993 42 12
69 -7408.6799 1993 42 12
70 -7408.6799 1993 42 12
71 -7408.6799 1993 42 12
72 -7408.6799 1993 42 12
73 -7408.6799 1993 42 12
74 -7408.6799 1993 42 12
75 -7408.6798 1993 42 12
76 -7408.6798 1993 42 12
77 -7408.6798 1993 42 12
78 -7408.6798 1993 42 12
79 -7408.6798 1993 42 12
80 -7408.6798 1993 42 12
81 -7408.6799 1993 42 12
82 -7408.6799 1993 42 12
83 -7408.6799 1993 42 12
84 -7408.6799 1993 42 12
85 -7408.6799 1993 42 12
86 -7408.6799 1993 42 12
87 -7408.6799 1993 42 12
88 -7408.68 1993 42 12
89 -7408.68 1993 42 12
90 -7408.68 1993 42 12
91 -7408.68 1993 42 12
92 -7408.68 1993 42 12
93 -7408.68 1993 42 12
94 -7408.68 1993 42 12
95 -7408.68 1993 42 12
96 -7408.68 1993 42 12
97 -7408.6801 1993 42 12
98 -7408.6801 1993 42 12
99 -7408.6801 1993 42 12
100 -7408.6801 1993 42 12
Loop time of 1.65093 on 1 procs for 100 steps with 2047 atoms
Performance: 5.233 ns/day, 4.586 hours/ns, 60.572 timesteps/s, 123.991 katom-step/s
99.8% CPU use with 1 MPI tasks x no OpenMP threads
MPI task timing breakdown:
Section | min time | avg time | max time |%varavg| %total
---------------------------------------------------------------
Pair | 1.6272 | 1.6272 | 1.6272 | 0.0 | 98.56
Neigh | 0 | 0 | 0 | 0.0 | 0.00
Comm | 0.012716 | 0.012716 | 0.012716 | 0.0 | 0.77
Output | 0.0078409 | 0.0078409 | 0.0078409 | 0.0 | 0.47
Modify | 0.0013654 | 0.0013654 | 0.0013654 | 0.0 | 0.08
Other | | 0.001839 | | | 0.11
Nlocal: 2047 ave 2047 max 2047 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Nghost: 7790 ave 7790 max 7790 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Neighs: 0 ave 0 max 0 min
Histogram: 1 0 0 0 0 0 0 0 0 0
FullNghs: 648022 ave 648022 max 648022 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Total # of neighbors = 648022
Ave neighs/atom = 316.57157
Neighbor list builds = 0
Dangerous builds = 0
Total wall time: 0:00:01

193
examples/PACKAGES/apip/log.02Apr25.vacancy.dynamic.lambda.no.thermostat.g++.1 Normal file
View File

@ -0,0 +1,193 @@
LAMMPS (2 Apr 2025 - Development - )
Reading data file ...
orthogonal box = (0 0 0) to (28.92 28.92 28.92)
1 by 1 by 1 MPI processor grid
reading atoms ...
2047 atoms
reading velocities ...
2047 velocities
read_data CPU = 0.009 seconds
ACE version: 2023.11.25
Recursive evaluator is used by ACE
Loading ../../../potentials/Cu-PBE-core-rep.ace
Total number of basis functions
Cu: 16 (r=1) 726 (r>1)
Mapping LAMMPS atom type #1(Cu) -> ACE species type #0
atomic load lambda:
fast potential: extract eam/apip:time_per_atom
precise potential: extract pace/apip:time_per_atom
lambda_input: extract lambda/input/apip:time_per_atom
lambda: extract lambda/zone/apip:time_per_atom
CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE
Your simulation uses code contributions which should be cited:
- fix lambda command: doi.org/10.1063/5.0245877
The log file lists these citations in BibTeX format.
CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE
WARNING: The energy is not conserved when lambda changes as fix lambda_thermostat/apip is not used. (../fix_lambda_apip.cpp:248)
Neighbor list info ...
update: every = 1 steps, delay = 0 steps, check = yes
max neighbors/atom: 2000, page size: 100000
master list distance cutoff = 9.4
ghost atom cutoff = 9.4
binsize = 4.7, bins = 7 7 7
4 neighbor lists, perpetual/occasional/extra = 4 0 0
(1) pair eam/fs/apip, perpetual, trim from (3)
attributes: full, newton on, cut 7.50679
pair build: trim
stencil: none
bin: none
(2) pair pace/apip, perpetual
attributes: full, newton on, cut 9.4
pair build: full/bin/atomonly
stencil: full/bin/3d
bin: standard
(3) pair lambda/input/csp/apip, perpetual, trim from (2)
attributes: full, newton on, cut 8
pair build: trim
stencil: none
bin: none
(4) pair lambda/zone/apip, perpetual
attributes: full, newton on, ghost
pair build: full/bin/ghost
stencil: full/ghost/bin/3d
bin: standard
Setting up Verlet run ...
Unit style : metal
Current step : 0
Time step : 0.001
Per MPI rank memory allocation (min/avg/max) = 49.37 | 49.37 | 49.37 Mbytes
Step TotEng c_lambda_types[1] c_lambda_types[2] c_lambda_types[3]
0 -7408.7649 1993 42 12
1 -7408.7649 1993 42 12
2 -7408.7649 1993 42 12
3 -7408.765 1993 42 12
4 -7408.7657 1993 42 12
5 -7408.7785 1993 42 12
6 -7408.7769 1993 42 12
7 -7408.778 1993 42 12
8 -7408.7862 1993 42 12
9 -7408.79 1993 42 12
10 -7408.7912 1993 42 12
11 -7408.8005 1993 42 12
12 -7408.8012 1993 42 12
13 -7408.8016 1993 42 12
14 -7408.8123 1993 42 12
15 -7408.8154 1993 42 12
16 -7408.8144 1993 42 12
17 -7408.8271 1993 42 12
18 -7408.8277 1993 42 12
19 -7408.8289 1993 42 12
20 -7408.8352 1993 42 12
21 -7408.8376 1993 42 12
22 -7408.841 1993 42 12
23 -7408.8507 1993 42 12
24 -7408.8496 1993 42 12
25 -7408.8544 1993 42 12
26 -7408.8645 1993 42 12
27 -7408.8665 1993 42 12
28 -7408.8713 1993 42 12
29 -7408.8763 1993 42 12
30 -7408.8812 1993 42 12
31 -7408.8842 1993 42 12
32 -7408.8905 1993 42 12
33 -7408.8947 1993 42 12
34 -7408.9048 1993 42 12
35 -7408.9099 1993 42 12
36 -7408.9101 1993 42 12
37 -7408.9159 1993 42 12
38 -7408.9256 1993 42 12
39 -7408.9241 1993 42 12
40 -7408.9342 1993 42 12
41 -7408.9423 1993 42 12
42 -7408.9402 1993 42 12
43 -7408.9452 1993 42 12
44 -7408.9548 1993 42 12
45 -7408.9543 1993 42 12
46 -7408.9607 1993 42 12
47 -7408.9699 1993 42 12
48 -7408.9751 1993 42 12
49 -7408.978 1993 42 12
50 -7408.9797 1993 42 12
51 -7408.9851 1993 42 12
52 -7408.9937 1993 42 12
53 -7408.9977 1993 42 12
54 -7408.9961 1993 42 12
55 -7409.0011 1993 42 12
56 -7409.0098 1993 42 12
57 -7409.0132 1993 42 12
58 -7409.0173 1993 42 12
59 -7409.0174 1993 42 12
60 -7409.0204 1993 42 12
61 -7409.0259 1993 42 12
62 -7409.0324 1993 42 12
63 -7409.0365 1993 42 12
64 -7409.0407 1993 42 12
65 -7409.0407 1993 42 12
66 -7409.0428 1993 42 12
67 -7409.0437 1993 42 12
68 -7409.0437 1993 42 12
69 -7409.0502 1993 42 12
70 -7409.0558 1993 42 12
71 -7409.0572 1993 42 12
72 -7409.0624 1993 42 12
73 -7409.0686 1993 42 12
74 -7409.0721 1993 42 12
75 -7409.075 1993 42 12
76 -7409.0751 1993 42 12
77 -7409.0728 1993 42 12
78 -7409.0732 1993 42 12
79 -7409.0764 1993 42 12
80 -7409.077 1993 42 12
81 -7409.0879 1993 42 12
82 -7409.0898 1993 42 12
83 -7409.0922 1993 42 12
84 -7409.0916 1993 42 12
85 -7409.0928 1993 42 12
86 -7409.0944 1993 42 12
87 -7409.1058 1993 42 12
88 -7409.1084 1993 42 12
89 -7409.1103 1993 42 12
90 -7409.1121 1993 42 12
91 -7409.1145 1993 42 12
92 -7409.1133 1993 42 12
93 -7409.1166 1993 42 12
94 -7409.12 1993 42 12
95 -7409.119 1993 42 12
96 -7409.1208 1993 42 12
97 -7409.1217 1993 42 12
98 -7409.1229 1993 42 12
99 -7409.1235 1993 42 12
100 -7409.1206 1993 42 12
Loop time of 2.01276 on 1 procs for 100 steps with 2047 atoms
Performance: 4.293 ns/day, 5.591 hours/ns, 49.683 timesteps/s, 101.701 katom-step/s
99.8% CPU use with 1 MPI tasks x no OpenMP threads
MPI task timing breakdown:
Section | min time | avg time | max time |%varavg| %total
---------------------------------------------------------------
Pair | 1.985 | 1.985 | 1.985 | 0.0 | 98.62
Neigh | 0 | 0 | 0 | 0.0 | 0.00
Comm | 0.012367 | 0.012367 | 0.012367 | 0.0 | 0.61
Output | 0.0080612 | 0.0080612 | 0.0080612 | 0.0 | 0.40
Modify | 0.0053111 | 0.0053111 | 0.0053111 | 0.0 | 0.26
Other | | 0.002 | | | 0.10
Nlocal: 2047 ave 2047 max 2047 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Nghost: 7790 ave 7790 max 7790 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Neighs: 0 ave 0 max 0 min
Histogram: 1 0 0 0 0 0 0 0 0 0
FullNghs: 291196 ave 291196 max 291196 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Total # of neighbors = 291196
Ave neighs/atom = 142.25501
Neighbor list builds = 0
Dangerous builds = 0
Total wall time: 0:00:02

197
examples/PACKAGES/apip/log.02Apr25.vacancy.dynamic.lambda.thermostat.g++.1 Normal file
View File

@ -0,0 +1,197 @@
LAMMPS (2 Apr 2025 - Development - )
Reading data file ...
orthogonal box = (0 0 0) to (28.92 28.92 28.92)
1 by 1 by 1 MPI processor grid
reading atoms ...
2047 atoms
reading velocities ...
2047 velocities
read_data CPU = 0.009 seconds
ACE version: 2023.11.25
Recursive evaluator is used by ACE
Loading ../../../potentials/Cu-PBE-core-rep.ace
Total number of basis functions
Cu: 16 (r=1) 726 (r>1)
Mapping LAMMPS atom type #1(Cu) -> ACE species type #0
atomic load lambda:
fast potential: extract eam/apip:time_per_atom
precise potential: extract pace/apip:time_per_atom
lambda_input: extract lambda/input/apip:time_per_atom
lambda: extract lambda/zone/apip:time_per_atom
CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE
Your simulation uses code contributions which should be cited:
- fix lambda command: doi.org/10.1063/5.0245877
The log file lists these citations in BibTeX format.
CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE
Neighbor list info ...
update: every = 1 steps, delay = 0 steps, check = yes
max neighbors/atom: 2000, page size: 100000
master list distance cutoff = 9.4
ghost atom cutoff = 9.4
binsize = 4.7, bins = 7 7 7
5 neighbor lists, perpetual/occasional/extra = 5 0 0
(1) pair eam/fs/apip, perpetual, trim from (3)
attributes: full, newton on, cut 7.50679
pair build: trim
stencil: none
bin: none
(2) pair pace/apip, perpetual
attributes: full, newton on, cut 9.4
pair build: full/bin/atomonly
stencil: full/bin/3d
bin: standard
(3) pair lambda/input/csp/apip, perpetual, trim from (2)
attributes: full, newton on, cut 8
pair build: trim
stencil: none
bin: none
(4) pair lambda/zone/apip, perpetual
attributes: full, newton on, ghost
pair build: full/bin/ghost
stencil: full/ghost/bin/3d
bin: standard
(5) fix lambda_thermostat/apip, perpetual, copy from (2)
attributes: full, newton on
pair build: copy
stencil: none
bin: none
Setting up Verlet run ...
Unit style : metal
Current step : 0
Time step : 0.001
Per MPI rank memory allocation (min/avg/max) = 52.93 | 52.93 | 52.93 Mbytes
Step TotEng c_lambda_types[1] c_lambda_types[2] c_lambda_types[3]
0 -7408.7649 1993 42 12
1 -7408.7649 1993 42 12
2 -7408.7649 1993 42 12
3 -7408.765 1993 42 12
4 -7408.765 1993 42 12
5 -7408.765 1993 42 12
6 -7408.765 1993 42 12
7 -7408.765 1993 42 12
8 -7408.765 1993 42 12
9 -7408.765 1993 42 12
10 -7408.7651 1993 42 12
11 -7408.7651 1993 42 12
12 -7408.7651 1993 42 12
13 -7408.7651 1993 42 12
14 -7408.7651 1993 42 12
15 -7408.7651 1993 42 12
16 -7408.7652 1993 42 12
17 -7408.7652 1993 42 12
18 -7408.7652 1993 42 12
19 -7408.7652 1993 42 12
20 -7408.7652 1993 42 12
21 -7408.7652 1993 42 12
22 -7408.7652 1993 42 12
23 -7408.7652 1993 42 12
24 -7408.7652 1993 42 12
25 -7408.7652 1993 42 12
26 -7408.7652 1993 42 12
27 -7408.7652 1993 42 12
28 -7408.7652 1993 42 12
29 -7408.7652 1993 42 12
30 -7408.7652 1993 42 12
31 -7408.7652 1993 42 12
32 -7408.7652 1993 42 12
33 -7408.7652 1993 42 12
34 -7408.7652 1993 42 12
35 -7408.7652 1993 42 12
36 -7408.7652 1993 42 12
37 -7408.7652 1993 42 12
38 -7408.7652 1993 42 12
39 -7408.7652 1993 42 12
40 -7408.7652 1993 42 12
41 -7408.7652 1993 42 12
42 -7408.7652 1993 42 12
43 -7408.7652 1993 42 12
44 -7408.7652 1993 42 12
45 -7408.7652 1993 42 12
46 -7408.7652 1993 42 12
47 -7408.7653 1993 42 12
48 -7408.7653 1993 42 12
49 -7408.7653 1993 42 12
50 -7408.7653 1993 42 12
51 -7408.7653 1993 42 12
52 -7408.7653 1993 42 12
53 -7408.7653 1993 42 12
54 -7408.7653 1993 42 12
55 -7408.7653 1993 42 12
56 -7408.7653 1993 42 12
57 -7408.7653 1993 42 12
58 -7408.7653 1993 42 12
59 -7408.7653 1993 42 12
60 -7408.7652 1993 42 12
61 -7408.7652 1993 42 12
62 -7408.7652 1993 42 12
63 -7408.7652 1993 42 12
64 -7408.7652 1993 42 12
65 -7408.7651 1993 42 12
66 -7408.7651 1993 42 12
67 -7408.7651 1993 42 12
68 -7408.7651 1993 42 12
69 -7408.7651 1993 42 12
70 -7408.765 1993 42 12
71 -7408.765 1993 42 12
72 -7408.765 1993 42 12
73 -7408.765 1993 42 12
74 -7408.765 1993 42 12
75 -7408.765 1993 42 12
76 -7408.765 1993 42 12
77 -7408.765 1993 42 12
78 -7408.765 1993 42 12
79 -7408.765 1993 42 12
80 -7408.765 1993 42 12
81 -7408.765 1993 42 12
82 -7408.765 1993 42 12
83 -7408.765 1993 42 12
84 -7408.765 1993 42 12
85 -7408.765 1993 42 12
86 -7408.765 1993 42 12
87 -7408.765 1993 42 12
88 -7408.765 1993 42 12
89 -7408.7651 1993 42 12
90 -7408.7651 1993 42 12
91 -7408.7651 1993 42 12
92 -7408.7651 1993 42 12
93 -7408.7651 1993 42 12
94 -7408.7651 1993 42 12
95 -7408.7651 1993 42 12
96 -7408.7651 1993 42 12
97 -7408.7651 1993 42 12
98 -7408.7651 1993 42 12
99 -7408.7651 1993 42 12
100 -7408.7651 1993 42 12
Loop time of 2.19492 on 1 procs for 100 steps with 2047 atoms
Performance: 3.936 ns/day, 6.097 hours/ns, 45.560 timesteps/s, 93.261 katom-step/s
99.8% CPU use with 1 MPI tasks x no OpenMP threads
MPI task timing breakdown:
Section | min time | avg time | max time |%varavg| %total
---------------------------------------------------------------
Pair | 2.0683 | 2.0683 | 2.0683 | 0.0 | 94.23
Neigh | 0 | 0 | 0 | 0.0 | 0.00
Comm | 0.012156 | 0.012156 | 0.012156 | 0.0 | 0.55
Output | 0.0084851 | 0.0084851 | 0.0084851 | 0.0 | 0.39
Modify | 0.10386 | 0.10386 | 0.10386 | 0.0 | 4.73
Other | | 0.002096 | | | 0.10
Nlocal: 2047 ave 2047 max 2047 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Nghost: 7790 ave 7790 max 7790 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Neighs: 0 ave 0 max 0 min
Histogram: 1 0 0 0 0 0 0 0 0 0
FullNghs: 291196 ave 291196 max 291196 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Total # of neighbors = 291196
Ave neighs/atom = 142.25501
Neighbor list builds = 0
Dangerous builds = 0
Total wall time: 0:00:02

201
examples/PACKAGES/apip/log.02Apr25.validate.g++.1 Normal file
View File

@ -0,0 +1,201 @@
LAMMPS (2 Apr 2025 - Development - )
Reading data file ...
orthogonal box = (0 0 0) to (7.23 7.23 7.23)
1 by 1 by 1 MPI processor grid
reading atoms ...
31 atoms
reading velocities ...
31 velocities
read_data CPU = 0.002 seconds
ACE version: 2023.11.25
Recursive evaluator is used
Loading Cu-1.yace
Total number of basis functions
Cu: 15 (r=1) 9 (r>1)
Mapping LAMMPS atom type #1(Cu) -> ACE species type #0
Neighbor list info ...
update: every = 1 steps, delay = 0 steps, check = yes
max neighbors/atom: 2000, page size: 100000
master list distance cutoff = 5.9
ghost atom cutoff = 5.9
binsize = 2.95, bins = 3 3 3
1 neighbor lists, perpetual/occasional/extra = 1 0 0
(1) pair pace, perpetual
attributes: full, newton on
pair build: full/bin/atomonly
stencil: full/bin/3d
bin: standard
Setting up Verlet run ...
Unit style : metal
Current step : 0
Time step : 0.001
Per MPI rank memory allocation (min/avg/max) = 4.908 | 4.908 | 4.908 Mbytes
Step PotEng Fnorm Fmax
0 -98.699376 49.367618 19.563052
Loop time of 6.74e-07 on 1 procs for 0 steps with 31 atoms
148.4% CPU use with 1 MPI tasks x no OpenMP threads
MPI task timing breakdown:
Section | min time | avg time | max time |%varavg| %total
---------------------------------------------------------------
Pair | 0 | 0 | 0 | 0.0 | 0.00
Neigh | 0 | 0 | 0 | 0.0 | 0.00
Comm | 0 | 0 | 0 | 0.0 | 0.00
Output | 0 | 0 | 0 | 0.0 | 0.00
Modify | 0 | 0 | 0 | 0.0 | 0.00
Other | | 6.74e-07 | | |100.00
Nlocal: 31 ave 31 max 31 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Nghost: 616 ave 616 max 616 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Neighs: 0 ave 0 max 0 min
Histogram: 1 0 0 0 0 0 0 0 0 0
FullNghs: 2132 ave 2132 max 2132 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Total # of neighbors = 2132
Ave neighs/atom = 68.774194
Neighbor list builds = 0
Dangerous builds = 0
ACE version: 2023.11.25
Recursive evaluator is used by ACE
Loading Cu-1.yace
Total number of basis functions
Cu: 15 (r=1) 9 (r>1)
Mapping LAMMPS atom type #1(Cu) -> ACE species type #0
Setting atom values ...
31 settings made for apip/lambda
Neighbor list info ...
update: every = 1 steps, delay = 0 steps, check = yes
max neighbors/atom: 2000, page size: 100000
master list distance cutoff = 7.50679
ghost atom cutoff = 7.50679
binsize = 3.753395, bins = 2 2 2
2 neighbor lists, perpetual/occasional/extra = 2 0 0
(1) pair eam/fs/apip, perpetual
attributes: full, newton on, cut 7.50679
pair build: full/bin/atomonly
stencil: full/bin/3d
bin: standard
(2) pair pace/apip, perpetual, copy from (1)
attributes: full, newton on
pair build: copy
stencil: none
bin: none
Setting up Verlet run ...
Unit style : metal
Current step : 0
Time step : 0.001
Per MPI rank memory allocation (min/avg/max) = 5.564 | 5.564 | 5.564 Mbytes
Step PotEng Fnorm Fmax
0 -98.699376 49.367618 19.563052
Loop time of 5.62e-07 on 1 procs for 0 steps with 31 atoms
177.9% CPU use with 1 MPI tasks x no OpenMP threads
MPI task timing breakdown:
Section | min time | avg time | max time |%varavg| %total
---------------------------------------------------------------
Pair | 0 | 0 | 0 | 0.0 | 0.00
Neigh | 0 | 0 | 0 | 0.0 | 0.00
Comm | 0 | 0 | 0 | 0.0 | 0.00
Output | 0 | 0 | 0 | 0.0 | 0.00
Modify | 0 | 0 | 0 | 0.0 | 0.00
Other | | 5.62e-07 | | |100.00
Nlocal: 31 ave 31 max 31 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Nghost: 957 ave 957 max 957 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Neighs: 0 ave 0 max 0 min
Histogram: 1 0 0 0 0 0 0 0 0 0
FullNghs: 4558 ave 4558 max 4558 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Total # of neighbors = 4558
Ave neighs/atom = 147.03226
Neighbor list builds = 0
Dangerous builds = 0
Setting atom values ...
31 settings made for apip/lambda
Setting up Verlet run ...
Unit style : metal
Current step : 0
Time step : 0.001
Per MPI rank memory allocation (min/avg/max) = 5.564 | 5.564 | 5.564 Mbytes
Step PotEng Fnorm Fmax
0 -85.025323 53.839249 22.182149
Loop time of 5.49e-07 on 1 procs for 0 steps with 31 atoms
182.1% CPU use with 1 MPI tasks x no OpenMP threads
MPI task timing breakdown:
Section | min time | avg time | max time |%varavg| %total
---------------------------------------------------------------
Pair | 0 | 0 | 0 | 0.0 | 0.00
Neigh | 0 | 0 | 0 | 0.0 | 0.00
Comm | 0 | 0 | 0 | 0.0 | 0.00
Output | 0 | 0 | 0 | 0.0 | 0.00
Modify | 0 | 0 | 0 | 0.0 | 0.00
Other | | 5.49e-07 | | |100.00
Nlocal: 31 ave 31 max 31 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Nghost: 957 ave 957 max 957 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Neighs: 0 ave 0 max 0 min
Histogram: 1 0 0 0 0 0 0 0 0 0
FullNghs: 4558 ave 4558 max 4558 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Total # of neighbors = 4558
Ave neighs/atom = 147.03226
Neighbor list builds = 0
Dangerous builds = 0
Neighbor list info ...
update: every = 1 steps, delay = 0 steps, check = yes
max neighbors/atom: 2000, page size: 100000
master list distance cutoff = 7.50679
ghost atom cutoff = 7.50679
binsize = 3.753395, bins = 2 2 2
1 neighbor lists, perpetual/occasional/extra = 1 0 0
(1) pair eam/fs, perpetual
attributes: half, newton on
pair build: half/bin/atomonly/newton
stencil: half/bin/3d
bin: standard
Setting up Verlet run ...
Unit style : metal
Current step : 0
Time step : 0.001
Per MPI rank memory allocation (min/avg/max) = 5.183 | 5.183 | 5.183 Mbytes
Step PotEng Fnorm Fmax
0 -85.025323 53.839249 22.182149
Loop time of 4.77e-07 on 1 procs for 0 steps with 31 atoms
0.0% CPU use with 1 MPI tasks x no OpenMP threads
MPI task timing breakdown:
Section | min time | avg time | max time |%varavg| %total
---------------------------------------------------------------
Pair | 0 | 0 | 0 | 0.0 | 0.00
Neigh | 0 | 0 | 0 | 0.0 | 0.00
Comm | 0 | 0 | 0 | 0.0 | 0.00
Output | 0 | 0 | 0 | 0.0 | 0.00
Modify | 0 | 0 | 0 | 0.0 | 0.00
Other | | 4.77e-07 | | |100.00
Nlocal: 31 ave 31 max 31 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Nghost: 957 ave 957 max 957 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Neighs: 2279 ave 2279 max 2279 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Total # of neighbors = 2279
Ave neighs/atom = 73.516129
Neighbor list builds = 0
Dangerous builds = 0
Total wall time: 0:00:00

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

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

46
examples/PACKAGES/neighbor-swap/in.KMC_pulse_center
View File

@ -1,46 +0,0 @@
# May 2025
# Test script for MD-KMC accelerated diffusion testing in LAMMPS
# Created by Jacob Tavenner, Baylor University
# Initiation -------------------------------------
units metal
dimension 3
boundary p p p
atom_style atomic
# Atom Definition --------------------------------
lattice fcc 3.762
region whole block 0 1 0 1 0 1
create_box 2 whole
create_atoms 1 region whole
replicate 6 16 6
region puck block INF INF 7 9 INF INF
set region puck type 2
# Force Fields -----------------------------------
pair_style meam
pair_coeff * * library_2nn.meam Mo Co Ni V Fe Al Cr MoCoNiVFeAlCr_2nn.meam Ni Cr
# Settings ---------------------------------------
timestep 0.002
thermo 100
# Computations -----------------------------------
compute voroN all voronoi/atom neighbors yes
run 0
thermo_style custom step temp press pxx pyy pzz lx ly lz vol pe
# Execution --------------------------------------
velocity all create 2400 908124 loop geom
fix temp all npt temp 1000 1000 1000 aniso 0 0 1
fix mc all neighbor/swap 50 12 1340723 1000 3 voroN diff 2
thermo_style custom step temp press pxx pyy pzz lx ly lz vol pe f_mc[*]
#dump dump2 all custom 5000 dump.edge-3_Ni-Cr.* id type x y z c_eng c_csym
run 1000
#write_data pulse_center.data

47
examples/PACKAGES/neighbor-swap/in.KMC_pulse_edge
View File

@ -1,47 +0,0 @@
# May 2025
# Test script for MD-KMC accelerated diffusion testing in LAMMPS
# Created by Jacob Tavenner, Baylor University
# Initiation -------------------------------------
units metal
dimension 3
boundary p p p
atom_style atomic
# Atom Definition --------------------------------
lattice fcc 3.762
region whole block 0 1 0 1 0 1
create_box 2 whole
create_atoms 1 region whole
replicate 6 16 6
region puck block INF INF INF 2 INF INF
set region puck type 2
# Force Fields -----------------------------------
pair_style meam
pair_coeff * * library_2nn.meam Mo Co Ni V Fe Al Cr MoCoNiVFeAlCr_2nn.meam Ni Cr
# Settings ---------------------------------------
timestep 0.002
thermo 100
# Computations -----------------------------------
compute voroN all voronoi/atom neighbors yes
run 0
thermo_style custom step temp press pxx pyy pzz lx ly lz vol pe
# Execution --------------------------------------
velocity all create 2400 908124 loop geom
fix temp all npt temp 1000 1000 1000 aniso 0 0 1
fix mc all neighbor/swap 50 12 1340723 1000 3 voroN diff 2
thermo_style custom step temp press pxx pyy pzz lx ly lz vol pe f_mc[*]
#dump dump2 all custom 5000 dump.edge-3_Ni-Cr.* id type x y z c_eng c_csym
run 1000
#write_data pulse_end.data

1
examples/PACKAGES/neighbor-swap/library_2nn.meam
View File

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

154
examples/PACKAGES/neighbor-swap/log.22May22.KMC_pulse_center.g++.1
View File

@ -1,154 +0,0 @@
LAMMPS (2 Apr 2025 - Development - patch_2Apr2025-384-g88bc7dc720-modified)
using 1 OpenMP thread(s) per MPI task
# May 2025
# Test script for MD-KMC accelerated diffusion testing in LAMMPS
# Created by Jacob Tavenner, Baylor University
# Initiation -------------------------------------
units metal
dimension 3
boundary p p p
atom_style atomic
# Atom Definition --------------------------------
lattice fcc 3.762
Lattice spacing in x,y,z = 3.762 3.762 3.762
region whole block 0 1 0 1 0 1
create_box 2 whole
Created orthogonal box = (0 0 0) to (3.762 3.762 3.762)
1 by 1 by 1 MPI processor grid
create_atoms 1 region whole
Created 4 atoms
using lattice units in orthogonal box = (0 0 0) to (3.762 3.762 3.762)
create_atoms CPU = 0.000 seconds
replicate 6 16 6
Replication is creating a 6x16x6 = 576 times larger system...
orthogonal box = (0 0 0) to (22.572 60.192 22.572)
1 by 1 by 1 MPI processor grid
2304 atoms
replicate CPU = 0.000 seconds
region puck block INF INF 7 9 INF INF
set region puck type 2
Setting atom values ...
360 settings made for type
# Force Fields -----------------------------------
pair_style meam
pair_coeff * * library_2nn.meam Mo Co Ni V Fe Al Cr MoCoNiVFeAlCr_2nn.meam Ni Cr
Reading MEAM library file library_2nn.meam with DATE: 2024-08-08
Reading MEAM potential file MoCoNiVFeAlCr_2nn.meam with DATE: 2024-08-08
# Settings ---------------------------------------
timestep 0.002
thermo 100
# Computations -----------------------------------
compute voroN all voronoi/atom neighbors yes
run 0
WARNING: No fixes with time integration, atoms won't move
For more information see https://docs.lammps.org/err0028 (src/verlet.cpp:60)
Neighbor list info ...
update: every = 1 steps, delay = 0 steps, check = yes
max neighbors/atom: 2000, page size: 100000
master list distance cutoff = 6.8
ghost atom cutoff = 6.8
binsize = 3.4, bins = 7 18 7
2 neighbor lists, perpetual/occasional/extra = 2 0 0
(1) pair meam, perpetual
attributes: full, newton on
pair build: full/bin/atomonly
stencil: full/bin/3d
bin: standard
(2) pair meam, perpetual, half/full from (1)
attributes: half, newton on
pair build: halffull/newton
stencil: none
bin: none
Per MPI rank memory allocation (min/avg/max) = 13.32 | 13.32 | 13.32 Mbytes
Step Temp E_pair E_mol TotEng Press
0 0 -9674.3728 0 -9674.3728 -212400.94
Loop time of 1.202e-06 on 1 procs for 0 steps with 2304 atoms
0.0% CPU use with 1 MPI tasks x 1 OpenMP threads
MPI task timing breakdown:
Section | min time | avg time | max time |%varavg| %total
---------------------------------------------------------------
Pair | 0 | 0 | 0 | 0.0 | 0.00
Neigh | 0 | 0 | 0 | 0.0 | 0.00
Comm | 0 | 0 | 0 | 0.0 | 0.00
Output | 0 | 0 | 0 | 0.0 | 0.00
Modify | 0 | 0 | 0 | 0.0 | 0.00
Other | | 1.202e-06 | | |100.00
Nlocal: 2304 ave 2304 max 2304 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Nghost: 4735 ave 4735 max 4735 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Neighs: 99072 ave 99072 max 99072 min
Histogram: 1 0 0 0 0 0 0 0 0 0
FullNghs: 198144 ave 198144 max 198144 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Total # of neighbors = 198144
Ave neighs/atom = 86
Neighbor list builds = 0
Dangerous builds = 0
thermo_style custom step temp press pxx pyy pzz lx ly lz vol pe
# Execution --------------------------------------
velocity all create 2400 908124
fix temp all npt temp 1000 1000 1000 aniso 0 0 1
fix mc all neighbor/swap 50 12 1340723 1000 3 voroN diff 2
thermo_style custom step temp press pxx pyy pzz lx ly lz vol pe f_mc[*]
#dump dump2 all custom 5000 dump.edge-3_Ni-Cr.* id type x y z c_eng c_csym
run 1000
Per MPI rank memory allocation (min/avg/max) = 13.32 | 13.32 | 13.32 Mbytes
Step Temp Press Pxx Pyy Pzz Lx Ly Lz Volume PotEng f_mc[1] f_mc[2]
0 2400 -187517.52 -187403.07 -187750.14 -187399.35 22.572 60.192 22.572 30667.534 -9674.3728 0 0
100 1664.9956 14000 14280.682 15095.077 12624.241 21.635315 57.726568 21.64791 27036.778 -9592.8978 24 22
200 1560.0093 -5452.2434 -5749.5816 -2957.4228 -7649.7258 21.734212 58.085959 21.724853 27426.596 -9562.8822 48 45
300 1586.4553 2030.9253 2776.4677 775.50538 2540.803 21.678654 58.101753 21.654423 27275.215 -9571.1308 72 66
400 1603.6896 -223.16773 156.17673 -478.47929 -347.20061 21.701021 58.098904 21.657752 27306.213 -9576.4456 96 90
500 1618.236 -925.51874 -1640.9078 451.6228 -1587.2713 21.718334 58.042685 21.666081 27312.054 -9581.2045 120 110
600 1581.9995 290.10126 1359.1314 1407.5434 -1896.371 21.679813 58.086147 21.692118 27316.815 -9570.4803 144 132
700 1568.3261 1387.3472 938.81523 2159.3686 1063.8577 21.685928 58.075626 21.67273 27295.153 -9566.2914 168 155
800 1607.1531 46.792964 -453.90265 -1533.3908 2127.6723 21.685188 58.202356 21.628338 27297.753 -9577.7848 192 177
900 1573.4747 -84.225488 548.90935 -1356.7479 555.16208 21.69634 58.150052 21.651847 27316.908 -9567.7039 216 196
1000 1609.2136 1215.0833 764.08936 3301.0811 -419.92053 21.683731 58.000401 21.68726 27275.31 -9578.2843 240 219
Loop time of 31.6263 on 1 procs for 1000 steps with 2304 atoms
Performance: 5.464 ns/day, 4.393 hours/ns, 31.619 timesteps/s, 72.851 katom-step/s
99.2% CPU use with 1 MPI tasks x 1 OpenMP threads
MPI task timing breakdown:
Section | min time | avg time | max time |%varavg| %total
---------------------------------------------------------------
Pair | 28.487 | 28.487 | 28.487 | 0.0 | 90.07
Neigh | 0.22789 | 0.22789 | 0.22789 | 0.0 | 0.72
Comm | 0.010808 | 0.010808 | 0.010808 | 0.0 | 0.03
Output | 0.00033526 | 0.00033526 | 0.00033526 | 0.0 | 0.00
Modify | 2.8963 | 2.8963 | 2.8963 | 0.0 | 9.16
Other | | 0.003905 | | | 0.01
Nlocal: 2304 ave 2304 max 2304 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Nghost: 4750 ave 4750 max 4750 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Neighs: 130023 ave 130023 max 130023 min
Histogram: 1 0 0 0 0 0 0 0 0 0
FullNghs: 260046 ave 260046 max 260046 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Total # of neighbors = 260046
Ave neighs/atom = 112.86719
Neighbor list builds = 65
Dangerous builds = 0
#write_data pulse_center.data
Total wall time: 0:00:31

154
examples/PACKAGES/neighbor-swap/log.22May22.KMC_pulse_center.g++.4
View File

@ -1,154 +0,0 @@
LAMMPS (2 Apr 2025 - Development - patch_2Apr2025-384-g88bc7dc720-modified)
using 1 OpenMP thread(s) per MPI task
# May 2025
# Test script for MD-KMC accelerated diffusion testing in LAMMPS
# Created by Jacob Tavenner, Baylor University
# Initiation -------------------------------------
units metal
dimension 3
boundary p p p
atom_style atomic
# Atom Definition --------------------------------
lattice fcc 3.762
Lattice spacing in x,y,z = 3.762 3.762 3.762
region whole block 0 1 0 1 0 1
create_box 2 whole
Created orthogonal box = (0 0 0) to (3.762 3.762 3.762)
1 by 2 by 2 MPI processor grid
create_atoms 1 region whole
Created 4 atoms
using lattice units in orthogonal box = (0 0 0) to (3.762 3.762 3.762)
create_atoms CPU = 0.000 seconds
replicate 6 16 6
Replication is creating a 6x16x6 = 576 times larger system...
orthogonal box = (0 0 0) to (22.572 60.192 22.572)
1 by 4 by 1 MPI processor grid
2304 atoms
replicate CPU = 0.000 seconds
region puck block INF INF 7 9 INF INF
set region puck type 2
Setting atom values ...
360 settings made for type
# Force Fields -----------------------------------
pair_style meam
pair_coeff * * library_2nn.meam Mo Co Ni V Fe Al Cr MoCoNiVFeAlCr_2nn.meam Ni Cr
Reading MEAM library file library_2nn.meam with DATE: 2024-08-08
Reading MEAM potential file MoCoNiVFeAlCr_2nn.meam with DATE: 2024-08-08
# Settings ---------------------------------------
timestep 0.002
thermo 100
# Computations -----------------------------------
compute voroN all voronoi/atom neighbors yes
run 0
WARNING: No fixes with time integration, atoms won't move
For more information see https://docs.lammps.org/err0028 (src/verlet.cpp:60)
Neighbor list info ...
update: every = 1 steps, delay = 0 steps, check = yes
max neighbors/atom: 2000, page size: 100000
master list distance cutoff = 6.8
ghost atom cutoff = 6.8
binsize = 3.4, bins = 7 18 7
2 neighbor lists, perpetual/occasional/extra = 2 0 0
(1) pair meam, perpetual
attributes: full, newton on
pair build: full/bin/atomonly
stencil: full/bin/3d
bin: standard
(2) pair meam, perpetual, half/full from (1)
attributes: half, newton on
pair build: halffull/newton
stencil: none
bin: none
Per MPI rank memory allocation (min/avg/max) = 9.636 | 9.636 | 9.636 Mbytes
Step Temp E_pair E_mol TotEng Press
0 0 -9674.3728 0 -9674.3728 -212400.94
Loop time of 1.422e-06 on 4 procs for 0 steps with 2304 atoms
35.2% CPU use with 4 MPI tasks x 1 OpenMP threads
MPI task timing breakdown:
Section | min time | avg time | max time |%varavg| %total
---------------------------------------------------------------
Pair | 0 | 0 | 0 | 0.0 | 0.00
Neigh | 0 | 0 | 0 | 0.0 | 0.00
Comm | 0 | 0 | 0 | 0.0 | 0.00
Output | 0 | 0 | 0 | 0.0 | 0.00
Modify | 0 | 0 | 0 | 0.0 | 0.00
Other | | 1.422e-06 | | |100.00
Nlocal: 576 ave 576 max 576 min
Histogram: 4 0 0 0 0 0 0 0 0 0
Nghost: 2131 ave 2131 max 2131 min
Histogram: 4 0 0 0 0 0 0 0 0 0
Neighs: 24768 ave 24768 max 24768 min
Histogram: 4 0 0 0 0 0 0 0 0 0
FullNghs: 49536 ave 49536 max 49536 min
Histogram: 4 0 0 0 0 0 0 0 0 0
Total # of neighbors = 198144
Ave neighs/atom = 86
Neighbor list builds = 0
Dangerous builds = 0
thermo_style custom step temp press pxx pyy pzz lx ly lz vol pe
# Execution --------------------------------------
velocity all create 2400 908124
fix temp all npt temp 1000 1000 1000 aniso 0 0 1
fix mc all neighbor/swap 50 12 1340723 1000 3 voroN diff 2
thermo_style custom step temp press pxx pyy pzz lx ly lz vol pe f_mc[*]
#dump dump2 all custom 5000 dump.edge-3_Ni-Cr.* id type x y z c_eng c_csym
run 1000
Per MPI rank memory allocation (min/avg/max) = 9.636 | 9.636 | 9.636 Mbytes
Step Temp Press Pxx Pyy Pzz Lx Ly Lz Volume PotEng f_mc[1] f_mc[2]
0 2400 -187517.52 -187403.09 -187750.05 -187399.42 22.572 60.192 22.572 30667.534 -9674.3728 0 0
100 1668.8754 13300.763 12419.304 15568.772 11914.212 21.636248 57.724775 21.647685 27036.823 -9594.7526 24 23
200 1584.9699 -5686.0414 -4741.8496 -5914.7681 -6401.5064 21.729384 58.060532 21.730736 27415.923 -9571.0639 48 46
300 1582.0473 2806.2983 3413.4122 2716.0124 2289.4702 21.6679 58.033587 21.694744 27280.402 -9570.5549 72 69
400 1582.5825 845.29268 -849.61221 2123.5339 1261.9563 21.676298 58.14253 21.656418 27293.905 -9570.7948 96 93
500 1591.7285 -501.17955 1151.9743 -1719.3712 -936.14174 21.696367 58.157211 21.648308 27315.839 -9573.5089 120 116
600 1610.708 -821.74669 -1002.4957 291.88502 -1754.6294 21.730338 58.008213 21.661226 27304.8 -9579.5573 144 138
700 1598.5176 -590.00633 -1844.42 408.97706 -334.57602 21.712908 57.96131 21.698129 27307.281 -9575.8973 168 162
800 1584.3478 330.16711 666.88818 74.698331 248.91482 21.650908 58.045055 21.719838 27295.933 -9571.9268 192 186
900 1557.9946 1471.1207 2124.6512 1526.9937 761.71731 21.645578 58.156083 21.681637 27293.323 -9564.4385 216 207
1000 1582.5312 379.57005 -602.96446 2696.737 -955.06238 21.655418 58.231248 21.649581 27300.598 -9571.9879 240 227
Loop time of 9.1632 on 4 procs for 1000 steps with 2304 atoms
Performance: 18.858 ns/day, 1.273 hours/ns, 109.132 timesteps/s, 251.440 katom-step/s
98.5% CPU use with 4 MPI tasks x 1 OpenMP threads
MPI task timing breakdown:
Section | min time | avg time | max time |%varavg| %total
---------------------------------------------------------------
Pair | 7.867 | 7.9923 | 8.1311 | 4.3 | 87.22
Neigh | 0.054997 | 0.057518 | 0.060145 | 1.0 | 0.63
Comm | 0.017529 | 0.14801 | 0.27408 | 29.5 | 1.62
Output | 0.00015963 | 0.00017216 | 0.00020869 | 0.0 | 0.00
Modify | 0.95227 | 0.96325 | 0.9917 | 1.7 | 10.51
Other | | 0.001983 | | | 0.02
Nlocal: 576 ave 609 max 540 min
Histogram: 2 0 0 0 0 0 0 0 0 2
Nghost: 2161.5 ave 2173 max 2151 min
Histogram: 1 0 1 0 0 0 1 0 0 1
Neighs: 32450.2 ave 35422 max 29271 min
Histogram: 2 0 0 0 0 0 0 0 0 2
FullNghs: 64900.5 ave 70800 max 58684 min
Histogram: 2 0 0 0 0 0 0 0 0 2
Total # of neighbors = 259602
Ave neighs/atom = 112.67448
Neighbor list builds = 62
Dangerous builds = 0
#write_data pulse_center.data
Total wall time: 0:00:09

155
examples/PACKAGES/neighbor-swap/log.22May22.KMC_pulse_edge.g++.1
View File

@ -1,155 +0,0 @@
LAMMPS (2 Apr 2025 - Development - patch_2Apr2025-384-g88bc7dc720-modified)
using 1 OpenMP thread(s) per MPI task
# May 2025
# Test script for MD-KMC accelerated diffusion testing in LAMMPS
# Created by Jacob Tavenner, Baylor University
# Initiation -------------------------------------
units metal
dimension 3
boundary p p p
atom_style atomic
# Atom Definition --------------------------------
lattice fcc 3.762
Lattice spacing in x,y,z = 3.762 3.762 3.762
region whole block 0 1 0 1 0 1
create_box 2 whole
Created orthogonal box = (0 0 0) to (3.762 3.762 3.762)
1 by 1 by 1 MPI processor grid
create_atoms 1 region whole
Created 4 atoms
using lattice units in orthogonal box = (0 0 0) to (3.762 3.762 3.762)
create_atoms CPU = 0.000 seconds
replicate 6 16 6
Replication is creating a 6x16x6 = 576 times larger system...
orthogonal box = (0 0 0) to (22.572 60.192 22.572)
1 by 1 by 1 MPI processor grid
2304 atoms
replicate CPU = 0.000 seconds
region puck block INF INF INF 2 INF INF
set region puck type 2
Setting atom values ...
360 settings made for type
# Force Fields -----------------------------------
pair_style meam
pair_coeff * * library_2nn.meam Mo Co Ni V Fe Al Cr MoCoNiVFeAlCr_2nn.meam Ni Cr
Reading MEAM library file library_2nn.meam with DATE: 2024-08-08
Reading MEAM potential file MoCoNiVFeAlCr_2nn.meam with DATE: 2024-08-08
# Settings ---------------------------------------
timestep 0.002
thermo 100
# Computations -----------------------------------
compute voroN all voronoi/atom neighbors yes
run 0
WARNING: No fixes with time integration, atoms won't move
For more information see https://docs.lammps.org/err0028 (src/verlet.cpp:60)
Neighbor list info ...
update: every = 1 steps, delay = 0 steps, check = yes
max neighbors/atom: 2000, page size: 100000
master list distance cutoff = 6.8
ghost atom cutoff = 6.8
binsize = 3.4, bins = 7 18 7
2 neighbor lists, perpetual/occasional/extra = 2 0 0
(1) pair meam, perpetual
attributes: full, newton on
pair build: full/bin/atomonly
stencil: full/bin/3d
bin: standard
(2) pair meam, perpetual, half/full from (1)
attributes: half, newton on
pair build: halffull/newton
stencil: none
bin: none
Per MPI rank memory allocation (min/avg/max) = 13.32 | 13.32 | 13.32 Mbytes
Step Temp E_pair E_mol TotEng Press
0 0 -9674.3728 0 -9674.3728 -212400.94
Loop time of 1.232e-06 on 1 procs for 0 steps with 2304 atoms
81.2% CPU use with 1 MPI tasks x 1 OpenMP threads
MPI task timing breakdown:
Section | min time | avg time | max time |%varavg| %total
---------------------------------------------------------------
Pair | 0 | 0 | 0 | 0.0 | 0.00
Neigh | 0 | 0 | 0 | 0.0 | 0.00
Comm | 0 | 0 | 0 | 0.0 | 0.00
Output | 0 | 0 | 0 | 0.0 | 0.00
Modify | 0 | 0 | 0 | 0.0 | 0.00
Other | | 1.232e-06 | | |100.00
Nlocal: 2304 ave 2304 max 2304 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Nghost: 4735 ave 4735 max 4735 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Neighs: 99072 ave 99072 max 99072 min
Histogram: 1 0 0 0 0 0 0 0 0 0
FullNghs: 198144 ave 198144 max 198144 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Total # of neighbors = 198144
Ave neighs/atom = 86
Neighbor list builds = 0
Dangerous builds = 0
thermo_style custom step temp press pxx pyy pzz lx ly lz vol pe
# Execution --------------------------------------
velocity all create 2400 908124 loop geom
fix temp all npt temp 1000 1000 1000 aniso 0 0 1
fix mc all neighbor/swap 50 12 1340723 1000 3 voroN diff 2
thermo_style custom step temp press pxx pyy pzz lx ly lz vol pe f_mc[*]
#dump dump2 all custom 5000 dump.edge-3_Ni-Cr.* id type x y z c_eng c_csym
run 1000
Per MPI rank memory allocation (min/avg/max) = 13.32 | 13.32 | 13.32 Mbytes
Step Temp Press Pxx Pyy Pzz Lx Ly Lz Volume PotEng f_mc[1] f_mc[2]
0 2400 -187517.52 -187464.47 -188202.62 -186885.48 22.572 60.192 22.572 30667.534 -9674.3728 0 0
100 1665.6154 14281.316 14426.547 14555.867 13861.534 21.637238 57.719793 21.637281 27022.733 -9594.4303 24 24
200 1603.3309 -7325.7341 -8878.1524 -5333.0485 -7766.0015 21.710246 58.122827 21.725933 27415.106 -9577.4545 48 48
300 1603.2974 207.19165 1983.4565 -1841.9518 480.07024 21.678227 58.079126 21.674033 27288.745 -9577.6391 72 69
400 1600.1515 810.95054 1087.969 802.04946 542.83316 21.683731 58.045848 21.678505 27285.662 -9576.6508 96 92
500 1629.8313 -2808.1005 -3197.9357 310.89931 -5537.265 21.683924 58.090375 21.697076 27330.229 -9585.5435 120 113
600 1598.8232 -67.845623 -1573.0718 -1526.7607 2896.2957 21.70213 58.12191 21.653853 27313.504 -9576.4147 144 137
700 1607.2185 154.66718 -1777.2469 2566.4705 -325.22208 21.712408 57.971553 21.678708 27287.033 -9579.1772 168 158
800 1582.559 -891.23631 -632.46037 -636.88203 -1404.3665 21.671936 58.127004 21.678224 27308.594 -9571.6663 192 180
900 1586.7172 -617.17083 -2495.5378 -2302.8766 2946.9018 21.658489 58.181921 21.668968 27305.771 -9572.9641 216 204
1000 1607.563 -389.8113 810.4908 298.84287 -2278.7676 21.624573 58.076745 21.724272 27283.183 -9579.5034 240 227
Loop time of 31.7733 on 1 procs for 1000 steps with 2304 atoms
Performance: 5.439 ns/day, 4.413 hours/ns, 31.473 timesteps/s, 72.514 katom-step/s
99.2% CPU use with 1 MPI tasks x 1 OpenMP threads
MPI task timing breakdown:
Section | min time | avg time | max time |%varavg| %total
---------------------------------------------------------------
Pair | 28.604 | 28.604 | 28.604 | 0.0 | 90.02
Neigh | 0.21293 | 0.21293 | 0.21293 | 0.0 | 0.67
Comm | 0.010645 | 0.010645 | 0.010645 | 0.0 | 0.03
Output | 0.00033194 | 0.00033194 | 0.00033194 | 0.0 | 0.00
Modify | 2.9411 | 2.9411 | 2.9411 | 0.0 | 9.26
Other | | 0.00448 | | | 0.01
Nlocal: 2304 ave 2304 max 2304 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Nghost: 4748 ave 4748 max 4748 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Neighs: 130301 ave 130301 max 130301 min
Histogram: 1 0 0 0 0 0 0 0 0 0
FullNghs: 260602 ave 260602 max 260602 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Total # of neighbors = 260602
Ave neighs/atom = 113.10851
Neighbor list builds = 62
Dangerous builds = 0
#write_data pulse_end.data
Total wall time: 0:00:31

155
examples/PACKAGES/neighbor-swap/log.22May22.KMC_pulse_edge.g++.4
View File

@ -1,155 +0,0 @@
LAMMPS (2 Apr 2025 - Development - patch_2Apr2025-384-g88bc7dc720-modified)
using 1 OpenMP thread(s) per MPI task
# May 2025
# Test script for MD-KMC accelerated diffusion testing in LAMMPS
# Created by Jacob Tavenner, Baylor University
# Initiation -------------------------------------
units metal
dimension 3
boundary p p p
atom_style atomic
# Atom Definition --------------------------------
lattice fcc 3.762
Lattice spacing in x,y,z = 3.762 3.762 3.762
region whole block 0 1 0 1 0 1
create_box 2 whole
Created orthogonal box = (0 0 0) to (3.762 3.762 3.762)
1 by 2 by 2 MPI processor grid
create_atoms 1 region whole
Created 4 atoms
using lattice units in orthogonal box = (0 0 0) to (3.762 3.762 3.762)
create_atoms CPU = 0.000 seconds
replicate 6 16 6
Replication is creating a 6x16x6 = 576 times larger system...
orthogonal box = (0 0 0) to (22.572 60.192 22.572)
1 by 4 by 1 MPI processor grid
2304 atoms
replicate CPU = 0.000 seconds
region puck block INF INF INF 2 INF INF
set region puck type 2
Setting atom values ...
360 settings made for type
# Force Fields -----------------------------------
pair_style meam
pair_coeff * * library_2nn.meam Mo Co Ni V Fe Al Cr MoCoNiVFeAlCr_2nn.meam Ni Cr
Reading MEAM library file library_2nn.meam with DATE: 2024-08-08
Reading MEAM potential file MoCoNiVFeAlCr_2nn.meam with DATE: 2024-08-08
# Settings ---------------------------------------
timestep 0.002
thermo 100
# Computations -----------------------------------
compute voroN all voronoi/atom neighbors yes
run 0
WARNING: No fixes with time integration, atoms won't move
For more information see https://docs.lammps.org/err0028 (src/verlet.cpp:60)
Neighbor list info ...
update: every = 1 steps, delay = 0 steps, check = yes
max neighbors/atom: 2000, page size: 100000
master list distance cutoff = 6.8
ghost atom cutoff = 6.8
binsize = 3.4, bins = 7 18 7
2 neighbor lists, perpetual/occasional/extra = 2 0 0
(1) pair meam, perpetual
attributes: full, newton on
pair build: full/bin/atomonly
stencil: full/bin/3d
bin: standard
(2) pair meam, perpetual, half/full from (1)
attributes: half, newton on
pair build: halffull/newton
stencil: none
bin: none
Per MPI rank memory allocation (min/avg/max) = 9.636 | 9.636 | 9.636 Mbytes
Step Temp E_pair E_mol TotEng Press
0 0 -9674.3728 0 -9674.3728 -212400.94
Loop time of 1.53e-06 on 4 procs for 0 steps with 2304 atoms
65.4% CPU use with 4 MPI tasks x 1 OpenMP threads
MPI task timing breakdown:
Section | min time | avg time | max time |%varavg| %total
---------------------------------------------------------------
Pair | 0 | 0 | 0 | 0.0 | 0.00
Neigh | 0 | 0 | 0 | 0.0 | 0.00
Comm | 0 | 0 | 0 | 0.0 | 0.00
Output | 0 | 0 | 0 | 0.0 | 0.00
Modify | 0 | 0 | 0 | 0.0 | 0.00
Other | | 1.53e-06 | | |100.00
Nlocal: 576 ave 576 max 576 min
Histogram: 4 0 0 0 0 0 0 0 0 0
Nghost: 2131 ave 2131 max 2131 min
Histogram: 4 0 0 0 0 0 0 0 0 0
Neighs: 24768 ave 24768 max 24768 min
Histogram: 4 0 0 0 0 0 0 0 0 0
FullNghs: 49536 ave 49536 max 49536 min
Histogram: 4 0 0 0 0 0 0 0 0 0
Total # of neighbors = 198144
Ave neighs/atom = 86
Neighbor list builds = 0
Dangerous builds = 0
thermo_style custom step temp press pxx pyy pzz lx ly lz vol pe
# Execution --------------------------------------
velocity all create 2400 908124 loop geom
fix temp all npt temp 1000 1000 1000 aniso 0 0 1
fix mc all neighbor/swap 50 12 1340723 1000 3 voroN diff 2
thermo_style custom step temp press pxx pyy pzz lx ly lz vol pe f_mc[*]
#dump dump2 all custom 5000 dump.edge-3_Ni-Cr.* id type x y z c_eng c_csym
run 1000
Per MPI rank memory allocation (min/avg/max) = 9.636 | 9.636 | 9.636 Mbytes
Step Temp Press Pxx Pyy Pzz Lx Ly Lz Volume PotEng f_mc[1] f_mc[2]
0 2400 -187517.52 -187464.47 -188202.62 -186885.48 22.572 60.192 22.572 30667.534 -9674.3728 0 0
100 1665.569 14271.813 14638.855 14316.569 13860.016 21.63675 57.721065 21.637799 27023.366 -9594.291 24 24
200 1598.6479 -6990.8349 -8574.1986 -5033.6147 -7364.6916 21.708963 58.123129 21.724821 27412.223 -9575.7322 48 47
300 1604.388 456.43285 1926.408 -1214.1721 657.0626 21.673369 58.090421 21.671716 27285.018 -9577.698 72 70
400 1601.1591 1303.6721 703.88473 1137.6607 2069.471 21.684004 58.049595 21.671161 27278.522 -9576.4811 96 94
500 1623.6044 -2243.2478 -2084.532 320.87709 -4966.0885 21.686171 58.097101 21.695911 27334.758 -9583.1878 120 118
600 1587.2041 421.60034 190.88741 -328.76599 1402.6796 21.712439 58.086039 21.655927 27312.229 -9572.559 144 141
700 1591.2923 32.327829 -2893.2353 1839.7574 1150.4614 21.719102 57.999862 21.666164 27292.974 -9573.9009 168 165
800 1580.8587 -105.51079 654.26389 -160.04168 -810.75457 21.670225 58.109245 21.684683 27306.229 -9570.6482 192 186
900 1570.7648 1290.088 1252.3689 255.62548 2362.2695 21.68101 58.100507 21.658755 27283.051 -9567.9864 216 209
1000 1598.1483 -125.35291 -3626.5479 3404.789 -154.29983 21.720146 57.952942 21.686111 27297.313 -9576.2975 240 231
Loop time of 9.17241 on 4 procs for 1000 steps with 2304 atoms
Performance: 18.839 ns/day, 1.274 hours/ns, 109.023 timesteps/s, 251.188 katom-step/s
98.1% CPU use with 4 MPI tasks x 1 OpenMP threads
MPI task timing breakdown:
Section | min time | avg time | max time |%varavg| %total
---------------------------------------------------------------
Pair | 7.7477 | 8.0143 | 8.1344 | 5.5 | 87.37
Neigh | 0.050543 | 0.056882 | 0.05986 | 1.6 | 0.62
Comm | 0.069784 | 0.16898 | 0.40996 | 34.2 | 1.84
Output | 0.00015612 | 0.0001707 | 0.00021249 | 0.0 | 0.00
Modify | 0.90628 | 0.93003 | 0.96157 | 2.2 | 10.14
Other | | 0.002053 | | | 0.02
Nlocal: 576 ave 614 max 505 min
Histogram: 1 0 0 0 0 0 1 0 0 2
Nghost: 2165.75 ave 2204 max 2132 min
Histogram: 1 0 0 0 2 0 0 0 0 1
Neighs: 32430.8 ave 35552 max 26564 min
Histogram: 1 0 0 0 0 0 1 0 0 2
FullNghs: 64861.5 ave 71111 max 53164 min
Histogram: 1 0 0 0 0 0 1 0 0 2
Total # of neighbors = 259446
Ave neighs/atom = 112.60677
Neighbor list builds = 62
Dangerous builds = 0
#write_data pulse_end.data
Total wall time: 0:00:09

61
examples/PACKAGES/reaction/tiny_nylon_json/in.tiny_nylon.stabilized Normal file
View File

@ -0,0 +1,61 @@
# two monomer nylon example
# reaction produces a condensed water molecule
units real
boundary p p p
atom_style full
kspace_style pppm 1.0e-4
pair_style lj/class2/coul/long 8.5
angle_style class2
bond_style class2
dihedral_style class2
improper_style class2
special_bonds lj/coul 0 0 1
pair_modify tail yes mix sixthpower
read_data tiny_nylon.data &
extra/bond/per/atom 5 &
extra/angle/per/atom 15 &
extra/dihedral/per/atom 15 &
extra/improper/per/atom 25 &
extra/special/per/atom 25
velocity all create 300.0 4928459 dist gaussian
molecule mol1 rxn1_stp1_unreacted.json
molecule mol2 rxn1_stp1_reacted.json
molecule mol3 rxn1_stp2_unreacted.json
molecule mol4 rxn1_stp2_reacted.json
thermo 50
# dump 1 all xyz 1 test_vis.xyz
# dump_modify 1 types labels
fix myrxns all bond/react stabilization yes statted_grp .03 &
react rxn1 all 1 0.0 2.9 mol1 mol2 rxn1_stp1_map &
react rxn2 all 1 0.0 5.0 mol3 mol4 rxn1_stp2_map rescale_charges yes
fix 1 statted_grp_REACT nvt temp 300 300 100
# optionally, you can customize behavior of reacting atoms,
# by using the internally-created 'bond_react_MASTER_group', like so:
fix 4 bond_react_MASTER_group temp/rescale 1 300 300 10 1
thermo_style custom step temp press density f_myrxns[*]
# restart 100 restart1 restart2
run 10000
# write_restart restart_longrun
# write_data restart_longrun.data

444
examples/PACKAGES/reaction/tiny_nylon_json/log.tiny_nylon.stabilized.12Jun2025.g++.1 Normal file
View File

@ -0,0 +1,444 @@
LAMMPS (2 Apr 2025 - Development - patch_2Apr2025-583-g5868aa095d-modified)
OMP_NUM_THREADS environment is not set. Defaulting to 1 thread. (src/comm.cpp:99)
using 1 OpenMP thread(s) per MPI task
# two monomer nylon example
# reaction produces a condensed water molecule
units real
boundary p p p
atom_style full
kspace_style pppm 1.0e-4
pair_style lj/class2/coul/long 8.5
angle_style class2
bond_style class2
dihedral_style class2
improper_style class2
special_bonds lj/coul 0 0 1
pair_modify tail yes mix sixthpower
read_data tiny_nylon.data extra/bond/per/atom 5 extra/angle/per/atom 15 extra/dihedral/per/atom 15 extra/improper/per/atom 25 extra/special/per/atom 25
Reading data file ...
orthogonal box = (-25 -25 -25) to (25 25 25)
1 by 1 by 1 MPI processor grid
reading atom labelmap ...
reading bond labelmap ...
reading angle labelmap ...
reading dihedral labelmap ...
reading improper labelmap ...
reading atoms ...
44 atoms
reading velocities ...
44 velocities
scanning bonds ...
9 = max bonds/atom
scanning angles ...
21 = max angles/atom
scanning dihedrals ...
29 = max dihedrals/atom
scanning impropers ...
29 = max impropers/atom
orthogonal box = (-25 -25 -25) to (25 25 25)
1 by 1 by 1 MPI processor grid
reading bonds ...
42 bonds
reading angles ...
74 angles
reading dihedrals ...
100 dihedrals
reading impropers ...
16 impropers
Finding 1-2 1-3 1-4 neighbors ...
special bond factors lj: 0 0 1
special bond factors coul: 0 0 1
4 = max # of 1-2 neighbors
6 = max # of 1-3 neighbors
35 = max # of special neighbors
special bonds CPU = 0.000 seconds
read_data CPU = 0.005 seconds
velocity all create 300.0 4928459 dist gaussian
molecule mol1 rxn1_stp1_unreacted.json
Read molecule template mol1:
(no title)
1 molecules
0 fragments
18 atoms with max type 0
16 bonds with max type 8
25 angles with max type 25
23 dihedrals with max type 33
2 impropers with max type 3
molecule mol2 rxn1_stp1_reacted.json
Read molecule template mol2:
(no title)
1 molecules
0 fragments
18 atoms with max type 0
17 bonds with max type 11
31 angles with max type 24
39 dihedrals with max type 30
0 impropers with max type 0
molecule mol3 rxn1_stp2_unreacted.json
Read molecule template mol3:
(no title)
1 molecules
0 fragments
15 atoms with max type 0
14 bonds with max type 11
25 angles with max type 24
30 dihedrals with max type 30
0 impropers with max type 0
molecule mol4 rxn1_stp2_reacted.json
Read molecule template mol4:
(no title)
1 molecules
0 fragments
15 atoms with max type 0
13 bonds with max type 13
19 angles with max type 26
16 dihedrals with max type 29
2 impropers with max type 5
thermo 50
# dump 1 all xyz 1 test_vis.xyz
# dump_modify 1 types labels
fix myrxns all bond/react stabilization yes statted_grp .03 react rxn1 all 1 0.0 2.9 mol1 mol2 rxn1_stp1_map react rxn2 all 1 0.0 5.0 mol3 mol4 rxn1_stp2_map rescale_charges yes
WARNING: Fix bond/react: Atom affected by reaction rxn1 is too close to template edge (src/REACTION/fix_bond_react.cpp:2708)
WARNING: Fix bond/react: Atom affected by reaction rxn2 is too close to template edge (src/REACTION/fix_bond_react.cpp:2708)
dynamic group bond_react_MASTER_group defined
dynamic group statted_grp_REACT defined
fix 1 statted_grp_REACT nvt temp 300 300 100
# optionally, you can customize behavior of reacting atoms,
# by using the internally-created 'bond_react_MASTER_group', like so:
fix 4 bond_react_MASTER_group temp/rescale 1 300 300 10 1
thermo_style custom step temp press density f_myrxns[*]
# restart 100 restart1 restart2
run 10000
CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE
Your simulation uses code contributions which should be cited:
- Type Label Framework: https://doi.org/10.1021/acs.jpcb.3c08419
@Article{Gissinger24,
author = {Jacob R. Gissinger, Ilia Nikiforov, Yaser Afshar, Brendon Waters, Moon-ki Choi, Daniel S. Karls, Alexander Stukowski, Wonpil Im, Hendrik Heinz, Axel Kohlmeyer, and Ellad B. Tadmor},
title = {Type Label Framework for Bonded Force Fields in LAMMPS},
journal = {J. Phys. Chem. B},
year = 2024,
volume = 128,
number = 13,
pages = {3282--3297}
}
- fix bond/react: reacter.org doi:10.1016/j.polymer.2017.09.038, doi:10.1021/acs.macromol.0c02012, doi:10.1016/j.cpc.2024.109287
@Article{Gissinger17,
author = {J. R. Gissinger and B. D. Jensen and K. E. Wise},
title = {Modeling Chemical Reactions in Classical Molecular Dynamics Simulations},
journal = {Polymer},
year = 2017,
volume = 128,
pages = {211--217}
}
@Article{Gissinger20,
author = {J. R. Gissinger, B. D. Jensen, K. E. Wise},
title = {{REACTER}: A Heuristic Method for Reactive Molecular Dynamics},
journal = {Macromolecules},
year = 2020,
volume = 53,
number = 22,
pages = {9953--9961}
}
@Article{Gissinger24,
author = {J. R. Gissinger, B. D. Jensen, K. E. Wise},
title = {Molecular Modeling of Reactive Systems with REACTER},
journal = {Computer Physics Communications},
year = 2024,
volume = 304,
number = 109287
}
CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE
PPPM initialization ...
using 12-bit tables for long-range coulomb (src/kspace.cpp:342)
G vector (1/distance) = 0.23408048
grid = 15 15 15
stencil order = 5
estimated absolute RMS force accuracy = 0.018627396
estimated relative force accuracy = 5.6095851e-05
using double precision FFTW3
3d grid and FFT values/proc = 8000 3375
Generated 55 of 55 mixed pair_coeff terms from sixthpower/sixthpower mixing rule
Neighbor list info ...
update: every = 1 steps, delay = 0 steps, check = yes
max neighbors/atom: 2000, page size: 100000
master list distance cutoff = 10.5
ghost atom cutoff = 10.5
binsize = 5.25, bins = 10 10 10
2 neighbor lists, perpetual/occasional/extra = 1 1 0
(1) pair lj/class2/coul/long, perpetual
attributes: half, newton on
pair build: half/bin/newton
stencil: half/bin/3d
bin: standard
(2) fix bond/react, occasional, copy from (1)
attributes: half, newton on
pair build: copy
stencil: none
bin: none
Per MPI rank memory allocation (min/avg/max) = 34 | 34 | 34 Mbytes
Step Temp Press Density f_myrxns[1] f_myrxns[2]
0 300 357.25588 0.0034851739 0 0
50 328.952 -39.291672 0.0034851739 1 0
100 311.59495 29.741131 0.0034851739 1 1
150 325.04965 -19.624049 0.0034851739 1 1
200 313.15254 15.730975 0.0034851739 1 1
250 307.88805 -22.944869 0.0034851739 1 1
300 287.9343 6.7916738 0.0034851739 1 1
350 314.40601 12.913246 0.0034851739 1 1
400 304.58587 6.9804459 0.0034851739 1 1
450 300.97668 14.68689 0.0034851739 1 1
500 345.19498 -29.961085 0.0034851739 1 1
550 229.37329 12.88087 0.0034851739 1 1
600 239.75504 -3.575567 0.0034851739 1 1
650 257.58951 -5.0844118 0.0034851739 1 1
700 249.84121 22.825491 0.0034851739 1 1
750 287.62022 28.059197 0.0034851739 1 1
800 352.31339 -50.233738 0.0034851739 1 1
850 316.12821 22.493396 0.0034851739 1 1
900 283.85252 26.129698 0.0034851739 1 1
950 290.30591 -25.743121 0.0034851739 1 1
1000 346.57856 -2.1188627 0.0034851739 1 1
1050 251.23391 20.636107 0.0034851739 1 1
1100 267.48303 -15.912571 0.0034851739 1 1
1150 282.66256 14.019753 0.0034851739 1 1
1200 227.56518 -27.076623 0.0034851739 1 1
1250 232.7204 -1.0387593 0.0034851739 1 1
1300 277.28783 32.449571 0.0034851739 1 1
1350 308.5732 -11.129035 0.0034851739 1 1
1400 264.96641 -20.93416 0.0034851739 1 1
1450 262.83931 30.82366 0.0034851739 1 1
1500 276.23182 -24.480049 0.0034851739 1 1
1550 319.00599 -9.8372065 0.0034851739 1 1
1600 316.48228 -15.940319 0.0034851739 1 1
1650 277.213 1.3856424 0.0034851739 1 1
1700 302.34736 -27.623644 0.0034851739 1 1
1750 312.06738 -52.786773 0.0034851739 1 1
1800 232.82457 -8.2208725 0.0034851739 1 1
1850 219.66312 0.0019676295 0.0034851739 1 1
1900 245.49515 -24.208901 0.0034851739 1 1
1950 262.40648 -1.8634047 0.0034851739 1 1
2000 307.5184 10.588572 0.0034851739 1 1
2050 316.54878 8.3925575 0.0034851739 1 1
2100 318.99324 29.042199 0.0034851739 1 1
2150 352.69886 18.443891 0.0034851739 1 1
2200 326.32556 -38.670826 0.0034851739 1 1
2250 333.73083 15.388091 0.0034851739 1 1
2300 258.51644 -42.524581 0.0034851739 1 1
2350 259.55019 -23.484535 0.0034851739 1 1
2400 289.75114 28.367986 0.0034851739 1 1
2450 312.34376 10.345659 0.0034851739 1 1
2500 298.65847 -14.077573 0.0034851739 1 1
2550 237.48617 -55.545493 0.0034851739 1 1
2600 266.79718 -17.165884 0.0034851739 1 1
2650 297.32794 -30.336059 0.0034851739 1 1
2700 258.77594 -1.3622741 0.0034851739 1 1
2750 240.05564 -0.4418629 0.0034851739 1 1
2800 189.88737 -13.20747 0.0034851739 1 1
2850 260.84014 -18.597276 0.0034851739 1 1
2900 299.99473 -7.3249394 0.0034851739 1 1
2950 377.90497 18.041664 0.0034851739 1 1
3000 263.92156 -54.260856 0.0034851739 1 1
3050 273.64003 26.973976 0.0034851739 1 1
3100 276.52232 -3.8583179 0.0034851739 1 1
3150 351.27802 84.899229 0.0034851739 1 1
3200 327.48822 -10.339189 0.0034851739 1 1
3250 356.11987 16.719201 0.0034851739 1 1
3300 263.01966 -18.033913 0.0034851739 1 1
3350 285.41196 -24.466282 0.0034851739 1 1
3400 233.65271 -39.293739 0.0034851739 1 1
3450 276.32895 44.300639 0.0034851739 1 1
3500 300.42687 28.489275 0.0034851739 1 1
3550 254.03142 -24.335427 0.0034851739 1 1
3600 304.6963 4.5827938 0.0034851739 1 1
3650 321.1785 -15.477109 0.0034851739 1 1
3700 256.00258 25.354176 0.0034851739 1 1
3750 356.60667 -5.4004451 0.0034851739 1 1
3800 361.31092 -1.481153 0.0034851739 1 1
3850 253.80196 -1.2120222 0.0034851739 1 1
3900 258.01895 19.280499 0.0034851739 1 1
3950 261.55352 -47.57161 0.0034851739 1 1
4000 254.54757 -8.6460339 0.0034851739 1 1
4050 301.56201 22.484551 0.0034851739 1 1
4100 304.73035 -31.321217 0.0034851739 1 1
4150 307.14343 0.5455717 0.0034851739 1 1
4200 291.05765 51.79974 0.0034851739 1 1
4250 333.73864 -24.668278 0.0034851739 1 1
4300 370.55562 -11.922425 0.0034851739 1 1
4350 408.03441 8.5963114 0.0034851739 1 1
4400 329.13138 -25.679871 0.0034851739 1 1
4450 366.98033 26.287047 0.0034851739 1 1
4500 311.80954 31.766893 0.0034851739 1 1
4550 292.28765 13.064974 0.0034851739 1 1
4600 320.72746 -49.078838 0.0034851739 1 1
4650 271.7173 -3.6846681 0.0034851739 1 1
4700 305.69502 37.947369 0.0034851739 1 1
4750 304.57521 52.411498 0.0034851739 1 1
4800 299.22173 12.555443 0.0034851739 1 1
4850 317.1756 -14.332118 0.0034851739 1 1
4900 330.62798 23.762097 0.0034851739 1 1
4950 342.34292 -21.428049 0.0034851739 1 1
5000 415.76656 10.136854 0.0034851739 1 1
5050 381.90086 18.17029 0.0034851739 1 1
5100 380.63709 28.042746 0.0034851739 1 1
5150 321.578 31.648896 0.0034851739 1 1
5200 301.22258 -29.246031 0.0034851739 1 1
5250 277.39891 -33.660526 0.0034851739 1 1
5300 259.34417 -47.78529 0.0034851739 1 1
5350 254.36079 10.616064 0.0034851739 1 1
5400 242.39213 29.468553 0.0034851739 1 1
5450 273.79403 -21.736668 0.0034851739 1 1
5500 367.30713 -6.0185517 0.0034851739 1 1
5550 309.52317 20.860119 0.0034851739 1 1
5600 316.82746 -10.339826 0.0034851739 1 1
5650 248.8707 33.659016 0.0034851739 1 1
5700 314.30152 19.05817 0.0034851739 1 1
5750 307.09966 14.458312 0.0034851739 1 1
5800 313.07936 15.825371 0.0034851739 1 1
5850 255.76382 23.890796 0.0034851739 1 1
5900 274.57947 -0.19520339 0.0034851739 1 1
5950 286.72486 -0.92397306 0.0034851739 1 1
6000 304.60873 -4.3983652 0.0034851739 1 1
6050 271.84784 -60.940602 0.0034851739 1 1
6100 283.48258 -8.2903551 0.0034851739 1 1
6150 336.07933 -8.2576526 0.0034851739 1 1
6200 363.09919 -17.309847 0.0034851739 1 1
6250 305.63822 14.475989 0.0034851739 1 1
6300 274.59195 49.13711 0.0034851739 1 1
6350 302.91015 -21.034604 0.0034851739 1 1
6400 293.87945 0.74647589 0.0034851739 1 1
6450 320.03843 47.624624 0.0034851739 1 1
6500 329.4551 -52.788127 0.0034851739 1 1
6550 320.74765 7.9598838 0.0034851739 1 1
6600 290.63144 -19.66089 0.0034851739 1 1
6650 266.9576 18.962642 0.0034851739 1 1
6700 274.61389 -9.823603 0.0034851739 1 1
6750 210.31417 -4.5767817 0.0034851739 1 1
6800 258.23732 44.233497 0.0034851739 1 1
6850 269.33119 -41.097429 0.0034851739 1 1
6900 318.88077 -21.601871 0.0034851739 1 1
6950 333.85796 26.067522 0.0034851739 1 1
7000 320.59631 -44.226656 0.0034851739 1 1
7050 348.15593 56.564077 0.0034851739 1 1
7100 291.30894 7.6597589 0.0034851739 1 1
7150 261.87574 -1.926724 0.0034851739 1 1
7200 318.17418 61.577301 0.0034851739 1 1
7250 269.73912 -41.921242 0.0034851739 1 1
7300 235.40776 -7.8606915 0.0034851739 1 1
7350 344.03017 73.910798 0.0034851739 1 1
7400 335.03212 13.288114 0.0034851739 1 1
7450 350.0822 -22.899498 0.0034851739 1 1
7500 360.69025 -78.556242 0.0034851739 1 1
7550 316.85895 -26.533434 0.0034851739 1 1
7600 271.65568 32.425371 0.0034851739 1 1
7650 264.7899 -40.230568 0.0034851739 1 1
7700 281.36612 8.9888402 0.0034851739 1 1
7750 276.96176 1.8256977 0.0034851739 1 1
7800 330.1516 -19.751957 0.0034851739 1 1
7850 325.80791 -12.52799 0.0034851739 1 1
7900 322.07086 35.21732 0.0034851739 1 1
7950 310.09493 -37.779071 0.0034851739 1 1
8000 309.87152 40.561377 0.0034851739 1 1
8050 252.91862 -27.545616 0.0034851739 1 1
8100 308.23471 -25.313089 0.0034851739 1 1
8150 278.69561 19.299388 0.0034851739 1 1
8200 270.81879 33.341696 0.0034851739 1 1
8250 312.58182 19.404863 0.0034851739 1 1
8300 302.20303 19.388391 0.0034851739 1 1
8350 299.55144 -12.952851 0.0034851739 1 1
8400 330.13129 -34.998178 0.0034851739 1 1
8450 281.66968 24.865214 0.0034851739 1 1
8500 262.4416 1.0196786 0.0034851739 1 1
8550 268.47784 44.761905 0.0034851739 1 1
8600 274.80898 8.6257741 0.0034851739 1 1
8650 264.82423 -3.9236534 0.0034851739 1 1
8700 268.88205 3.7102664 0.0034851739 1 1
8750 315.78315 -44.215318 0.0034851739 1 1
8800 280.19362 -4.2172962 0.0034851739 1 1
8850 331.88665 58.274571 0.0034851739 1 1
8900 314.70472 36.746006 0.0034851739 1 1
8950 395.82228 53.308443 0.0034851739 1 1
9000 351.95636 29.133084 0.0034851739 1 1
9050 369.74695 -37.487774 0.0034851739 1 1
9100 259.4453 -2.1826545 0.0034851739 1 1
9150 294.9952 -44.357151 0.0034851739 1 1
9200 273.94092 12.07438 0.0034851739 1 1
9250 257.18809 -29.792606 0.0034851739 1 1
9300 269.54343 -19.617554 0.0034851739 1 1
9350 301.09849 -26.979046 0.0034851739 1 1
9400 316.93675 -46.890327 0.0034851739 1 1
9450 304.52185 -8.8525101 0.0034851739 1 1
9500 371.73494 11.979311 0.0034851739 1 1
9550 291.23417 8.1900851 0.0034851739 1 1
9600 359.20912 38.693544 0.0034851739 1 1
9650 321.73443 33.448943 0.0034851739 1 1
9700 362.4237 36.54429 0.0034851739 1 1
9750 296.19875 -11.425255 0.0034851739 1 1
9800 329.9426 16.039783 0.0034851739 1 1
9850 296.79216 40.176303 0.0034851739 1 1
9900 345.63868 43.479483 0.0034851739 1 1
9950 282.27772 -49.08352 0.0034851739 1 1
10000 286.24393 -12.060687 0.0034851739 1 1
Loop time of 1.29509 on 1 procs for 10000 steps with 44 atoms
Performance: 667.133 ns/day, 0.036 hours/ns, 7721.451 timesteps/s, 339.744 katom-step/s
99.6% CPU use with 1 MPI tasks x 1 OpenMP threads
MPI task timing breakdown:
Section | min time | avg time | max time |%varavg| %total
---------------------------------------------------------------
Pair | 0.065326 | 0.065326 | 0.065326 | 0.0 | 5.04
Bond | 0.23111 | 0.23111 | 0.23111 | 0.0 | 17.84
Kspace | 0.94073 | 0.94073 | 0.94073 | 0.0 | 72.64
Neigh | 0.0032599 | 0.0032599 | 0.0032599 | 0.0 | 0.25
Comm | 0.0013719 | 0.0013719 | 0.0013719 | 0.0 | 0.11
Output | 0.00093869 | 0.00093869 | 0.00093869 | 0.0 | 0.07
Modify | 0.049692 | 0.049692 | 0.049692 | 0.0 | 3.84
Other | | 0.002667 | | | 0.21
Nlocal: 44 ave 44 max 44 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Nghost: 14 ave 14 max 14 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Neighs: 869 ave 869 max 869 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Total # of neighbors = 869
Ave neighs/atom = 19.75
Ave special neighs/atom = 6.4090909
Neighbor list builds = 209
Dangerous builds = 0
# write_restart restart_longrun
# write_data restart_longrun.data
Total wall time: 0:00:01

444
examples/PACKAGES/reaction/tiny_nylon_json/log.tiny_nylon.stabilized.12Jun2025.g++.4 Normal file
View File

@ -0,0 +1,444 @@
LAMMPS (2 Apr 2025 - Development - patch_2Apr2025-583-g5868aa095d-modified)
OMP_NUM_THREADS environment is not set. Defaulting to 1 thread. (src/comm.cpp:99)
using 1 OpenMP thread(s) per MPI task
# two monomer nylon example
# reaction produces a condensed water molecule
units real
boundary p p p
atom_style full
kspace_style pppm 1.0e-4
pair_style lj/class2/coul/long 8.5
angle_style class2
bond_style class2
dihedral_style class2
improper_style class2
special_bonds lj/coul 0 0 1
pair_modify tail yes mix sixthpower
read_data tiny_nylon.data extra/bond/per/atom 5 extra/angle/per/atom 15 extra/dihedral/per/atom 15 extra/improper/per/atom 25 extra/special/per/atom 25
Reading data file ...
orthogonal box = (-25 -25 -25) to (25 25 25)
1 by 2 by 2 MPI processor grid
reading atom labelmap ...
reading bond labelmap ...
reading angle labelmap ...
reading dihedral labelmap ...
reading improper labelmap ...
reading atoms ...
44 atoms
reading velocities ...
44 velocities
scanning bonds ...
9 = max bonds/atom
scanning angles ...
21 = max angles/atom
scanning dihedrals ...
29 = max dihedrals/atom
scanning impropers ...
29 = max impropers/atom
orthogonal box = (-25 -25 -25) to (25 25 25)
1 by 2 by 2 MPI processor grid
reading bonds ...
42 bonds
reading angles ...
74 angles
reading dihedrals ...
100 dihedrals
reading impropers ...
16 impropers
Finding 1-2 1-3 1-4 neighbors ...
special bond factors lj: 0 0 1
special bond factors coul: 0 0 1
4 = max # of 1-2 neighbors
6 = max # of 1-3 neighbors
35 = max # of special neighbors
special bonds CPU = 0.000 seconds
read_data CPU = 0.006 seconds
velocity all create 300.0 4928459 dist gaussian
molecule mol1 rxn1_stp1_unreacted.json
Read molecule template mol1:
(no title)
1 molecules
0 fragments
18 atoms with max type 0
16 bonds with max type 8
25 angles with max type 25
23 dihedrals with max type 33
2 impropers with max type 3
molecule mol2 rxn1_stp1_reacted.json
Read molecule template mol2:
(no title)
1 molecules
0 fragments
18 atoms with max type 0
17 bonds with max type 11
31 angles with max type 24
39 dihedrals with max type 30
0 impropers with max type 0
molecule mol3 rxn1_stp2_unreacted.json
Read molecule template mol3:
(no title)
1 molecules
0 fragments
15 atoms with max type 0
14 bonds with max type 11
25 angles with max type 24
30 dihedrals with max type 30
0 impropers with max type 0
molecule mol4 rxn1_stp2_reacted.json
Read molecule template mol4:
(no title)
1 molecules
0 fragments
15 atoms with max type 0
13 bonds with max type 13
19 angles with max type 26
16 dihedrals with max type 29
2 impropers with max type 5
thermo 50
# dump 1 all xyz 1 test_vis.xyz
# dump_modify 1 types labels
fix myrxns all bond/react stabilization yes statted_grp .03 react rxn1 all 1 0.0 2.9 mol1 mol2 rxn1_stp1_map react rxn2 all 1 0.0 5.0 mol3 mol4 rxn1_stp2_map rescale_charges yes
WARNING: Fix bond/react: Atom affected by reaction rxn1 is too close to template edge (src/REACTION/fix_bond_react.cpp:2708)
WARNING: Fix bond/react: Atom affected by reaction rxn2 is too close to template edge (src/REACTION/fix_bond_react.cpp:2708)
dynamic group bond_react_MASTER_group defined
dynamic group statted_grp_REACT defined
fix 1 statted_grp_REACT nvt temp 300 300 100
# optionally, you can customize behavior of reacting atoms,
# by using the internally-created 'bond_react_MASTER_group', like so:
fix 4 bond_react_MASTER_group temp/rescale 1 300 300 10 1
thermo_style custom step temp press density f_myrxns[*]
# restart 100 restart1 restart2
run 10000
CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE
Your simulation uses code contributions which should be cited:
- Type Label Framework: https://doi.org/10.1021/acs.jpcb.3c08419
@Article{Gissinger24,
author = {Jacob R. Gissinger, Ilia Nikiforov, Yaser Afshar, Brendon Waters, Moon-ki Choi, Daniel S. Karls, Alexander Stukowski, Wonpil Im, Hendrik Heinz, Axel Kohlmeyer, and Ellad B. Tadmor},
title = {Type Label Framework for Bonded Force Fields in LAMMPS},
journal = {J. Phys. Chem. B},
year = 2024,
volume = 128,
number = 13,
pages = {3282--3297}
}
- fix bond/react: reacter.org doi:10.1016/j.polymer.2017.09.038, doi:10.1021/acs.macromol.0c02012, doi:10.1016/j.cpc.2024.109287
@Article{Gissinger17,
author = {J. R. Gissinger and B. D. Jensen and K. E. Wise},
title = {Modeling Chemical Reactions in Classical Molecular Dynamics Simulations},
journal = {Polymer},
year = 2017,
volume = 128,
pages = {211--217}
}
@Article{Gissinger20,
author = {J. R. Gissinger, B. D. Jensen, K. E. Wise},
title = {{REACTER}: A Heuristic Method for Reactive Molecular Dynamics},
journal = {Macromolecules},
year = 2020,
volume = 53,
number = 22,
pages = {9953--9961}
}
@Article{Gissinger24,
author = {J. R. Gissinger, B. D. Jensen, K. E. Wise},
title = {Molecular Modeling of Reactive Systems with REACTER},
journal = {Computer Physics Communications},
year = 2024,
volume = 304,
number = 109287
}
CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE
PPPM initialization ...
using 12-bit tables for long-range coulomb (src/kspace.cpp:342)
G vector (1/distance) = 0.23408048
grid = 15 15 15
stencil order = 5
estimated absolute RMS force accuracy = 0.018627396
estimated relative force accuracy = 5.6095851e-05
using double precision FFTW3
3d grid and FFT values/proc = 3380 960
Generated 55 of 55 mixed pair_coeff terms from sixthpower/sixthpower mixing rule
Neighbor list info ...
update: every = 1 steps, delay = 0 steps, check = yes
max neighbors/atom: 2000, page size: 100000
master list distance cutoff = 10.5
ghost atom cutoff = 10.5
binsize = 5.25, bins = 10 10 10
2 neighbor lists, perpetual/occasional/extra = 1 1 0
(1) pair lj/class2/coul/long, perpetual
attributes: half, newton on
pair build: half/bin/newton
stencil: half/bin/3d
bin: standard
(2) fix bond/react, occasional, copy from (1)
attributes: half, newton on
pair build: copy
stencil: none
bin: none
Per MPI rank memory allocation (min/avg/max) = 33.49 | 33.72 | 34.28 Mbytes
Step Temp Press Density f_myrxns[1] f_myrxns[2]
0 300 357.25588 0.0034851739 0 0
50 328.952 -39.291672 0.0034851739 1 0
100 311.59495 29.741131 0.0034851739 1 1
150 325.04965 -19.624049 0.0034851739 1 1
200 313.15254 15.730975 0.0034851739 1 1
250 307.88805 -22.944869 0.0034851739 1 1
300 287.9343 6.7916738 0.0034851739 1 1
350 314.40601 12.913246 0.0034851739 1 1
400 304.58587 6.9804459 0.0034851739 1 1
450 300.97668 14.68689 0.0034851739 1 1
500 345.19498 -29.961085 0.0034851739 1 1
550 229.37329 12.88087 0.0034851739 1 1
600 239.75504 -3.575567 0.0034851739 1 1
650 257.58951 -5.0844118 0.0034851739 1 1
700 249.84121 22.825491 0.0034851739 1 1
750 287.62022 28.059197 0.0034851739 1 1
800 352.31339 -50.233738 0.0034851739 1 1
850 316.12821 22.493396 0.0034851739 1 1
900 283.85252 26.129698 0.0034851739 1 1
950 290.30591 -25.743121 0.0034851739 1 1
1000 346.57856 -2.1188627 0.0034851739 1 1
1050 251.23391 20.636107 0.0034851739 1 1
1100 267.48303 -15.912571 0.0034851739 1 1
1150 282.66256 14.019753 0.0034851739 1 1
1200 227.56518 -27.076623 0.0034851739 1 1
1250 232.7204 -1.0387593 0.0034851739 1 1
1300 277.28783 32.449571 0.0034851739 1 1
1350 308.5732 -11.129035 0.0034851739 1 1
1400 264.96641 -20.93416 0.0034851739 1 1
1450 262.83931 30.82366 0.0034851739 1 1
1500 276.23182 -24.480049 0.0034851739 1 1
1550 319.00599 -9.8372065 0.0034851739 1 1
1600 316.48228 -15.940319 0.0034851739 1 1
1650 277.213 1.3856424 0.0034851739 1 1
1700 302.34736 -27.623644 0.0034851739 1 1
1750 312.06738 -52.786773 0.0034851739 1 1
1800 232.82457 -8.2208725 0.0034851739 1 1
1850 219.66312 0.0019675712 0.0034851739 1 1
1900 245.49515 -24.2089 0.0034851739 1 1
1950 262.40648 -1.8634053 0.0034851739 1 1
2000 307.5184 10.588572 0.0034851739 1 1
2050 316.54878 8.3925573 0.0034851739 1 1
2100 318.99324 29.042199 0.0034851739 1 1
2150 352.69886 18.443891 0.0034851739 1 1
2200 326.32556 -38.670827 0.0034851739 1 1
2250 333.73083 15.388091 0.0034851739 1 1
2300 258.51644 -42.524579 0.0034851739 1 1
2350 259.55019 -23.484534 0.0034851739 1 1
2400 289.75114 28.367991 0.0034851739 1 1
2450 312.34376 10.34566 0.0034851739 1 1
2500 298.65847 -14.077574 0.0034851739 1 1
2550 237.48617 -55.545492 0.0034851739 1 1
2600 266.79719 -17.165888 0.0034851739 1 1
2650 297.32793 -30.336065 0.0034851739 1 1
2700 258.77594 -1.3622773 0.0034851739 1 1
2750 240.05564 -0.44186476 0.0034851739 1 1
2800 189.88736 -13.20747 0.0034851739 1 1
2850 260.84014 -18.597268 0.0034851739 1 1
2900 299.99469 -7.3249657 0.0034851739 1 1
2950 377.90515 18.041562 0.0034851739 1 1
3000 263.92164 -54.260872 0.0034851739 1 1
3050 273.63965 26.974167 0.0034851739 1 1
3100 276.52188 -3.8587984 0.0034851739 1 1
3150 351.27821 84.898762 0.0034851739 1 1
3200 327.48898 -10.338223 0.0034851739 1 1
3250 356.1212 16.719521 0.0034851739 1 1
3300 263.02135 -18.034405 0.0034851739 1 1
3350 285.4132 -24.466598 0.0034851739 1 1
3400 233.65385 -39.293822 0.0034851739 1 1
3450 276.32817 44.300742 0.0034851739 1 1
3500 300.43096 28.490491 0.0034851739 1 1
3550 254.03694 -24.336803 0.0034851739 1 1
3600 304.68561 4.5774591 0.0034851739 1 1
3650 321.19694 -15.472971 0.0034851739 1 1
3700 256.01801 25.355422 0.0034851739 1 1
3750 356.6048 -5.4033701 0.0034851739 1 1
3800 361.31685 -1.4920086 0.0034851739 1 1
3850 253.81335 -1.20491 0.0034851739 1 1
3900 257.99176 19.272863 0.0034851739 1 1
3950 261.56599 -47.578625 0.0034851739 1 1
4000 254.55501 -8.6462427 0.0034851739 1 1
4050 301.57465 22.466646 0.0034851739 1 1
4100 304.71812 -31.337506 0.0034851739 1 1
4150 307.05688 0.54710967 0.0034851739 1 1
4200 291.11678 51.789059 0.0034851739 1 1
4250 333.71702 -24.64525 0.0034851739 1 1
4300 370.53725 -11.852814 0.0034851739 1 1
4350 407.98596 8.5128018 0.0034851739 1 1
4400 329.43106 -25.637208 0.0034851739 1 1
4450 366.91557 26.250029 0.0034851739 1 1
4500 311.63134 31.61568 0.0034851739 1 1
4550 292.18008 13.020734 0.0034851739 1 1
4600 320.76549 -49.324846 0.0034851739 1 1
4650 271.72115 -3.6666938 0.0034851739 1 1
4700 305.52974 38.114013 0.0034851739 1 1
4750 304.37057 52.050863 0.0034851739 1 1
4800 300.50548 13.158616 0.0034851739 1 1
4850 317.66606 -14.951608 0.0034851739 1 1
4900 331.39591 23.823575 0.0034851739 1 1
4950 340.899 -19.557136 0.0034851739 1 1
5000 414.45112 8.7124515 0.0034851739 1 1
5050 382.95479 18.555744 0.0034851739 1 1
5100 381.26344 22.674486 0.0034851739 1 1
5150 309.88477 36.184971 0.0034851739 1 1
5200 312.4976 -31.403643 0.0034851739 1 1
5250 285.1896 -36.180241 0.0034851739 1 1
5300 249.68604 -55.078779 0.0034851739 1 1
5350 251.76542 12.156887 0.0034851739 1 1
5400 278.40908 15.846527 0.0034851739 1 1
5450 281.22116 -12.005198 0.0034851739 1 1
5500 362.38064 -14.608206 0.0034851739 1 1
5550 287.39255 38.446058 0.0034851739 1 1
5600 264.87699 -20.21112 0.0034851739 1 1
5650 300.31424 -15.899086 0.0034851739 1 1
5700 318.6444 18.688317 0.0034851739 1 1
5750 321.74224 -7.5355749 0.0034851739 1 1
5800 314.65871 33.512178 0.0034851739 1 1
5850 307.11597 -16.492491 0.0034851739 1 1
5900 259.10441 -49.668159 0.0034851739 1 1
5950 292.09045 -22.04962 0.0034851739 1 1
6000 243.99229 -15.110485 0.0034851739 1 1
6050 276.66494 -21.052012 0.0034851739 1 1
6100 328.39444 64.522811 0.0034851739 1 1
6150 289.49991 -18.518616 0.0034851739 1 1
6200 358.50076 -9.3115021 0.0034851739 1 1
6250 303.15143 -42.618735 0.0034851739 1 1
6300 297.17364 18.116143 0.0034851739 1 1
6350 254.2382 2.4963759 0.0034851739 1 1
6400 227.56255 23.535315 0.0034851739 1 1
6450 280.70805 13.243012 0.0034851739 1 1
6500 251.14485 -18.466759 0.0034851739 1 1
6550 284.32321 9.0351234 0.0034851739 1 1
6600 284.03779 -10.683306 0.0034851739 1 1
6650 315.1569 -39.736019 0.0034851739 1 1
6700 302.50424 5.9013011 0.0034851739 1 1
6750 368.279 44.343503 0.0034851739 1 1
6800 279.67266 -35.967233 0.0034851739 1 1
6850 298.98045 3.0539699 0.0034851739 1 1
6900 236.94852 0.55971293 0.0034851739 1 1
6950 303.38382 -9.1880246 0.0034851739 1 1
7000 264.56096 3.904024 0.0034851739 1 1
7050 272.26968 -44.608801 0.0034851739 1 1
7100 235.38132 13.141913 0.0034851739 1 1
7150 272.0985 26.601686 0.0034851739 1 1
7200 314.41177 -7.6236617 0.0034851739 1 1
7250 313.29915 -45.214663 0.0034851739 1 1
7300 309.20548 -11.691744 0.0034851739 1 1
7350 342.22769 18.805899 0.0034851739 1 1
7400 301.02701 32.830071 0.0034851739 1 1
7450 318.19524 48.620851 0.0034851739 1 1
7500 290.00663 -9.1444424 0.0034851739 1 1
7550 238.07666 32.654941 0.0034851739 1 1
7600 275.95317 -23.982336 0.0034851739 1 1
7650 274.54472 -29.183684 0.0034851739 1 1
7700 307.25317 11.981268 0.0034851739 1 1
7750 299.40271 -19.390542 0.0034851739 1 1
7800 314.18813 -6.0794802 0.0034851739 1 1
7850 271.14043 40.491364 0.0034851739 1 1
7900 266.43792 37.250574 0.0034851739 1 1
7950 330.21996 31.783381 0.0034851739 1 1
8000 313.80294 44.878972 0.0034851739 1 1
8050 331.1094 1.9597746 0.0034851739 1 1
8100 267.80448 26.159121 0.0034851739 1 1
8150 267.17305 16.135234 0.0034851739 1 1
8200 290.248 -13.058622 0.0034851739 1 1
8250 231.77635 -42.850795 0.0034851739 1 1
8300 233.58288 29.137765 0.0034851739 1 1
8350 270.2913 -11.177011 0.0034851739 1 1
8400 254.69873 3.1775639 0.0034851739 1 1
8450 334.88277 -27.336924 0.0034851739 1 1
8500 354.95137 -9.751911 0.0034851739 1 1
8550 327.78998 8.2348621 0.0034851739 1 1
8600 306.15772 1.3756734 0.0034851739 1 1
8650 325.68699 6.5939205 0.0034851739 1 1
8700 302.84804 13.912169 0.0034851739 1 1
8750 299.34988 10.311212 0.0034851739 1 1
8800 258.77684 -8.0783535 0.0034851739 1 1
8850 299.8835 -9.61362 0.0034851739 1 1
8900 350.28205 -34.897861 0.0034851739 1 1
8950 316.90133 -52.845562 0.0034851739 1 1
9000 337.50548 18.172556 0.0034851739 1 1
9050 306.67254 37.062973 0.0034851739 1 1
9100 310.74844 58.178538 0.0034851739 1 1
9150 301.53463 5.9650738 0.0034851739 1 1
9200 284.61384 10.677528 0.0034851739 1 1
9250 247.86475 -15.325203 0.0034851739 1 1
9300 309.74481 -60.070902 0.0034851739 1 1
9350 290.17111 5.6049467 0.0034851739 1 1
9400 268.79925 -9.2423032 0.0034851739 1 1
9450 315.80445 18.124612 0.0034851739 1 1
9500 351.58161 -14.465115 0.0034851739 1 1
9550 344.93028 43.161438 0.0034851739 1 1
9600 265.92273 0.3396608 0.0034851739 1 1
9650 261.1649 -20.46043 0.0034851739 1 1
9700 262.05627 27.187613 0.0034851739 1 1
9750 249.12463 15.911339 0.0034851739 1 1
9800 262.40626 -16.159153 0.0034851739 1 1
9850 267.48677 0.32143902 0.0034851739 1 1
9900 316.15674 40.664589 0.0034851739 1 1
9950 323.94181 20.356291 0.0034851739 1 1
10000 307.90841 4.8392456 0.0034851739 1 1
Loop time of 0.937214 on 4 procs for 10000 steps with 44 atoms
Performance: 921.881 ns/day, 0.026 hours/ns, 10669.916 timesteps/s, 469.476 katom-step/s
96.5% CPU use with 4 MPI tasks x 1 OpenMP threads
MPI task timing breakdown:
Section | min time | avg time | max time |%varavg| %total
---------------------------------------------------------------
Pair | 0.00042896 | 0.01827 | 0.04944 | 14.9 | 1.95
Bond | 0.00067626 | 0.061292 | 0.18867 | 31.0 | 6.54
Kspace | 0.50738 | 0.64527 | 0.7136 | 10.4 | 68.85
Neigh | 0.0031476 | 0.0031815 | 0.0032165 | 0.0 | 0.34
Comm | 0.01335 | 0.020817 | 0.035424 | 6.1 | 2.22
Output | 0.0010449 | 0.0012202 | 0.0016969 | 0.8 | 0.13
Modify | 0.16314 | 0.18266 | 0.20201 | 4.3 | 19.49
Other | | 0.004499 | | | 0.48
Nlocal: 11 ave 40 max 0 min
Histogram: 2 1 0 0 0 0 0 0 0 1
Nghost: 22 ave 40 max 4 min
Histogram: 1 0 0 0 0 2 0 0 0 1
Neighs: 216.5 ave 845 max 0 min
Histogram: 3 0 0 0 0 0 0 0 0 1
Total # of neighbors = 866
Ave neighs/atom = 19.681818
Ave special neighs/atom = 6.4090909
Neighbor list builds = 212
Dangerous builds = 0
# write_restart restart_longrun
# write_data restart_longrun.data
Total wall time: 0:00:00

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