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

Renamed: adaptglok -> fire2

Browse Source
This commit is contained in:
jguenole
2019-10-24 14:11:16 +02:00
parent 48967a6fd6 634c0537a1
commit 549c8ee734
283 changed files with 21586 additions and 1543 deletions
Download Patch File Download Diff File Expand all files Collapse all files

3
.github/CONTRIBUTING.md vendored
View File

@ -68,7 +68,8 @@ How quickly your contribution will be integrated depends largely on how much eff
Here is a checklist of steps you need to follow to submit a single file or user package for our consideration. Following these steps will save both you and us time. See existing files in packages in the source directory for examples. If you are uncertain, please ask on the lammps-users mailing list.
* All source files you provide must compile with the most current version of LAMMPS with multiple configurations. In particular you need to test compiling LAMMPS from scratch with `-DLAMMPS_BIGBIG` set in addition to the default `-DLAMMPS_SMALLBIG` setting. Your code will need to work correctly in serial and in parallel using MPI.
* For consistency with the rest of LAMMPS and especially, if you want your contribution(s) to be added to main LAMMPS code or one of its standard packages, it needs to be written in a style compatible with other LAMMPS source files. This means: 2-character indentation per level, no tabs, no lines over 80 characters. I/O is done via the C-style stdio library, style class header files should not import any system headers outside of <cstdio>, STL containers should be avoided in headers, and forward declarations used where possible or needed. All added code should be placed into the LAMMPS_NS namespace or a sub-namespace; global or static variables should be avoided, as they conflict with the modular nature of LAMMPS and the C++ class structure. There MUST NOT be any "using namespace XXX;" statements in headers. In the implementation file (<name>.cpp) system includes should be placed in angular brackets (<>) and for c-library functions the C++ style header files should be included (<cstdio> instead of <stdio.h>, or <cstring> instead of <string.h>). This all is so the developers can more easily understand, integrate, and maintain your contribution and reduce conflicts with other parts of LAMMPS. This basically means that the code accesses data structures, performs its operations, and is formatted similar to other LAMMPS source files, including the use of the error class for error and warning messages.
* For consistency with the rest of LAMMPS and especially, if you want your contribution(s) to be added to main LAMMPS code or one of its standard packages, it needs to be written in a style compatible with other LAMMPS source files. This means: 2-character indentation per level, no tabs, no lines over 80 characters. I/O is done via the C-style stdio library, style class header files should not import any system headers, STL containers should be avoided in headers, and forward declarations used where possible or needed. All added code should be placed into the LAMMPS_NS namespace or a sub-namespace; global or static variables should be avoided, as they conflict with the modular nature of LAMMPS and the C++ class structure. There MUST NOT be any "using namespace XXX;" statements in headers. In the implementation file (<name>.cpp) system includes should be placed in angular brackets (<>) and for c-library functions the C++ style header files should be included (<cstdio> instead of <stdio.h>, or <cstring> instead of <string.h>). This all is so the developers can more easily understand, integrate, and maintain your contribution and reduce conflicts with other parts of LAMMPS. This basically means that the code accesses data structures, performs its operations, and is formatted similar to other LAMMPS source files, including the use of the error class for error and warning messages.
* Source, style name, and documentation file should follow the following naming convention: style names should be lowercase and words separated by a forward slash; for a new fix style 'foo/bar', the class should be named FixFooBar, the name of the source files should be 'fix_foo_bar.h' and 'fix_foo_bar.cpp' and the corresponding documentation should be in a file 'fix_foo_bar.txt'.
* If you want your contribution to be added as a user-contributed feature, and it is a single file (actually a `<name>.cpp` and `<name>.h` file) it can be rapidly added to the USER-MISC directory. Include the one-line entry to add to the USER-MISC/README file in that directory, along with the 2 source files. You can do this multiple times if you wish to contribute several individual features.
* If you want your contribution to be added as a user-contribution and it is several related features, it is probably best to make it a user package directory with a name like USER-FOO. In addition to your new files, the directory should contain a README text file. The README should contain your name and contact information and a brief description of what your new package does. If your files depend on other LAMMPS style files also being installed (e.g. because your file is a derived class from the other LAMMPS class), then an Install.sh file is also needed to check for those dependencies. See other README and Install.sh files in other USER directories as examples. Send us a tarball of this USER-FOO directory.
* Your new source files need to have the LAMMPS copyright, GPL notice, and your name and email address at the top, like other user-contributed LAMMPS source files. They need to create a class that is inside the LAMMPS namespace. If the file is for one of the USER packages, including USER-MISC, then we are not as picky about the coding style (see above). I.e. the files do not need to be in the same stylistic format and syntax as other LAMMPS files, though that would be nice for developers as well as users who try to read your code.

25
cmake/CMakeLists.txt
View File

@ -52,10 +52,17 @@ check_for_autogen_files(${LAMMPS_SOURCE_DIR})
include(CheckCCompilerFlag)
include(CheckIncludeFileCXX)
if (${CMAKE_CXX_COMPILER_ID} STREQUAL "Intel")
if(${CMAKE_CXX_COMPILER_ID} STREQUAL "Intel")
set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -restrict")
endif()
option(DISABLE_CXX11_REQUIREMENT "Disable check that requires C++11 for compiling LAMMPS" OFF)
if(DISABLE_CXX11_REQUIREMENT)
add_definitions(-DLAMMPS_CXX98)
else()
set(CMAKE_CXX_STANDARD 11)
endif()
# GNU compiler features
if (${CMAKE_CXX_COMPILER_ID} STREQUAL "GNU")
option(ENABLE_COVERAGE "Enable code coverage" OFF)
@ -315,13 +322,14 @@ endif()
include(Packages/KSPACE)
include(Packages/PYTHON)
include(Packages/VORONOI)
include(Packages/USER-SCAFACOS)
include(Packages/USER-PLUMED)
include(Packages/USER-COLVARS)
include(Packages/USER-MOLFILE)
include(Packages/USER-NETCDF)
include(Packages/USER-SMD)
include(Packages/USER-QUIP)
include(Packages/USER-PLUMED)
include(Packages/USER-QMMM)
include(Packages/USER-QUIP)
include(Packages/USER-SCAFACOS)
include(Packages/USER-SMD)
include(Packages/USER-VTK)
include(Packages/KIM)
include(Packages/LATTE)
@ -411,8 +419,7 @@ endforeach()
##############################################
# add lib sources of (simple) enabled packages
############################################
foreach(SIMPLE_LIB POEMS USER-ATC USER-AWPMD USER-COLVARS USER-H5MD
USER-QMMM)
foreach(SIMPLE_LIB POEMS USER-ATC USER-AWPMD USER-H5MD USER-QMMM)
if(PKG_${SIMPLE_LIB})
string(REGEX REPLACE "^USER-" "" PKG_LIB "${SIMPLE_LIB}")
string(TOLOWER "${PKG_LIB}" PKG_LIB)
@ -426,10 +433,6 @@ foreach(SIMPLE_LIB POEMS USER-ATC USER-AWPMD USER-COLVARS USER-H5MD
target_include_directories(awpmd PUBLIC ${LAMMPS_LIB_SOURCE_DIR}/awpmd/systems/interact ${LAMMPS_LIB_SOURCE_DIR}/awpmd/ivutils/include)
elseif(PKG_LIB STREQUAL h5md)
target_include_directories(h5md PUBLIC ${LAMMPS_LIB_SOURCE_DIR}/h5md/include ${HDF5_INCLUDE_DIRS})
elseif(PKG_LIB STREQUAL colvars)
target_compile_options(colvars PRIVATE -DLEPTON)
target_include_directories(colvars PRIVATE ${LAMMPS_LIB_SOURCE_DIR}/colvars/lepton/include)
target_include_directories(colvars PUBLIC ${LAMMPS_LIB_SOURCE_DIR}/colvars)
else()
target_include_directories(${PKG_LIB} PUBLIC ${LAMMPS_LIB_SOURCE_DIR}/${PKG_LIB})
endif()

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

@ -1,15 +1,24 @@
if(PKG_KOKKOS)
set(LAMMPS_LIB_KOKKOS_SRC_DIR ${LAMMPS_LIB_SOURCE_DIR}/kokkos)
set(LAMMPS_LIB_KOKKOS_BIN_DIR ${LAMMPS_LIB_BINARY_DIR}/kokkos)
# TODO: this option needs to be documented when this works with a
# regular release version of KOKKOS, and a version compatibility check
# of external KOKKOS lib versus what the KOKKOS package needs is required.
option(EXTERNAL_KOKKOS "Build against external kokkos library")
if(EXTERNAL_KOKKOS)
find_package(Kokkos REQUIRED)
list(APPEND LAMMPS_LINK_LIBS Kokkos::kokkos)
else()
set(LAMMPS_LIB_KOKKOS_SRC_DIR ${LAMMPS_LIB_SOURCE_DIR}/kokkos)
set(LAMMPS_LIB_KOKKOS_BIN_DIR ${LAMMPS_LIB_BINARY_DIR}/kokkos)
add_subdirectory(${LAMMPS_LIB_KOKKOS_SRC_DIR} ${LAMMPS_LIB_KOKKOS_BIN_DIR})
set(Kokkos_INCLUDE_DIRS ${LAMMPS_LIB_KOKKOS_SRC_DIR}/core/src
${LAMMPS_LIB_KOKKOS_SRC_DIR}/containers/src
${LAMMPS_LIB_KOKKOS_SRC_DIR}/algorithms/src
${LAMMPS_LIB_KOKKOS_BIN_DIR})
include_directories(${Kokkos_INCLUDE_DIRS})
list(APPEND LAMMPS_LINK_LIBS kokkos)
endif()
add_definitions(-DLMP_KOKKOS)
add_subdirectory(${LAMMPS_LIB_KOKKOS_SRC_DIR} ${LAMMPS_LIB_KOKKOS_BIN_DIR})
set(Kokkos_INCLUDE_DIRS ${LAMMPS_LIB_KOKKOS_SRC_DIR}/core/src
${LAMMPS_LIB_KOKKOS_SRC_DIR}/containers/src
${LAMMPS_LIB_KOKKOS_SRC_DIR}/algorithms/src
${LAMMPS_LIB_KOKKOS_BIN_DIR})
include_directories(${Kokkos_INCLUDE_DIRS})
list(APPEND LAMMPS_LINK_LIBS kokkos)
set(KOKKOS_PKG_SOURCES_DIR ${LAMMPS_SOURCE_DIR}/KOKKOS)
set(KOKKOS_PKG_SOURCES ${KOKKOS_PKG_SOURCES_DIR}/kokkos.cpp

42
cmake/Modules/Packages/USER-COLVARS.cmake Normal file
View File

@ -0,0 +1,42 @@
if(PKG_USER-COLVARS)
set(COLVARS_SOURCE_DIR ${LAMMPS_LIB_SOURCE_DIR}/colvars)
file(GLOB COLVARS_SOURCES ${COLVARS_SOURCE_DIR}/[^.]*.cpp)
# Build Lepton by default
set(COLVARS_LEPTON_DEFAULT ON)
# but not if C++11 is disabled per user request
if(DEFINED DISABLE_CXX11_REQUIREMENT)
if(DISABLE_CXX11_REQUIREMENT)
set(COLVARS_LEPTON_DEFAULT OFF)
endif()
endif()
option(COLVARS_LEPTON "Build and link the Lepton library" ${COLVARS_LEPTON_DEFAULT})
# Verify that the user's choice is consistent
if(DEFINED DISABLE_CXX11_REQUIREMENT)
if((DISABLE_CXX11_REQUIREMENT) AND (COLVARS_LEPTON))
message(FATAL_ERROR "Building the Lepton library requires C++11 or later.")
endif()
endif()
if(COLVARS_LEPTON)
set(LEPTON_DIR ${LAMMPS_LIB_SOURCE_DIR}/colvars/lepton)
file(GLOB LEPTON_SOURCES ${LEPTON_DIR}/src/[^.]*.cpp)
add_library(lepton STATIC ${LEPTON_SOURCES})
target_include_directories(lepton PRIVATE ${LEPTON_DIR}/include)
endif()
add_library(colvars STATIC ${COLVARS_SOURCES})
target_include_directories(colvars PUBLIC ${LAMMPS_LIB_SOURCE_DIR}/colvars)
list(APPEND LAMMPS_LINK_LIBS colvars)
if(COLVARS_LEPTON)
list(APPEND LAMMPS_LINK_LIBS lepton)
target_compile_options(colvars PRIVATE -DLEPTON)
target_include_directories(colvars PUBLIC ${LEPTON_DIR}/include)
endif()
endif()

2
cmake/presets/most.cmake
View File

@ -7,7 +7,7 @@ set(ALL_PACKAGES ASPHERE CLASS2 COLLOID CORESHELL DIPOLE
PYTHON QEQ REPLICA RIGID SHOCK SRD VORONOI
USER-CGDNA USER-CGSDK USER-COLVARS USER-DIFFRACTION USER-DPD
USER-DRUDE USER-FEP USER-MEAMC USER-MESO
USER-MISC USER-MOFFF USER-OMP USER-PLUMED USER-PHONON USER-REAXC
USER-MISC USER-MOFFF USER-OMP USER-PHONON USER-REAXC
USER-SPH USER-SMD USER-UEF USER-YAFF)
foreach(PKG ${ALL_PACKAGES})

1
doc/Makefile
View File

@ -69,6 +69,7 @@ html: $(OBJECTS) $(ANCHORCHECK)
sphinx-build $(SPHINXEXTRA) -b html -c utils/sphinx-config -d $(BUILDDIR)/doctrees $(RSTDIR) html ;\
echo "############################################" ;\
doc_anchor_check src/*.txt ;\
env LC_ALL=C grep -n '[^ -~]' src/*.txt ;\
echo "############################################" ;\
deactivate ;\
)

2
doc/lammps.1
View File

@ -1,4 +1,4 @@
.TH LAMMPS "7 August 2019" "2019-08-07"
.TH LAMMPS "19 September 2019" "2019-09-19"
.SH NAME
.B LAMMPS
\- Molecular Dynamics Simulator.

2
doc/src/Build_development.txt
View File

@ -50,7 +50,7 @@ Code Coverage and Testing :h4,link(testing)
We do extensive regression testing of the LAMMPS code base on a continuous
basis. Some of the logic to do this has been added to the CMake build so
developers can run the tests directly on their workstation.
developers can run the tests directly on their workstation.
NOTE: this is incomplete and only represents a small subset of tests that we run

23
doc/src/Build_settings.txt
View File

@ -12,6 +12,7 @@ Optional build settings :h3
LAMMPS can be built with several optional settings. Each sub-section
explain how to do this for building both with CMake and make.
"C++11 standard compliance test"_#cxx11 when building all of LAMMPS
"FFT library"_#fft for use with the "kspace_style pppm"_kspace_style.html command
"Size of LAMMPS data types"_#size
"Read or write compressed files"_#gzip
@ -23,6 +24,28 @@ explain how to do this for building both with CMake and make.
:line
C++11 standard compliance test :h4,link(cxx11)
The LAMMPS developers plan to transition to make the C++11 standard the
minimum requirement for compiling LAMMPS. Currently this only applies to
some packages like KOKKOS while the rest aims to be compatible with the C++98
standard. Most currently used compilers are compatible with C++11; some need
to set extra flags to switch. To determine the impact of requiring C++11,
we have added a simple compliance test to the source code, that will cause
the compilation to abort, if C++11 compliance is not available or enabled.
To bypass this check, you need to change a setting in the makefile or
when calling CMake.
[CMake variable]:
-D DISABLE_CXX11_REQUIREMENT=yes
[Makefile.machine setting]:
LMP_INC = -DLAMMPS_CXX98
:line
FFT library :h4,link(fft)
When the KSPACE package is included in a LAMMPS build, the

1
doc/src/Commands_all.txt
View File

@ -124,6 +124,7 @@ An alphabetic list of all general LAMMPS commands.
"thermo"_thermo.html,
"thermo_modify"_thermo_modify.html,
"thermo_style"_thermo_style.html,
"third_order"_third_order.html,
"timer"_timer.html,
"timestep"_timestep.html,
"uncompute"_uncompute.html,

1
doc/src/Commands_pair.txt
View File

@ -166,6 +166,7 @@ OPT.
"lj/smooth/linear (o)"_pair_lj_smooth_linear.html,
"lj/switch3/coulgauss/long"_pair_lj_switch3_coulgauss.html,
"lj96/cut (go)"_pair_lj96.html,
"local/density"_pair_local_density.html,
"lubricate (o)"_pair_lubricate.html,
"lubricate/poly (o)"_pair_lubricate.html,
"lubricateU"_pair_lubricateU.html,

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

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 14 KiB

15
doc/src/Eqs/norm_inf.tex Normal file
View File

@ -0,0 +1,15 @@
\documentclass[preview]{standalone}
\usepackage{varwidth}
\usepackage[utf8x]{inputenc}
\usepackage{amsmath, amssymb, graphics, setspace}
\begin{document}
\begin{varwidth}{50in}
\begin{equation}
|| \vec{F} ||_{inf}
= {\rm max}\left(|F_1^1|, |F_1^2|, |F_1^3| \cdots,
|F_N^1|, |F_N^2|, |F_N^3|\right)
\nonumber
\end{equation}
\end{varwidth}
\end{document}

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

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 9.2 KiB

15
doc/src/Eqs/norm_max.tex Normal file
View File

@ -0,0 +1,15 @@
\documentclass[preview]{standalone}
\usepackage{varwidth}
\usepackage[utf8x]{inputenc}
\usepackage{amsmath, amssymb, graphics, setspace}
\begin{document}
\begin{varwidth}{50in}
\begin{equation}
% \left| \left| \vec{F} \right| \right|_2
|| \vec{F} ||_{max}
= {\rm max}\left(||\vec{F}_1||, \cdots, ||\vec{F}_N||\right)
\nonumber
\end{equation}
\end{varwidth}
\end{document}

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

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 5.9 KiB

15
doc/src/Eqs/norm_two.tex Normal file
View File

@ -0,0 +1,15 @@
\documentclass[preview]{standalone}
\usepackage{varwidth}
\usepackage[utf8x]{inputenc}
\usepackage{amsmath, amssymb, graphics, setspace}
\begin{document}
\begin{varwidth}{50in}
\begin{equation}
% \left| \left| \vec{F} \right| \right|_2
|| \vec{F} ||_{2}
= \sqrt{\vec{F}_1+ \cdots + \vec{F}_N}
\nonumber
\end{equation}
\end{varwidth}
\end{document}

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

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 3.0 KiB

11
doc/src/Eqs/pair_local_density_energy.tex Normal file
View File

@ -0,0 +1,11 @@
\documentclass[12pt]{article}
\begin{document}
$$
U_{LD} = \sum_i F(\rho_i)
$$
\end{document}
~

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

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 7.8 KiB

9
doc/src/Eqs/pair_local_density_energy_implement.tex Normal file
View File

@ -0,0 +1,9 @@
\documentclass[12pt]{article}
\begin{document}
$$
U_{LD} = \sum_k U_{LD}^{(k)} = \sum_i \left[ \sum_k a_\alpha^{(k)} F^{(k)} \left(\rho_i^{(k)}\right) \right]
$$
\end{document}

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

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 3.4 KiB

9
doc/src/Eqs/pair_local_density_energy_multi.tex Normal file
View File

@ -0,0 +1,9 @@
\documentclass[12pt]{article}
\begin{document}
$$
U_{LD} = \sum_i a_\alpha F(\rho_i)
$$
\end{document}

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

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 8.8 KiB

16
doc/src/Eqs/pair_local_density_indicator_func.tex Normal file
View File

@ -0,0 +1,16 @@
\documentclass[12pt]{article}
\usepackage[utf8]{inputenc}
\usepackage{amsmath}
\usepackage{amsfonts}
\begin{document}
\[
\varphi(r) =
\begin{cases}
1 & r \le R_1 \\
c_0 + c_2r^2 + c_4r^4 + c_6r^6 & r \in (R_1, R_2) \\
0 & r \ge R_2
\end{cases}
\]
\end{document}

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

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 3.0 KiB

10
doc/src/Eqs/pair_local_density_ld.tex Normal file
View File

@ -0,0 +1,10 @@
\documentclass[12pt]{article}
\begin{document}
$$
\rho_i = \sum_{j \neq i} \varphi(r_{ij})
$$
\end{document}

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

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 4.2 KiB

10
doc/src/Eqs/pair_local_density_ld_implement.tex Normal file
View File

@ -0,0 +1,10 @@
\documentstyle[12pt]{article}
\begin{document}
$$
\rho_i^{(k)} = \sum_j b_\beta^{(k)} \varphi^{(k)} (r_{ij})
$$
\end{document}

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

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 3.4 KiB

10
doc/src/Eqs/pair_local_density_ld_multi.tex Normal file
View File

@ -0,0 +1,10 @@
\documentclass[12pt]{article}
\begin{document}
$$
\rho_i = \sum_{j \neq i} b_\beta \varphi(r_{ij})
$$
\end{document}

16
doc/src/Errors_messages.txt
View File

@ -4791,6 +4791,22 @@ Self-explanatory. :dd
This fix option cannot be used with point particles. :dd
{Fix langevin gjf and respa are not compatible} :dt
Self-explanatory. :dd
{Fix langevin gjf cannot have period equal to dt/2} :dt
If the period is equal to dt/2 then division by zero will happen. :dd
{Fix langevin gjf should come before fix nve} :dt
Self-explanatory. :dd
{Fix langevin gjf with tbias is not yet implemented with kokkos} :dt
This option is not yet available. :dd
{Fix langevin omega is not yet implemented with kokkos} :dt
This option is not yet available. :dd

48
doc/src/Errors_warnings.txt
View File

@ -47,6 +47,11 @@ too far away. :dd
Self-explanatory. :dd
{Angles are defined but no angle style is set} :dt
The topology contains angles, but there are no angle forces computed
since there was no angle_style command. :dd
{Atom style in data file differs from currently defined atom style} :dt
Self-explanatory. :dd
@ -73,6 +78,11 @@ short or the bond has blown apart and an atom is too far away. :dd
Self-explanatory. :dd
{Bonds are defined but no bond style is set} :dt
The topology contains bonds, but there are no bond forces computed
since there was no bond_style command. :dd
{Bond/angle/dihedral extent > half of periodic box length} :dt
This is a restriction because LAMMPS can be confused about which image
@ -186,6 +196,11 @@ to check your simulation geometry. :dd
Self-explanatory. :dd
{Dihedrals are defined but no dihedral style is set} :dt
The topology contains dihedrals, but there are no dihedral forces computed
since there was no dihedral_style command. :dd
{Dump dcd/xtc timestamp may be wrong with fix dt/reset} :dt
If the fix changes the timestep, the dump dcd file will not
@ -248,6 +263,10 @@ included one or more of the following: kspace, triclinic, a hybrid
pair style, an eam pair style, or no "single" function for the pair
style. :dd
{Fix langevin gjf using random gaussians is not implemented with kokkos} :dt
This will most likely cause errors in kinetic fluctuations.
{Fix property/atom mol or charge w/out ghost communication} :dt
A model typically needs these properties defined for ghost atoms. :dd
@ -348,6 +367,11 @@ to check your simulation geometry. :dd
Self-explanatory. :dd
{Impropers are defined but no improper style is set} :dt
The topology contains impropers, but there are no improper forces computed
since there was no improper_style command. :dd
{Inconsistent image flags} :dt
The image flags for a pair on bonded atoms appear to be inconsistent.
@ -403,6 +427,30 @@ This library function cannot be used if atom IDs are not defined or
are not consecutively numbered, or if no atom map is defined. See the
atom_modify command for details about atom maps. :dd
{Likewise 1-2 special neighbor interactions != 1.0} :dt
The topology contains bonds, but there is no bond style defined
and a 1-2 special neighbor scaling factor was not 1.0. This
means that pair style interactions may have scaled or missing
pairs in the neighbor list in expectation of interactions for
those pairs being computed from the bond style. :dd
{Likewise 1-3 special neighbor interactions != 1.0} :dt
The topology contains angles, but there is no angle style defined
and a 1-3 special neighbor scaling factor was not 1.0. This
means that pair style interactions may have scaled or missing
pairs in the neighbor list in expectation of interactions for
those pairs being computed from the angle style. :dd
{Likewise 1-4 special neighbor interactions != 1.0} :dt
The topology contains dihedrals, but there is no dihedral style defined
and a 1-4 special neighbor scaling factor was not 1.0. This
means that pair style interactions may have scaled or missing
pairs in the neighbor list in expectation of interactions for
those pairs being computed from the dihedral style. :dd
{Lost atoms via change_box: original %ld current %ld} :dt
The command options you have used caused atoms to be lost. :dd

1
doc/src/Examples.txt
View File

@ -141,6 +141,7 @@ HEAT: compute thermal conductivity for LJ and water via fix ehex
KAPPA: compute thermal conductivity via several methods
MC: using LAMMPS in a Monte Carlo mode to relax the energy of a system
SPIN: examples for features of the SPIN package
UNITS: examples that run the same simulation in lj, real, metal units
USER: examples for USER packages and USER-contributed commands
VISCOSITY: compute viscosity via several methods :tb(s=:)

16
doc/src/Howto_spins.txt
View File

@ -43,19 +43,19 @@ langevin/spin"_fix_langevin_spin.html. It allows to either dissipate
the thermal energy of the Langevin thermostat, or to perform a
relaxation of the magnetic configuration toward an equilibrium state.
The command "fix setforce/spin"_fix_setforce.html allows to set the
components of the magnetic precession vectors (while erasing and
replacing the previously computed magnetic precession vectors on
the atom).
This command can be used to freeze the magnetic moment of certain
atoms in the simulation by zeroing their precession vector.
The command "fix setforce/spin"_fix_setforce.html allows to set the
components of the magnetic precession vectors (while erasing and
replacing the previously computed magnetic precession vectors on
the atom).
This command can be used to freeze the magnetic moment of certain
atoms in the simulation by zeroing their precession vector.
The command "fix nve/spin"_fix_nve_spin.html can be used to
perform a symplectic integration of the combined dynamics of spins
perform a symplectic integration of the combined dynamics of spins
and atomic motions.
The minimization style "min/spin"_min_spin.html can be applied
to the spins to perform a minimization of the spin configuration.
to the spins to perform a minimization of the spin configuration.
All the computed magnetic properties can be output by two main

2
doc/src/Howto_viscosity.txt
View File

@ -83,7 +83,7 @@ variable d equal $p*$s # dump interval :pre
# convert from LAMMPS real units to SI :pre
variable kB equal 1.3806504e-23 # \[J/K/] Boltzmann
variable kB equal 1.3806504e-23 # \[J/K\] Boltzmann
variable atm2Pa equal 101325.0
variable A2m equal 1.0e-10
variable fs2s equal 1.0e-15

BIN
doc/src/JPG/dynamical_matrix_dynmat.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 17 KiB

BIN
doc/src/JPG/dynamical_matrix_force_constant.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 19 KiB

BIN
doc/src/JPG/dynamical_matrix_phonons.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 26 KiB

BIN
doc/src/JPG/third_order_force_constant.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 24 KiB

4
doc/src/Manual.txt
View File

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

8
doc/src/Packages_details.txt
View File

@ -1746,11 +1746,12 @@ USER-PHONON package :link(PKG-USER-PHONON),h4
A "fix phonon"_fix_phonon.html command that calculates dynamical
matrices, which can then be used to compute phonon dispersion
relations, directly from molecular dynamics simulations.
And a "dynamical_matrix" command to compute the dynamical matrix
from finite differences.
And a "dynamical_matrix"_dynamical_matrix.html as well as a
"third_order"_third_order.html command to compute the dynamical matrix
and third order tensor from finite differences.
[Authors:] Ling-Ti Kong (Shanghai Jiao Tong University) for "fix phonon"
and Charlie Sievers (UC Davis) for "dynamical_matrix"
and Charlie Sievers (UC Davis) for "dynamical_matrix" and "third_order"
[Supporting info:]
@ -1759,6 +1760,7 @@ src/USER-PHONON: filenames -> commands
src/USER-PHONON/README
"fix phonon"_fix_phonon.html
"dynamical_matrix"_dynamical_matrix.html
"third_order"_third_order.html
examples/USER/phonon :ul
:line

88
doc/src/Speed_kokkos.txt
View File

@ -46,14 +46,14 @@ software version 7.5 or later must be installed on your system. See
the discussion for the "GPU package"_Speed_gpu.html for details of how
to check and do this.
NOTE: Kokkos with CUDA currently implicitly assumes that the MPI library
is CUDA-aware. This is not always the case, especially when using
pre-compiled MPI libraries provided by a Linux distribution. This is not
a problem when using only a single GPU with a single MPI rank. When
running with multiple MPI ranks, you may see segmentation faults without
CUDA-aware MPI support. These can be avoided by adding the flags "-pk
kokkos cuda/aware off"_Run_options.html to the LAMMPS command line or by
using the command "package kokkos cuda/aware off"_package.html in the
NOTE: Kokkos with CUDA currently implicitly assumes that the MPI library
is CUDA-aware. This is not always the case, especially when using
pre-compiled MPI libraries provided by a Linux distribution. This is not
a problem when using only a single GPU with a single MPI rank. When
running with multiple MPI ranks, you may see segmentation faults without
CUDA-aware MPI support. These can be avoided by adding the flags "-pk
kokkos cuda/aware off"_Run_options.html to the LAMMPS command line or by
using the command "package kokkos cuda/aware off"_package.html in the
input file.
[Building LAMMPS with the KOKKOS package:]
@ -110,10 +110,10 @@ Makefile.kokkos_mpi_only) will give better performance than the OpenMP
back end (i.e. Makefile.kokkos_omp) because some of the overhead to make
the code thread-safe is removed.
NOTE: Use the "-pk kokkos" "command-line switch"_Run_options.html to
change the default "package kokkos"_package.html options. See its doc
page for details and default settings. Experimenting with its options
can provide a speed-up for specific calculations. For example:
NOTE: Use the "-pk kokkos" "command-line switch"_Run_options.html to
change the default "package kokkos"_package.html options. See its doc
page for details and default settings. Experimenting with its options
can provide a speed-up for specific calculations. For example:
mpirun -np 16 lmp_kokkos_mpi_only -k on -sf kk -pk kokkos newton on neigh half comm no -in in.lj # Newton on, Half neighbor list, non-threaded comm :pre
@ -183,15 +183,15 @@ tasks/node. The "-k on t Nt" command-line switch sets the number of
threads/task as Nt. The product of these two values should be N, i.e.
256 or 264.
NOTE: The default for the "package kokkos"_package.html command when
running on KNL is to use "half" neighbor lists and set the Newton flag
to "on" for both pairwise and bonded interactions. This will typically
be best for many-body potentials. For simpler pair-wise potentials, it
may be faster to use a "full" neighbor list with Newton flag to "off".
Use the "-pk kokkos" "command-line switch"_Run_options.html to change
the default "package kokkos"_package.html options. See its doc page for
details and default settings. Experimenting with its options can provide
a speed-up for specific calculations. For example:
NOTE: The default for the "package kokkos"_package.html command when
running on KNL is to use "half" neighbor lists and set the Newton flag
to "on" for both pairwise and bonded interactions. This will typically
be best for many-body potentials. For simpler pair-wise potentials, it
may be faster to use a "full" neighbor list with Newton flag to "off".
Use the "-pk kokkos" "command-line switch"_Run_options.html to change
the default "package kokkos"_package.html options. See its doc page for
details and default settings. Experimenting with its options can provide
a speed-up for specific calculations. For example:
mpirun -np 64 lmp_kokkos_phi -k on t 4 -sf kk -pk kokkos comm host -in in.reax # Newton on, half neighbor list, threaded comm
mpirun -np 64 lmp_kokkos_phi -k on t 4 -sf kk -pk kokkos newton off neigh full comm no -in in.lj # Newton off, full neighbor list, non-threaded comm :pre
@ -206,19 +206,19 @@ supports.
[Running on GPUs:]
Use the "-k" "command-line switch"_Run_options.html to specify the
number of GPUs per node. Typically the -np setting of the mpirun command
should set the number of MPI tasks/node to be equal to the number of
physical GPUs on the node. You can assign multiple MPI tasks to the same
GPU with the KOKKOS package, but this is usually only faster if some
portions of the input script have not been ported to use Kokkos. In this
case, also packing/unpacking communication buffers on the host may give
speedup (see the KOKKOS "package"_package.html command). Using CUDA MPS
Use the "-k" "command-line switch"_Run_options.html to specify the
number of GPUs per node. Typically the -np setting of the mpirun command
should set the number of MPI tasks/node to be equal to the number of
physical GPUs on the node. You can assign multiple MPI tasks to the same
GPU with the KOKKOS package, but this is usually only faster if some
portions of the input script have not been ported to use Kokkos. In this
case, also packing/unpacking communication buffers on the host may give
speedup (see the KOKKOS "package"_package.html command). Using CUDA MPS
is recommended in this scenario.
Using a CUDA-aware MPI library is highly recommended. CUDA-aware MPI use can be
avoided by using "-pk kokkos cuda/aware no"_package.html. As above for
multi-core CPUs (and no GPU), if N is the number of physical cores/node,
Using a CUDA-aware MPI library is highly recommended. CUDA-aware MPI use can be
avoided by using "-pk kokkos cuda/aware no"_package.html. As above for
multi-core CPUs (and no GPU), if N is the number of physical cores/node,
then the number of MPI tasks/node should not exceed N.
-k on g Ng :pre
@ -229,18 +229,18 @@ one or more nodes, each with two GPUs:
mpirun -np 2 lmp_kokkos_cuda_openmpi -k on g 2 -sf kk -in in.lj # 1 node, 2 MPI tasks/node, 2 GPUs/node
mpirun -np 32 -ppn 2 lmp_kokkos_cuda_openmpi -k on g 2 -sf kk -in in.lj # 16 nodes, 2 MPI tasks/node, 2 GPUs/node (32 GPUs total) :pre
NOTE: The default for the "package kokkos"_package.html command when
running on GPUs is to use "full" neighbor lists and set the Newton flag
to "off" for both pairwise and bonded interactions, along with threaded
communication. When running on Maxwell or Kepler GPUs, this will
typically be best. For Pascal GPUs, using "half" neighbor lists and
setting the Newton flag to "on" may be faster. For many pair styles,
setting the neighbor binsize equal to twice the CPU default value will
give speedup, which is the default when running on GPUs. Use the "-pk
kokkos" "command-line switch"_Run_options.html to change the default
"package kokkos"_package.html options. See its doc page for details and
default settings. Experimenting with its options can provide a speed-up
for specific calculations. For example:
NOTE: The default for the "package kokkos"_package.html command when
running on GPUs is to use "full" neighbor lists and set the Newton flag
to "off" for both pairwise and bonded interactions, along with threaded
communication. When running on Maxwell or Kepler GPUs, this will
typically be best. For Pascal GPUs, using "half" neighbor lists and
setting the Newton flag to "on" may be faster. For many pair styles,
setting the neighbor binsize equal to twice the CPU default value will
give speedup, which is the default when running on GPUs. Use the "-pk
kokkos" "command-line switch"_Run_options.html to change the default
"package kokkos"_package.html options. See its doc page for details and
default settings. Experimenting with its options can provide a speed-up
for specific calculations. For example:
mpirun -np 2 lmp_kokkos_cuda_openmpi -k on g 2 -sf kk -pk kokkos newton on neigh half binsize 2.8 -in in.lj # Newton on, half neighbor list, set binsize = neighbor ghost cutoff :pre

14
doc/src/Tools.txt
View File

@ -87,6 +87,7 @@ Miscellaneous tools :h3
"emacs"_#emacs,
"i-pi"_#ipi,
"kate"_#kate,
"singularity"_#singularity_tool,
"vim"_#vim :tb(c=5,ea=c,a=l)
:line
@ -531,17 +532,26 @@ Ernst Mach Institute in Germany (georg.ganzenmueller at emi.fhg.de).
spin tool :h4,link(spin)
The spin sub-directory contains a C file interpolate.c which can
be compiled and used to perform a cubic polynomial interpolation of
be compiled and used to perform a cubic polynomial interpolation of
the MEP following a GNEB calculation.
See the README file in tools/spin/interpolate_gneb for more details.
This tool was written by the SPIN package author, Julien
Tranchida at Sandia National Labs (jtranch at sandia.gov, and by Aleksei
Tranchida at Sandia National Labs (jtranch at sandia.gov, and by Aleksei
Ivanov, at University of Iceland (ali5 at hi.is).
:line
singularity tool :h4,link(singularity_tool)
The singularity sub-directory contains container definitions files
that can be used to build container images for building and testing
LAMMPS on specific OS variants using the "Singularity"_https://sylabs.io
container software. Contributions for additional variants are welcome.
:line
vim tool :h4,link(vim)
The files in the tools/vim directory are add-ons to the VIM editor

1
doc/src/commands_list.txt
View File

@ -108,6 +108,7 @@ Commands :h1
thermo
thermo_modify
thermo_style
third_order
timer
timestep
uncompute

4
doc/src/compute.txt
View File

@ -244,7 +244,7 @@ compute"_Commands_compute.html doc page are followed by one or more of
"plasticity/atom"_compute_plasticity_atom.html - Peridynamic plasticity for each atom
"pressure"_compute_pressure.html - total pressure and pressure tensor
"pressure/cylinder"_compute_pressure_cylinder.html - pressure tensor in cylindrical coordinates
"pressure/uef"_compute_pressure_uef.html - pressure tensor in the reference frame of an applied flow field
"pressure/uef"_compute_pressure_uef.html - pressure tensor in the reference frame of an applied flow field
"property/atom"_compute_property_atom.html - convert atom attributes to per-atom vectors/arrays
"property/chunk"_compute_property_chunk.html - extract various per-chunk attributes
"property/local"_compute_property_local.html - convert local attributes to localvectors/arrays
@ -284,7 +284,7 @@ compute"_Commands_compute.html doc page are followed by one or more of
"stress/mop"_compute_stress_mop.html - normal components of the local stress tensor using the method of planes
"stress/mop/profile"_compute_stress_mop.html - profile of the normal components of the local stress tensor using the method of planes
"stress/tally"_compute_tally.html -
"tdpd/cc/atom"_compute_tdpd_cc_atom.html - per-atom chemical concentration of a specified species for each tDPD particle
"tdpd/cc/atom"_compute_tdpd_cc_atom.html - per-atom chemical concentration of a specified species for each tDPD particle
"temp"_compute_temp.html - temperature of group of atoms
"temp/asphere"_compute_temp_asphere.html - temperature of aspherical particles
"temp/body"_compute_temp_body.html - temperature of body particles

2
doc/src/compute_coord_atom.txt
View File

@ -47,7 +47,7 @@ neighboring atoms, unless selected by type, type range, or group option,
are included in the coordination number tally.
The optional {group} keyword allows to specify from which group atoms
contribute to the coordination number. Default setting is group 'all'.
contribute to the coordination number. Default setting is group 'all'.
The {typeN} keywords allow specification of which atom types
contribute to each coordination number. One coordination number is

3
doc/src/compute_gyration_shape.txt
View File

@ -84,3 +84,6 @@ package"_Build_package.html doc page for more info.
:link(Theodorou)
[(Theodorou)] Theodorou, Suter, Macromolecules, 18, 1206 (1985).
:link(Mattice)
[(Mattice)] Mattice, Suter, Conformational Theory of Large Molecules, Wiley, New York, 1994.

36
doc/src/compute_hma.txt
View File

@ -34,7 +34,7 @@ compute 2 all hma 1 u cv :pre
Define a computation that calculates the properties of a solid (potential
energy, pressure or heat capacity), using the harmonically-mapped averaging
(HMA) method.
(HMA) method.
This command yields much higher precision than the equivalent compute commands
("compute pe"_compute_pe.html, "compute pressure"_compute_pressure.html, etc.)
commands during a canonical simulation of an atomic crystal. Specifically,
@ -52,7 +52,7 @@ restricted to simulations in the NVT ensemble. While this compute may be
used with any potential in LAMMPS, it will provide inaccurate results
for potentials that do not go to 0 at the truncation distance;
"pair_lj_smooth_linear"_pair_lj_smooth_linear.html and Ewald summation should
work fine, while "pair_lj"_pair_lj.html will perform poorly unless
work fine, while "pair_lj"_pair_lj.html will perform poorly unless
the potential is shifted (via "pair_modify"_pair_modify.html shift) or the cutoff is large. Furthermore, computation of the heat capacity with
this compute is restricted to those that implement the single_hessian method
in Pair. Implementing single_hessian in additional pair styles is simple.
@ -64,8 +64,8 @@ the list of pair styles that currently implement pair_hessian:
:ule
In this method, the analytically known harmonic behavior of a crystal is removed from the traditional ensemble
averages, which leads to an accurate and precise measurement of the anharmonic contributions without contamination
by noise produced by the already-known harmonic behavior.
averages, which leads to an accurate and precise measurement of the anharmonic contributions without contamination
by noise produced by the already-known harmonic behavior.
A detailed description of this method can be found in ("Moustafa"_#hma-Moustafa). The potential energy is computed by the formula:
\begin\{equation\}
@ -74,9 +74,9 @@ A detailed description of this method can be found in ("Moustafa"_#hma-Moustafa)
where \(N\) is the number of atoms in the system, \(k_B\) is Boltzmann's
constant, \(T\) is the temperature, \(d\) is the
dimensionality of the system (2 or 3 for 2d/3d), \(F\bullet\Delta r\) is the sum of dot products of the
atomic force vectors and displacement (from lattice sites) vectors, and \(U\) is the sum of
pair, bond, angle, dihedral, improper, kspace (long-range), and fix energies.
dimensionality of the system (2 or 3 for 2d/3d), \(F\bullet\Delta r\) is the sum of dot products of the
atomic force vectors and displacement (from lattice sites) vectors, and \(U\) is the sum of
pair, bond, angle, dihedral, improper, kspace (long-range), and fix energies.
The pressure is computed by the formula:
@ -118,30 +118,30 @@ When using this keyword, the compute must be first active (it must be included
via a "thermo_style custom"_thermo_style.html command) while the atoms are
still at their lattice sites (before equilibration).
The temp-ID specified with compute hma command should be same as the fix-ID of Nose-Hoover ("fix nvt"_fix_nh.html) or
Berendsen ("fix temp/berendsen"_fix_temp_berendsen.html) thermostat used for the simulation. While using this command, Langevin thermostat
("fix langevin"_fix_langevin.html)
should be avoided as its extra forces interfere with the HMA implementation.
The temp-ID specified with compute hma command should be same as the fix-ID of Nose-Hoover ("fix nvt"_fix_nh.html) or
Berendsen ("fix temp/berendsen"_fix_temp_berendsen.html) thermostat used for the simulation. While using this command, Langevin thermostat
("fix langevin"_fix_langevin.html)
should be avoided as its extra forces interfere with the HMA implementation.
NOTE: Compute hma command should be used right after the energy minimization, when the atoms are at their lattice sites.
NOTE: Compute hma command should be used right after the energy minimization, when the atoms are at their lattice sites.
The simulation should not be started before this command has been used in the input script.
The following example illustrates the placement of this command in the input script:
min_style cg
minimize 1e-35 1e-15 50000 500000
min_style cg
minimize 1e-35 1e-15 50000 500000
compute 1 all hma thermostatid u
fix thermostatid all nvt temp 600.0 600.0 100.0 :pre
fix thermostatid all nvt temp 600.0 600.0 100.0 :pre
NOTE: Compute hma should be used when the atoms of the solid do not diffuse. Diffusion will reduce the precision in the potential energy computation.
NOTE: The "fix_modify energy yes"_fix_modify.html command must also be specified if a fix is to contribute potential energy to this command.
An example input script that uses this compute is included in
@ -180,5 +180,5 @@ this compute.
:line
:link(hma-Moustafa)
[(Moustafa)] Sabry G. Moustafa, Andrew J. Schultz, and David A. Kofke, {Very fast averaging of thermal properties of crystals by molecular simulation},
[(Moustafa)] Sabry G. Moustafa, Andrew J. Schultz, and David A. Kofke, {Very fast averaging of thermal properties of crystals by molecular simulation},
"Phys. Rev. E \[92\], 043303 (2015)"_https://link.aps.org/doi/10.1103/PhysRevE.92.043303

12
doc/src/compute_orientorder_atom.txt
View File

@ -76,14 +76,14 @@ parameters up to {Q}12 for a range of commonly encountered
high-symmetry structures are given in Table I of "Mickel et
al."_#Mickel, and these can be reproduced with this compute
The optional keyword {wl} will output the third-order invariants {Wl}
The optional keyword {wl} will output the third-order invariants {Wl}
(see Eq. 1.4 in "Steinhardt"_#Steinhardt) for the same degrees as
for the {Ql} parameters. For the FCC crystal with {nnn} =12,
{W}4 = -sqrt(14/143).(49/4096)/Pi^1.5 = -0.0006722136...
The optional keyword {wl/hat} will output the normalized third-order
invariants {Wlhat} (see Eq. 2.2 in "Steinhardt"_#Steinhardt)
for the same degrees as for the {Ql} parameters. For the FCC crystal
The optional keyword {wl/hat} will output the normalized third-order
invariants {Wlhat} (see Eq. 2.2 in "Steinhardt"_#Steinhardt)
for the same degrees as for the {Ql} parameters. For the FCC crystal
with {nnn} =12, {W}4hat = -7/3*sqrt(2/429) = -0.159317...The numerical
values of {Wlhat} for a range of commonly encountered high-symmetry
structures are given in Table I of "Steinhardt"_#Steinhardt, and these
@ -127,9 +127,9 @@ range 0 <= {Ql} <= 1.
If the keyword {wl} is set to yes, then the {Wl} values for each
atom will be added to the output array, which are real numbers.
If the keyword {wl/hat} is set to yes, then the {Wl_hat}
If the keyword {wl/hat} is set to yes, then the {Wl_hat}
values for each atom will be added to the output array, which are real numbers.
If the keyword {components} is set, then the real and imaginary parts
of each component of (normalized) {Ybar_lm} will be added to the
output array in the following order: Re({Ybar_-m}) Im({Ybar_-m})

2
doc/src/compute_sna_atom.txt
View File

@ -196,7 +196,7 @@ for j1 in range(0,twojmax+1):
if (j>=j1): print j1/2.,j2/2.,j/2. :pre
NOTE: the {diagonal} keyword allowing other possible choices
for the number of bispectrum components was removed in 2019,
for the number of bispectrum components was removed in 2019,
since all potentials use the value of 3, corresponding to the
above set of bispectrum components.

12
doc/src/compute_spin.txt
View File

@ -40,14 +40,14 @@ The simplest way to output the results of the compute spin calculation
is to define some of the quantities as variables, and to use the thermo and
thermo_style commands, for example:
compute out_mag all spin :pre
compute out_mag all spin :pre
variable mag_z equal c_out_mag\[3\]
variable mag_norm equal c_out_mag\[4\]
variable temp_mag equal c_out_mag\[6\] :pre
variable mag_z equal c_out_mag\[3\]
variable mag_norm equal c_out_mag\[4\]
variable temp_mag equal c_out_mag\[6\] :pre
thermo 10
thermo_style custom step v_mag_z v_mag_norm v_temp_mag :pre
thermo 10
thermo_style custom step v_mag_z v_mag_norm v_temp_mag :pre
This series of commands evaluates the total magnetization along z, the norm of
the total magnetization, and the magnetic temperature. Three variables are

73
doc/src/create_bonds.txt
View File

@ -23,11 +23,14 @@ style = {many} or {single/bond} or {single/angle} or {single/dihedral} :ule,l
btype = bond type of new bond
batom1,batom2 = atom IDs for two atoms in bond
{single/angle} args = atype aatom1 aatom2 aatom3
atype = bond type of new angle
atype = angle type of new angle
aatom1,aatom2,aatom3 = atom IDs for three atoms in angle
{single/dihedral} args = dtype datom1 datom2 datom3 datom4
dtype = bond type of new dihedral
datom1,datom2,datom3,datom4 = atom IDs for four atoms in dihedral :pre
dtype = dihedral type of new dihedral
datom1,datom2,datom3,datom4 = atom IDs for four atoms in dihedral
{single/improper} args = itype iatom1 iatom2 iatom3 iatom4
itype = improper type of new improper
iatom1,iatom2,iatom3,iatom4 = atom IDs for four atoms in improper :pre
zero or more keyword/value pairs may be appended :l
keyword = {special} :l
{special} value = {yes} or {no} :pre
@ -38,51 +41,54 @@ keyword = {special} :l
create_bonds many all all 1 1.0 1.2
create_bonds many surf solvent 3 2.0 2.4
create_bonds single/bond 1 1 2
create_bonds single/angle 5 52 98 107 special no :pre
create_bonds single/angle 5 52 98 107 special no
create_bonds single/dihedral 2 4 19 27 101
create_bonds single/improper 3 23 26 31 57 :pre
[Description:]
Create bonds between pairs of atoms that meet a specified distance
criteria. Or create a single bond, angle, or dihedral between 2, 3,
criteria. Or create a single bond, angle, dihedral or improper between 2, 3,
or 4 specified atoms.
The new bond (angle, dihedral) interactions will then be computed
during a simulation by the bond (angle, dihedral) potential defined by
The new bond (angle, dihedral, improper) interactions will then be computed
during a simulation by the bond (angle, dihedral, improper) potential defined by
the "bond_style"_bond_style.html, "bond_coeff"_bond_coeff.html,
"angle_style"_angle_style.html, "angle_coeff"_angle_coeff.html,
"dihedral_style"_dihedral_style.html,
"dihedral_coeff"_dihedral_coeff.html commands.
"dihedral_coeff"_dihedral_coeff.html, "improper_style"_improper_style.html,
"improper_coeff"_improper_coeff.html commands.
The {many} style is useful for adding bonds to a system, e.g. between
nearest neighbors in a lattice of atoms, without having to enumerate
all the bonds in the data file read by the "read_data"_read_data.html
command.
The {single} styles are useful for adding bonds, angles, dihedrals
The {single} styles are useful for adding bonds, angles, dihedrals, impropers
to a system incrementally, then continuing a simulation.
Note that this command does not auto-create any angle or dihedral
Note that this command does not auto-create any angle, dihedral or improper
interactions when a bond is added. Nor does it auto-create any bonds
when an angle or dihedral is added. Or auto-create any angles when a
dihedral is added. Thus the flexibility of this command is limited.
when an angle, dihedral or improper is added. Or auto-create any angles when a
dihedral or improper is added. Thus the flexibility of this command is limited.
It can be used several times to create different types of bond at
different distances. But it cannot typically auto-create all the
bonds or angles or dihedral that would normally be defined in a data
file for a complex system of molecules.
bonds or angles or dihedrals or impropers that would normally be defined in a
data file for a complex system of molecules.
NOTE: If the system has no bonds (angles, dihedrals) to begin with, or
if more bonds per atom are being added than currently exist, then you
NOTE: If the system has no bonds (angles, dihedrals, impropers) to begin with,
or if more bonds per atom are being added than currently exist, then you
must insure that the number of bond types and the maximum number of
bonds per atom are set to large enough values. And similarly for
angles and dihedrals. Otherwise an error may occur when too many
bonds (angles, dihedrals) are added to an atom. If the
angles, dihedrals and impropers. Otherwise an error may occur when too many
bonds (angles, dihedrals, impropers) are added to an atom. If the
"read_data"_read_data.html command is used to define the system, these
parameters can be set via the "bond types" and "extra bond per atom"
fields in the header section of the data file. If the
"create_box"_create_box.html command is used to define the system,
these 2 parameters can be set via its optional "bond/types" and
"extra/bond/per/atom" arguments. And similarly for angles and
dihedrals. See the doc pages for these 2 commands for details.
"extra/bond/per/atom" arguments. And similarly for angles, dihedrals and
impropers. See the doc pages for these 2 commands for details.
:line
@ -137,18 +143,25 @@ ordered linearly within the angle; the central atom is {aatom2}.
{Atype} must be a value between 1 and the number of angle types
defined.
The {single/dihedral} style creates a single dihedral of type {btype}
between two atoms with IDs {batom1} and {batom2}. The ordering of the
atoms is the same as in the {Dihedrals} section of a data file read by
the "read_data"_read_data.html command. I.e. the 4 atoms are ordered
linearly within the dihedral. {Dtype} must be a value between 1 and
The {single/dihedral} style creates a single dihedral of type {dtype}
between four atoms with IDs {datom1}, {datom2}, {datom3}, and {datom4}. The
ordering of the atoms is the same as in the {Dihedrals} section of a data file
read by the "read_data"_read_data.html command. I.e. the 4 atoms are ordered
linearly within the dihedral. {dtype} must be a value between 1 and
the number of dihedral types defined.
The {single/improper} style creates a single improper of type {itype}
between four atoms with IDs {iatom1}, {iatom2}, {iatom3}, and {iatom4}. The
ordering of the atoms is the same as in the {Impropers} section of a data file
read by the "read_data"_read_data.html command. I.e. the 4 atoms are ordered
linearly within the improper. {itype} must be a value between 1 and
the number of improper types defined.
:line
The keyword {special} controls whether an internal list of special
bonds is created after one or more bonds, or a single angle or
dihedral is added to the system.
bonds is created after one or more bonds, or a single angle, dihedral or
improper is added to the system.
The default value is {yes}. A value of {no} cannot be used
with the {many} style.
@ -161,16 +174,16 @@ see the "special_bonds"_special_bonds.html command for details.
Thus if you are adding a few bonds or a large list of angles all at
the same time, by using this command repeatedly, it is more efficient
to only trigger the internal list to be created once, after the last
bond (or angle, or dihedral) is added:
bond (or angle, or dihedral, or improper) is added:
create_bonds single/bond 5 52 98 special no
create_bonds single/bond 5 73 74 special no
create_bonds single/bond 5 73 74 special no
...
create_bonds single/bond 5 17 386 special no
create_bonds single/bond 4 112 183 special yes :pre
Note that you MUST insure the internal list is re-built after the last
bond (angle, dihedral) is added, before performing a simulation.
bond (angle, dihedral, improper) is added, before performing a simulation.
Otherwise pairwise interactions will not be properly excluded or
weighted. LAMMPS does NOT check that you have done this correctly.

3
doc/src/dump.txt
View File

@ -21,7 +21,8 @@ dump ID group-ID style N file args :pre
ID = user-assigned name for the dump :ulb,l
group-ID = ID of the group of atoms to be dumped :l
style = {atom} or {atom/gz} or {atom/mpiio} or {cfg} or {cfg/gz} or {cfg/mpiio} or {custom} or {custom/gz} or {custom/mpiio} or {dcd} or {h5md} or {image} or {local} or {molfile} or {movie} or {netcdf} or {netcdf/mpiio} or {vtk} or {xtc} or {xyz} or {xyz/gz} or {xyz/mpiio} :l
style = {atom} or {atom/gz} or {atom/mpiio} or {cfg} or {cfg/gz} or
{cfg/mpiio} or {custom} or {custom/gz} or {custom/mpiio} or {dcd} or {h5md} or {image} or {local} or {local/gz} or {molfile} or {movie} or {netcdf} or {netcdf/mpiio} or {vtk} or {xtc} or {xyz} or {xyz/gz} or {xyz/mpiio} :l
N = dump every this many timesteps :l
file = name of file to write dump info to :l
args = list of arguments for a particular style :l

42
doc/src/dump_modify.txt
View File

@ -15,7 +15,7 @@ dump_modify dump-ID keyword values ... :pre
dump-ID = ID of dump to modify :ulb,l
one or more keyword/value pairs may be appended :l
these keywords apply to various dump styles :l
keyword = {append} or {at} or {buffer} or {delay} or {element} or {every} or {fileper} or {first} or {flush} or {format} or {image} or {label} or {maxfiles} or {nfile} or {pad} or {precision} or {region} or {scale} or {sort} or {thresh} or {unwrap} :l
keyword = {append} or {at} or {buffer} or {delay} or {element} or {every} or {fileper} or {first} or {flush} or {format} or {image} or {label} or {maxfiles} or {nfile} or {pad} or {pbc} or {precision} or {region} or {refresh} or {scale} or {sfactor} or {sort} or {tfactor} or {thermo} or {thresh} or {time} or {units} or {unwrap} :l
{append} arg = {yes} or {no}
{at} arg = N
N = index of frame written upon first dump
@ -30,10 +30,10 @@ keyword = {append} or {at} or {buffer} or {delay} or {element} or {every} or {fi
{fileper} arg = Np
Np = write one file for every this many processors
{first} arg = {yes} or {no}
{flush} arg = {yes} or {no}
{format} args = {line} string, {int} string, {float} string, M string, or {none}
string = C-style format string
M = integer from 1 to N, where N = # of per-atom quantities being output
{flush} arg = {yes} or {no}
{image} arg = {yes} or {no}
{label} arg = string
string = character string (e.g. BONDS) to use in header of dump local file
@ -48,18 +48,20 @@ keyword = {append} or {at} or {buffer} or {delay} or {element} or {every} or {fi
{refresh} arg = c_ID = compute ID that supports a refresh operation
{scale} arg = {yes} or {no}
{sfactor} arg = coordinate scaling factor (> 0.0)
{thermo} arg = {yes} or {no}
{tfactor} arg = time scaling factor (> 0.0)
{sort} arg = {off} or {id} or N or -N
off = no sorting of per-atom lines within a snapshot
id = sort per-atom lines by atom ID
N = sort per-atom lines in ascending order by the Nth column
-N = sort per-atom lines in descending order by the Nth column
{tfactor} arg = time scaling factor (> 0.0)
{thermo} arg = {yes} or {no}
{time} arg = {yes} or {no}
{thresh} args = attribute operator value
attribute = same attributes (x,fy,etotal,sxx,etc) used by dump custom style
operator = "<" or "<=" or ">" or ">=" or "==" or "!=" or "|^"
value = numeric value to compare to, or LAST
these 3 args can be replaced by the word "none" to turn off thresholding
{units} arg = {yes} or {no}
{unwrap} arg = {yes} or {no} :pre
these keywords apply only to the {image} and {movie} "styles"_dump_image.html :l
keyword = {acolor} or {adiam} or {amap} or {backcolor} or {bcolor} or {bdiam} or {boxcolor} or {color} or {bitrate} or {framerate} :l
@ -620,6 +622,37 @@ threshold criterion is met. Otherwise it is not met.
:line
The {time} keyword only applies to the dump {atom}, {custom}, and
{local} styles (and their COMPRESS package versions {atom/gz},
{custom/gz} and {local/gz}). If set to {yes}, each frame will will
contain two extra lines before the "ITEM: TIMESTEP" entry:
ITEM: TIME
\<elapsed time\> :pre
This will output the current elapsed simulation time in current
time units equivalent to the "thermo keyword"_thermo_style.html {time}.
This is to simplify post-processing of trajectories using a variable time
step, e.g. when using "fix dt/reset"_fix_dt_reset.html.
The default setting is {no}.
:line
The {units} keyword only applies to the dump {atom}, {custom}, and
{local} styles (and their COMPRESS package versions {atom/gz},
{custom/gz} and {local/gz}). If set to {yes}, each individual dump
file will contain two extra lines at the very beginning with:
ITEM: UNITS
\<units style\> :pre
This will output the current selected "units"_units.html style
to the dump file and thus allows visualization and post-processing
tools to determine the choice of units of the data in the dump file.
The default setting is {no}.
:line
The {unwrap} keyword only applies to the dump {dcd} and {xtc} styles.
If set to {yes}, coordinates will be written "unwrapped" by the image
flags for each atom. Unwrapped means that if the atom has passed through
@ -924,6 +957,7 @@ scale = yes
sort = off for dump styles {atom}, {custom}, {cfg}, and {local}
sort = id for dump styles {dcd}, {xtc}, and {xyz}
thresh = none
units = no
unwrap = no :ul
acolor = * red/green/blue/yellow/aqua/cyan

27
doc/src/dynamical_matrix.txt
View File

@ -30,14 +30,29 @@ dynamical_matrix 5 eskm 0.00000001 file dynamical.dat binary yes :pre
[Description:]
Calculate the dynamical matrix of the selected group.
Calculate the dynamical matrix by finite difference of the selected group,
:c,image(JPG/dynamical_matrix_dynmat.jpg)
where D is the dynamical matrix and Phi is the force constant matrix defined by
:c,image(JPG/dynamical_matrix_force_constant.jpg).
The output for the dynamical matrix is printed three elements at a time. The
three elements are the three beta elements for a respective i/alpha/j combination.
Each line is printed in order of j increasing first, alpha second, and i last.
If the style eskm is selected, the dynamical matrix will be in units of inverse squared
femtoseconds. These units will then conveniently leave frequencies in THz, where
frequencies, represented as omega, can be calculated from
:c, image(Eqs/dynamical_matrix_phonons.jpg)
[Restrictions:]
The command collects the entire dynamical matrix a single MPI rank,
so the memory requirements can be very significant for large systems.
This command assumes a periodic system.
The command collects an array of nine times the number of atoms in a group
on every single MPI rank, so the memory requirements can be very significant
for large systems.
This command is part of the USER-PHONON package. It is only enabled if
LAMMPS was built with that package. See the "Build
@ -52,4 +67,4 @@ provided by Pair's single_hessian.
[Default:]
The default settings are file = "dynmat.dyn", binary = no
The default settings are file = "dynmat.dyn", binary = no

6
doc/src/fix.txt
View File

@ -188,7 +188,7 @@ accelerated styles exist.
"box/relax"_fix_box_relax.html - relax box size during energy minimization
"client/md"_fix_client_md.html - MD client for client/server simulations
"cmap"_fix_cmap.html - enables CMAP cross-terms of the CHARMM force field
"colvars"_fix_colvars.html - interface to the collective variables “Colvars” library
"colvars"_fix_colvars.html - interface to the collective variables "Colvars" library
"controller"_fix_controller.html - apply control loop feedback mechanism
"deform"_fix_deform.html - change the simulation box size/shape
"deposit"_fix_deposit.html - add new atoms above a surface
@ -221,7 +221,7 @@ accelerated styles exist.
"heat"_fix_heat.html - add/subtract momentum-conserving heat
"hyper/global"_fix_hyper_global.html - global hyperdynamics
"hyper/local"_fix_hyper_local.html - local hyperdynamics
"imd"_fix_imd.html - implements the “Interactive MD” (IMD) protocol
"imd"_fix_imd.html - implements the "Interactive MD" (IMD) protocol
"indent"_fix_indent.html - impose force due to an indenter
"ipi"_fix_ipi.html - enable LAMMPS to run as a client for i-PI path-integral simulations
"langevin"_fix_langevin.html - Langevin temperature control
@ -327,7 +327,7 @@ accelerated styles exist.
"rigid/nvt/small"_fix_rigid.html - constrain many small clusters of atoms to move as a rigid body with NVT integration
"rigid/small"_fix_rigid.html - constrain many small clusters of atoms to move as a rigid body with NVE integration
"rx"_fix_rx.html -
"saed/vtk"_fix_saed_vtk.html -
"saed/vtk"_fix_saed_vtk.html -
"setforce"_fix_setforce.html - set the force on each atom
"shake"_fix_shake.html - SHAKE constraints on bonds and/or angles
"shardlow"_fix_shardlow.html - integration of DPD equations of motion using the Shardlow splitting

71
doc/src/fix_bond_react.txt
View File

@ -186,20 +186,25 @@ reacting atoms.
Some atoms in the pre-reacted template that are not reacting may have
missing topology with respect to the simulation. For example, the
pre-reacted template may contain an atom that would connect to the
rest of a long polymer chain. These are referred to as edge atoms, and
are also specified in the map file. When the pre-reaction template
contains edge atoms, not all atoms, bonds, charges, etc. specified in
the reaction templates will be updated. Specifically, topology that
involves only atoms that are 'too near' to template edges will not be
updated. The definition of 'too near the edge' depends on which
interactions are defined in the simulation. If the simulation has
defined dihedrals, atoms within two bonds of edge atoms are considered
'too near the edge.' If the simulation defines angles, but not
dihedrals, atoms within one bond of edge atoms are considered 'too
near the edge.' If just bonds are defined, only edge atoms are
pre-reacted template may contain an atom that, in the simulation, is
currently connected to the rest of a long polymer chain. These are
referred to as edge atoms, and are also specified in the map file. All
pre-reaction template atoms should be linked to a bonding atom, via at
least one path that does not involve edge atoms. When the pre-reaction
template contains edge atoms, not all atoms, bonds, charges, etc.
specified in the reaction templates will be updated. Specifically,
topology that involves only atoms that are 'too near' to template
edges will not be updated. The definition of 'too near the edge'
depends on which interactions are defined in the simulation. If the
simulation has defined dihedrals, atoms within two bonds of edge atoms
are considered 'too near the edge.' If the simulation defines angles,
but not dihedrals, atoms within one bond of edge atoms are considered
'too near the edge.' If just bonds are defined, only edge atoms are
considered 'too near the edge.'
NOTE: Small molecules, i.e. ones that have all their atoms contained
within the reaction templates, never have edge atoms.
Note that some care must be taken when a building a molecule template
for a given simulation. All atom types in the pre-reacted template
must be the same as those of a potential reaction site in the
@ -261,7 +266,7 @@ either 'none' or 'charges.' Further details are provided in the
discussion of the 'update_edges' keyword. The fourth optional section
begins with the keyword 'Constraints' and lists additional criteria
that must be satisfied in order for the reaction to occur. Currently,
there is one type of constraint available, as discussed below.
there are two types of constraints available, as discussed below.
A sample map file is given below:
@ -295,14 +300,23 @@ Equivalences :pre
:line
Any number of additional constraints may be specified in the
Constraints section of the map file. Currently there is one type of
additional constraint, of type 'distance', whose syntax is as follows:
Constraints section of the map file. The constraint of type 'distance'
has syntax as follows:
distance {ID1} {ID2} {rmin} {rmax} :pre
where 'distance' is the required keyword, {ID1} and {ID2} are
pre-reaction atom IDs, and these two atoms must be separated by a
distance between {rmin} and {rmax} for the reaction to occur. This
distance between {rmin} and {rmax} for the reaction to occur.
The constraint of type 'angle' has the following syntax:
angle {ID1} {ID2} {ID3} {amin} {amax} :pre
where 'angle' is the required keyword, {ID1}, {ID2} and {ID3} are
pre-reaction atom IDs, and these three atoms must form an angle
between {amin} and {amax} for the reaction to occur (where {ID2} is
the central atom). Angles must be specified in degrees. This
constraint can be used to enforce a certain orientation between
reacting molecules.
@ -392,10 +406,11 @@ local command.
[Restart, fix_modify, output, run start/stop, minimize info:]
No information about this fix is written to "binary restart
files"_restart.html, aside from internally-created per-atom
properties. None of the "fix_modify"_fix_modify.html options are
relevant to this fix.
Cumulative reaction counts for each reaction are written to "binary
restart files"_restart.html. These values are associated with the
reaction name (react-ID). Additionally, internally-created per-atom
properties are stored to allow for smooth restarts. None of the
"fix_modify"_fix_modify.html options are relevant to this fix.
This fix computes one statistic for each {react} argument that it
stores in a global vector, of length 'number of react arguments', that
@ -406,8 +421,8 @@ These is 1 quantity for each react argument:
(1) cumulative # of reactions occurred :ul
No parameter of this fix can be used with the {start/stop} keywords of
the "run"_run.html command. This fix is not invoked during "energy
No parameter of this fix can be used with the {start/stop} keywords
of the "run"_run.html command. This fix is not invoked during "energy
minimization"_minimize.html.
When fix bond/react is 'unfixed,' all internally-created groups are
@ -417,18 +432,20 @@ all other fixes that use any group created by fix bond/react.
[Restrictions:]
This fix is part of the USER-MISC package. It is only enabled if
LAMMPS was built with that package. See the "Build
package"_Build_package.html doc page for more info.
LAMMPS was built with that package. See the
"Build package"_Build_package.html doc page for more info.
[Related commands:]
"fix bond/create"_fix_bond_create.html, "fix
bond/break"_fix_bond_break.html, "fix bond/swap"_fix_bond_swap.html,
"fix bond/create"_fix_bond_create.html,
"fix bond/break"_fix_bond_break.html,
"fix bond/swap"_fix_bond_swap.html,
"dump local"_dump.html, "special_bonds"_special_bonds.html
[Default:]
The option defaults are stabilization = no, prob = 1.0, stabilize_steps = 60, update_edges = none
The option defaults are stabilization = no, prob = 1.0, stabilize_steps = 60,
update_edges = none
:line

1
doc/src/fix_controller.txt
View File

@ -31,7 +31,6 @@ cvar = name of control variable :l
[Examples:]
fix 1 all controller 100 1.0 0.5 0.0 0.0 c_thermo_temp 1.5 tcontrol
fix 1 all controller 100 0.2 0.5 0 100.0 v_pxxwall 1.01325 xwall
fix 1 all controller 10000 0.2 0.5 0 2000 v_avpe -3.785 tcontrol :pre

58
doc/src/fix_langevin.txt
View File

@ -24,9 +24,10 @@ keyword = {angmom} or {omega} or {scale} or {tally} or {zero} :l
{angmom} value = {no} or factor
{no} = do not thermostat rotational degrees of freedom via the angular momentum
factor = do thermostat rotational degrees of freedom via the angular momentum and apply numeric scale factor as discussed below
{gjf} value = {no} or {yes}
{gjf} value = {no} or {vfull} or {vhalf}
{no} = use standard formulation
{yes} = use Gronbech-Jensen/Farago formulation
{vfull} = use Gronbech-Jensen/Farago formulation
{vhalf} = use 2GJ formulation
{omega} value = {no} or {yes}
{no} = do not thermostat rotational degrees of freedom via the angular velocity
{yes} = do thermostat rotational degrees of freedom via the angular velocity
@ -217,6 +218,10 @@ the particles. As described below, this energy can then be printed
out or added to the potential energy of the system to monitor energy
conservation.
NOTE: this accumulated energy does NOT include kinetic energy removed
by the {zero} flag. LAMMPS will print a warning when both options are
active.
The keyword {zero} can be used to eliminate drift due to the
thermostat. Because the random forces on different atoms are
independent, they do not sum exactly to zero. As a result, this fix
@ -232,29 +237,24 @@ The keyword {gjf} can be used to run the "Gronbech-Jensen/Farago
described in the papers cited below, the purpose of this method is to
enable longer timesteps to be used (up to the numerical stability
limit of the integrator), while still producing the correct Boltzmann
distribution of atom positions. It is implemented within LAMMPS, by
changing how the random force is applied so that it is composed of
the average of two random forces representing half-contributions from
the previous and current time intervals.
distribution of atom positions.
In common with all methods based on Verlet integration, the
discretized velocities generated by this method in conjunction with
velocity-Verlet time integration are not exactly conjugate to the
positions. As a result the temperature (computed from the discretized
velocities) will be systematically lower than the target temperature,
by a small amount which grows with the timestep. Nonetheless, the
distribution of atom positions will still be consistent with the
The current implementation provides the user with the option to output
the velocity in one of two forms: {vfull} or {vhalf}, which replaces
the outdated option {yes}. The {gjf} option {vfull} outputs the on-site
velocity given in "Gronbech-Jensen/Farago"_#Gronbech-Jensen; this velocity
is shown to be systematically lower than the target temperature by a small
amount, which grows quadratically with the timestep.
The {gjf} option {vhalf} outputs the 2GJ half-step velocity given in
"Gronbech Jensen/Gronbech-Jensen"_#2Gronbech-Jensen; for linear systems,
this velocity is shown to not have any statistical errors for any stable time step.
An overview of statistically correct Boltzmann and Maxwell-Boltzmann
sampling of true on-site and true half-step velocities is given in
"Gronbech-Jensen"_#1Gronbech-Jensen.
Regardless of the choice of output velocity, the sampling of the configurational
distribution of atom positions is the same, and linearly consistent with the
target temperature.
As an example of using the {gjf} keyword, for molecules containing C-H
bonds, configurational properties generated with dt = 2.5 fs and tdamp
= 100 fs are indistinguishable from dt = 0.5 fs. Because the velocity
distribution systematically decreases with increasing timestep, the
method should not be used to generate properties that depend on the
velocity distribution, such as the velocity auto-correlation function
(VACF). In this example, the velocity distribution at dt = 2.5fs
generates an average temperature of 220 K, instead of 300 K.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
@ -312,7 +312,10 @@ This fix can ramp its target temperature over multiple runs, using the
This fix is not invoked during "energy minimization"_minimize.html.
[Restrictions:] none
[Restrictions:]
For {gjf} do not choose damp=dt/2. {gjf} is not compatible
with run_style respa.
[Related commands:]
@ -335,5 +338,10 @@ types, tally = no, zero = no, gjf = no.
:link(Gronbech-Jensen)
[(Gronbech-Jensen)] Gronbech-Jensen and Farago, Mol Phys, 111, 983
(2013); Gronbech-Jensen, Hayre, and Farago, Comp Phys Comm,
185, 524 (2014)
(2013); Gronbech-Jensen, Hayre, and Farago, Comp Phys Comm, 185, 524 (2014)
:link(2Gronbech-Jensen)
[(Gronbech-Jensen)] Gronbech Jensen and Gronbech-Jensen, Mol Phys, 117, 2511 (2019)
:link(1Gronbech-Jensen)
[(Gronbech-Jensen)] Gronbech-Jensen, Mol Phys (2019); https://doi.org/10.1080/00268976.2019.1662506

2
doc/src/fix_langevin_spin.txt
View File

@ -50,7 +50,7 @@ As an example:
fix 1 all precession/spin zeeman 0.01 0.0 0.0 1.0
fix 2 all langevin/spin 300.0 0.01 21
fix 3 all nve/spin lattice yes :pre
fix 3 all nve/spin lattice moving :pre
is correct, but defining a force/spin command after the langevin/spin command
would give an error message.

22
doc/src/fix_neb_spin.txt
View File

@ -24,18 +24,18 @@ fix 1 active neb/spin 1.0
[Description:]
Add nudging forces to spins in the group for a multi-replica
simulation run via the "neb/spin"_neb_spin.html command to perform a
geodesic nudged elastic band (GNEB) calculation for finding the
simulation run via the "neb/spin"_neb_spin.html command to perform a
geodesic nudged elastic band (GNEB) calculation for finding the
transition state.
Hi-level explanations of GNEB are given with the
"neb/spin"_neb_spin.html command and on the
"Howto replica"_Howto_replica.html doc page.
The fix neb/spin command must be used with the "neb/spin" command and
defines how inter-replica nudging forces are computed. A GNEB
calculation is divided in two stages. In the first stage n replicas
are relaxed toward a MEP until convergence. In the second stage, the
climbing image scheme is enabled, so that the replica having the highest
energy relaxes toward the saddle point (i.e. the point of highest energy
Hi-level explanations of GNEB are given with the
"neb/spin"_neb_spin.html command and on the
"Howto replica"_Howto_replica.html doc page.
The fix neb/spin command must be used with the "neb/spin" command and
defines how inter-replica nudging forces are computed. A GNEB
calculation is divided in two stages. In the first stage n replicas
are relaxed toward a MEP until convergence. In the second stage, the
climbing image scheme is enabled, so that the replica having the highest
energy relaxes toward the saddle point (i.e. the point of highest energy
along the MEP), and a second relaxation is performed.
The nudging forces are calculated as explained in

20
doc/src/fix_nve_spin.txt
View File

@ -15,22 +15,26 @@ fix ID group-ID nve/spin keyword values :pre
ID, group-ID are documented in "fix"_fix.html command :ulb,l
nve/spin = style name of this fix command :l
keyword = {lattice} :l
{lattice} value = {no} or {yes} :pre
{lattice} value = {moving} or {frozen}
moving = integrate both spin and atomic degress of freedom
frozen = integrate spins on a fixed lattice :pre
:ule
[Examples:]
fix 3 all nve/spin lattice yes
fix 1 all nve/spin lattice no :pre
fix 3 all nve/spin lattice moving
fix 1 all nve/spin lattice frozen :pre
[Description:]
Perform a symplectic integration for the spin or spin-lattice system.
The {lattice} keyword defines if the spins are integrated on a lattice
of fixed atoms (lattice = no), or if atoms are moving (lattice = yes).
By default (lattice = yes), a spin-lattice integration is performed.
of fixed atoms (lattice = frozen), or if atoms are moving
(lattice = moving).
The first case corresponds to a spin dynamics calculation, and
the second to a spin-lattice calculation.
By default a spin-lattice integration is performed (lattice = moving).
The {nve/spin} fix applies a Suzuki-Trotter decomposition to
the equations of motion of the spin lattice system, following the scheme:
@ -63,7 +67,9 @@ instead of "array" is also valid.
"atom_style spin"_atom_style.html, "fix nve"_fix_nve.html
[Default:] none
[Default:]
The option default is lattice = moving.
:line

14
doc/src/fix_precession_spin.txt
View File

@ -21,7 +21,7 @@ style = {zeeman} or {anisotropy} or {cubic} :l
{anisotropy} args = K x y z
K = intensity of the magnetic anisotropy (in eV)
x y z = vector direction of the anisotropy :pre
{cubic} args = K1 K2c n1x n1y n1x n2x n2y n2z n3x n3y n3z
{cubic} args = K1 K2c n1x n1y n1x n2x n2y n2z n3x n3y n3z
K1 and K2c = intensity of the magnetic anisotropy (in eV)
n1x to n3z = three direction vectors of the cubic anisotropy :pre
:ule
@ -55,24 +55,24 @@ with n defining the direction of the anisotropy, and K (in eV) its intensity.
If K>0, an easy axis is defined, and if K<0, an easy plane is defined.
Style {cubic} is used to simulate a cubic anisotropy, with three
possible easy axis for the magnetic spins in the defined group:
possible easy axis for the magnetic spins in the defined group:
:c,image(Eqs/fix_spin_cubic.jpg)
with K1 and K2c (in eV) the intensity coefficients and
with K1 and K2c (in eV) the intensity coefficients and
n1, n2 and n3 defining the three anisotropic directions
defined by the command (from n1x to n3z).
For n1 = (100), n2 = (010), and n3 = (001), K1 < 0 defines an
defined by the command (from n1x to n3z).
For n1 = (100), n2 = (010), and n3 = (001), K1 < 0 defines an
iron type anisotropy (easy axis along the (001)-type cube
edges), and K1 > 0 defines a nickel type anisotropy (easy axis
along the (111)-type cube diagonals).
along the (111)-type cube diagonals).
K2^c > 0 also defines easy axis along the (111)-type cube
diagonals.
See chapter 2 of "(Skomski)"_#Skomski1 for more details on cubic
anisotropies.
In all cases, the choice of (x y z) only imposes the vector
directions for the forces. Only the direction of the vector is
directions for the forces. Only the direction of the vector is
important; it's length is ignored (the entered vectors are
normalized).

2
doc/src/fix_rigid_meso.txt
View File

@ -44,7 +44,7 @@ fix 1 rods rigid/meso molecule
fix 1 spheres rigid/meso single force 1 off off on
fix 1 particles rigid/meso molecule force 1*5 off off off force 6*10 off off on
fix 2 spheres rigid/meso group 3 sphere1 sphere2 sphere3 torque * off off off :pre
[Description:]
Treat one or more sets of mesoscopic SPH/SDPD particles as independent

14
doc/src/fix_setforce.txt
View File

@ -67,15 +67,15 @@ to it.
:line
Style {spin} suffix sets the components of the magnetic precession
vectors instead of the mechanical forces. This also erases all
previously computed magnetic precession vectors on the atom, though
Style {spin} suffix sets the components of the magnetic precession
vectors instead of the mechanical forces. This also erases all
previously computed magnetic precession vectors on the atom, though
additional magnetic fixes could add new forces.
This command can be used to freeze the magnetic moment of certain
atoms in the simulation by zeroing their precession vector.
This command can be used to freeze the magnetic moment of certain
atoms in the simulation by zeroing their precession vector.
All options defined above remain valid, they just apply to the magnetic
All options defined above remain valid, they just apply to the magnetic
precession vectors instead of the forces.
:line
@ -132,7 +132,7 @@ forces to any value besides zero when performing a minimization. Use
the "fix addforce"_fix_addforce.html command if you want to apply a
non-zero force to atoms during a minimization.
[Restrictions:]
[Restrictions:]
The fix {setforce/spin} only makes sense when LAMMPS was built with the
SPIN package.

16
doc/src/improper_fourier.txt
View File

@ -16,7 +16,7 @@ improper_style fourier :pre
[Examples:]
improper_style fourier
improper_coeff 1 100.0 180.0 :pre
improper_coeff 1 100.0 0.0 1.0 0.5 1 :pre
[Description:]
@ -24,12 +24,12 @@ The {fourier} improper style uses the following potential:
:c,image(Eqs/improper_fourier.jpg)
where K is the force constant and omega is the angle between the IL
axis and the IJK plane:
where K is the force constant, C0, C1, C2 are dimensionless coefficients,
and omega is the angle between the IL axis and the IJK plane:
:c,image(JPG/umbrella.jpg)
If all parameter (see bellow) is not zero, the all the three possible angles will taken in account.
If all parameter (see below) is not zero, the all the three possible angles will taken in account.
The following coefficients must be defined for each improper type via
the "improper_coeff"_improper_coeff.html command as in the example
@ -38,10 +38,10 @@ above, or in the data file or restart files read by the
commands:
K (energy)
C0 (real)
C1 (real)
C2 (real)
all (integer >= 0) :ul
C0 (unitless)
C1 (unitless)
C2 (unitless)
all (0 or 1, optional) :ul
:line

10
doc/src/kspace_style.txt
View File

@ -116,10 +116,10 @@ used without a cutoff, i.e. they become full long-range potentials.
The {ewald/disp} style can also be used with point-dipoles, see
"(Toukmaji)"_#Toukmaji.
The {ewald/dipole} style adds long-range standard Ewald summations
The {ewald/dipole} style adds long-range standard Ewald summations
for dipole-dipole interactions, see "(Toukmaji)"_#Toukmaji.
The {ewald/dipole/spin} style adds long-range standard Ewald
The {ewald/dipole/spin} style adds long-range standard Ewald
summations for magnetic dipole-dipole interactions between
magnetic spins.
@ -142,11 +142,11 @@ The optional {smallq} argument defines the cutoff for the absolute
charge value which determines whether a particle is considered charged
or not. Its default value is 1.0e-5.
The {pppm/dipole} style invokes a particle-particle particle-mesh solver
The {pppm/dipole} style invokes a particle-particle particle-mesh solver
for dipole-dipole interactions, following the method of "(Cerda)"_#Cerda2008.
The {pppm/dipole/spin} style invokes a particle-particle particle-mesh solver
for magnetic dipole-dipole interactions between magnetic spins.
The {pppm/dipole/spin} style invokes a particle-particle particle-mesh solver
for magnetic dipole-dipole interactions between magnetic spins.
The {pppm/tip4p} style is identical to the {pppm} style except that it
adds a charge at the massless 4th site in each TIP4P water molecule.

2
doc/src/lammps.book
View File

@ -217,6 +217,7 @@ temper_npt.html
thermo.html
thermo_modify.html
thermo_style.html
third_order.html
timer.html
timestep.html
uncompute.html
@ -611,6 +612,7 @@ pair_lj_smooth.html
pair_lj_smooth_linear.html
pair_fep_soft.html
pair_lj_switch3_coulgauss.html
pair_local_density.html
pair_lubricate.html
pair_lubricateU.html
pair_mdf.html

84
doc/src/min_modify.txt
View File

@ -13,18 +13,22 @@ min_modify command :h3
min_modify keyword values ... :pre
one or more keyword/value pairs may be listed :ulb,l
keyword = {dmax} or {line} or {alpha_damp} or {discrete_factor}
keyword = {dmax} or {line} or {norm} or {alpha_damp} or {discrete_factor}
{dmax} value = max
max = maximum distance for line search to move (distance units)
{line} value = {backtrack} or {quadratic} or {forcezero}
backtrack,quadratic,forcezero = style of linesearch to use
{line} value = {backtrack} or {quadratic} or {forcezero} or {spin_cubic} or {spin_none}
backtrack,quadratic,forcezero,spin_cubic,spin_none = style of linesearch to use
{norm} value = {two} or {max}
two = Euclidean two-norm (length of 3N vector)
inf = max force component across all 3-vectors
max = max force norm across all 3-vectors
{alpha_damp} value = damping
damping = fictitious Gilbert damping for spin minimization (adim)
{discrete_factor} value = factor
factor = discretization factor for adaptive spin timestep (adim) :pre
:ule
these keywords apply only to the "min_style"_min_style.html {adaptglok} :ulb,l
these keywords apply only to the "min_style"_min_style.html {fire2} :ulb,l
keyword = {integrator} or {tmax} or {tmin} or {delaystep} or {dtgrow} or {dtshrink}
or {alpha0} or {alphashrink} or {halfstepback} or {initialdelay} or {vdfmax}
{integrator} arg = {eulerimplicit} or {eulerexplicit} or {verlet}
@ -95,13 +99,56 @@ difference of two large values (energy before and energy after) and
that difference may be smaller than machine epsilon even if atoms
could move in the gradient direction to reduce forces further.
The style {adaptglok} has several parameters that can be tuned in order
The choice of a norm can be modified for the min styles {cg}, {sd},
{quickmin}, {fire}, {spin}, {spin/cg} and {spin/lbfgs} using
the {norm} keyword.
The default {two} norm computes the 2-norm (Euclidean length) of the
global force vector:
:c,image(Eqs/norm_two.jpg)
The {max} norm computes the length of the 3-vector force
for each atom (2-norm), and takes the maximum value of those across
all atoms
:c,image(Eqs/norm_max.jpg)
The {inf} norm takes the maximum component across the forces of
all atoms in the system:
:c,image(Eqs/norm_inf.jpg)
For the min styles {spin}, {spin/cg} and {spin/lbfgs}, the force
norm is replaced by the spin-torque norm.
Keywords {alpha_damp} and {discrete_factor} only make sense when
a "min_spin"_min_spin.html command is declared.
Keyword {alpha_damp} defines an analog of a magnetic Gilbert
damping. It defines a relaxation rate toward an equilibrium for
a given magnetic system.
Keyword {discrete_factor} defines a discretization factor for the
adaptive timestep used in the {spin} minimization.
See "min_spin"_min_spin.html for more information about those
quantities.
The choice of a line search algorithm for the {spin/cg} and
{spin/lbfgs} styles can be specified via the {line} keyword.
The {spin_cubic} and {spin_none} only make sense when one of those
two minimization styles is declared.
The {spin_cubic} performs the line search based on a cubic interpolation
of the energy along the search direction. The {spin_none} keyword
deactivates the line search procedure.
The {spin_none} is a default value for {line} keyword for both {spin/lbfgs}
and {spin/cg}. Convergence of {spin/lbfgs} can be more robust if
{spin_cubic} line search is used.
The style {fire2} has several parameters that can be tuned in order
to optimize the relaxation: {integrator}, {tmax}, {tmin}, {delaystep}, {dtgrow}, {dtshrink},
{alpha0}, and {alphashrink}.
Different Newton {integrator} can be selected: explicit Euler,
semi-implicit Euler (= symplectic Euler) and velocity Verlet.
The parameters {tmax} and {tmin} define the maximum and minimum timestep
allowed during an adaptglok minimization. Those are not in time unit, but are
allowed during an fire2 minimization. Those are not in time unit, but are
multiplication factor applied to the "timestep"_timestep.html. Thus
{tmax} = 10.0 in metal "units"_units.html means that the maximum value
the timestep can be reached during the relaxation is 10 fs (with the default
@ -117,18 +164,11 @@ happen when the system comes to be stuck in a local basin of the phase space.
For debugging purposes, it is possible to switch off the inertia correction
({halfstepback} = {no}) and the initial delay ({initialdelay} = {no}).
Keywords {alpha_damp} and {discrete_factor} only make sense when
a "min_spin"_min_spin.html command is declared.
Keyword {alpha_damp} defines an analog of a magnetic Gilbert
damping. It defines a relaxation rate toward an equilibrium for
a given magnetic system.
Keyword {discrete_factor} defines a discretization factor for the
adaptive timestep used in the {spin} minimization.
See "min_spin"_min_spin.html for more information about those
quantities.
Default values are {alpha_damp} = 1.0 and {discrete_factor} = 10.0.
[Restrictions:]
[Restrictions:] none
For magnetic GNEB calculations, only {spin_none} value for {line} keyword can be used
when styles {spin/cg} and {spin/lbfgs} are employed.
See "neb/spin"_neb_spin.html for more explanation.
[Related commands:]
@ -136,7 +176,13 @@ Default values are {alpha_damp} = 1.0 and {discrete_factor} = 10.0.
[Default:]
The option defaults are dmax = 0.1, line = quadratic,
The option defaults are dmax = 0.1, line = quadratic and norm = two.
For the {spin}, {spin/cg} and {spin/lbfgs} styles, the
option defaults are alpha_damp = 1.0, discrete_factor = 10.0,
line = spin_none, and norm = euclidean.
For the {fire2} style, the option defaults are
integrator = eulerimplicit, tmax = 10.0, tmin = 0.02,
delaystep = 20, dtgrow = 1.1, dtshrink = 0.5, alpha0 = 0.25, alphashrink = 0.99,
vdfmax = 2000, halfstepback = yes and initialdelay = yes.
vdfmax = 2000, halfstepback = yes and initialdelay = yes.

65
doc/src/min_spin.txt
View File

@ -6,14 +6,19 @@
:line
min_style spin command :h3
min_style spin/cg command :h3
min_style spin/lbfgs command :h3
[Syntax:]
min_style spin :pre
min_style spin
min_style spin/cg
min_style spin/lbfgs :pre
[Examples:]
min_style spin :pre
min_style spin/lbfgs
min_modify line spin_cubic discrete_factor 10.0 :pre
[Description:]
@ -27,28 +32,57 @@ timestep, according to:
with lambda a damping coefficient (similar to a Gilbert
damping).
Lambda can be defined by setting the {alpha_damp} keyword with the
"min_modify"_min_modify.html command.
Lambda can be defined by setting the {alpha_damp} keyword with the
"min_modify"_min_modify.html command.
The minimization procedure solves this equation using an
adaptive timestep. The value of this timestep is defined
by the largest precession frequency that has to be solved in the
adaptive timestep. The value of this timestep is defined
by the largest precession frequency that has to be solved in the
system:
:c,image(Eqs/min_spin_timestep.jpg)
with {|omega|_{max}} the norm of the largest precession frequency
in the system (across all processes, and across all replicas if a
spin/neb calculation is performed).
spin/neb calculation is performed).
Kappa defines a discretization factor {discrete_factor} for the
definition of this timestep.
Kappa defines a discretization factor {discrete_factor} for the
definition of this timestep.
{discrete_factor} can be defined with the "min_modify"_min_modify.html
command.
NOTE: The {spin} style replaces the force tolerance by a torque
Style {spin/cg} defines an orthogonal spin optimization
(OSO) combined to a conjugate gradient (CG) algorithm.
The "min_modify"_min_modify.html command can be used to
couple the {spin/cg} to a line search procedure, and to modify the
discretization factor {discrete_factor}.
By default, style {spin/cg} does not employ the line search procedure
and uses the adaptive time-step technique in the same way as style {spin}.
Style {spin/lbfgs} defines an orthogonal spin optimization
(OSO) combined to a limited-memory Broyden-Fletcher-Goldfarb-Shanno
(L-BFGS) algorithm.
By default, style {spin/lbfgs} does not employ line search procedure.
If the line search procedure is not used then the discrete factor defines
the maximum root mean squared rotation angle of spins by equation {pi/(5*Kappa)}.
The default value for Kappa is 10.
The {spin_cubic} line search can improve the convergence of the
{spin/lbfgs} algorithm.
The "min_modify"_min_modify.html command can be used to
activate the line search procedure, and to modify the
discretization factor {discrete_factor}.
For more information about styles {spin/cg} and {spin/lbfgs},
see their implementation reported in "(Ivanov)"_#Ivanov1.
NOTE: All the {spin} styles replace the force tolerance by a torque
tolerance. See "minimize"_minimize.html for more explanation.
NOTE: The {spin/cg} and {spin/lbfgs} styles can be used
for magnetic NEB calculations only if the line search procedure
is deactivated. See "neb/spin"_neb_spin.html for more explanation.
[Restrictions:]
This minimization procedure is only applied to spin degrees of
@ -56,10 +90,15 @@ freedom for a frozen lattice configuration.
[Related commands:]
"min_style"_min_style.html, "minimize"_minimize.html,
"min_style"_min_style.html, "minimize"_minimize.html,
"min_modify"_min_modify.html
[Default:]
The option defaults are {alpha_damp} = 1.0 and {discrete_factor} =
10.0.
The option defaults are {alpha_damp} = 1.0, {discrete_factor} =
10.0, {line} = spin_none and {norm} = euclidean.
:line
:link(Ivanov1)
[(Ivanov)] Ivanov, Uzdin, Jonsson. arXiv preprint arXiv:1904.02669, (2019).

32
doc/src/min_style.txt
View File

@ -11,7 +11,7 @@ min_style command :h3
min_style style :pre
style = {cg} or {cg/kk} or {hftn} or {sd} or {quickmin} or {fire} or {spin} or {adaptglok} :ul
style = {cg} or {hftn} or {sd} or {quickmin} or {fire} or {fire2} or {spin} or {spin/cg} or {spin/lbfgs} :ul
[Examples:]
@ -62,26 +62,40 @@ the velocity non-parallel to the current force vector. The velocity
of each atom is initialized to 0.0 by this style, at the beginning of
a minimization.
Style {adaptglok} is a re-implementation of the style {fire} with
Style {fire2} is a re-implementation of the style {fire} with
additional optimizations of the method described
in "(Bitzek)"_#Bitzek, including different time integration schemes.
Style {spin} is a damped spin dynamics with an adaptive
Style {spin} is a damped spin dynamics with an adaptive
timestep.
See the "min/spin"_min_spin.html doc page for more information.
Either the {quickmin}, {fire} and {adaptglok} styles are useful in the context of
Style {spin/cg} uses an orthogonal spin optimization (OSO)
combined to a conjugate gradient (CG) approach to minimize spin
configurations.
Style {spin/lbfgs} uses an orthogonal spin optimization (OSO)
combined to a limited-memory Broyden-Fletcher-Goldfarb-Shanno
(LBFGS) approach to minimize spin configurations.
See the "min/spin"_min_spin.html doc page for more information
about the {spin}, {spin/cg} and {spin/lbfgs} styles.
Either the {quickmin}, {fire} and {fire2} styles are useful in the context of
nudged elastic band (NEB) calculations via the "neb"_neb.html command.
Either the {spin}, {spin/cg} and {spin/lbfgs} styles are useful
in the context of magnetic geodesic nudged elastic band (GNEB) calculations
via the "neb/spin"_neb_spin.html command.
NOTE: The damped dynamic minimizers use whatever timestep you have
defined via the "timestep"_timestep.html command. Often they will
converge more quickly if you use a timestep about 10x larger than you
would normally use for dynamics simulations.
NOTE: The {quickmin}, {fire}, {hftn}, and {cg/kk} styles do not yet
support the use of the "fix box/relax"_fix_box_relax.html command or
minimizations involving the electron radius in "eFF"_pair_eff.html
models.
NOTE: The {quickmin}, {fire}, {hftn}, and {cg/kk} styles do not yet
support the use of the "fix box/relax"_fix_box_relax.html command or
minimizations involving the electron radius in "eFF"_pair_eff.html
models.
:line

11
doc/src/minimize.txt
View File

@ -104,12 +104,13 @@ the line search fails because the step distance backtracks to 0.0
the number of outer iterations or timesteps exceeds {maxiter}
the number of total force evaluations exceeds {maxeval} :ul
NOTE: the "minimization style"_min_style.html {spin} replaces
NOTE: the "minimization style"_min_style.html {spin},
{spin/cg}, and {spin/lbfgs} replace
the force tolerance {ftol} by a torque tolerance.
The minimization procedure stops if the 2-norm (length) of the
global torque vector (defined as the cross product between the
spins and their precession vectors omega) is less than {ftol},
or if any of the other criteria are met.
The minimization procedure stops if the 2-norm (length) of the torque vector on atom
(defined as the cross product between the
atomic spin and its precession vectors omega) is less than {ftol},
or if any of the other criteria are met. Torque have the same units as the energy.
NOTE: You can also use the "fix halt"_fix_halt.html command to specify
a general criterion for exiting a minimization, that is a calculation

140
doc/src/neb_spin.txt
View File

@ -45,7 +45,7 @@ and last are the end points of the transition path.
GNEB is a method for finding both the spin configurations and height
of the energy barrier associated with a transition state, e.g.
spins to perform a collective rotation from one energy basin to
another.
another.
The implementation in LAMMPS follows the discussion in the
following paper: "(BessarabA)"_#BessarabA.
@ -59,35 +59,35 @@ performance speed-up you would see with one or more physical
processors per replica. See the "Howto replica"_Howto_replica.html
doc page for further discussion.
NOTE: As explained below, a GNEB calculation performs a damped dynamics
minimization across all the replicas. The "spin"_min_spin.html
style minimizer has to be defined in your input script.
NOTE: As explained below, a GNEB calculation performs a
minimization across all the replicas. One of the "spin"_min_spin.html
style minimizers has to be defined in your input script.
When a GNEB calculation is performed, it is assumed that each replica
is running the same system, though LAMMPS does not check for this.
I.e. the simulation domain, the number of magnetic atoms, the
interaction potentials, and the starting configuration when the neb
I.e. the simulation domain, the number of magnetic atoms, the
interaction potentials, and the starting configuration when the neb
command is issued should be the same for every replica.
In a GNEB calculation each replica is connected to other replicas by
inter-replica nudging forces. These forces are imposed by the "fix
neb/spin"_fix_neb_spin.html command, which must be used in conjunction
with the neb command.
neb/spin"_fix_neb_spin.html command, which must be used in conjunction
with the neb command.
The group used to define the fix neb/spin command defines the
GNEB magnetic atoms which are the only ones that inter-replica springs
are applied to.
GNEB magnetic atoms which are the only ones that inter-replica springs
are applied to.
If the group does not include all magnetic atoms, then non-GNEB
magnetic atoms have no inter-replica springs and the torques they feel
and their precession motion is computed in the usual way due only
to other magnetic atoms within their replica.
Conceptually, the non-GNEB atoms provide a background force field for
the GNEB atoms.
Their magnetic spins can be allowed to evolve during the GNEB
magnetic atoms have no inter-replica springs and the torques they feel
and their precession motion is computed in the usual way due only
to other magnetic atoms within their replica.
Conceptually, the non-GNEB atoms provide a background force field for
the GNEB atoms.
Their magnetic spins can be allowed to evolve during the GNEB
minimization procedure.
The initial spin configuration for each of the replicas can be
specified in different manners via the {file-style} setting, as
discussed below. Only atomic spins whose initial coordinates should
discussed below. Only atomic spins whose initial coordinates should
differ from the current configuration need to be specified.
Conceptually, the initial and final configurations for the first
@ -106,21 +106,21 @@ closer to the MEP and read them in.
:line
For a {file-style} setting of {final}, a filename is specified which
contains atomic and spin coordinates for zero or more atoms, in the
format described below.
For each atom that appears in the file, the new coordinates are
assigned to that atom in the final replica. Each intermediate replica
also assigns a new spin to that atom in an interpolated manner.
This is done by using the current direction of the spin at the starting
point and the read-in direction as the final point.
The "angular distance" between them is calculated, and the new direction
contains atomic and spin coordinates for zero or more atoms, in the
format described below.
For each atom that appears in the file, the new coordinates are
assigned to that atom in the final replica. Each intermediate replica
also assigns a new spin to that atom in an interpolated manner.
This is done by using the current direction of the spin at the starting
point and the read-in direction as the final point.
The "angular distance" between them is calculated, and the new direction
is assigned to be a fraction of the angular distance.
NOTE: The "angular distance" between the starting and final point is
evaluated in the geodesic sense, as described in
"(BessarabA)"_#BessarabA.
NOTE: The "angular distance" between the starting and final point is
evaluated in the geodesic sense, as described in
"(BessarabA)"_#BessarabA.
NOTE: The angular interpolation between the starting and final point
NOTE: The angular interpolation between the starting and final point
is achieved using Rodrigues formula:
:c,image(Eqs/neb_spin_rodrigues_formula.jpg)
@ -130,7 +130,7 @@ omega_i^nu is a rotation angle defined as:
:c,image(Eqs/neb_spin_angle.jpg)
with nu the image number, Q the total number of images, and
with nu the image number, Q the total number of images, and
omega_i the total rotation between the initial and final spins.
k_i defines a rotation axis such as:
@ -139,16 +139,16 @@ k_i defines a rotation axis such as:
if the initial and final spins are not aligned.
If the initial and final spins are aligned, then their cross
product is null, and the expression above does not apply.
If they point toward the same direction, the intermediate images
If they point toward the same direction, the intermediate images
conserve the same orientation.
If the initial and final spins are aligned, but point toward
opposite directions, an arbitrary rotation vector belonging to
the plane perpendicular to initial and final spins is chosen.
the plane perpendicular to initial and final spins is chosen.
In this case, a warning message is displayed.
For a {file-style} setting of {each}, a filename is specified which is
assumed to be unique to each replica.
See the "neb"_neb.html documentation page for more information about this
assumed to be unique to each replica.
See the "neb"_neb.html documentation page for more information about this
option.
For a {file-style} setting of {none}, no filename is specified. Each
@ -170,9 +170,10 @@ command is issued.
:line
A NEB calculation proceeds in two stages, each of which is a
minimization procedure, performed via damped dynamics. To enable
this, you must first define a damped spin dynamics
"min_style"_min_style.html, using the {spin} style (see
minimization procedure. To enable
this, you must first define a
"min_style"_min_style.html, using either the {spin},
{spin/cg}, or {spin/lbfgs} style (see
"min_spin"_min_spin.html for more information).
The other styles cannot be used, since they relax the lattice
degrees of freedom instead of the spins.
@ -195,9 +196,9 @@ damped dynamics is like a single timestep in a dynamics
replica and its normalized distance along the reaction path (reaction
coordinate RD) will be printed to the screen and log file every
{Nevery} timesteps. The RD is 0 and 1 for the first and last replica.
For intermediate replicas, it is the cumulative angular distance
(normalized by the total cumulative angular distance) between adjacent
replicas, where "distance" is defined as the length of the 3N-vector of
For intermediate replicas, it is the cumulative angular distance
(normalized by the total cumulative angular distance) between adjacent
replicas, where "distance" is defined as the length of the 3N-vector of
the geodesic distances in spin coordinates, with N the number of
GNEB spins involved (see equation (13) in "(BessarabA)"_#BessarabA).
These outputs allow you to monitor NEB's progress in
@ -207,11 +208,11 @@ of {Nevery}.
In the first stage of GNEB, the set of replicas should converge toward
a minimum energy path (MEP) of conformational states that transition
over a barrier. The MEP for a transition is defined as a sequence of
3N-dimensional spin states, each of which has a potential energy
gradient parallel to the MEP itself.
The configuration of highest energy along a MEP corresponds to a saddle
point. The replica states will also be roughly equally spaced along
the MEP due to the inter-replica nudging force added by the
3N-dimensional spin states, each of which has a potential energy
gradient parallel to the MEP itself.
The configuration of highest energy along a MEP corresponds to a saddle
point. The replica states will also be roughly equally spaced along
the MEP due to the inter-replica nudging force added by the
"fix neb"_fix_neb.html command.
In the second stage of GNEB, the replica with the highest energy is
@ -234,12 +235,12 @@ An atom map must be defined which it is not by default for "atom_style
atomic"_atom_style.html problems. The "atom_modify
map"_atom_modify.html command can be used to do this.
An initial value can be defined for the timestep. Although, the {spin}
minimization algorithm is an adaptive timestep methodology, so that
this timestep is likely to evolve during the calculation.
An initial value can be defined for the timestep. Although, the {spin}
minimization algorithm is an adaptive timestep methodology, so that
this timestep is likely to evolve during the calculation.
The minimizers in LAMMPS operate on all spins in your system, even
non-GNEB atoms, as defined above.
non-GNEB atoms, as defined above.
:line
@ -257,7 +258,7 @@ ID2 g2 x2 y2 z2 sx2 sy2 sz2
...
IDN gN yN zN sxN syN szN :pre
The fields are the atom ID, the norm of the associated magnetic spin,
The fields are the atom ID, the norm of the associated magnetic spin,
followed by the {x,y,z} coordinates and the {sx,sy,sz} spin coordinates.
The lines can be listed in any order. Additional trailing information on
the line is OK, such as a comment.
@ -290,22 +291,22 @@ reaction coordinate and potential energy of each replica.
The "maximum torque per replica" is the two-norm of the
3N-length vector given by the cross product of a spin by its
precession vector omega, in each replica, maximized across replicas,
precession vector omega, in each replica, maximized across replicas,
which is what the {ttol} setting is checking against. In this case, N is
all the atoms in each replica. The "maximum torque per atom" is the
maximum torque component of any atom in any replica. The potential
gradients are the two-norm of the 3N-length magnetic precession vector
solely due to the interaction potential i.e. without adding in
inter-replica forces, and projected along the path tangent (as detailed
gradients are the two-norm of the 3N-length magnetic precession vector
solely due to the interaction potential i.e. without adding in
inter-replica forces, and projected along the path tangent (as detailed
in Appendix D of "(BessarabA)"_#BessarabA).
The "reaction coordinate" (RD) for each replica is the two-norm of the
3N-length vector of geodesic distances between its spins and the preceding
replica's spins (see equation (13) of "(BessarabA)"_#BessarabA), added to
the RD of the preceding replica. The RD of the first replica RD1 = 0.0;
the RD of the final replica RDN = RDT, the total reaction coordinate.
The normalized RDs are divided by RDT, so that they form a monotonically
increasing sequence from zero to one. When computing RD, N only includes
replica's spins (see equation (13) of "(BessarabA)"_#BessarabA), added to
the RD of the preceding replica. The RD of the first replica RD1 = 0.0;
the RD of the final replica RDN = RDT, the total reaction coordinate.
The normalized RDs are divided by RDT, so that they form a monotonically
increasing sequence from zero to one. When computing RD, N only includes
the spins being operated on by the fix neb/spin command.
The forward (reverse) energy barrier is the potential energy of the
@ -313,17 +314,17 @@ highest replica minus the energy of the first (last) replica.
Supplementary information for all replicas can be printed out to the
screen and master log.lammps file by adding the verbose keyword. This
information include the following.
The "GradVidottan" are the projections of the potential gradient for
the replica i on its tangent vector (as detailed in Appendix D of
information include the following.
The "GradVidottan" are the projections of the potential gradient for
the replica i on its tangent vector (as detailed in Appendix D of
"(BessarabA)"_#BessarabA).
The "DNi" are the non normalized geodesic distances (see equation (13)
of "(BessarabA)"_#BessarabA), between a replica i and the next replica
The "DNi" are the non normalized geodesic distances (see equation (13)
of "(BessarabA)"_#BessarabA), between a replica i and the next replica
i+1. For the last replica, this distance is not defined and a "NAN"
value is the corresponding output.
value is the corresponding output.
When a NEB calculation does not converge properly, the supplementary
information can help understanding what is going wrong.
information can help understanding what is going wrong.
When running on multiple partitions, LAMMPS produces additional log
files for each partition, e.g. log.lammps.0, log.lammps.1, etc. For a
@ -346,9 +347,9 @@ restart the calculation from an intermediate point with altered
parameters.
A c file script in provided in the tool/spin/interpolate_gneb
directory, that interpolates the MEP given the information provided
directory, that interpolates the MEP given the information provided
by the verbose output option (as detailed in Appendix D of
"(BessarabA)"_#BessarabA).
"(BessarabA)"_#BessarabA).
:line
@ -358,6 +359,9 @@ This command can only be used if LAMMPS was built with the SPIN
package. See the "Build package"_Build_package.html doc
page for more info.
For magnetic GNEB calculations, only {spin_none} value for {line} keyword can be used
when styles {spin/cg} and {spin/lbfgs} are employed.
:line
[Related commands:]

200
doc/src/package.txt
View File

@ -423,115 +423,115 @@ processes/threads used for LAMMPS.
:line
The {kokkos} style invokes settings associated with the use of the
KOKKOS package.
The {kokkos} style invokes settings associated with the use of the
KOKKOS package.
All of the settings are optional keyword/value pairs. Each has a default
value as listed below.
All of the settings are optional keyword/value pairs. Each has a default
value as listed below.
The {neigh} keyword determines how neighbor lists are built. A value of
{half} uses a thread-safe variant of half-neighbor lists, the same as
used by most pair styles in LAMMPS, which is the default when running on
CPUs (i.e. the Kokkos CUDA back end is not enabled).
The {neigh} keyword determines how neighbor lists are built. A value of
{half} uses a thread-safe variant of half-neighbor lists, the same as
used by most pair styles in LAMMPS, which is the default when running on
CPUs (i.e. the Kokkos CUDA back end is not enabled).
A value of {full} uses a full neighbor lists and is the default when
running on GPUs. This performs twice as much computation as the {half}
option, however that is often a win because it is thread-safe and
doesn't require atomic operations in the calculation of pair forces. For
that reason, {full} is the default setting for GPUs. However, when
running on CPUs, a {half} neighbor list is the default because it are
often faster, just as it is for non-accelerated pair styles. Similarly,
the {neigh/qeq} keyword determines how neighbor lists are built for "fix
qeq/reax/kk"_fix_qeq_reax.html. If not explicitly set, the value of
A value of {full} uses a full neighbor lists and is the default when
running on GPUs. This performs twice as much computation as the {half}
option, however that is often a win because it is thread-safe and
doesn't require atomic operations in the calculation of pair forces. For
that reason, {full} is the default setting for GPUs. However, when
running on CPUs, a {half} neighbor list is the default because it are
often faster, just as it is for non-accelerated pair styles. Similarly,
the {neigh/qeq} keyword determines how neighbor lists are built for "fix
qeq/reax/kk"_fix_qeq_reax.html. If not explicitly set, the value of
{neigh/qeq} will match {neigh}.
If the {neigh/thread} keyword is set to {off}, then the KOKKOS package
threads only over atoms. However, for small systems, this may not expose
enough parallelism to keep a GPU busy. When this keyword is set to {on},
the KOKKOS package threads over both atoms and neighbors of atoms. When
using {neigh/thread} {on}, a full neighbor list must also be used. Using
{neigh/thread} {on} may be slower for large systems, so this this option
is turned on by default only when there are 16K atoms or less owned by
an MPI rank and when using a full neighbor list. Not all KOKKOS-enabled
potentials support this keyword yet, and only thread over atoms. Many
simple pair-wise potentials such as Lennard-Jones do support threading
If the {neigh/thread} keyword is set to {off}, then the KOKKOS package
threads only over atoms. However, for small systems, this may not expose
enough parallelism to keep a GPU busy. When this keyword is set to {on},
the KOKKOS package threads over both atoms and neighbors of atoms. When
using {neigh/thread} {on}, a full neighbor list must also be used. Using
{neigh/thread} {on} may be slower for large systems, so this this option
is turned on by default only when there are 16K atoms or less owned by
an MPI rank and when using a full neighbor list. Not all KOKKOS-enabled
potentials support this keyword yet, and only thread over atoms. Many
simple pair-wise potentials such as Lennard-Jones do support threading
over both atoms and neighbors.
The {newton} keyword sets the Newton flags for pairwise and bonded
interactions to {off} or {on}, the same as the "newton"_newton.html
command allows. The default for GPUs is {off} because this will almost
always give better performance for the KOKKOS package. This means more
computation is done, but less communication. However, when running on
CPUs a value of {on} is the default since it can often be faster, just
as it is for non-accelerated pair styles
The {newton} keyword sets the Newton flags for pairwise and bonded
interactions to {off} or {on}, the same as the "newton"_newton.html
command allows. The default for GPUs is {off} because this will almost
always give better performance for the KOKKOS package. This means more
computation is done, but less communication. However, when running on
CPUs a value of {on} is the default since it can often be faster, just
as it is for non-accelerated pair styles
The {binsize} keyword sets the size of bins used to bin atoms in
neighbor list builds. The same value can be set by the "neigh_modify
binsize"_neigh_modify.html command. Making it an option in the package
kokkos command allows it to be set from the command line. The default
value for CPUs is 0.0, which means the LAMMPS default will be used,
which is bins = 1/2 the size of the pairwise cutoff + neighbor skin
distance. This is fine when neighbor lists are built on the CPU. For GPU
builds, a 2x larger binsize equal to the pairwise cutoff + neighbor skin
is often faster, which is the default. Note that if you use a
longer-than-usual pairwise cutoff, e.g. to allow for a smaller fraction
of KSpace work with a "long-range Coulombic solver"_kspace_style.html
because the GPU is faster at performing pairwise interactions, then this
rule of thumb may give too large a binsize and the default should be
overridden with a smaller value.
The {binsize} keyword sets the size of bins used to bin atoms in
neighbor list builds. The same value can be set by the "neigh_modify
binsize"_neigh_modify.html command. Making it an option in the package
kokkos command allows it to be set from the command line. The default
value for CPUs is 0.0, which means the LAMMPS default will be used,
which is bins = 1/2 the size of the pairwise cutoff + neighbor skin
distance. This is fine when neighbor lists are built on the CPU. For GPU
builds, a 2x larger binsize equal to the pairwise cutoff + neighbor skin
is often faster, which is the default. Note that if you use a
longer-than-usual pairwise cutoff, e.g. to allow for a smaller fraction
of KSpace work with a "long-range Coulombic solver"_kspace_style.html
because the GPU is faster at performing pairwise interactions, then this
rule of thumb may give too large a binsize and the default should be
overridden with a smaller value.
The {comm} and {comm/exchange} and {comm/forward} and {comm/reverse}
keywords determine whether the host or device performs the packing and
unpacking of data when communicating per-atom data between processors.
"Exchange" communication happens only on timesteps that neighbor lists
are rebuilt. The data is only for atoms that migrate to new processors.
"Forward" communication happens every timestep. "Reverse" communication
happens every timestep if the {newton} option is on. The data is for
atom coordinates and any other atom properties that needs to be updated
The {comm} and {comm/exchange} and {comm/forward} and {comm/reverse}
keywords determine whether the host or device performs the packing and
unpacking of data when communicating per-atom data between processors.
"Exchange" communication happens only on timesteps that neighbor lists
are rebuilt. The data is only for atoms that migrate to new processors.
"Forward" communication happens every timestep. "Reverse" communication
happens every timestep if the {newton} option is on. The data is for
atom coordinates and any other atom properties that needs to be updated
for ghost atoms owned by each processor.
The {comm} keyword is simply a short-cut to set the same value for both
The {comm} keyword is simply a short-cut to set the same value for both
the {comm/exchange} and {comm/forward} and {comm/reverse} keywords.
The value options for all 3 keywords are {no} or {host} or {device}. A
value of {no} means to use the standard non-KOKKOS method of
packing/unpacking data for the communication. A value of {host} means to
use the host, typically a multi-core CPU, and perform the
packing/unpacking in parallel with threads. A value of {device} means to
use the device, typically a GPU, to perform the packing/unpacking
The value options for all 3 keywords are {no} or {host} or {device}. A
value of {no} means to use the standard non-KOKKOS method of
packing/unpacking data for the communication. A value of {host} means to
use the host, typically a multi-core CPU, and perform the
packing/unpacking in parallel with threads. A value of {device} means to
use the device, typically a GPU, to perform the packing/unpacking
operation.
The optimal choice for these keywords depends on the input script and
the hardware used. The {no} value is useful for verifying that the
Kokkos-based {host} and {device} values are working correctly. It is the
The optimal choice for these keywords depends on the input script and
the hardware used. The {no} value is useful for verifying that the
Kokkos-based {host} and {device} values are working correctly. It is the
default when running on CPUs since it is usually the fastest.
When running on CPUs or Xeon Phi, the {host} and {device} values work
identically. When using GPUs, the {device} value is the default since it
will typically be optimal if all of your styles used in your input
script are supported by the KOKKOS package. In this case data can stay
on the GPU for many timesteps without being moved between the host and
GPU, if you use the {device} value. If your script uses styles (e.g.
fixes) which are not yet supported by the KOKKOS package, then data has
to be move between the host and device anyway, so it is typically faster
to let the host handle communication, by using the {host} value. Using
{host} instead of {no} will enable use of multiple threads to
pack/unpack communicated data. When running small systems on a GPU,
performing the exchange pack/unpack on the host CPU can give speedup
When running on CPUs or Xeon Phi, the {host} and {device} values work
identically. When using GPUs, the {device} value is the default since it
will typically be optimal if all of your styles used in your input
script are supported by the KOKKOS package. In this case data can stay
on the GPU for many timesteps without being moved between the host and
GPU, if you use the {device} value. If your script uses styles (e.g.
fixes) which are not yet supported by the KOKKOS package, then data has
to be move between the host and device anyway, so it is typically faster
to let the host handle communication, by using the {host} value. Using
{host} instead of {no} will enable use of multiple threads to
pack/unpack communicated data. When running small systems on a GPU,
performing the exchange pack/unpack on the host CPU can give speedup
since it reduces the number of CUDA kernel launches.
The {cuda/aware} keyword chooses whether CUDA-aware MPI will be used. When
this keyword is set to {on}, buffers in GPU memory are passed directly
through MPI send/receive calls. This reduces overhead of first copying
the data to the host CPU. However CUDA-aware MPI is not supported on all
systems, which can lead to segmentation faults and would require using a
value of {off}. If LAMMPS can safely detect that CUDA-aware MPI is not
available (currently only possible with OpenMPI v2.0.0 or later), then
the {cuda/aware} keyword is automatically set to {off} by default. When
the {cuda/aware} keyword is set to {off} while any of the {comm}
keywords are set to {device}, the value for these {comm} keywords will
be automatically changed to {host}. This setting has no effect if not
running on GPUs. CUDA-aware MPI is available for OpenMPI 1.8 (or later
The {cuda/aware} keyword chooses whether CUDA-aware MPI will be used. When
this keyword is set to {on}, buffers in GPU memory are passed directly
through MPI send/receive calls. This reduces overhead of first copying
the data to the host CPU. However CUDA-aware MPI is not supported on all
systems, which can lead to segmentation faults and would require using a
value of {off}. If LAMMPS can safely detect that CUDA-aware MPI is not
available (currently only possible with OpenMPI v2.0.0 or later), then
the {cuda/aware} keyword is automatically set to {off} by default. When
the {cuda/aware} keyword is set to {off} while any of the {comm}
keywords are set to {device}, the value for these {comm} keywords will
be automatically changed to {host}. This setting has no effect if not
running on GPUs. CUDA-aware MPI is available for OpenMPI 1.8 (or later
versions), Mvapich2 1.9 (or later) when the "MV2_USE_CUDA" environment
variable is set to "1", CrayMPI, and IBM Spectrum MPI when the "-gpu"
flag is used.
@ -641,16 +641,16 @@ not used, you must invoke the package intel command in your input
script or via the "-pk intel" "command-line
switch"_Run_options.html.
For the KOKKOS package, the option defaults for GPUs are neigh = full,
neigh/qeq = full, newton = off, binsize for GPUs = 2x LAMMPS default
value, comm = device, cuda/aware = on. When LAMMPS can safely detect
that CUDA-aware MPI is not available, the default value of cuda/aware
becomes "off". For CPUs or Xeon Phis, the option defaults are neigh =
half, neigh/qeq = half, newton = on, binsize = 0.0, and comm = no. The
option neigh/thread = on when there are 16K atoms or less on an MPI
rank, otherwise it is "off". These settings are made automatically by
the required "-k on" "command-line switch"_Run_options.html. You can
change them by using the package kokkos command in your input script or
For the KOKKOS package, the option defaults for GPUs are neigh = full,
neigh/qeq = full, newton = off, binsize for GPUs = 2x LAMMPS default
value, comm = device, cuda/aware = on. When LAMMPS can safely detect
that CUDA-aware MPI is not available, the default value of cuda/aware
becomes "off". For CPUs or Xeon Phis, the option defaults are neigh =
half, neigh/qeq = half, newton = on, binsize = 0.0, and comm = no. The
option neigh/thread = on when there are 16K atoms or less on an MPI
rank, otherwise it is "off". These settings are made automatically by
the required "-k on" "command-line switch"_Run_options.html. You can
change them by using the package kokkos command in your input script or
via the "-pk kokkos command-line switch"_Run_options.html.
For the OMP package, the default is Nthreads = 0 and the option

4
doc/src/pair_e3b.txt
View File

@ -20,8 +20,8 @@ If the {preset} keyword is given, no others are needed.
Otherwise, all are mandatory except for {neigh}.
The {neigh} keyword is always optional. :l
{preset} arg = {2011} or {2015} = which set of predefined parameters to use
2011 = use the potential parameters from "(Tainter 2011)"_#Tainter2011
2015 = use the potential parameters from "(Tainter 2015)"_#Tainter2015
2011 = use the potential parameters from "(Tainter 2011)"_#Tainter2011
2015 = use the potential parameters from "(Tainter 2015)"_#Tainter2015
{Ea} arg = three-body energy for type A hydrogen bonding interactions (energy units)
{Eb} arg = three-body energy for type B hydrogen bonding interactions (energy units)
{Ec} arg = three-body energy for type C hydrogen bonding interactions (energy units)

24
doc/src/pair_granular.txt
View File

@ -100,7 +100,7 @@ on particle {i} due to contact with particle {j} is given by:
\mathbf\{F\}_\{ne, Hooke\} = k_N \delta_\{ij\} \mathbf\{n\}
\end\{equation\}
Where \(\delta = R_i + R_j - \|\mathbf\{r\}_\{ij\}\|\) is the particle
Where \(\delta_\{ij\} = R_i + R_j - \|\mathbf\{r\}_\{ij\}\|\) is the particle
overlap, \(R_i, R_j\) are the particle radii, \(\mathbf\{r\}_\{ij\} =
\mathbf\{r\}_i - \mathbf\{r\}_j\) is the vector separating the two
particle centers (note the i-j ordering so that \(F_\{ne\}\) is
@ -177,7 +177,7 @@ following general form:
\end\{equation\}
Here, \(\mathbf\{v\}_\{n,rel\} = (\mathbf\{v\}_j - \mathbf\{v\}_i)
\cdot \mathbf\{n\}\) is the component of relative velocity along
\cdot \mathbf\{n\} \mathbf\{n\}\) is the component of relative velocity along
\(\mathbf\{n\}\).
The optional {damping} keyword to the {pair_coeff} command followed by
@ -299,8 +299,8 @@ the normal damping \(\eta_n\) (see above):
\eta_t = -x_\{\gamma,t\} \eta_n
\end\{equation\}
The normal damping prefactor \(\eta_n\) is determined by the choice of
the {damping} keyword, as discussed above. Thus, the {damping}
The normal damping prefactor \(\eta_n\) is determined by the choice
of the {damping} keyword, as discussed above. Thus, the {damping}
keyword also affects the tangential damping. The parameter
\(x_\{\gamma,t\}\) is a scaling coefficient. Several works in the
literature use \(x_\{\gamma,t\} = 1\) ("Marshall"_#Marshall2009,
@ -308,10 +308,10 @@ literature use \(x_\{\gamma,t\} = 1\) ("Marshall"_#Marshall2009,
tangential velocity at the point of contact is given by
\(\mathbf\{v\}_\{t, rel\} = \mathbf\{v\}_\{t\} - (R_i\Omega_i +
R_j\Omega_j) \times \mathbf\{n\}\), where \(\mathbf\{v\}_\{t\} =
\mathbf\{v\}_r - \mathbf\{v\}_r\cdot\mathbf\{n\}\), \(\mathbf\{v\}_r =
\mathbf\{v\}_j - \mathbf\{v\}_i\). The direction of the applied force
is \(\mathbf\{t\} =
\mathbf\{v_\{t,rel\}\}/\|\mathbf\{v_\{t,rel\}\}\|\).
\mathbf\{v\}_r - \mathbf\{v\}_r\cdot\mathbf\{n\}\{n\}\),
\(\mathbf\{v\}_r = \mathbf\{v\}_j - \mathbf\{v\}_i\).
The direction of the applied force is \(\mathbf\{t\} =
\mathbf\{v_\{t,rel\}\}/\|\mathbf\{v_\{t,rel\}\}\|\) .
The normal force value \(F_\{n0\}\) used to compute the critical force
depends on the form of the contact model. For non-cohesive models
@ -411,8 +411,8 @@ option by an additional factor of {a}, the radius of the contact region. The tan
\mathbf\{F\}_t = -min(\mu_t F_\{n0\}, \|-k_t a \mathbf\{\xi\} + \mathbf\{F\}_\mathrm\{t,damp\}\|) \mathbf\{t\}
\end\{equation\}
Here, {a} is the radius of the contact region, given by \(a = \delta
R\) for all normal contact models, except for {jkr}, where it is given
Here, {a} is the radius of the contact region, given by \(a =\sqrt\{R\delta\}\)
for all normal contact models, except for {jkr}, where it is given
implicitly by \(\delta = a^2/R - 2\sqrt\{\pi \gamma a/E\}\), see
discussion above. To match the Mindlin solution, one should set \(k_t
= 8G\), where \(G\) is the shear modulus, related to Young's modulus
@ -680,7 +680,7 @@ The single() function of these pair styles returns 0.0 for the energy
of a pairwise interaction, since energy is not conserved in these
dissipative potentials. It also returns only the normal component of
the pairwise interaction force. However, the single() function also
calculates 10 extra pairwise quantities. The first 3 are the
calculates 12 extra pairwise quantities. The first 3 are the
components of the tangential force between particles I and J, acting
on particle I. The 4th is the magnitude of this tangential force.
The next 3 (5-7) are the components of the rolling torque acting on
@ -790,4 +790,4 @@ alternative contact force models during inelastic collisions. Powder
Technology, 233, 30-46.
:link(WaltonPC)
[(Otis R. Walton)] Walton, O.R., Personal Communication
[(Otis R. Walton)] Walton, O.R., Personal Communication

4
doc/src/pair_kolmogorov_crespi_full.txt
View File

@ -43,8 +43,8 @@ when the tapper function is turned off. The formula of taper function
can be found in pair style "ilp/graphene/hbn"_pair_ilp_graphene_hbn.html.
NOTE: This potential (ILP) is intended for interlayer interactions between two
different layers of graphene. To perform a realistic simulation, this potential
must be used in combination with intralayer potential, such as
different layers of graphene. To perform a realistic simulation, this potential
must be used in combination with intralayer potential, such as
"AIREBO"_pair_airebo.html or "Tersoff"_pair_tersoff.html potential.
To keep the intralayer properties unaffected, the interlayer interaction
within the same layers should be avoided. Hence, each atom has to have a layer

207
doc/src/pair_local_density.txt Normal file
View File

@ -0,0 +1,207 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
pair_style local/density command :h3
[Syntax:]
pair_style style arg :pre
style = {local/density}
arg = name of file containing tabulated values of local density and the potential :ul
[Examples:]
pair_style local/density benzene_water.localdensity.table :pre
pair_style hybrid/overlay table spline 500 local/density
pair_coeff * * local/density benzene_water.localdensity.table :pre
[Description:]
The local density (LD) potential is a mean-field manybody potential, and, in some
sense,a generalization of embedded atom models (EAM). The name "local density
potential" arises from the fact that it assigns an energy to an atom depending
on the number of neighboring atoms of given type around it within a predefined
spherical volume (i.e., within a cutoff). The bottom-up coarse-graining (CG)
literature suggests that such potentials can be widely useful in capturing
effective multibody forces in a computationally efficient manner so as to
improve the quality of CG models of implicit solvation"(Sanyal1)"_#Sanyal1 and
phase-segregation in liquid mixtures"(Sanyal2)"_#Sanyal2, and provide guidelines
to determine the extent of manybody correlations present in a CG
model."(Rosenberger)"_#Rosenberger The LD potential in LAMMPS is primarily
intended to be used as a corrective potential over traditional pair potentials
in bottom-up CG models, i.e., as a hybrid pair style with
other explicit pair interaction terms (e.g., table spline, Lennard Jones, etc.).
Because the LD potential is not a pair potential per se, it is implemented
simply as a single auxiliary file with all specifications that will be read
upon initialization.
NOTE: Thus when used as the only interaction in the system, there is no
corresponding pair_coeff command and when used with other pair styles using the
hybrid/overlay option, the corresponding pair_coeff command must be supplied
* * as placeholders for the atom types.
:line
[System with a single CG atom type:]
A system of a single atom type (e.g., LJ argon) with a single local density (LD)
potential would have an energy given by:
:c,image(Eqs/pair_local_density_energy.jpg)
where rho_i is the LD at atom i and F(rho) is similar in spirit to the
embedding function used in EAM potentials. The LD at atom i is given by the sum
:c,image(Eqs/pair_local_density_ld.jpg)
where phi is an indicator function that is one at r=0 and zero beyond a cutoff
distance R2. The choice of the functional form of phi is somewhat arbitrary,
but the following piecewise cubic function has proven sufficiently general:
"(Sanyal1)"_#Sanyal1, "(Sanyal2)"_#Sanyal2 "(Rosenberger)"_#Rosenberger
:c,image(Eqs/pair_local_density_indicator_func.jpg)
The constants {c} are chosen so that the indicator function smoothly
interpolates between 1 and 0 between the distances R1 and R2, which are
called the inner and outer cutoffs, respectively. Thus phi satisfies
phi(R1) = 1, phi(R2) = dphi/dr @ (r=R1) = dphi/dr @ (r=R2) = 0. The embedding
function F(rho) may or may not have a closed-form expression. To maintain
generality, it is practically represented with a spline-interpolated table
over a predetermined range of rho. Outside of that range it simply adopts zero
values at the endpoints.
It can be shown that the total force between two atoms due to the LD potential
takes the form of a pair force, which motivates its designation as a LAMMPS
pair style. Please see "(Sanyal1)"_#Sanyal1 for details of the derivation.
:line
[Systems with arbitrary numbers of atom types:]
The potential is easily generalized to systems involving multiple atom types:
:c,image(Eqs/pair_local_density_energy_multi.jpg)
with the LD expressed as
:c,image(Eqs/pair_local_density_ld_multi.jpg)
where alpha gives the type of atom i, beta the type of atom j, and the
coefficients a and b filter for atom types as specified by the user. a is
called the central atom filter as it determines to which atoms the
potential applies; a_alpha = 1 if the LD potential applies to atom type alpha
else zero. On the other hand, b is called the neighbor atom filter because it
specifies which atom types to use in the calculation of the LD; b_beta = 1 if
atom type beta contributes to the LD and zero otherwise.
NOTE: Note that the potentials need not be symmetric with respect to atom types,
which is the reason for two distinct sets of coefficients a and b. An atom type
may contribute to the LD but not the potential, or to the potential but not the
LD. Such decisions are made by the user and should (ideally) be motivated on
physical grounds for the problem at hand.
:line
[General form for implementation in LAMMPS:]
Of course, a system with many atom types may have many different possible LD
potentials, each with their own atom type filters, cutoffs, and embedding
functions. The most general form of this potential as implemented in the
pair_style local/density is:
:c,image(Eqs/pair_local_density_energy_implement.jpg)
where, k is an index that spans the (arbitrary) number of applied LD potentials
N_LD. Each LD is calculated as before with:
:c,image(Eqs/pair_local_density_ld_implement.jpg)
The superscript on the indicator function phi simply indicates that it is
associated with specific values of the cutoff distances R1(k) and R2(k). In
summary, there may be N_LD distinct LD potentials. With each potential type (k),
one must specify:
the inner and outer cutoffs as R1 and R2
the central type filter a(k), where k = 1,2,...N_LD
the neighbor type filter b(k), where k = 1,2,...N_LD
the LD potential function F(k)(rho), typically as a table that is later spline-interpolated :ul
:line
[Tabulated input file format:]
Line 1: comment or blank (ignored)
Line 2: comment or blank (ignored)
Line 3: N_LD N_rho (# of LD potentials and # of tabulated values, single space separated)
Line 4: blank (ignored)
Line 5: R1(k) R2(k) (lower and upper cutoffs, single space separated)
Line 6: central-types (central atom types, single space separated)
Line 7: neighbor-types (neighbor atom types single space separated)
Line 8: rho_min rho_max drho (min, max and diff. in tabulated rho values, single space separated)
Line 9: F(k)(rho_min + 0.drho)
Line 10: F(k)(rho_min + 1.drho)
Line 11: F(k)(rho_min + 2.drho)
...
Line 9+N_rho: F(k)(rho_min + N_rho . drho)
Line 10+N_rho: blank (ignored) :pre
Block 2 :pre
Block 3 :pre
Block N_LD :pre
Lines 5 to 9+N_rho constitute the first block. Thus the input file is separated
(by blank lines) into N_LD blocks each representing a separate LD potential and
each specifying its own upper and lower cutoffs, central and neighbor atoms,
and potential. In general, blank lines anywhere are ignored.
:line
[Mixing, shift, table, tail correction, restart, info]:
This pair style does not support automatic mixing. For atom type pairs alpha,
beta and alpha != beta, even if LD potentials of type (alpha, alpha) and
(beta, beta) are provided, you will need to explicitly provide LD potential
types (alpha, beta) and (beta, alpha) if need be (Here, the notation (alpha,
beta) means that alpha is the central atom to which the LD potential is applied
and beta is the neighbor atom which contributes to the LD potential on alpha).
This pair style does not support the "pair_modify"_pair_modify.html
shift, table, and tail options.
The local/density pair style does not write its information to "binary restart
files"_restart.html, 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.
:line
[Restrictions:]
The local/density pair style is a part of the USER-MISC package. It is only
enabled if LAMMPS was built with that package. See the "Build
package"_Build_package.html doc page for more info.
[Related commands:]
"pair_coeff"_pair_coeff.html
[Default:] none
:line
:link(Sanyal1)
[(Sanyal1)] Sanyal and Shell, Journal of Chemical Physics, 2016, 145 (3), 034109.
:link(Sanyal2)
[(Sanyal2)] Sanyal and Shell, Journal of Physical Chemistry B, 122 (21), 5678-5693.
:link(Rosenberger)
[(Rosenberger)] Rosenberger, Sanyal, Shell and van der Vegt, Journal of Chemical Physics, 2019, 151 (4), 044111.

2
doc/src/pair_mm3_switch3_coulgauss.txt
View File

@ -68,7 +68,7 @@ gamma (distance) :ul
[Mixing, shift, table, tail correction, restart, rRESPA info]:
Mixing rules are fixed for this style as defined above.
Mixing rules are fixed for this style as defined above.
Shifting the potential energy is not necessary because the switching
function ensures that the potential is zero at the cut-off.

4
doc/src/pair_oxdna2.txt
View File

@ -27,8 +27,8 @@ args = list of arguments for these particular styles :ul
{oxdna2/stk} args = seq T xi kappa 6.0 0.4 0.9 0.32 0.6 1.3 0 0.8 0.9 0 0.95 0.9 0 0.95 2.0 0.65 2.0 0.65
seq = seqav (for average sequence stacking strength) or seqdep (for sequence-dependent stacking strength)
T = temperature (oxDNA units, 0.1 = 300 K)
xi = temperature-independent coefficient in stacking strength
kappa = coefficient of linear temperature dependence in stacking strength
xi = temperature-independent coefficient in stacking strength
kappa = coefficient of linear temperature dependence in stacking strength
{oxdna2/hbond} args = seq eps 8.0 0.4 0.75 0.34 0.7 1.5 0 0.7 1.5 0 0.7 1.5 0 0.7 0.46 3.141592653589793 0.7 4.0 1.5707963267948966 0.45 4.0 1.5707963267948966 0.45
seq = seqav (for average sequence base-pairing strength) or seqdep (for sequence-dependent base-pairing strength)
eps = 1.0678 (between base pairs A-T and C-G) or 0 (all other pairs)

4
doc/src/pair_snap.txt
View File

@ -50,7 +50,7 @@ the SNAP potential files themselves.
Only a single pair_coeff command is used with the {snap} style which
specifies a SNAP coefficient file followed by a SNAP parameter file
and then N additional arguments specifying the mapping of SNAP
elements to LAMMPS atom types, where N is the number of
elements to LAMMPS atom types, where N is the number of
LAMMPS atom types:
SNAP coefficient file
@ -79,7 +79,7 @@ The name of the SNAP coefficient file usually ends in the
".snapcoeff" extension. It may contain coefficients
for many SNAP elements. The only requirement is that it
contain at least those element names appearing in the
LAMMPS mapping list.
LAMMPS mapping list.
The name of the SNAP parameter file usually ends in the ".snapparam"
extension. It contains a small number
of parameters that define the overall form of the SNAP potential.

29
doc/src/pair_spin_dipole.txt
View File

@ -11,7 +11,7 @@ pair_style spin/dipole/long command :h3
[Syntax:]
pair_style spin/dipole/cut cutoff
pair_style spin/dipole/cut cutoff
pair_style spin/dipole/long cutoff :pre
cutoff = global cutoff for magnetic dipole energy and forces
@ -21,35 +21,34 @@ cutoff = global cutoff for magnetic dipole energy and forces
[Examples:]
pair_style spin/dipole/cut 10.0
pair_coeff * * 10.0
pair_coeff * * 10.0
pair_coeff 2 3 8.0 :pre
pair_style spin/dipole/long 9.0
pair_coeff * * 1.0 1.0
pair_coeff 2 3 1.0 1.0 2.5 4.0 scale 0.5
pair_coeff 2 3 1.0 1.0 2.5 4.0 :pre
pair_coeff * * 10.0
pair_coeff 2 3 6.0 :pre
[Description:]
Style {spin/dipole/cut} computes a short-range dipole-dipole
interaction between pairs of magnetic particles that each
have a magnetic spin.
interaction between pairs of magnetic particles that each
have a magnetic spin.
The magnetic dipole-dipole interactions are computed by the
following formulas for the magnetic energy, magnetic precession
following formulas for the magnetic energy, magnetic precession
vector omega and mechanical force between particles I and J.
:c,image(Eqs/pair_spin_dipole.jpg)
where si and sj are the spin on two magnetic particles,
r is their separation distance, and the vector e = (Ri - Rj)/|Ri - Rj|
is the direction vector between the two particles.
where si and sj are the spin on two magnetic particles,
r is their separation distance, and the vector e = (Ri - Rj)/|Ri - Rj|
is the direction vector between the two particles.
Style {spin/dipole/long} computes long-range magnetic dipole-dipole
interaction.
A "kspace_style"_kspace_style.html must be defined to
use this pair style. Currently, "kspace_style
use this pair style. Currently, "kspace_style
ewald/dipole/spin"_kspace_style.html and "kspace_style
pppm/dipole/spin"_kspace_style.html support long-range magnetic
pppm/dipole/spin"_kspace_style.html support long-range magnetic
dipole-dipole interactions.
:line
@ -68,8 +67,8 @@ to be specified in an input script that reads a restart file.
[Restrictions:]
The {spin/dipole/cut} and {spin/dipole/long} styles are part of
the SPIN package. They are only enabled if LAMMPS was built with that
package. See the "Build package"_Build_package.html doc page for more
the SPIN package. They are only enabled if LAMMPS was built with that
package. See the "Build package"_Build_package.html doc page for more
info.
Using dipole/spin pair styles with {electron} "units"_units.html is not

4
doc/src/pair_spin_dmi.txt
View File

@ -15,11 +15,11 @@ pair_style spin/dmi cutoff :pre
cutoff = global cutoff pair (distance in metal units) :ulb,l
:ule
[Examples:]
pair_style spin/dmi 4.0
pair_coeff * * dmi 2.6 0.001 1.0 0.0 0.0
pair_coeff * * dmi 2.6 0.001 1.0 0.0 0.0
pair_coeff 1 2 dmi 4.0 0.00109 0.0 0.0 1.0 :pre
[Description:]

2
doc/src/pair_spin_neel.txt
View File

@ -15,7 +15,7 @@ pair_style spin/neel cutoff :pre
cutoff = global cutoff pair (distance in metal units) :ulb,l
:ule
[Examples:]
pair_style spin/neel 4.0

1
doc/src/pair_style.txt
View File

@ -228,6 +228,7 @@ accelerated styles exist.
"lj/smooth/linear"_pair_lj_smooth_linear.html - linear smoothed LJ potential
"lj/switch3/coulgauss"_pair_lj_switch3_coulgauss - smoothed LJ vdW potential with Gaussian electrostatics
"lj96/cut"_pair_lj96.html - Lennard-Jones 9/6 potential
"local/density"_pair_local_density.html - generalized basic local density potential
"lubricate"_pair_lubricate.html - hydrodynamic lubrication forces
"lubricate/poly"_pair_lubricate.html - hydrodynamic lubrication forces with polydispersity
"lubricateU"_pair_lubricateU.html - hydrodynamic lubrication forces for Fast Lubrication Dynamics

1
doc/src/pairs.txt
View File

@ -66,6 +66,7 @@ Pair Styles :h1
pair_lj_smooth
pair_lj_smooth_linear
pair_lj_switch3_coulgauss
pair_local_density
pair_lubricate
pair_lubricateU
pair_mdf

62
doc/src/third_order.txt Normal file
View File

@ -0,0 +1,62 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
third_order command :h3
[Syntax:]
third_order group-ID style delta args keyword value ... :pre
group-ID = ID of group of atoms to displace :ulb,l
style = {regular} or {eskm} :l
delta = finite different displacement length (distance units) :l
one or more keyword/arg pairs may be appended :l
keyword = {file} or {binary}
{file} name = name of output file for the third order tensor
{binary} arg = {yes} or {no} or {gzip} :pre
:ule
[Examples:]
third_order 1 regular 0.000001
third_order 1 eskm 0.000001
third_order 3 regular 0.00004 file third_order.dat
third_order 5 eskm 0.00000001 file third_order.dat binary yes :pre
[Description:]
Calculate the third order force constant tensor by finite difference of the selected group,
:c,image(JPG/third_order_force_constant.png))
where Phi is the third order force constant tensor.
The output of the command is the tensor, three elements at a time. The
three elements correspond to the three gamma elements for a specific i/alpha/j/beta/k.
The initial five numbers are i, alpha, j, beta, and k respectively.
If the style eskm is selected, the tensor will be using energy units of 10 J/mol.
These units conform to eskm style from the dynamical_matrix command, which
will simplify operations using dynamical matrices with third order tensors.
[Restrictions:]
The command collects a 9 times the number of atoms in the group on every single MPI rank,
so the memory requirements can be very significant for large systems.
This command is part of the USER-PHONON package. It is only enabled if
LAMMPS was built with that package. See the "Build
package"_Build_package.html doc page for more info.
[Related commands:]
"fix phonon"_fix_phonon.html "dynamical_matrix"_dynamical_matrix.html
[Default:]
The default settings are file = "third_order.dat", binary = no

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

@ -276,6 +276,7 @@ Broadwell
Broglie
brownian
brownw
Broyden
Bryantsev
Btarget
btype
@ -306,6 +307,7 @@ Cavium
Cawkwell
cbecker
ccache
ccachepiecewise
ccmake
ccNspecies
CCu
@ -624,6 +626,7 @@ Doye
dpd
DPD
dpdTheta
dphi
DPhil
dr
dR
@ -782,6 +785,7 @@ erotate
Ertas
ervel
Espanol
eskm
esu
esub
esw
@ -991,6 +995,7 @@ gmask
Gmask
gneb
GNEB
Goldfarb
googlemail
Gordan
GPa
@ -1410,6 +1415,7 @@ Laupretre
lavenderblush
lawngreen
lB
lbfgs
lbl
LBtype
lcbop
@ -1583,6 +1589,7 @@ Materias
mathbf
matlab
matplotlib
Mattice
Mattox
Mattson
maxangle
@ -2046,6 +2053,7 @@ Orsi
ortho
orthonormal
orthorhombic
oso
ot
Otype
Ouldridge
@ -2130,6 +2138,7 @@ ph
Phillpot
phiphi
phonon
phonons
phophorous
phosphide
Phs
@ -2143,6 +2152,7 @@ picograms
picosecond
picoseconds
pid
piecewise
Pieniazek
Pieter
pimd
@ -2277,6 +2287,7 @@ qoffload
qopenmp
qoverride
qtb
quadratically
quadrupolar
Quant
quartic
@ -2427,6 +2438,7 @@ Rodrigues
Rohart
Ronchetti
Rosati
Rosenberger
Rossky
rosybrown
rotationally
@ -2491,6 +2503,7 @@ Scripta
sdk
sdpd
SDPD
se
seagreen
Secor
sectoring
@ -2517,6 +2530,7 @@ setvel
sfftw
Sg
Shan
Shanno
shapex
shapey
shapez
@ -2584,6 +2598,7 @@ Snodin
Sodani
Soderlind
solvated
solvation
Sorensen
soundspeed
Souza
@ -2946,6 +2961,7 @@ vectorial
vectorization
Vectorization
vectorized
Vegt
vel
Verlag
verlet

12
examples/README
View File

@ -76,6 +76,7 @@ ellipse: ellipsoidal particles in spherical solvent, 2d system
flow: Couette and Poiseuille flow in a 2d channel
friction: frictional contact of spherical asperities between 2d surfaces
gcmc: Grand Canonical Monte Carlo (GCMC) via the fix gcmc command
gjf: use of fix langevin Gronbech-Jensen/Farago option
granregion: use of fix wall/region/gran as boundary on granular particles
hugoniostat: Hugoniostat shock dynamics
hyper: global and local hyperdynamics of diffusion on Pt surface
@ -99,12 +100,11 @@ pour: pouring of granular particles into a 3d box, then chute flow
prd: parallel replica dynamics of vacancy diffusion in bulk Si
python: use of PYTHON package to invoke Python code from input script
qeq: use of QEQ package for charge equilibration
reax: RDX and TATB models using the ReaxFF
reax: RDX and TATB and several other models using ReaxFF
rigid: rigid bodies modeled as independent or coupled
shear: sideways shear applied to 2d solid, with and without a void
snap: use of SNAP potential for Ta
snap: examples for using several bundled SNAP potentials
srd: stochastic rotation dynamics (SRD) particles as solvent
snap: NVE dynamics for BCC tantalum crystal using SNAP potential
steinhardt: Steinhardt-Nelson Q_l and W_l parameters usng orientorder/atom
streitz: Streitz-Mintmire potential for Al2O3
tad: temperature-accelerated dynamics of vacancy diffusion in bulk Si
@ -164,6 +164,12 @@ The MC directory has an example script for using LAMMPS as an
energy-evaluation engine in a iterative Monte Carlo energy-relaxation
loop.
The UNITS directory contains examples of input scripts modeling the
same Lennard-Jones liquid model, written in 3 different unit systems:
lj, real, and metal. So that you can see how to scale/unscale input
and output values read/written by LAMMPS to verify you are performing
the same simulation in different unit systems.
The USER directory contains subdirectories of user-provided example
scripts for ser packages. See the README files in those directories
for more info. See the doc/Section_start.html file for more info

2
examples/SPIN/bfo/in.spin.bfo
View File

@ -32,7 +32,7 @@ neigh_modify every 10 check yes delay 20
fix 1 all precession/spin anisotropy 0.0000033 0.0 0.0 1.0
fix 2 all langevin/spin 0.0 0.1 21
fix 3 all nve/spin lattice no
fix 3 all nve/spin lattice frozen
timestep 0.0002

2
examples/SPIN/cobalt_fcc/in.spin.cobalt_fcc
View File

@ -35,7 +35,7 @@ fix_modify 1 energy yes
fix 2 all langevin/spin 0.0 0.0 21
fix 3 all nve/spin lattice yes
fix 3 all nve/spin lattice moving
timestep 0.0001
# compute and output options

2
examples/SPIN/cobalt_hcp/in.spin.cobalt_hcp
View File

@ -37,7 +37,7 @@ neigh_modify every 10 check yes delay 20
fix 1 all precession/spin anisotropy 0.01 0.0 0.0 1.0
#fix 2 all langevin/spin 0.0 0.0 21
fix 2 all langevin/spin 0.0 0.1 21
fix 3 all nve/spin lattice yes
fix 3 all nve/spin lattice moving
timestep 0.0001

2
examples/SPIN/dipole_spin/in.spin.iron_dipole_cut
View File

@ -33,7 +33,7 @@ fix 1 all precession/spin cubic 0.001 0.0005 1.0 0.0 0.0 0.0 1.0 0.0 0.0 0.0 1
fix_modify 1 energy yes
fix 2 all langevin/spin 0.0 0.0 21
fix 3 all nve/spin lattice yes
fix 3 all nve/spin lattice moving
timestep 0.0001
# compute and output options

2
examples/SPIN/dipole_spin/in.spin.iron_dipole_ewald
View File

@ -35,7 +35,7 @@ fix 1 all precession/spin cubic 0.001 0.0005 1.0 0.0 0.0 0.0 1.0 0.0 0.0 0.0 1
fix_modify 1 energy yes
fix 2 all langevin/spin 0.0 0.0 21
fix 3 all nve/spin lattice yes
fix 3 all nve/spin lattice moving
timestep 0.0001
# compute and output options

2
examples/SPIN/dipole_spin/in.spin.iron_dipole_pppm
View File

@ -36,7 +36,7 @@ fix 1 all precession/spin cubic 0.001 0.0005 1.0 0.0 0.0 0.0 1.0 0.0 0.0 0.0 1
fix_modify 1 energy yes
fix 2 all langevin/spin 0.0 0.0 21
fix 3 all nve/spin lattice yes
fix 3 all nve/spin lattice moving
timestep 0.0001
# compute and output options

2
examples/SPIN/iron/in.spin.iron
View File

@ -33,7 +33,7 @@ neigh_modify every 10 check yes delay 20
fix 1 all precession/spin zeeman 0.0 0.0 0.0 1.0
fix 2 all langevin/spin 0.0 0.0 21
fix 3 all nve/spin lattice yes
fix 3 all nve/spin lattice moving
timestep 0.0001
# compute and output options

2
examples/SPIN/iron/in.spin.iron_cubic
View File

@ -31,7 +31,7 @@ fix 1 all precession/spin cubic 0.001 0.0005 1.0 0.0 0.0 0.0 1.0 0.0 0.0 0.0 1
fix_modify 1 energy yes
fix 2 all langevin/spin 0.0 0.0 21
fix 3 all nve/spin lattice yes
fix 3 all nve/spin lattice moving
timestep 0.0001
# compute and output options

2
examples/SPIN/nickel/in.spin.nickel
View File

@ -33,7 +33,7 @@ neigh_modify every 10 check yes delay 20
fix 1 all precession/spin zeeman 0.0 0.0 0.0 1.0
fix 2 all langevin/spin 0.0 0.0 21
fix 3 all nve/spin lattice yes
fix 3 all nve/spin lattice moving
timestep 0.0001
# compute and output options

2
examples/SPIN/nickel/in.spin.nickel_cubic
View File

@ -35,7 +35,7 @@ fix 1 all precession/spin cubic -0.0001 0.0 1.0 0.0 0.0 0.0 1.0 0.0 0.0 0.0 1.
fix_modify 1 energy yes
fix 2 all langevin/spin 0.0 0.0 21
fix 3 all nve/spin lattice yes
fix 3 all nve/spin lattice moving
timestep 0.0001
# compute and output options

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