tx258/lammps-gran-kokkos
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge remote-tracking branch 'origin/master' into HEAD

Browse Source
This commit is contained in:
Christoph Junghans
2018-08-03 08:13:12 -06:00
parent efaebe0eb0 1b0a8fdc9b
commit 463e34cef5
372 changed files with 16891 additions and 5931 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
.github/CODEOWNERS vendored
View File

@ -17,6 +17,7 @@ src/GPU/* @ndtrung81
src/KOKKOS/* @stanmoore1
src/KIM/* @ellio167
src/LATTE/* @cnegre
src/SPIN/* @julient31
src/USER-CGDNA/* @ohenrich
src/USER-CGSDK/* @akohlmey
src/USER-COLVARS/* @giacomofiorin
@ -44,6 +45,7 @@ src/USER-MISC/*_grem.* @dstelter92
# tools
tools/msi2lmp/* @akohlmey
tools/emacs/* @HaoZeke
# cmake
cmake/* @junghans @rbberger

141
cmake/CMakeLists.txt
View File

@ -9,6 +9,7 @@ set(SOVERSION 0)
get_filename_component(LAMMPS_SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/../src ABSOLUTE)
get_filename_component(LAMMPS_LIB_SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/../lib ABSOLUTE)
get_filename_component(LAMMPS_LIB_BINARY_DIR ${CMAKE_BINARY_DIR}/lib ABSOLUTE)
get_filename_component(LAMMPS_DOC_DIR ${CMAKE_CURRENT_SOURCE_DIR}/../doc ABSOLUTE)
# To avoid conflicts with the conventional Makefile build system, we build everything here
@ -153,14 +154,15 @@ if(ENABLE_TESTING)
enable_testing()
endif(ENABLE_TESTING)
set(DEFAULT_PACKAGES ASPHERE BODY CLASS2 COLLOID COMPRESS CORESHELL DIPOLE GRANULAR
KSPACE MANYBODY MC MEAM MISC MOLECULE PERI QEQ REAX REPLICA RIGID SHOCK SPIN SNAP
set(DEFAULT_PACKAGES ASPHERE BODY CLASS2 COLLOID COMPRESS DIPOLE GRANULAR
KSPACE MANYBODY MC MEAM MISC MOLECULE PERI REAX REPLICA RIGID SHOCK SPIN SNAP
SRD KIM PYTHON MSCG MPIIO VORONOI POEMS LATTE USER-ATC USER-AWPMD USER-BOCS
USER-CGDNA USER-MESO USER-CGSDK USER-COLVARS USER-DIFFRACTION USER-DPD USER-DRUDE
USER-EFF USER-FEP USER-H5MD USER-LB USER-MANIFOLD USER-MEAMC USER-MGPT USER-MISC
USER-MOFFF USER-MOLFILE USER-NETCDF USER-PHONON USER-QTB USER-REAXC USER-SCAFACOS
USER-SMD USER-SMTBQ USER-SPH USER-TALLY USER-UEF USER-VTK USER-QUIP USER-QMMM)
set(ACCEL_PACKAGES USER-OMP KOKKOS OPT USER-INTEL GPU)
set(OTHER_PACKAGES CORESHELL QEQ)
foreach(PKG ${DEFAULT_PACKAGES})
option(PKG_${PKG} "Build ${PKG} Package" OFF)
endforeach()
@ -174,13 +176,12 @@ macro(pkg_depends PKG1 PKG2)
endif()
endmacro()
# "hard" dependencies between packages resulting
# in an error instead of skipping over files
pkg_depends(MPIIO MPI)
pkg_depends(QEQ MANYBODY)
pkg_depends(USER-ATC MANYBODY)
pkg_depends(USER-LB MPI)
pkg_depends(USER-MISC MANYBODY)
pkg_depends(USER-PHONON KSPACE)
pkg_depends(CORESHELL KSPACE)
######################################################
# packages with special compiler needs or external libs
@ -332,7 +333,7 @@ if(PKG_LATTE)
include(ExternalProject)
ExternalProject_Add(latte_build
URL https://github.com/lanl/LATTE/archive/v1.2.1.tar.gz
URL_MD5 bed76e7e76c545c36dd848a8f1fd35eb
URL_MD5 85ac414fdada2d04619c8f936344df14
SOURCE_SUBDIR cmake
CMAKE_ARGS -DCMAKE_INSTALL_PREFIX=<INSTALL_DIR> -DCMAKE_POSITION_INDEPENDENT_CODE=${CMAKE_POSITION_INDEPENDENT_CODE}
)
@ -581,6 +582,41 @@ endif()
# packages which selectively include variants based on enabled styles
# e.g. accelerator packages
######################################################################
if(PKG_CORESHELL)
set(CORESHELL_SOURCES_DIR ${LAMMPS_SOURCE_DIR}/CORESHELL)
set(CORESHELL_SOURCES)
set_property(GLOBAL PROPERTY "CORESHELL_SOURCES" "${CORESHELL_SOURCES}")
# detects styles which have a CORESHELL version
RegisterStylesExt(${CORESHELL_SOURCES_DIR} cs CORESHELL_SOURCES)
get_property(CORESHELL_SOURCES GLOBAL PROPERTY CORESHELL_SOURCES)
list(APPEND LIB_SOURCES ${CORESHELL_SOURCES})
include_directories(${CORESHELL_SOURCES_DIR})
endif()
# Fix qeq/fire requires MANYBODY (i.e. COMB and COMB3) to be installed
if(PKG_QEQ)
set(QEQ_SOURCES_DIR ${LAMMPS_SOURCE_DIR}/QEQ)
file(GLOB QEQ_HEADERS ${QEQ_SOURCES_DIR}/fix*.h)
file(GLOB QEQ_SOURCES ${QEQ_SOURCES_DIR}/fix*.cpp)
if(NOT PKG_MANYBODY)
list(REMOVE_ITEM QEQ_HEADERS ${QEQ_SOURCES_DIR}/fix_qeq_fire.h)
list(REMOVE_ITEM QEQ_SOURCES ${QEQ_SOURCES_DIR}/fix_qeq_fire.cpp)
endif()
set_property(GLOBAL PROPERTY "QEQ_SOURCES" "${QEQ_SOURCES}")
foreach(MY_HEADER ${QEQ_HEADERS})
AddStyleHeader(${MY_HEADER} FIX)
endforeach()
get_property(QEQ_SOURCES GLOBAL PROPERTY QEQ_SOURCES)
list(APPEND LIB_SOURCES ${QEQ_SOURCES})
include_directories(${QEQ_SOURCES_DIR})
endif()
if(PKG_USER-OMP)
set(USER-OMP_SOURCES_DIR ${LAMMPS_SOURCE_DIR}/USER-OMP)
set(USER-OMP_SOURCES ${USER-OMP_SOURCES_DIR}/thr_data.cpp
@ -592,8 +628,27 @@ if(PKG_USER-OMP)
# detects styles which have USER-OMP version
RegisterStylesExt(${USER-OMP_SOURCES_DIR} omp OMP_SOURCES)
get_property(USER-OMP_SOURCES GLOBAL PROPERTY OMP_SOURCES)
# manually add package dependent source files from USER-OMP that do not provide styles
if(PKG_RIGID)
list(APPEND USER-OMP_SOURCES ${USER-OMP_SOURCES_DIR}/fix_rigid_nh_omp.cpp)
endif()
if(PKG_USER-REAXC)
list(APPEND USER-OMP_SOURCES ${USER-OMP_SOURCES_DIR}/reaxc_bond_orders_omp.cpp
${USER-OMP_SOURCES_DIR}/reaxc_hydrogen_bonds_omp.cpp
${USER-OMP_SOURCES_DIR}/reaxc_nonbonded_omp.cpp
${USER-OMP_SOURCES_DIR}/reaxc_bonds_omp.cpp
${USER-OMP_SOURCES_DIR}/reaxc_init_md_omp.cpp
${USER-OMP_SOURCES_DIR}/reaxc_torsion_angles_omp.cpp
${USER-OMP_SOURCES_DIR}/reaxc_forces_omp.cpp
${USER-OMP_SOURCES_DIR}/reaxc_multi_body_omp.cpp
${USER-OMP_SOURCES_DIR}/reaxc_valence_angles_omp.cpp)
endif()
list(APPEND LIB_SOURCES ${USER-OMP_SOURCES})
include_directories(${USER-OMP_SOURCES_DIR})
endif()
@ -907,6 +962,80 @@ if(BUILD_EXE)
endif()
endif()
###############################################################################
# Build documentation
###############################################################################
option(BUILD_DOC "Build LAMMPS documentation" OFF)
if(BUILD_DOC)
include(ProcessorCount)
ProcessorCount(NPROCS)
find_package(PythonInterp 3 REQUIRED)
set(VIRTUALENV ${PYTHON_EXECUTABLE} -m virtualenv)
file(GLOB DOC_SOURCES ${LAMMPS_DOC_DIR}/src/*.txt)
file(GLOB PDF_EXTRA_SOURCES ${LAMMPS_DOC_DIR}/src/lammps_commands*.txt ${LAMMPS_DOC_DIR}/src/lammps_support.txt ${LAMMPS_DOC_DIR}/src/lammps_tutorials.txt)
list(REMOVE_ITEM DOC_SOURCES ${PDF_EXTRA_SOURCES})
add_custom_command(
OUTPUT docenv
COMMAND ${VIRTUALENV} docenv
)
set(DOCENV_BINARY_DIR ${CMAKE_BINARY_DIR}/docenv/bin)
add_custom_command(
OUTPUT requirements.txt
DEPENDS docenv
COMMAND ${CMAKE_COMMAND} -E copy ${LAMMPS_DOC_DIR}/utils/requirements.txt requirements.txt
COMMAND ${DOCENV_BINARY_DIR}/pip install -r requirements.txt --upgrade
COMMAND ${DOCENV_BINARY_DIR}/pip install --upgrade ${LAMMPS_DOC_DIR}/utils/converters
)
set(RST_FILES "")
set(RST_DIR ${CMAKE_BINARY_DIR}/rst)
file(MAKE_DIRECTORY ${RST_DIR})
foreach(TXT_FILE ${DOC_SOURCES})
get_filename_component(FILENAME ${TXT_FILE} NAME_WE)
set(RST_FILE ${RST_DIR}/${FILENAME}.rst)
list(APPEND RST_FILES ${RST_FILE})
add_custom_command(
OUTPUT ${RST_FILE}
DEPENDS requirements.txt docenv ${TXT_FILE}
COMMAND ${DOCENV_BINARY_DIR}/txt2rst -o ${RST_DIR} ${TXT_FILE}
)
endforeach()
add_custom_command(
OUTPUT html
DEPENDS ${RST_FILES}
COMMAND ${CMAKE_COMMAND} -E copy_directory ${LAMMPS_DOC_DIR}/src ${RST_DIR}
COMMAND ${DOCENV_BINARY_DIR}/sphinx-build -j ${NPROCS} -b html -c ${LAMMPS_DOC_DIR}/utils/sphinx-config -d ${CMAKE_BINARY_DIR}/doctrees ${RST_DIR} html
)
add_custom_target(
doc ALL
DEPENDS html
SOURCES ${LAMMPS_DOC_DIR}/utils/requirements.txt ${DOC_SOURCES}
)
install(DIRECTORY ${CMAKE_BINARY_DIR}/html DESTINATION ${CMAKE_INSTALL_DOCDIR})
endif()
###############################################################################
# Install potential files in data directory
###############################################################################
set(LAMMPS_POTENTIALS_DIR ${CMAKE_INSTALL_FULL_DATADIR}/lammps/potentials)
install(DIRECTORY ${LAMMPS_SOURCE_DIR}/../potentials DESTINATION ${CMAKE_INSTALL_DATADIR}/lammps/potentials)
configure_file(etc/profile.d/lammps.sh.in ${CMAKE_BINARY_DIR}/etc/profile.d/lammps.sh @ONLY)
configure_file(etc/profile.d/lammps.csh.in ${CMAKE_BINARY_DIR}/etc/profile.d/lammps.csh @ONLY)
install(
FILES ${CMAKE_BINARY_DIR}/etc/profile.d/lammps.sh
${CMAKE_BINARY_DIR}/etc/profile.d/lammps.csh
DESTINATION ${CMAKE_INSTALL_SYSCONFDIR}/profile.d
)
###############################################################################
# Testing
#

20
cmake/README.md
View File

@ -275,6 +275,16 @@ cmake -C ../cmake/presets/std_nolib.cmake ../cmake -DPKG_GPU=on
</dl>
</td>
</tr>
<tr>
<td><code>BUILD_DOC</code></td>
<td>control whether to build LAMMPS documentation</td>
<td>
<dl>
<dt><code>off</code> (default)</dt>
<dt><code>on</code></dt>
</dl>
</td>
</tr>
<tr>
<td><code>LAMMPS_LONGLONG_TO_LONG</code></td>
<td>Workaround if your system or MPI version does not recognize <code>long long</code> data types</td>
@ -1421,11 +1431,11 @@ target API.
<td>CUDA SM architecture targeted by GPU package</td>
<td>
<dl>
<dt><code>sm20</code> (Fermi)</dt>
<dt><code>sm30</code> (Kepler)</dt>
<dt><code>sm50</code> (Maxwell)</dt>
<dt><code>sm60</code> (Pascal)</dt>
<dt><code>sm70</code> (Volta)</dt>
<dt><code>sm_20</code> (Fermi)</dt>
<dt><code>sm_30</code> (Kepler)</dt>
<dt><code>sm_50</code> (Maxwell)</dt>
<dt><code>sm_60</code> (Pascal)</dt>
<dt><code>sm_70</code> (Volta)</dt>
</dl>
</td>
</tr>

2
cmake/etc/profile.d/lammps.csh.in Normal file
View File

@ -0,0 +1,2 @@
# set environment for LAMMPS executables to find potential files
if ( "$?LAMMPS_POTENTIALS" == 0 ) setenv LAMMPS_POTENTIALS @LAMMPS_POTENTIALS_DIR@

2
cmake/etc/profile.d/lammps.sh.in Normal file
View File

@ -0,0 +1,2 @@
# set environment for LAMMPS executables to find potential files
export LAMMPS_POTENTIALS=${LAMMPS_POTENTIALS-@LAMMPS_POTENTIALS_DIR@}

6
doc/Makefile
View File

@ -49,11 +49,11 @@ help:
# ------------------------------------------
clean-all:
clean-all: clean
rm -rf $(BUILDDIR)/* utils/txt2html/txt2html.exe
clean:
rm -rf $(RSTDIR) html
rm -rf $(RSTDIR) html old epub
rm -rf spelling
clean-spelling:
@ -157,7 +157,7 @@ $(RSTDIR)/%.rst : src/%.txt $(TXT2RST)
@(\
mkdir -p $(RSTDIR) ; \
. $(VENV)/bin/activate ;\
txt2rst $< > $@ ;\
txt2rst -v $< > $@ ;\
deactivate ;\
)

2
doc/src/Developer/developer.tex
View File

@ -476,7 +476,7 @@ is the name of the class. This code allows LAMMPS to find your fix
when it parses input script. In addition, your fix header must be
included in the file "style\_fix.h". In case if you use LAMMPS make,
this file is generated automatically - all files starting with prefix
fix\_ are included, so call your header the same way. Otherwise, don<EFBFBD>t
fix\_ are included, so call your header the same way. Otherwise, don't
forget to add your include into "style\_fix.h".
Let's write a simple fix which will print average velocity at the end

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

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 144 KiB

13
doc/src/Eqs/pair_body_rounded.tex Normal file
View File

@ -0,0 +1,13 @@
\documentstyle[12pt]{article}
\begin{document}
\begin{eqnarray*}
F_n &=& k_n \delta_n - c_n v_n, \qquad \delta_n \le 0 \\
&=& -k_{na} \delta_n - c_n v_n, \qquad 0 < \delta_n \le r_c \\
&=& 0 \qquad \qquad \qquad \qquad \delta_n > r_c \\
F_t &=& \mu k_n \delta_n - c_t v_t, \qquad \delta_n \le 0 \\
&=& 0 \qquad \qquad \qquad \qquad \delta_n > 0
\end{eqnarray*}
\end{document}

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

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 13 KiB

14
doc/src/Eqs/pair_spin_dmi_forces.tex Normal file
View File

@ -0,0 +1,14 @@
\documentclass[preview]{standalone}
\usepackage{varwidth}
\usepackage[utf8x]{inputenc}
\usepackage{amsmath,amssymb,amsthm,bm}
\begin{document}
\begin{varwidth}{50in}
\begin{equation}
\vec{\omega}_i = -\frac{1}{\hbar} \sum_{j}^{Neighb} \vec{s}_{j}\times \left(\vec{e}_{ij}\times \vec{D} \right)
~~{\rm and}~~
\vec{F}_i = -\sum_{j}^{Neighb} \frac{1}{r_{ij}} \vec{D} \times \left( \vec{s}_{i}\times \vec{s}_{j} \right)
, \nonumber
\end{equation}
\end{varwidth}
\end{document}

BIN
doc/src/Eqs/pair_spin_dmi_interaction.jpg
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 6.2 KiB

After

Width:  |  Height:  |  Size: 7.7 KiB

2
doc/src/Eqs/pair_spin_dmi_interaction.tex
View File

@ -5,7 +5,7 @@
\begin{document}
\begin{varwidth}{50in}
\begin{equation}
\bm{H}_{dm} = -\sum_{{ i,j}=1,i\neq j}^{N}
\bm{H}_{dm} = \sum_{{ i,j}=1,i\neq j}^{N}
\left( \vec{e}_{ij} \times \vec{D} \right)
\cdot\left(\vec{s}_{i}\times \vec{s}_{j}\right),
\nonumber

BIN
doc/src/Eqs/pair_spin_exchange_forces.jpg
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 13 KiB

After

Width:  |  Height:  |  Size: 13 KiB

10
doc/src/Eqs/pair_spin_exchange_forces.tex
View File

@ -5,10 +5,12 @@
\begin{document}
\begin{varwidth}{50in}
\begin{equation}
\vec{F}^{i} = \sum_{j}^{Neighbor} \frac{\partial {J} \left(r_{ij} \right)}{
\partial r_{ij}} \left( \vec{s}_{i}\cdot \vec{s}_{j} \right) \vec{r}_{ij}
~~{\rm and}~~ \vec{\omega}^{i} = \frac{1}{\hbar} \sum_{j}^{Neighbor} {J}
\left(r_{ij} \right)\,\vec{s}_{j} \nonumber
\vec{\omega}_{i} = \frac{1}{\hbar} \sum_{j}^{Neighb} {J}
\left(r_{ij} \right)\,\vec{s}_{j}
~~{\rm and}~~
\vec{F}_{i} = \sum_{j}^{Neighb} \frac{\partial {J} \left(r_{ij} \right)}{
\partial r_{ij}} \left( \vec{s}_{i}\cdot \vec{s}_{j} \right) \vec{e}_{ij}
\nonumber
\end{equation}
\end{varwidth}
\end{document}

BIN
doc/src/Eqs/pair_spin_exchange_interaction.jpg
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 6.5 KiB

After

Width:  |  Height:  |  Size: 5.8 KiB

2
doc/src/Eqs/pair_spin_exchange_interaction.tex
View File

@ -5,7 +5,7 @@
\begin{document}
\begin{varwidth}{50in}
\begin{equation}
\bm{H}_{exchange} ~=~ -\sum_{i,j,i\neq j}^{N} {J} \left(r_{ij} \right)\, \vec{s}_{i}\cdot \vec{s}_{j} \nonumber
\bm{H}_{ex} ~=~ -\sum_{i,j,i\neq j}^{N} {J} \left(r_{ij} \right)\, \vec{s}_{i}\cdot \vec{s}_{j} \nonumber
\end{equation}
\end{varwidth}
\end{document}

37
doc/src/Errors.txt Normal file
View File

@ -0,0 +1,37 @@
"Previous Section"_Python.html - "LAMMPS WWW Site"_lws -
"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
Section"_Section_history.html :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
Errors :h2
These doc pages describe the errors you can encounter when using
LAMMPS. The common problems include conceptual issues. The messages
and warnings doc pages give complete lists of all the messages the
code may generate (except those generated by USER packages), with
additional details for many of them.
<!-- RST
.. toctree::
Errors_common
Errors_bugs
Errors_messages
Errors_warnings
END_RST -->
<!-- HTML_ONLY -->
"Common problems"_Errors_common.html
"Reporting bugs"_Errors_bugs.html
"Error messages"_Errors_messages.html
"Warning messages"_Errors_warnings.html :all(b)
<!-- END_HTML_ONLY -->

35
doc/src/Errors_bugs.txt Normal file
View File

@ -0,0 +1,35 @@
"Higher level section"_Errors.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
Reporting bugs :h3
If you are confident that you have found a bug in LAMMPS, follow these
steps.
Check the "New features and bug
fixes"_http://lammps.sandia.gov/bug.html section of the "LAMMPS WWW
site"_lws to see if the bug has already been reported or fixed or the
"Unfixed bug"_http://lammps.sandia.gov/unbug.html to see if a fix is
pending.
Check the "mailing list"_http://lammps.sandia.gov/mail.html to see if
it has been discussed before.
If not, send an email to the mailing list describing the problem with
any ideas you have as to what is causing it or where in the code the
problem might be. The developers will ask for more info if needed,
such as an input script or data files.
The most useful thing you can do to help us fix the bug is to isolate
the problem. Run it on the smallest number of atoms and fewest number
of processors and with the simplest input script that reproduces the
bug and try to identify what command or combination of commands is
causing the problem.
NOTE: this page needs to have GitHub issues info added

123
doc/src/Errors_common.txt Normal file
View File

@ -0,0 +1,123 @@
"Higher level section"_Errors.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
Common problems :h3
If two LAMMPS runs do not produce the exact same answer on different
machines or different numbers of processors, this is typically not a
bug. In theory you should get identical answers on any number of
processors and on any machine. In practice, numerical round-off can
cause slight differences and eventual divergence of molecular dynamics
phase space trajectories within a few 100s or few 1000s of timesteps.
However, the statistical properties of the two runs (e.g. average
energy or temperature) should still be the same.
If the "velocity"_velocity.html command is used to set initial atom
velocities, a particular atom can be assigned a different velocity
when the problem is run on a different number of processors or on
different machines. If this happens, the phase space trajectories of
the two simulations will rapidly diverge. See the discussion of the
{loop} option in the "velocity"_velocity.html command for details and
options that avoid this issue.
Similarly, the "create_atoms"_create_atoms.html command generates a
lattice of atoms. For the same physical system, the ordering and
numbering of atoms by atom ID may be different depending on the number
of processors.
Some commands use random number generators which may be setup to
produce different random number streams on each processor and hence
will produce different effects when run on different numbers of
processors. A commonly-used example is the "fix
langevin"_fix_langevin.html command for thermostatting.
A LAMMPS simulation typically has two stages, setup and run. Most
LAMMPS errors are detected at setup time; others like a bond
stretching too far may not occur until the middle of a run.
LAMMPS tries to flag errors and print informative error messages so
you can fix the problem. For most errors it will also print the last
input script command that it was processing. Of course, LAMMPS cannot
figure out your physics or numerical mistakes, like choosing too big a
timestep, specifying erroneous force field coefficients, or putting 2
atoms on top of each other! If you run into errors that LAMMPS
doesn't catch that you think it should flag, please send an email to
the "developers"_http://lammps.sandia.gov/authors.html.
If you get an error message about an invalid command in your input
script, you can determine what command is causing the problem by
looking in the log.lammps file or using the "echo command"_echo.html
to see it on the screen. If you get an error like "Invalid ...
style", with ... being fix, compute, pair, etc, it means that you
mistyped the style name or that the command is part of an optional
package which was not compiled into your executable. The list of
available styles in your executable can be listed by using "the -h
command-line argument"_Section_start.html#start_6. The installation
and compilation of optional packages is explained in the "installation
instructions"_Section_start.html#start_3.
For a given command, LAMMPS expects certain arguments in a specified
order. If you mess this up, LAMMPS will often flag the error, but it
may also simply read a bogus argument and assign a value that is
valid, but not what you wanted. E.g. trying to read the string "abc"
as an integer value of 0. Careful reading of the associated doc page
for the command should allow you to fix these problems. In most cases,
where LAMMPS expects to read a number, either integer or floating point,
it performs a stringent test on whether the provided input actually
is an integer or floating-point number, respectively, and reject the
input with an error message (for instance, when an integer is required,
but a floating-point number 1.0 is provided):
ERROR: Expected integer parameter in input script or data file :pre
Some commands allow for using variable references in place of numeric
constants so that the value can be evaluated and may change over the
course of a run. This is typically done with the syntax {v_name} for a
parameter, where name is the name of the variable. On the other hand,
immediate variable expansion with the syntax ${name} is performed while
reading the input and before parsing commands,
NOTE: Using a variable reference (i.e. {v_name}) is only allowed if
the documentation of the corresponding command explicitly says it is.
Generally, LAMMPS will print a message to the screen and logfile and
exit gracefully when it encounters a fatal error. Sometimes it will
print a WARNING to the screen and logfile and continue on; you can
decide if the WARNING is important or not. A WARNING message that is
generated in the middle of a run is only printed to the screen, not to
the logfile, to avoid cluttering up thermodynamic output. If LAMMPS
crashes or hangs without spitting out an error message first then it
could be a bug (see "this section"_#err_2) or one of the following
cases:
LAMMPS runs in the available memory a processor allows to be
allocated. Most reasonable MD runs are compute limited, not memory
limited, so this shouldn't be a bottleneck on most platforms. Almost
all large memory allocations in the code are done via C-style malloc's
which will generate an error message if you run out of memory.
Smaller chunks of memory are allocated via C++ "new" statements. If
you are unlucky you could run out of memory just when one of these
small requests is made, in which case the code will crash or hang (in
parallel), since LAMMPS doesn't trap on those errors.
Illegal arithmetic can cause LAMMPS to run slow or crash. This is
typically due to invalid physics and numerics that your simulation is
computing. If you see wild thermodynamic values or NaN values in your
LAMMPS output, something is wrong with your simulation. If you
suspect this is happening, it is a good idea to print out
thermodynamic info frequently (e.g. every timestep) via the
"thermo"_thermo.html so you can monitor what is happening.
Visualizing the atom movement is also a good idea to insure your model
is behaving as you expect.
In parallel, one way LAMMPS can hang is due to how different MPI
implementations handle buffering of messages. If the code hangs
without an error message, it may be that you need to specify an MPI
setting or two (usually via an environment variable) to enable
buffering or boost the sizes of messages that can be buffered.

1097
doc/src/Section_errors.txt → doc/src/Errors_messages.txt
View File

File diff suppressed because it is too large Load Diff

934
doc/src/Errors_warnings.txt Normal file
View File

@ -0,0 +1,934 @@
"Higher level section"_Errors.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
Warning messages :h3
This is an alphabetic list of the WARNING messages LAMMPS prints out
and the reason why. If the explanation here is not sufficient, the
documentation for the offending command may help. Warning messages
also list the source file and line number where the warning was
generated. For example, a message lile this:
WARNING: Bond atom missing in box size check (domain.cpp:187) :pre
means that line #187 in the file src/domain.cpp generated the error.
Looking in the source code may help you figure out what went wrong.
Note that warning messages from "user-contributed
packages"_Packages_user.html are not listed here. If such a warning
occurs and is not self-explanatory, you'll need to look in the source
code or contact the author of the package.
Doc page with "ERROR messages"_Errors_messages.html
:line
:dlb
{Adjusting Coulombic cutoff for MSM, new cutoff = %g} :dt
The adjust/cutoff command is turned on and the Coulombic cutoff has been
adjusted to match the user-specified accuracy. :dd
{Angle atoms missing at step %ld} :dt
One or more of 3 atoms needed to compute a particular angle are
missing on this processor. Typically this is because the pairwise
cutoff is set too short or the angle has blown apart and an atom is
too far away. :dd
{Angle style in data file differs from currently defined angle style} :dt
Self-explanatory. :dd
{Atom style in data file differs from currently defined atom style} :dt
Self-explanatory. :dd
{Bond atom missing in box size check} :dt
The 2nd atoms needed to compute a particular bond is missing on this
processor. Typically this is because the pairwise cutoff is set too
short or the bond has blown apart and an atom is too far away. :dd
{Bond atom missing in image check} :dt
The 2nd atom in a particular bond is missing on this processor.
Typically this is because the pairwise cutoff is set too short or the
bond has blown apart and an atom is too far away. :dd
{Bond atoms missing at step %ld} :dt
The 2nd atom needed to compute a particular bond is missing on this
processor. Typically this is because the pairwise cutoff is set too
short or the bond has blown apart and an atom is too far away. :dd
{Bond style in data file differs from currently defined bond style} :dt
Self-explanatory. :dd
{Bond/angle/dihedral extent > half of periodic box length} :dt
This is a restriction because LAMMPS can be confused about which image
of an atom in the bonded interaction is the correct one to use.
"Extent" in this context means the maximum end-to-end length of the
bond/angle/dihedral. LAMMPS computes this by taking the maximum bond
length, multiplying by the number of bonds in the interaction (e.g. 3
for a dihedral) and adding a small amount of stretch. :dd
{Both groups in compute group/group have a net charge; the Kspace boundary correction to energy will be non-zero} :dt
Self-explanatory. :dd
{Calling write_dump before a full system init.} :dt
The write_dump command is used before the system has been fully
initialized as part of a 'run' or 'minimize' command. Not all dump
styles and features are fully supported at this point and thus the
command may fail or produce incomplete or incorrect output. Insert
a "run 0" command, if a full system init is required. :dd
{Cannot count rigid body degrees-of-freedom before bodies are fully initialized} :dt
This means the temperature associated with the rigid bodies may be
incorrect on this timestep. :dd
{Cannot count rigid body degrees-of-freedom before bodies are initialized} :dt
This means the temperature associated with the rigid bodies may be
incorrect on this timestep. :dd
{Cannot include log terms without 1/r terms; setting flagHI to 1} :dt
Self-explanatory. :dd
{Cannot include log terms without 1/r terms; setting flagHI to 1.} :dt
Self-explanatory. :dd
{Charges are set, but coulombic solver is not used} :dt
Self-explanatory. :dd
{Charges did not converge at step %ld: %lg} :dt
Self-explanatory. :dd
{Communication cutoff is too small for SNAP micro load balancing, increased to %lf} :dt
Self-explanatory. :dd
{Compute cna/atom cutoff may be too large to find ghost atom neighbors} :dt
The neighbor cutoff used may not encompass enough ghost atoms
to perform this operation correctly. :dd
{Computing temperature of portions of rigid bodies} :dt
The group defined by the temperature compute does not encompass all
the atoms in one or more rigid bodies, so the change in
degrees-of-freedom for the atoms in those partial rigid bodies will
not be accounted for. :dd
{Create_bonds max distance > minimum neighbor cutoff} :dt
This means atom pairs for some atom types may not be in the neighbor
list and thus no bond can be created between them. :dd
{Delete_atoms cutoff > minimum neighbor cutoff} :dt
This means atom pairs for some atom types may not be in the neighbor
list and thus an atom in that pair cannot be deleted. :dd
{Dihedral atoms missing at step %ld} :dt
One or more of 4 atoms needed to compute a particular dihedral are
missing on this processor. Typically this is because the pairwise
cutoff is set too short or the dihedral has blown apart and an atom is
too far away. :dd
{Dihedral problem} :dt
Conformation of the 4 listed dihedral atoms is extreme; you may want
to check your simulation geometry. :dd
{Dihedral problem: %d %ld %d %d %d %d} :dt
Conformation of the 4 listed dihedral atoms is extreme; you may want
to check your simulation geometry. :dd
{Dihedral style in data file differs from currently defined dihedral style} :dt
Self-explanatory. :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
reflect the change. :dd
{Energy due to X extra global DOFs will be included in minimizer energies} :dt
When using fixes like box/relax, the potential energy used by the minimizer
is augmented by an additional energy provided by the fix. Thus the printed
converged energy may be different from the total potential energy. :dd
{Energy tally does not account for 'zero yes'} :dt
The energy removed by using the 'zero yes' flag is not accounted
for in the energy tally and thus energy conservation cannot be
monitored in this case. :dd
{Estimated error in splitting of dispersion coeffs is %g} :dt
Error is greater than 0.0001 percent. :dd
{Ewald/disp Newton solver failed, using old method to estimate g_ewald} :dt
Self-explanatory. Choosing a different cutoff value may help. :dd
{FENE bond too long} :dt
A FENE bond has stretched dangerously far. It's interaction strength
will be truncated to attempt to prevent the bond from blowing up. :dd
{FENE bond too long: %ld %d %d %g} :dt
A FENE bond has stretched dangerously far. It's interaction strength
will be truncated to attempt to prevent the bond from blowing up. :dd
{FENE bond too long: %ld %g} :dt
A FENE bond has stretched dangerously far. It's interaction strength
will be truncated to attempt to prevent the bond from blowing up. :dd
{Fix SRD walls overlap but fix srd overlap not set} :dt
You likely want to set this in your input script. :dd
{Fix bond/swap will ignore defined angles} :dt
See the doc page for fix bond/swap for more info on this
restriction. :dd
{Fix deposit near setting < possible overlap separation %g} :dt
This test is performed for finite size particles with a diameter, not
for point particles. The near setting is smaller than the particle
diameter which can lead to overlaps. :dd
{Fix evaporate may delete atom with non-zero molecule ID} :dt
This is probably an error, since you should not delete only one atom
of a molecule. :dd
{Fix gcmc using full_energy option} :dt
Fix gcmc has automatically turned on the full_energy option since it
is required for systems like the one specified by the user. User input
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 property/atom mol or charge w/out ghost communication} :dt
A model typically needs these properties defined for ghost atoms. :dd
{Fix qeq CG convergence failed (%g) after %d iterations at %ld step} :dt
Self-explanatory. :dd
{Fix qeq has non-zero lower Taper radius cutoff} :dt
Absolute value must be <= 0.01. :dd
{Fix qeq has very low Taper radius cutoff} :dt
Value should typically be >= 5.0. :dd
{Fix qeq/dynamic tolerance may be too small for damped dynamics} :dt
Self-explanatory. :dd
{Fix qeq/fire tolerance may be too small for damped fires} :dt
Self-explanatory. :dd
{Fix rattle should come after all other integration fixes} :dt
This fix is designed to work after all other integration fixes change
atom positions. Thus it should be the last integration fix specified.
If not, it will not satisfy the desired constraints as well as it
otherwise would. :dd
{Fix recenter should come after all other integration fixes} :dt
Other fixes may change the position of the center-of-mass, so
fix recenter should come last. :dd
{Fix srd SRD moves may trigger frequent reneighboring} :dt
This is because the SRD particles may move long distances. :dd
{Fix srd grid size > 1/4 of big particle diameter} :dt
This may cause accuracy problems. :dd
{Fix srd particle moved outside valid domain} :dt
This may indicate a problem with your simulation parameters. :dd
{Fix srd particles may move > big particle diameter} :dt
This may cause accuracy problems. :dd
{Fix srd viscosity < 0.0 due to low SRD density} :dt
This may cause accuracy problems. :dd
{Fix thermal/conductivity comes before fix ave/spatial} :dt
The order of these 2 fixes in your input script is such that fix
thermal/conductivity comes first. If you are using fix ave/spatial to
measure the temperature profile induced by fix viscosity, then this
may cause a glitch in the profile since you are averaging immediately
after swaps have occurred. Flipping the order of the 2 fixes
typically helps. :dd
{Fix viscosity comes before fix ave/spatial} :dt
The order of these 2 fixes in your input script is such that
fix viscosity comes first. If you are using fix ave/spatial
to measure the velocity profile induced by fix viscosity, then
this may cause a glitch in the profile since you are averaging
immediately after swaps have occurred. Flipping the order
of the 2 fixes typically helps. :dd
{Fixes cannot send data in Kokkos communication, switching to classic communication} :dt
This is current restriction with Kokkos. :dd
{For better accuracy use 'pair_modify table 0'} :dt
The user-specified force accuracy cannot be achieved unless the table
feature is disabled by using 'pair_modify table 0'. :dd
{Geometric mixing assumed for 1/r^6 coefficients} :dt
Self-explanatory. :dd
{Group for fix_modify temp != fix group} :dt
The fix_modify command is specifying a temperature computation that
computes a temperature on a different group of atoms than the fix
itself operates on. This is probably not what you want to do. :dd
{H matrix size has been exceeded: m_fill=%d H.m=%d\n} :dt
This is the size of the matrix. :dd
{Ignoring unknown or incorrect info command flag} :dt
Self-explanatory. An unknown argument was given to the info command.
Compare your input with the documentation. :dd
{Improper atoms missing at step %ld} :dt
One or more of 4 atoms needed to compute a particular improper are
missing on this processor. Typically this is because the pairwise
cutoff is set too short or the improper has blown apart and an atom is
too far away. :dd
{Improper problem: %d %ld %d %d %d %d} :dt
Conformation of the 4 listed improper atoms is extreme; you may want
to check your simulation geometry. :dd
{Improper style in data file differs from currently defined improper style} :dt
Self-explanatory. :dd
{Inconsistent image flags} :dt
The image flags for a pair on bonded atoms appear to be inconsistent.
Inconsistent means that when the coordinates of the two atoms are
unwrapped using the image flags, the two atoms are far apart.
Specifically they are further apart than half a periodic box length.
Or they are more than a box length apart in a non-periodic dimension.
This is usually due to the initial data file not having correct image
flags for the 2 atoms in a bond that straddles a periodic boundary.
They should be different by 1 in that case. This is a warning because
inconsistent image flags will not cause problems for dynamics or most
LAMMPS simulations. However they can cause problems when such atoms
are used with the fix rigid or replicate commands. Note that if you
have an infinite periodic crystal with bonds then it is impossible to
have fully consistent image flags, since some bonds will cross
periodic boundaries and connect two atoms with the same image
flag. :dd
{KIM Model does not provide 'energy'; Potential energy will be zero} :dt
Self-explanatory. :dd
{KIM Model does not provide 'forces'; Forces will be zero} :dt
Self-explanatory. :dd
{KIM Model does not provide 'particleEnergy'; energy per atom will be zero} :dt
Self-explanatory. :dd
{KIM Model does not provide 'particleVirial'; virial per atom will be zero} :dt
Self-explanatory. :dd
{Kspace_modify slab param < 2.0 may cause unphysical behavior} :dt
The kspace_modify slab parameter should be larger to insure periodic
grids padded with empty space do not overlap. :dd
{Less insertions than requested} :dt
The fix pour command was unsuccessful at finding open space
for as many particles as it tried to insert. :dd
{Library error in lammps_gather_atoms} :dt
This library function cannot be used if atom IDs are not defined
or are not consecutively numbered. :dd
{Library error in lammps_scatter_atoms} :dt
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
{Lost atoms via change_box: original %ld current %ld} :dt
The command options you have used caused atoms to be lost. :dd
{Lost atoms via displace_atoms: original %ld current %ld} :dt
The command options you have used caused atoms to be lost. :dd
{Lost atoms: original %ld current %ld} :dt
Lost atoms are checked for each time thermo output is done. See the
thermo_modify lost command for options. Lost atoms usually indicate
bad dynamics, e.g. atoms have been blown far out of the simulation
box, or moved further than one processor's sub-domain away before
reneighboring. :dd
{MSM mesh too small, increasing to 2 points in each direction} :dt
Self-explanatory. :dd
{Mismatch between velocity and compute groups} :dt
The temperature computation used by the velocity command will not be
on the same group of atoms that velocities are being set for. :dd
{Mixing forced for lj coefficients} :dt
Self-explanatory. :dd
{Molecule attributes do not match system attributes} :dt
An attribute is specified (e.g. diameter, charge) that is
not defined for the specified atom style. :dd
{Molecule has bond topology but no special bond settings} :dt
This means the bonded atoms will not be excluded in pair-wise
interactions. :dd
{Molecule template for create_atoms has multiple molecules} :dt
The create_atoms command will only create molecules of a single type,
i.e. the first molecule in the template. :dd
{Molecule template for fix gcmc has multiple molecules} :dt
The fix gcmc command will only create molecules of a single type,
i.e. the first molecule in the template. :dd
{Molecule template for fix shake has multiple molecules} :dt
The fix shake command will only recognize molecules of a single
type, i.e. the first molecule in the template. :dd
{More than one compute centro/atom} :dt
It is not efficient to use compute centro/atom more than once. :dd
{More than one compute cluster/atom} :dt
It is not efficient to use compute cluster/atom more than once. :dd
{More than one compute cna/atom defined} :dt
It is not efficient to use compute cna/atom more than once. :dd
{More than one compute contact/atom} :dt
It is not efficient to use compute contact/atom more than once. :dd
{More than one compute coord/atom} :dt
It is not efficient to use compute coord/atom more than once. :dd
{More than one compute damage/atom} :dt
It is not efficient to use compute ke/atom more than once. :dd
{More than one compute dilatation/atom} :dt
Self-explanatory. :dd
{More than one compute erotate/sphere/atom} :dt
It is not efficient to use compute erorate/sphere/atom more than once. :dd
{More than one compute hexorder/atom} :dt
It is not efficient to use compute hexorder/atom more than once. :dd
{More than one compute ke/atom} :dt
It is not efficient to use compute ke/atom more than once. :dd
{More than one compute orientorder/atom} :dt
It is not efficient to use compute orientorder/atom more than once. :dd
{More than one compute plasticity/atom} :dt
Self-explanatory. :dd
{More than one compute sna/atom} :dt
Self-explanatory. :dd
{More than one compute snad/atom} :dt
Self-explanatory. :dd
{More than one compute snav/atom} :dt
Self-explanatory. :dd
{More than one fix poems} :dt
It is not efficient to use fix poems more than once. :dd
{More than one fix rigid} :dt
It is not efficient to use fix rigid more than once. :dd
{Neighbor exclusions used with KSpace solver may give inconsistent Coulombic energies} :dt
This is because excluding specific pair interactions also excludes
them from long-range interactions which may not be the desired effect.
The special_bonds command handles this consistently by insuring
excluded (or weighted) 1-2, 1-3, 1-4 interactions are treated
consistently by both the short-range pair style and the long-range
solver. This is not done for exclusions of charged atom pairs via the
neigh_modify exclude command. :dd
{New thermo_style command, previous thermo_modify settings will be lost} :dt
If a thermo_style command is used after a thermo_modify command, the
settings changed by the thermo_modify command will be reset to their
default values. This is because the thermo_modify command acts on
the currently defined thermo style, and a thermo_style command creates
a new style. :dd
{No Kspace calculation with verlet/split} :dt
The 2nd partition performs a kspace calculation so the kspace_style
command must be used. :dd
{No automatic unit conversion to XTC file format conventions possible for units lj} :dt
This means no scaling will be performed. :dd
{No fixes defined, atoms won't move} :dt
If you are not using a fix like nve, nvt, npt then atom velocities and
coordinates will not be updated during timestepping. :dd
{No joints between rigid bodies, use fix rigid instead} :dt
The bodies defined by fix poems are not connected by joints. POEMS
will integrate the body motion, but it would be more efficient to use
fix rigid. :dd
{Not using real units with pair reax} :dt
This is most likely an error, unless you have created your own ReaxFF
parameter file in a different set of units. :dd
{Number of MSM mesh points changed to be a multiple of 2} :dt
MSM requires that the number of grid points in each direction be a multiple
of two and the number of grid points in one or more directions have been
adjusted to meet this requirement. :dd
{OMP_NUM_THREADS environment is not set.} :dt
This environment variable must be set appropriately to use the
USER-OMP package. :dd
{One or more atoms are time integrated more than once} :dt
This is probably an error since you typically do not want to
advance the positions or velocities of an atom more than once
per timestep. :dd
{One or more chunks do not contain all atoms in molecule} :dt
This may not be what you intended. :dd
{One or more dynamic groups may not be updated at correct point in timestep} :dt
If there are other fixes that act immediately after the initial stage
of time integration within a timestep (i.e. after atoms move), then
the command that sets up the dynamic group should appear after those
fixes. This will insure that dynamic group assignments are made
after all atoms have moved. :dd
{One or more respa levels compute no forces} :dt
This is computationally inefficient. :dd
{Pair COMB charge %.10f with force %.10f hit max barrier} :dt
Something is possibly wrong with your model. :dd
{Pair COMB charge %.10f with force %.10f hit min barrier} :dt
Something is possibly wrong with your model. :dd
{Pair brownian needs newton pair on for momentum conservation} :dt
Self-explanatory. :dd
{Pair dpd needs newton pair on for momentum conservation} :dt
Self-explanatory. :dd
{Pair dsmc: num_of_collisions > number_of_A} :dt
Collision model in DSMC is breaking down. :dd
{Pair dsmc: num_of_collisions > number_of_B} :dt
Collision model in DSMC is breaking down. :dd
{Pair style in data file differs from currently defined pair style} :dt
Self-explanatory. :dd
{Pair style restartinfo set but has no restart support} :dt
This pair style has a bug, where it does not support reading and
writing information to a restart file, but does not set the member
variable "restartinfo" to 0 as required in that case. :dd
{Particle deposition was unsuccessful} :dt
The fix deposit command was not able to insert as many atoms as
needed. The requested volume fraction may be too high, or other atoms
may be in the insertion region. :dd
{Proc sub-domain size < neighbor skin, could lead to lost atoms} :dt
The decomposition of the physical domain (likely due to load
balancing) has led to a processor's sub-domain being smaller than the
neighbor skin in one or more dimensions. Since reneighboring is
triggered by atoms moving the skin distance, this may lead to lost
atoms, if an atom moves all the way across a neighboring processor's
sub-domain before reneighboring is triggered. :dd
{Reducing PPPM order b/c stencil extends beyond nearest neighbor processor} :dt
This may lead to a larger grid than desired. See the kspace_modify overlap
command to prevent changing of the PPPM order. :dd
{Reducing PPPMDisp Coulomb order b/c stencil extends beyond neighbor processor} :dt
This may lead to a larger grid than desired. See the kspace_modify overlap
command to prevent changing of the PPPM order. :dd
{Reducing PPPMDisp dispersion order b/c stencil extends beyond neighbor processor} :dt
This may lead to a larger grid than desired. See the kspace_modify overlap
command to prevent changing of the PPPM order. :dd
{Replacing a fix, but new group != old group} :dt
The ID and style of a fix match for a fix you are changing with a fix
command, but the new group you are specifying does not match the old
group. :dd
{Replicating in a non-periodic dimension} :dt
The parameters for a replicate command will cause a non-periodic
dimension to be replicated; this may cause unwanted behavior. :dd
{Resetting reneighboring criteria during PRD} :dt
A PRD simulation requires that neigh_modify settings be delay = 0,
every = 1, check = yes. Since these settings were not in place,
LAMMPS changed them and will restore them to their original values
after the PRD simulation. :dd
{Resetting reneighboring criteria during TAD} :dt
A TAD simulation requires that neigh_modify settings be delay = 0,
every = 1, check = yes. Since these settings were not in place,
LAMMPS changed them and will restore them to their original values
after the PRD simulation. :dd
{Resetting reneighboring criteria during minimization} :dt
Minimization requires that neigh_modify settings be delay = 0, every =
1, check = yes. Since these settings were not in place, LAMMPS
changed them and will restore them to their original values after the
minimization. :dd
{Restart file used different # of processors} :dt
The restart file was written out by a LAMMPS simulation running on a
different number of processors. Due to round-off, the trajectories of
your restarted simulation may diverge a little more quickly than if
you ran on the same # of processors. :dd
{Restart file used different 3d processor grid} :dt
The restart file was written out by a LAMMPS simulation running on a
different 3d grid of processors. Due to round-off, the trajectories
of your restarted simulation may diverge a little more quickly than if
you ran on the same # of processors. :dd
{Restart file used different boundary settings, using restart file values} :dt
Your input script cannot change these restart file settings. :dd
{Restart file used different newton bond setting, using restart file value} :dt
The restart file value will override the setting in the input script. :dd
{Restart file used different newton pair setting, using input script value} :dt
The input script value will override the setting in the restart file. :dd
{Restrain problem: %d %ld %d %d %d %d} :dt
Conformation of the 4 listed dihedral atoms is extreme; you may want
to check your simulation geometry. :dd
{Running PRD with only one replica} :dt
This is allowed, but you will get no parallel speed-up. :dd
{SRD bin shifting turned on due to small lamda} :dt
This is done to try to preserve accuracy. :dd
{SRD bin size for fix srd differs from user request} :dt
Fix SRD had to adjust the bin size to fit the simulation box. See the
cubic keyword if you want this message to be an error vs warning. :dd
{SRD bins for fix srd are not cubic enough} :dt
The bin shape is not within tolerance of cubic. See the cubic
keyword if you want this message to be an error vs warning. :dd
{SRD particle %d started inside big particle %d on step %ld bounce %d} :dt
See the inside keyword if you want this message to be an error vs
warning. :dd
{SRD particle %d started inside wall %d on step %ld bounce %d} :dt
See the inside keyword if you want this message to be an error vs
warning. :dd
{Shake determinant < 0.0} :dt
The determinant of the quadratic equation being solved for a single
cluster specified by the fix shake command is numerically suspect. LAMMPS
will set it to 0.0 and continue. :dd
{Shell command '%s' failed with error '%s'} :dt
Self-explanatory. :dd
{Shell command returned with non-zero status} :dt
This may indicate the shell command did not operate as expected. :dd
{Should not allow rigid bodies to bounce off relecting walls} :dt
LAMMPS allows this, but their dynamics are not computed correctly. :dd
{Should not use fix nve/limit with fix shake or fix rattle} :dt
This will lead to invalid constraint forces in the SHAKE/RATTLE
computation. :dd
{Simulations might be very slow because of large number of structure factors} :dt
Self-explanatory. :dd
{Slab correction not needed for MSM} :dt
Slab correction is intended to be used with Ewald or PPPM and is not needed by MSM. :dd
{System is not charge neutral, net charge = %g} :dt
The total charge on all atoms on the system is not 0.0.
For some KSpace solvers this is only a warning. :dd
{Table inner cutoff >= outer cutoff} :dt
You specified an inner cutoff for a Coulombic table that is longer
than the global cutoff. Probably not what you wanted. :dd
{Temperature for MSST is not for group all} :dt
User-assigned temperature to MSST fix does not compute temperature for
all atoms. Since MSST computes a global pressure, the kinetic energy
contribution from the temperature is assumed to also be for all atoms.
Thus the pressure used by MSST could be inaccurate. :dd
{Temperature for NPT is not for group all} :dt
User-assigned temperature to NPT fix does not compute temperature for
all atoms. Since NPT computes a global pressure, the kinetic energy
contribution from the temperature is assumed to also be for all atoms.
Thus the pressure used by NPT could be inaccurate. :dd
{Temperature for fix modify is not for group all} :dt
The temperature compute is being used with a pressure calculation
which does operate on group all, so this may be inconsistent. :dd
{Temperature for thermo pressure is not for group all} :dt
User-assigned temperature to thermo via the thermo_modify command does
not compute temperature for all atoms. Since thermo computes a global
pressure, the kinetic energy contribution from the temperature is
assumed to also be for all atoms. Thus the pressure printed by thermo
could be inaccurate. :dd
{The fix ave/spatial command has been replaced by the more flexible fix ave/chunk and compute chunk/atom commands -- fix ave/spatial will be removed in the summer of 2015} :dt
Self-explanatory. :dd
{The minimizer does not re-orient dipoles when using fix efield} :dt
This means that only the atom coordinates will be minimized,
not the orientation of the dipoles. :dd
{Too many common neighbors in CNA %d times} :dt
More than the maximum # of neighbors was found multiple times. This
was unexpected. :dd
{Too many inner timesteps in fix ttm} :dt
Self-explanatory. :dd
{Too many neighbors in CNA for %d atoms} :dt
More than the maximum # of neighbors was found multiple times. This
was unexpected. :dd
{Triclinic box skew is large} :dt
The displacement in a skewed direction is normally required to be less
than half the box length in that dimension. E.g. the xy tilt must be
between -half and +half of the x box length. You have relaxed the
constraint using the box tilt command, but the warning means that a
LAMMPS simulation may be inefficient as a result. :dd
{Use special bonds = 0,1,1 with bond style fene} :dt
Most FENE models need this setting for the special_bonds command. :dd
{Use special bonds = 0,1,1 with bond style fene/expand} :dt
Most FENE models need this setting for the special_bonds command. :dd
{Using a manybody potential with bonds/angles/dihedrals and special_bond exclusions} :dt
This is likely not what you want to do. The exclusion settings will
eliminate neighbors in the neighbor list, which the manybody potential
needs to calculated its terms correctly. :dd
{Using compute temp/deform with inconsistent fix deform remap option} :dt
Fix nvt/sllod assumes deforming atoms have a velocity profile provided
by "remap v" or "remap none" as a fix deform option. :dd
{Using compute temp/deform with no fix deform defined} :dt
This is probably an error, since it makes little sense to use
compute temp/deform in this case. :dd
{Using fix srd with box deformation but no SRD thermostat} :dt
The deformation will heat the SRD particles so this can
be dangerous. :dd
{Using kspace solver on system with no charge} :dt
Self-explanatory. :dd
{Using largest cut-off for lj/long/dipole/long long long} :dt
Self-explanatory. :dd
{Using largest cutoff for buck/long/coul/long} :dt
Self-explanatory. :dd
{Using largest cutoff for lj/long/coul/long} :dt
Self-explanatory. :dd
{Using largest cutoff for pair_style lj/long/tip4p/long} :dt
Self-explanatory. :dd
{Using package gpu without any pair style defined} :dt
Self-explanatory. :dd
{Using pair potential shift with pair_modify compute no} :dt
The shift effects will thus not be computed. :dd
{Using pair tail corrections with nonperiodic system} :dt
This is probably a bogus thing to do, since tail corrections are
computed by integrating the density of a periodic system out to
infinity. :dd
{Using pair tail corrections with pair_modify compute no} :dt
The tail corrections will thus not be computed. :dd
{pair style reax is now deprecated and will soon be retired. Users should switch to pair_style reax/c} :dt
Self-explanatory. :dd
:dle

12
doc/src/Section_example.txt → doc/src/Examples.txt
View File

@ -1,4 +1,6 @@
"Previous Section"_Section_howto.html - "LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next Section"_Section_perf.html :c
"Previous Section"_Section_howto.html - "LAMMPS WWW Site"_lws -
"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
Section"_Section_perf.html :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
@ -6,7 +8,7 @@
:line
7. Example problems :h2
Example scripts :h3
The LAMMPS distribution includes an examples sub-directory with many
sample problems. Many are 2d models that run quickly are are
@ -46,7 +48,7 @@ Lists of both kinds of directories are given below.
:line
Lowercase directories :h3
Lowercase directories :h4
accelerate: run with various acceleration options (OpenMP, GPU, Phi)
airebo: polyethylene with AIREBO potential
@ -122,7 +124,7 @@ browser.
:line
Uppercase directories :h3
Uppercase directories :h4
ASPHERE: various aspherical particle models, using ellipsoids, rigid bodies, line/triangle particles, etc
COUPLE: examples of how to use LAMMPS as a library
@ -141,5 +143,5 @@ The USER directory has a large number of sub-directories which
correspond by name to a USER package. They contain scripts that
illustrate how to use the command(s) provided in that package. Many
of the sub-directories have their own README files which give further
instructions. See the "Section 4"_Section_packages.html doc
instructions. See the "Packages_details"_Packages_details.html doc
page for more info on specific USER packages.

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

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 35 KiB

108
doc/src/Manual.txt
View File

@ -1,7 +1,7 @@
<!-- HTML_ONLY -->
<HEAD>
<
<TITLE>LAMMPS Users Manual</TITLE>
<META NAME="docnumber" CONTENT="29 Jun 2018 version">
<META NAME="docnumber" CONTENT="2 Aug 2018 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>
@ -19,7 +19,7 @@
:line
LAMMPS Documentation :c,h1
29 Jun 2018 version :c,h2
2 Aug 2018 version :c,h2
Version info: :h3
@ -111,15 +111,14 @@ it gives quick access to documentation for all LAMMPS commands.
Section_intro
Section_start
Section_commands
Section_packages
Section_accelerate
Packages
Speed
Section_howto
Section_example
Section_perf
Section_tools
Section_modify
Section_python
Section_errors
Examples
Tools
Modify
Python
Errors
Section_history
.. toctree::
@ -167,19 +166,8 @@ END_RST -->
3.3 "Input script structure"_cmd_3 :b
3.4 "Commands listed by category"_cmd_4 :b
3.5 "Commands listed alphabetically"_cmd_5 :ule,b
"Packages"_Section_packages.html :l
4.1 "Standard packages"_pkg_1 :ulb,b
4.2 "User packages"_pkg_2 :ule,b
"Accelerating LAMMPS performance"_Section_accelerate.html :l
5.1 "Measuring performance"_acc_1 :ulb,b
5.2 "Algorithms and code options to boost performace"_acc_2 :b
5.3 "Accelerator packages with optimized styles"_acc_3 :b
5.3.1 "GPU package"_accelerate_gpu.html :b
5.3.2 "USER-INTEL package"_accelerate_intel.html :b
5.3.3 "KOKKOS package"_accelerate_kokkos.html :b
5.3.4 "USER-OMP package"_accelerate_omp.html :b
5.3.5 "OPT package"_accelerate_opt.html :b
5.4 "Comparison of various accelerator packages"_acc_4 :ule,b
"Optional packages"_Packages.html :l
"Accelerate performance"_Speed.html :l
"How-to discussions"_Section_howto.html :l
6.1 "Restarting a simulation"_howto_1 :ulb,b
6.2 "2d simulations"_howto_2 :b
@ -208,38 +196,11 @@ END_RST -->
6.25 "Polarizable models"_howto_25 :b
6.26 "Adiabatic core/shell model"_howto_26 :b
6.27 "Drude induced dipoles"_howto_27 :ule,b
"Example problems"_Section_example.html :l
"Performance & scalability"_Section_perf.html :l
"Additional tools"_Section_tools.html :l
"Modifying & extending LAMMPS"_Section_modify.html :l
10.1 "Atom styles"_mod_1 :ulb,b
10.2 "Bond, angle, dihedral, improper potentials"_mod_2 :b
10.3 "Compute styles"_mod_3 :b
10.4 "Dump styles"_mod_4 :b
10.5 "Dump custom output options"_mod_5 :b
10.6 "Fix styles"_mod_6 :b
10.7 "Input script commands"_mod_7 :b
10.8 "Kspace computations"_mod_8 :b
10.9 "Minimization styles"_mod_9 :b
10.10 "Pairwise potentials"_mod_10 :b
10.11 "Region styles"_mod_11 :b
10.12 "Body styles"_mod_12 :b
10.13 "Thermodynamic output options"_mod_13 :b
10.14 "Variable options"_mod_14 :b
10.15 "Submitting new features for inclusion in LAMMPS"_mod_15 :ule,b
"Python interface"_Section_python.html :l
11.1 "Overview of running LAMMPS from Python"_py_1 :ulb,b
11.2 "Overview of using Python from a LAMMPS script"_py_2 :b
11.3 "Building LAMMPS as a shared library"_py_3 :b
11.4 "Installing the Python wrapper into Python"_py_4 :b
11.5 "Extending Python with MPI to run in parallel"_py_5 :b
11.6 "Testing the Python-LAMMPS interface"_py_6 :b
11.7 "Using LAMMPS from Python"_py_7 :b
11.8 "Example Python scripts that use LAMMPS"_py_8 :ule,b
"Errors"_Section_errors.html :l
12.1 "Common problems"_err_1 :ulb,b
12.2 "Reporting bugs"_err_2 :b
12.3 "Error & warning messages"_err_3 :ule,b
"Example scripts"_Examples.html :l
"Auxiliary tools"_Tools.html :l
"Modify & extend LAMMPS"_Modify.html :l
"Use Python with LAMMPS"_Python.html :l
"Errors"_Errors.html :l
"Future and history"_Section_history.html :l
13.1 "Coming attractions"_hist_1 :ulb,b
13.2 "Past versions"_hist_2 :ule,b
@ -266,14 +227,6 @@ END_RST -->
:link(cmd_4,Section_commands.html#cmd_4)
:link(cmd_5,Section_commands.html#cmd_5)
:link(pkg_1,Section_packages.html#pkg_1)
:link(pkg_2,Section_packages.html#pkg_2)
:link(acc_1,Section_accelerate.html#acc_1)
:link(acc_2,Section_accelerate.html#acc_2)
:link(acc_3,Section_accelerate.html#acc_3)
:link(acc_4,Section_accelerate.html#acc_4)
:link(howto_1,Section_howto.html#howto_1)
:link(howto_2,Section_howto.html#howto_2)
:link(howto_3,Section_howto.html#howto_3)
@ -302,33 +255,6 @@ END_RST -->
:link(howto_26,Section_howto.html#howto_26)
:link(howto_27,Section_howto.html#howto_27)
:link(mod_1,Section_modify.html#mod_1)
:link(mod_2,Section_modify.html#mod_2)
:link(mod_3,Section_modify.html#mod_3)
:link(mod_4,Section_modify.html#mod_4)
:link(mod_5,Section_modify.html#mod_5)
:link(mod_6,Section_modify.html#mod_6)
:link(mod_7,Section_modify.html#mod_7)
:link(mod_8,Section_modify.html#mod_8)
:link(mod_9,Section_modify.html#mod_9)
:link(mod_10,Section_modify.html#mod_10)
:link(mod_11,Section_modify.html#mod_11)
:link(mod_12,Section_modify.html#mod_12)
:link(mod_13,Section_modify.html#mod_13)
:link(mod_14,Section_modify.html#mod_14)
:link(mod_15,Section_modify.html#mod_15)
:link(py_1,Section_python.html#py_1)
:link(py_2,Section_python.html#py_2)
:link(py_3,Section_python.html#py_3)
:link(py_4,Section_python.html#py_4)
:link(py_5,Section_python.html#py_5)
:link(py_6,Section_python.html#py_6)
:link(err_1,Section_errors.html#err_1)
:link(err_2,Section_errors.html#err_2)
:link(err_3,Section_errors.html#err_3)
:link(hist_1,Section_history.html#hist_1)
:link(hist_2,Section_history.html#hist_2)
<!-- END_HTML_ONLY -->

76
doc/src/Modify.txt Normal file
View File

@ -0,0 +1,76 @@
"Previous Section"_Tools.html - "LAMMPS WWW Site"_lws -
"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
Section"_Python.html :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
Modify & extend LAMMPS :h2
LAMMPS is designed in a modular fashion so as to be easy to modify and
extend with new functionality. In fact, about 95% of its source code
is add-on files. These doc pages give basic instructions on how to do
this.
If you add a new feature to LAMMPS and think it will be of interest to
general users, we encourage you to submit it for inclusion in LAMMPS
as a pull request on our "GitHub
site"_https://github.com/lammps/lammps, after reading the "Modify
contribute"_Modify_contribute.html doc page.
<!-- RST
.. toctree::
Modify_overview
Modify_contribute
.. toctree::
Modify_atom
Modify_pair
Modify_bond
Modify_compute
Modify_fix
Modify_command
.. toctree::
Modify_dump
Modify_kspace
Modify_min
Modify_region
Modify_body
.. toctree::
Modify_thermo
Modify_variable
END_RST -->
<!-- HTML_ONLY -->
"Overview"_Modify_overview.html
"Submitting new features for inclusion in LAMMPS"_Modify_contribute.html :all(b)
"Atom styles"_Modify_atom.html
"Pair styles"_Modify_pair.html
"Bond, angle, dihedral, improper styles"_Modify_bond.html
"Compute styles"_Modify_compute.html
"Fix styles"_Modify_fix.html
"Input script command styles"_Modify_command.html :all(b)
"Dump styles"_Modify_dump.html
"Kspace styles"_Modify_kspace.html
"Minimization styles"_Modify_min.html
"Region styles"_Modify_region.html
"Body styles"_Modify_body.html :all(b)
"Thermodynamic output options"_Modify_thermo.html
"Variable options"_Modify_variable.html :all(b)
<!-- END_HTML_ONLY -->

90
doc/src/Modify_atom.txt Normal file
View File

@ -0,0 +1,90 @@
"Higher level section"_Modify.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
Atom styles :h3
Classes that define an "atom style"_atom_style.html are derived from
the AtomVec class and managed by the Atom class. The atom style
determines what attributes are associated with an atom. A new atom
style can be created if one of the existing atom styles does not
define all the attributes you need to store and communicate with
atoms.
Atom_vec_atomic.cpp is a simple example of an atom style.
Here is a brief description of methods you define in your new derived
class. See atom_vec.h for details.
init: one time setup (optional)
grow: re-allocate atom arrays to longer lengths (required)
grow_reset: make array pointers in Atom and AtomVec classes consistent (required)
copy: copy info for one atom to another atom's array locations (required)
pack_comm: store an atom's info in a buffer communicated every timestep (required)
pack_comm_vel: add velocity info to communication buffer (required)
pack_comm_hybrid: store extra info unique to this atom style (optional)
unpack_comm: retrieve an atom's info from the buffer (required)
unpack_comm_vel: also retrieve velocity info (required)
unpack_comm_hybrid: retrieve extra info unique to this atom style (optional)
pack_reverse: store an atom's info in a buffer communicating partial forces (required)
pack_reverse_hybrid: store extra info unique to this atom style (optional)
unpack_reverse: retrieve an atom's info from the buffer (required)
unpack_reverse_hybrid: retrieve extra info unique to this atom style (optional)
pack_border: store an atom's info in a buffer communicated on neighbor re-builds (required)
pack_border_vel: add velocity info to buffer (required)
pack_border_hybrid: store extra info unique to this atom style (optional)
unpack_border: retrieve an atom's info from the buffer (required)
unpack_border_vel: also retrieve velocity info (required)
unpack_border_hybrid: retrieve extra info unique to this atom style (optional)
pack_exchange: store all an atom's info to migrate to another processor (required)
unpack_exchange: retrieve an atom's info from the buffer (required)
size_restart: number of restart quantities associated with proc's atoms (required)
pack_restart: pack atom quantities into a buffer (required)
unpack_restart: unpack atom quantities from a buffer (required)
create_atom: create an individual atom of this style (required)
data_atom: parse an atom line from the data file (required)
data_atom_hybrid: parse additional atom info unique to this atom style (optional)
data_vel: parse one line of velocity information from data file (optional)
data_vel_hybrid: parse additional velocity data unique to this atom style (optional)
memory_usage: tally memory allocated by atom arrays (required) :tb(s=:)
The constructor of the derived class sets values for several variables
that you must set when defining a new atom style, which are documented
in atom_vec.h. New atom arrays are defined in atom.cpp. Search for
the word "customize" and you will find locations you will need to
modify.
NOTE: It is possible to add some attributes, such as a molecule ID, to
atom styles that do not have them via the "fix
property/atom"_fix_property_atom.html command. This command also
allows new custom attributes consisting of extra integer or
floating-point values to be added to atoms. See the "fix
property/atom"_fix_property_atom.html doc page for examples of cases
where this is useful and details on how to initialize, access, and
output the custom values.
New "pair styles"_pair_style.html, "fixes"_fix.html, or
"computes"_compute.html can be added to LAMMPS, as discussed below.
The code for these classes can use the per-atom properties defined by
fix property/atom. The Atom class has a find_custom() method that is
useful in this context:
int index = atom->find_custom(char *name, int &flag); :pre
The "name" of a custom attribute, as specified in the "fix
property/atom"_fix_property_atom.html command, is checked to verify
that it exists and its index is returned. The method also sets flag =
0/1 depending on whether it is an integer or floating-point attribute.
The vector of values associated with the attribute can then be
accessed using the returned index as
int *ivector = atom->ivector\[index\];
double *dvector = atom->dvector\[index\]; :pre
Ivector or dvector are vectors of length Nlocal = # of owned atoms,
which store the attributes of individual atoms.

35
doc/src/Modify_body.txt Normal file
View File

@ -0,0 +1,35 @@
"Higher level section"_Modify.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
Body styles :h3
Classes that define body particles are derived from the Body class.
Body particles can represent complex entities, such as surface meshes
of discrete points, collections of sub-particles, deformable objects,
etc.
See "Section 6.14"_Section_howto.html#howto_14 of the manual for
an overview of using body particles and the "body"_body.html doc page
for details on the various body styles LAMMPS supports. New styles
can be created to add new kinds of body particles to LAMMPS.
Body_nparticle.cpp is an example of a body particle that is treated as
a rigid body containing N sub-particles.
Here is a brief description of methods you define in your new derived
class. See body.h for details.
data_body: process a line from the Bodies section of a data file
noutrow: number of sub-particles output is generated for
noutcol: number of values per-sub-particle output is generated for
output: output values for the Mth sub-particle
pack_comm_body: body attributes to communicate every timestep
unpack_comm_body: unpacking of those attributes
pack_border_body: body attributes to communicate when reneighboring is done
unpack_border_body: unpacking of those attributes :tb(s=:)

33
doc/src/Modify_bond.txt Normal file
View File

@ -0,0 +1,33 @@
"Higher level section"_Modify.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
Bond, angle, dihedral, improper styles :h3
Classes that compute molecular interactions are derived from the Bond,
Angle, Dihedral, and Improper classes. New styles can be created to
add new potentials to LAMMPS.
Bond_harmonic.cpp is the simplest example of a bond style. Ditto for
the harmonic forms of the angle, dihedral, and improper style
commands.
Here is a brief description of common methods you define in your
new derived class. See bond.h, angle.h, dihedral.h, and improper.h
for details and specific additional methods.
init: check if all coefficients are set, calls {init_style} (optional)
init_style: check if style specific conditions are met (optional)
compute: compute the molecular interactions (required)
settings: apply global settings for all types (optional)
coeff: set coefficients for one type (required)
equilibrium_distance: length of bond, used by SHAKE (required, bond only)
equilibrium_angle: opening of angle, used by SHAKE (required, angle only)
write & read_restart: writes/reads coeffs to restart files (required)
single: force and energy of a single bond or angle (required, bond or angle only)
memory_usage: tally memory allocated by the style (optional) :tb(s=:)

27
doc/src/Modify_command.txt Normal file
View File

@ -0,0 +1,27 @@
"Higher level section"_Modify.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
Input script command style :h3
New commands can be added to LAMMPS input scripts by adding new
classes that have a "command" method. For example, the create_atoms,
read_data, velocity, and run commands are all implemented in this
fashion. When such a command is encountered in the LAMMPS input
script, LAMMPS simply creates a class with the corresponding name,
invokes the "command" method of the class, and passes it the arguments
from the input script. The command method can perform whatever
operations it wishes on LAMMPS data structures.
The single method your new class must define is as follows:
command: operations performed by the new command :tb(s=:)
Of course, the new class can define other methods and variables as
needed.

49
doc/src/Modify_compute.txt Normal file
View File

@ -0,0 +1,49 @@
"Higher level section"_Modify.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
Compute styles :h3
Classes that compute scalar and vector quantities like temperature
and the pressure tensor, as well as classes that compute per-atom
quantities like kinetic energy and the centro-symmetry parameter
are derived from the Compute class. New styles can be created
to add new calculations to LAMMPS.
Compute_temp.cpp is a simple example of computing a scalar
temperature. Compute_ke_atom.cpp is a simple example of computing
per-atom kinetic energy.
Here is a brief description of methods you define in your new derived
class. See compute.h for details.
init: perform one time setup (required)
init_list: neighbor list setup, if needed (optional)
compute_scalar: compute a scalar quantity (optional)
compute_vector: compute a vector of quantities (optional)
compute_peratom: compute one or more quantities per atom (optional)
compute_local: compute one or more quantities per processor (optional)
pack_comm: pack a buffer with items to communicate (optional)
unpack_comm: unpack the buffer (optional)
pack_reverse: pack a buffer with items to reverse communicate (optional)
unpack_reverse: unpack the buffer (optional)
remove_bias: remove velocity bias from one atom (optional)
remove_bias_all: remove velocity bias from all atoms in group (optional)
restore_bias: restore velocity bias for one atom after remove_bias (optional)
restore_bias_all: same as before, but for all atoms in group (optional)
pair_tally_callback: callback function for {tally}-style computes (optional).
memory_usage: tally memory usage (optional) :tb(s=:)
Tally-style computes are a special case, as their computation is done
in two stages: the callback function is registered with the pair style
and then called from the Pair::ev_tally() function, which is called for
each pair after force and energy has been computed for this pair. Then
the tallied values are retrieved with the standard compute_scalar or
compute_vector or compute_peratom methods. The USER-TALLY package
provides {examples}_compute_tally.html for utilizing this mechanism.

210
doc/src/Modify_contribute.txt Normal file
View File

@ -0,0 +1,210 @@
"Higher level section"_Modify.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
Submitting new features for inclusion in LAMMPS :h3
We encourage users to submit new features or modifications for LAMMPS
to "the core developers"_http://lammps.sandia.gov/authors.html so they
can be added to the LAMMPS distribution. The preferred way to manage
and coordinate this is as of Fall 2016 via the LAMMPS project on
"GitHub"_https://github.com/lammps/lammps. An alternative is to
contact the LAMMPS developers or the indicated developer of a package
or feature directly and send in your contribution via e-mail.
For any larger modifications or programming project, you are
encouraged to contact the LAMMPS developers ahead of time, in order to
discuss implementation strategies and coding guidelines, that will
make it easier to integrate your contribution and result in less work
for everybody involved. You are also encouraged to search through the
list of "open issues on
GitHub"_https://github.com/lammps/lammps/issues and submit a new issue
for a planned feature, so you would not duplicate the work of others
(and possibly get scooped by them) or have your work duplicated by
others.
How quickly your contribution will be integrated depends largely on
how much effort it will cause to integrate and test it, how much it
requires changes to the core codebase, and of how much interest it is
to the larger LAMMPS community. Please see below for a checklist of
typical requirements. Once you have prepared everything, see "this
tutorial"_tutorial_github.html for instructions on how to submit your
changes or new files through a GitHub pull request. If you prefer to
submit patches or full files, you should first make certain, that your
code works correctly with the latest patch-level version of LAMMPS and
contains all bugfixes from it. Then create a gzipped tar file of all
changed or added files or a corresponding patch file using 'diff -u'
or 'diff -c' and compress it with gzip. Please only use gzip
compression, as this works well on all platforms.
If the new features/files are broadly useful we may add them as core
files to LAMMPS or as part of a "standard
package"_Section_start.html#start_3. Else we will add them as a
user-contributed file or package. Examples of user packages are in
src sub-directories that start with USER. The USER-MISC package is
simply a collection of (mostly) unrelated single files, which is the
simplest way to have your contribution quickly added to the LAMMPS
distribution. You can see a list of the both standard and user
packages by typing "make package" in the LAMMPS src directory.
Note that by providing us files to release, you are agreeing to make
them open-source, i.e. we can release them under the terms of the GPL,
used as a license for the rest of LAMMPS. See "Section
1.4"_Section_intro.html#intro_4 for details.
With user packages and files, all we are really providing (aside from
the fame and fortune that accompanies having your name in the source
code and on the "Authors page"_http://lammps.sandia.gov/authors.html
of the "LAMMPS WWW site"_lws), is a means for you to distribute your
work to the LAMMPS user community, and a mechanism for others to
easily try out your new feature. This may help you find bugs or make
contact with new collaborators. Note that you're also implicitly
agreeing to support your code which means answer questions, fix bugs,
and maintain it if LAMMPS changes in some way that breaks it (an
unusual event).
NOTE: If you prefer to actively develop and support your add-on
feature yourself, then you may wish to make it available for download
from your own website, as a user package that LAMMPS users can add to
their copy of LAMMPS. See the "Offsite LAMMPS packages and
tools"_http://lammps.sandia.gov/offsite.html page of the LAMMPS web
site for examples of groups that do this. We are happy to advertise
your package and web site from that page. Simply email the
"developers"_http://lammps.sandia.gov/authors.html with info about
your package and we will post it there.
The previous sections of this doc page describe how to add new "style"
files of various kinds to LAMMPS. Packages are simply collections of
one or more new class files which are invoked as a new style within a
LAMMPS input script. If designed correctly, these additions typically
do not require changes to the main core of LAMMPS; they are simply
add-on files. If you think your new feature requires non-trivial
changes in core LAMMPS files, you'll need to "communicate with the
developers"_http://lammps.sandia.gov/authors.html, since we may or may
not want to make those changes. An example of a trivial change is
making a parent-class method "virtual" when you derive a new child
class from it.
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 src dir for
examples. If you are uncertain, please ask.
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. :ulb,l
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, class header files should not import any
system headers outside <stdio.h>, 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.
Header files must [not] import namespaces with {using}.
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. :l
If you want your contribution to be added as a user-contributed
feature, and it's a single file (actually a *.cpp and *.h file) it can
rapidly be added to the USER-MISC directory. Send us the one-line
entry to add to the USER-MISC/README file in that dir, along with the
2 source files. You can do this multiple times if you wish to
contribute several individual features. :l
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. :l
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. :l
You [must] also create a [documentation] file for each new command or
style you are adding to LAMMPS. For simplicity and convenience, the
documentation of groups of closely related commands or styles may be
combined into a single file. This will be one file for a single-file
feature. For a package, it might be several files. These are simple
text files with a specific markup language, that are then auto-converted
to HTML and PDF. The tools for this conversion are included in the
source distribution, and the translation can be as simple as doing
"make html pdf" in the doc folder.
Thus the documentation source files must be in the same format and
style as other *.txt files in the lammps/doc/src directory for similar
commands and styles; use one or more of them as a starting point.
A description of the markup can also be found in
lammps/doc/utils/txt2html/README.html
As appropriate, the text files can include links to equations
(see doc/Eqs/*.tex for examples, we auto-create the associated JPG
files), or figures (see doc/JPG for examples), or even additional PDF
files with further details (see doc/PDF for examples). The doc page
should also include literature citations as appropriate; see the
bottom of doc/fix_nh.txt for examples and the earlier part of the same
file for how to format the cite itself. The "Restrictions" section of
the doc page should indicate that your command is only available if
LAMMPS is built with the appropriate USER-MISC or USER-FOO package.
See other user package doc files for examples of how to do this. The
prerequisite for building the HTML format files are Python 3.x and
virtualenv, the requirement for generating the PDF format manual
is the "htmldoc"_http://www.htmldoc.org/ software. Please run at least
"make html" and carefully inspect and proofread the resulting HTML format
doc page before submitting your code. :l
For a new package (or even a single command) you should include one or
more example scripts demonstrating its use. These should run in no
more than a couple minutes, even on a single processor, and not require
large data files as input. See directories under examples/USER for
examples of input scripts other users provided for their packages.
These example inputs are also required for validating memory accesses
and testing for memory leaks with valgrind :l
If there is a paper of yours describing your feature (either the
algorithm/science behind the feature itself, or its initial usage, or
its implementation in LAMMPS), you can add the citation to the *.cpp
source file. See src/USER-EFF/atom_vec_electron.cpp for an example.
A LaTeX citation is stored in a variable at the top of the file and a
single line of code that references the variable is added to the
constructor of the class. Whenever a user invokes your feature from
their input script, this will cause LAMMPS to output the citation to a
log.cite file and prompt the user to examine the file. Note that you
should only use this for a paper you or your group authored.
E.g. adding a cite in the code for a paper by Nose and Hoover if you
write a fix that implements their integrator is not the intended
usage. That kind of citation should just be in the doc page you
provide. :l
:ule
Finally, as a general rule-of-thumb, the more clear and
self-explanatory you make your documentation and README files, and the
easier you make it for people to get started, e.g. by providing example
scripts, the more likely it is that users will try out your new feature.

35
doc/src/Modify_dump.txt Normal file
View File

@ -0,0 +1,35 @@
"Higher level section"_Modify.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
Dump styles :h3
Classes that dump per-atom info to files are derived from the Dump
class. To dump new quantities or in a new format, a new derived dump
class can be added, but it is typically simpler to modify the
DumpCustom class contained in the dump_custom.cpp file.
Dump_atom.cpp is a simple example of a derived dump class.
Here is a brief description of methods you define in your new derived
class. See dump.h for details.
write_header: write the header section of a snapshot of atoms
count: count the number of lines a processor will output
pack: pack a proc's output data into a buffer
write_data: write a proc's data to a file :tb(s=:)
See the "dump"_dump.html command and its {custom} style for a list of
keywords for atom information that can already be dumped by
DumpCustom. It includes options to dump per-atom info from Compute
classes, so adding a new derived Compute class is one way to calculate
new quantities to dump.
Note that new keywords for atom properties are not typically
added to the "dump custom"_dump.html command. Instead they are added
to the "compute property/atom"_compute_property_atom.html command.

107
doc/src/Modify_fix.txt Normal file
View File

@ -0,0 +1,107 @@
"Higher level section"_Modify.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
Fix styles :h3
In LAMMPS, a "fix" is any operation that is computed during
timestepping that alters some property of the system. Essentially
everything that happens during a simulation besides force computation,
neighbor list construction, and output, is a "fix". This includes
time integration (update of coordinates and velocities), force
constraints or boundary conditions (SHAKE or walls), and diagnostics
(compute a diffusion coefficient). New styles can be created to add
new options to LAMMPS.
Fix_setforce.cpp is a simple example of setting forces on atoms to
prescribed values. There are dozens of fix options already in LAMMPS;
choose one as a template that is similar to what you want to
implement.
Here is a brief description of methods you can define in your new
derived class. See fix.h for details.
setmask: determines when the fix is called during the timestep (required)
init: initialization before a run (optional)
setup_pre_exchange: called before atom exchange in setup (optional)
setup_pre_force: called before force computation in setup (optional)
setup: called immediately before the 1st timestep and after forces are computed (optional)
min_setup_pre_force: like setup_pre_force, but for minimizations instead of MD runs (optional)
min_setup: like setup, but for minimizations instead of MD runs (optional)
initial_integrate: called at very beginning of each timestep (optional)
pre_exchange: called before atom exchange on re-neighboring steps (optional)
pre_neighbor: called before neighbor list build (optional)
pre_force: called before pair & molecular forces are computed (optional)
post_force: called after pair & molecular forces are computed and communicated (optional)
final_integrate: called at end of each timestep (optional)
end_of_step: called at very end of timestep (optional)
write_restart: dumps fix info to restart file (optional)
restart: uses info from restart file to re-initialize the fix (optional)
grow_arrays: allocate memory for atom-based arrays used by fix (optional)
copy_arrays: copy atom info when an atom migrates to a new processor (optional)
pack_exchange: store atom's data in a buffer (optional)
unpack_exchange: retrieve atom's data from a buffer (optional)
pack_restart: store atom's data for writing to restart file (optional)
unpack_restart: retrieve atom's data from a restart file buffer (optional)
size_restart: size of atom's data (optional)
maxsize_restart: max size of atom's data (optional)
setup_pre_force_respa: same as setup_pre_force, but for rRESPA (optional)
initial_integrate_respa: same as initial_integrate, but for rRESPA (optional)
post_integrate_respa: called after the first half integration step is done in rRESPA (optional)
pre_force_respa: same as pre_force, but for rRESPA (optional)
post_force_respa: same as post_force, but for rRESPA (optional)
final_integrate_respa: same as final_integrate, but for rRESPA (optional)
min_pre_force: called after pair & molecular forces are computed in minimizer (optional)
min_post_force: called after pair & molecular forces are computed and communicated in minimizer (optional)
min_store: store extra data for linesearch based minimization on a LIFO stack (optional)
min_pushstore: push the minimization LIFO stack one element down (optional)
min_popstore: pop the minimization LIFO stack one element up (optional)
min_clearstore: clear minimization LIFO stack (optional)
min_step: reset or move forward on line search minimization (optional)
min_dof: report number of degrees of freedom {added} by this fix in minimization (optional)
max_alpha: report maximum allowed step size during linesearch minimization (optional)
pack_comm: pack a buffer to communicate a per-atom quantity (optional)
unpack_comm: unpack a buffer to communicate a per-atom quantity (optional)
pack_reverse_comm: pack a buffer to reverse communicate a per-atom quantity (optional)
unpack_reverse_comm: unpack a buffer to reverse communicate a per-atom quantity (optional)
dof: report number of degrees of freedom {removed} by this fix during MD (optional)
compute_scalar: return a global scalar property that the fix computes (optional)
compute_vector: return a component of a vector property that the fix computes (optional)
compute_array: return a component of an array property that the fix computes (optional)
deform: called when the box size is changed (optional)
reset_target: called when a change of the target temperature is requested during a run (optional)
reset_dt: is called when a change of the time step is requested during a run (optional)
modify_param: called when a fix_modify request is executed (optional)
memory_usage: report memory used by fix (optional)
thermo: compute quantities for thermodynamic output (optional) :tb(s=:)
Typically, only a small fraction of these methods are defined for a
particular fix. Setmask is mandatory, as it determines when the fix
will be invoked during the timestep. Fixes that perform time
integration ({nve}, {nvt}, {npt}) implement initial_integrate() and
final_integrate() to perform velocity Verlet updates. Fixes that
constrain forces implement post_force().
Fixes that perform diagnostics typically implement end_of_step(). For
an end_of_step fix, one of your fix arguments must be the variable
"nevery" which is used to determine when to call the fix and you must
set this variable in the constructor of your fix. By convention, this
is the first argument the fix defines (after the ID, group-ID, style).
If the fix needs to store information for each atom that persists from
timestep to timestep, it can manage that memory and migrate the info
with the atoms as they move from processors to processor by
implementing the grow_arrays, copy_arrays, pack_exchange, and
unpack_exchange methods. Similarly, the pack_restart and
unpack_restart methods can be implemented to store information about
the fix in restart files. If you wish an integrator or force
constraint fix to work with rRESPA (see the "run_style"_run_style.html
command), the initial_integrate, post_force_integrate, and
final_integrate_respa methods can be implemented. The thermo method
enables a fix to contribute values to thermodynamic output, as printed
quantities and/or to be summed to the potential energy of the system.

25
doc/src/Modify_kspace.txt Normal file
View File

@ -0,0 +1,25 @@
"Higher level section"_Modify.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
Kspace styles :h3
Classes that compute long-range Coulombic interactions via K-space
representations (Ewald, PPPM) are derived from the KSpace class. New
styles can be created to add new K-space options to LAMMPS.
Ewald.cpp is an example of computing K-space interactions.
Here is a brief description of methods you define in your new derived
class. See kspace.h for details.
init: initialize the calculation before a run
setup: computation before the 1st timestep of a run
compute: every-timestep computation
memory_usage: tally of memory usage :tb(s=:)

23
doc/src/Modify_min.txt Normal file
View File

@ -0,0 +1,23 @@
"Higher level section"_Modify.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
Minimization styles :h3
Classes that perform energy minimization derived from the Min class.
New styles can be created to add new minimization algorithms to
LAMMPS.
Min_cg.cpp is an example of conjugate gradient minimization.
Here is a brief description of methods you define in your new derived
class. See min.h for details.
init: initialize the minimization before a run
run: perform the minimization
memory_usage: tally of memory usage :tb(s=:)

101
doc/src/Modify_overview.txt Normal file
View File

@ -0,0 +1,101 @@
"Higher level section"_Modify.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
Overview :h3
The best way to add a new feature to LAMMPS is to find a similar
featureand look at the corresponding source and header files to figure
out what it does. You will need some knowledge of C++ to be able to
understand the hi-level structure of LAMMPS and its class
organization, but functions (class methods) that do actual
computations are written in vanilla C-style code and operate on simple
C-style data structures (vectors and arrays).
Most of the new features described on the "Modify"_Modify.html doc
page require you to write a new C++ derived class (except for
exceptions described below, where you can make small edits to existing
files). Creating a new class requires 2 files, a source code file
(*.cpp) and a header file (*.h). The derived class must provide
certain methods to work as a new option. Depending on how different
your new feature is compared to existing features, you can either
derive from the base class itself, or from a derived class that
already exists. Enabling LAMMPS to invoke the new class is as simple
as putting the two source files in the src dir and re-building LAMMPS.
The advantage of C++ and its object-orientation is that all the code
and variables needed to define the new feature are in the 2 files you
write, and thus shouldn't make the rest of LAMMPS more complex or
cause side-effect bugs.
Here is a concrete example. Suppose you write 2 files pair_foo.cpp
and pair_foo.h that define a new class PairFoo that computes pairwise
potentials described in the classic 1997 "paper"_#Foo by Foo, et al.
If you wish to invoke those potentials in a LAMMPS input script with a
command like
pair_style foo 0.1 3.5 :pre
then your pair_foo.h file should be structured as follows:
#ifdef PAIR_CLASS
PairStyle(foo,PairFoo)
#else
...
(class definition for PairFoo)
...
#endif :pre
where "foo" is the style keyword in the pair_style command, and
PairFoo is the class name defined in your pair_foo.cpp and pair_foo.h
files.
When you re-build LAMMPS, your new pairwise potential becomes part of
the executable and can be invoked with a pair_style command like the
example above. Arguments like 0.1 and 3.5 can be defined and
processed by your new class.
As illustrated by this pairwise example, many kinds of options are
referred to in the LAMMPS documentation as the "style" of a particular
command.
The "Modify page"_Modify.html lists all the common styles in LAMMPS,
and discusses the header file for the base class that these styles are
derived from. Public variables in that file are ones used and set by
the derived classes which are also used by the base class. Sometimes
they are also used by the rest of LAMMPS. Virtual functions in the
base class header file which are set = 0 are ones you must define in
your new derived class to give it the functionality LAMMPS expects.
Virtual functions that are not set to 0 are functions you can
optionally define.
Additionally, new output options can be added directly to the
thermo.cpp, dump_custom.cpp, and variable.cpp files. These are also
listed on the "Modify page"_Modify.html.
Here are additional guidelines for modifying LAMMPS and adding new
functionality:
Think about whether what you want to do would be better as a pre- or
post-processing step. Many computations are more easily and more
quickly done that way. :ulb,l
Don't do anything within the timestepping of a run that isn't
parallel. E.g. don't accumulate a bunch of data on a single processor
and analyze it. You run the risk of seriously degrading the parallel
efficiency. :l
If your new feature reads arguments or writes output, make sure you
follow the unit conventions discussed by the "units"_units.html
command. :l
:ule
:line
:link(Foo)
[(Foo)] Foo, Morefoo, and Maxfoo, J of Classic Potentials, 75, 345 (1997).

33
doc/src/Modify_pair.txt Normal file
View File

@ -0,0 +1,33 @@
"Higher level section"_Modify.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
Pair styles :h3
Classes that compute pairwise interactions are derived from the Pair
class. In LAMMPS, pairwise calculation include manybody potentials
such as EAM or Tersoff where particles interact without a static bond
topology. New styles can be created to add new pair potentials to
LAMMPS.
Pair_lj_cut.cpp is a simple example of a Pair class, though it
includes some optional methods to enable its use with rRESPA.
Here is a brief description of the class methods in pair.h:
compute: workhorse routine that computes pairwise interactions
settings: reads the input script line with arguments you define
coeff: set coefficients for one i,j type pair
init_one: perform initialization for one i,j type pair
init_style: initialization specific to this pair style
write & read_restart: write/read i,j pair coeffs to restart files
write & read_restart_settings: write/read global settings to restart files
single: force and energy of a single pairwise interaction between 2 atoms
compute_inner/middle/outer: versions of compute used by rRESPA :tb(s=:)
The inner/middle/outer routines are optional.

25
doc/src/Modify_region.txt Normal file
View File

@ -0,0 +1,25 @@
"Higher level section"_Modify.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
Region styles :h3
Classes that define geometric regions are derived from the Region
class. Regions are used elsewhere in LAMMPS to group atoms, delete
atoms to create a void, insert atoms in a specified region, etc. New
styles can be created to add new region shapes to LAMMPS.
Region_sphere.cpp is an example of a spherical region.
Here is a brief description of methods you define in your new derived
class. See region.h for details.
inside: determine whether a point is in the region
surface_interior: determine if a point is within a cutoff distance inside of surc
surface_exterior: determine if a point is within a cutoff distance outside of surf
shape_update : change region shape if set by time-dependent variable :tb(s=:)

35
doc/src/Modify_thermo.txt Normal file
View File

@ -0,0 +1,35 @@
"Higher level section"_Modify.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
Thermodynamic output options :h3
There is one class that computes and prints thermodynamic information
to the screen and log file; see the file thermo.cpp.
There are two styles defined in thermo.cpp: "one" and "multi". There
is also a flexible "custom" style which allows the user to explicitly
list keywords for quantities to print when thermodynamic info is
output. See the "thermo_style"_thermo_style.html command for a list
of defined quantities.
The thermo styles (one, multi, etc) are simply lists of keywords.
Adding a new style thus only requires defining a new list of keywords.
Search for the word "customize" with references to "thermo style" in
thermo.cpp to see the two locations where code will need to be added.
New keywords can also be added to thermo.cpp to compute new quantities
for output. Search for the word "customize" with references to
"keyword" in thermo.cpp to see the several locations where code will
need to be added.
Note that the "thermo_style custom"_thermo.html command already allows
for thermo output of quantities calculated by "fixes"_fix.html,
"computes"_compute.html, and "variables"_variable.html. Thus, it may
be simpler to compute what you wish via one of those constructs, than
by adding a new keyword to the thermo command.

46
doc/src/Modify_variable.txt Normal file
View File

@ -0,0 +1,46 @@
"Higher level section"_Modify.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
Variable options :h3
There is one class that computes and stores "variable"_variable.html
information in LAMMPS; see the file variable.cpp. The value
associated with a variable can be periodically printed to the screen
via the "print"_print.html, "fix print"_fix_print.html, or
"thermo_style custom"_thermo_style.html commands. Variables of style
"equal" can compute complex equations that involve the following types
of arguments:
thermo keywords = ke, vol, atoms, ...
other variables = v_a, v_myvar, ...
math functions = div(x,y), mult(x,y), add(x,y), ...
group functions = mass(group), xcm(group,x), ...
atom values = x\[123\], y\[3\], vx\[34\], ...
compute values = c_mytemp\[0\], c_thermo_press\[3\], ... :pre
Adding keywords for the "thermo_style custom"_thermo_style.html
command (which can then be accessed by variables) is discussed on the
"Modify thermo"_Modify_thermo.html doc page.
Adding a new math function of one or two arguments can be done by
editing one section of the Variable::evaluate() method. Search for
the word "customize" to find the appropriate location.
Adding a new group function can be done by editing one section of the
Variable::evaluate() method. Search for the word "customize" to find
the appropriate location. You may need to add a new method to the
Group class as well (see the group.cpp file).
Accessing a new atom-based vector can be done by editing one section
of the Variable::evaluate() method. Search for the word "customize"
to find the appropriate location.
Adding new "compute styles"_compute.html (whose calculated values can
then be accessed by variables) is discussed on the "Modify
compute"_Modify_compute.html doc page.

39
doc/src/Packages.txt Normal file
View File

@ -0,0 +1,39 @@
"Previous Section"_Section_commands.html - "LAMMPS WWW Site"_lws -
"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
Section"_Speed.html :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
Optional packages :h2
This section gives an overview of the optional packages that extend
LAMMPS functionality. Packages are groups of files that enable a
specific set of features. For example, force fields for molecular
systems or rigid-body constraint are in packages. You can see the
list of all packages and "make" commands to manage them by typing
"make package" from within the src directory of the LAMMPS
distribution. "Section 2.3"_Section_start.html#start_3 gives general
info on how to install and un-install packages as part of the LAMMPS
build process.
<!-- RST
.. toctree::
Packages_standard
Packages_user
Packages_details
END_RST -->
<!-- HTML_ONLY -->
"Standard packages"_Packages_standard.html
"User packages"_Packages_user.html
"Details on each package"_Packages_details.html :ul
<!-- END_HTML_ONLY -->

323
doc/src/Section_packages.txt → doc/src/Packages_details.txt
View File

@ -1,6 +1,5 @@
"Previous Section"_Section_commands.html - "LAMMPS WWW Site"_lws -
"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
Section"_Section_accelerate.html :c
"Higher level section"_Packages.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
@ -8,154 +7,90 @@ Section"_Section_accelerate.html :c
:line
4. Packages :h2
Package details :h3
This section gives an overview of the optional packages that extend
LAMMPS functionality with instructions on how to build LAMMPS with
each of them. Packages are groups of files that enable a specific set
of features. For example, force fields for molecular systems or
granular systems are in packages. You can see the list of all
packages and "make" commands to manage them by typing "make package"
from within the src directory of the LAMMPS distribution. "Section
2.3"_Section_start.html#start_3 gives general info on how to install
and un-install packages as part of the LAMMPS build process.
There are two kinds of packages in LAMMPS, standard and user packages:
"Table of standard packages"_#table_standard
"Table of user packages"_#table_user :ul
Either of these kinds of packages may work as is, may require some
additional code compiled located in the lib folder, or may require
an external library to be downloaded, compiled, installed, and LAMMPS
configured to know about its location and additional compiler flags.
You can often do the build of the internal or external libraries
in one step by typing "make lib-name args='...'" from the src dir,
with appropriate arguments included in args='...'. If you just type
"make lib-name" you should see a help message about supported flags
and some examples. For more details about this, please study the
tables below and the sections about the individual packages.
Standard packages are supported by the LAMMPS developers and are
written in a syntax and style consistent with the rest of LAMMPS.
This means the developers will answer questions about them, debug and
fix them if necessary, and keep them compatible with future changes to
LAMMPS.
User packages have been contributed by users, and begin with the
"user" prefix. If they are a single command (single file), they are
typically in the user-misc package. User packages don't necessarily
meet the requirements of the standard packages. This means the
developers will try to keep things working and usually can answer
technical questions about compiling the package. If you have problems
using a feature provided in a user package, you may need to contact
the contributor directly to get help. Information on how to submit
additions you make to LAMMPS as single files or as a standard or user
package are given in "this section"_Section_modify.html#mod_15 of the
manual.
Following the next two tables is a sub-section for each package. It
lists authors (if applicable) and summarizes the package contents. It
has specific instructions on how to install the package, including (if
necessary) downloading or building any extra library it requires. It
also gives links to documentation, example scripts, and
pictures/movies (if available) that illustrate use of the package.
Here is a brief description of all the standard and user packages in
LAMMPS. It lists authors (if applicable) and summarizes the package
contents. It has specific instructions on how to install the package,
including, if necessary, info on how to download or build any extra
library it requires. It also gives links to documentation, example
scripts, and pictures/movies (if available) that illustrate use of the
package.
NOTE: To see the complete list of commands a package adds to LAMMPS,
just look at the files in its src directory, e.g. "ls src/GRANULAR".
Files with names that start with fix, compute, atom, pair, bond,
angle, etc correspond to commands with the same style names.
you can examine the files in its src directory, e.g. "ls
src/GRANULAR". Files with names that start with fix, compute, atom,
pair, bond, angle, etc correspond to commands with the same style name
as contained in the file name.
In these two tables, the "Example" column is a sub-directory in the
examples directory of the distribution which has an input script that
uses the package. E.g. "peptide" refers to the examples/peptide
directory; USER/atc refers to the examples/USER/atc directory. The
"Library" column indicates whether an extra library is needed to build
and use the package:
"ASPHERE"_#ASPHERE,
"BODY"_#BODY,
"CLASS2"_#CLASS2,
"COLLOID"_#COLLOID,
"COMPRESS"_#COMPRESS,
"CORESHELL"_#CORESHELL,
"DIPOLE"_#DIPOLE,
"GPU"_#GPU,
"GRANULAR"_#GRANULAR,
"KIM"_#KIM,
"KOKKOS"_#KOKKOS,
"KSPACE"_#KSPACE,
"LATTE"_#LATTE,
"MANYBODY"_#MANYBODY,
"MC"_#MC,
"MEAM"_#MEAM,
"MISC"_#MISC,
"MOLECULE"_#MOLECULE,
"MPIIO"_#MPIIO,
"MSCG"_#MSCG,
"OPT"_#OPT,
"PERI"_#PERI,
"POEMS"_#POEMS,
"PYTHON"_#PYTHON,
"QEQ"_#QEQ,
"REAX"_#REAX,
"REPLICA"_#REPLICA,
"RIGID"_#RIGID,
"SHOCK"_#SHOCK,
"SNAP"_#SNAP,
"SRD"_#SRD,
"VORONOI"_#VORONOI :tb(c=6,ea=c)
dash = no library
sys = system library: you likely have it on your machine
int = internal library: provided with LAMMPS, but you may need to build it
ext = external library: you will need to download and install it on your machine :ul
:line
:line
[Standard packages] :link(table_standard),p
Package, Description, Doc page, Example, Library
"ASPHERE"_#ASPHERE, aspherical particle models, "Section 6.6.14"_Section_howto.html#howto_14, ellipse, -
"BODY"_#BODY, body-style particles, "body"_body.html, body, -
"CLASS2"_#CLASS2, class 2 force fields, "pair_style lj/class2"_pair_class2.html, -, -
"COLLOID"_#COLLOID, colloidal particles, "atom_style colloid"_atom_style.html, colloid, -
"COMPRESS"_#COMPRESS, I/O compression, "dump */gz"_dump.html, -, sys
"CORESHELL"_#CORESHELL, adiabatic core/shell model, "Section 6.6.25"_Section_howto.html#howto_25, coreshell, -
"DIPOLE"_#DIPOLE, point dipole particles, "pair_style dipole/cut"_pair_dipole.html, dipole, -
"GPU"_#GPU, GPU-enabled styles, "Section 5.3.1"_accelerate_gpu.html, "Benchmarks"_http://lammps.sandia.gov/bench.html, int
"GRANULAR"_#GRANULAR, granular systems, "Section 6.6.6"_Section_howto.html#howto_6, pour, -
"KIM"_#KIM, OpenKIM wrapper, "pair_style kim"_pair_kim.html, kim, ext
"KOKKOS"_#KOKKOS, Kokkos-enabled styles, "Section 5.3.3"_accelerate_kokkos.html, "Benchmarks"_http://lammps.sandia.gov/bench.html, -
"KSPACE"_#KSPACE, long-range Coulombic solvers, "kspace_style"_kspace_style.html, peptide, -
"LATTE"_#LATTE, quantum DFTB forces via LATTE, "fix latte"_fix_latte.html, latte, ext
"MANYBODY"_#MANYBODY, many-body potentials, "pair_style tersoff"_pair_tersoff.html, shear, -
"MC"_#MC, Monte Carlo options, "fix gcmc"_fix_gcmc.html, -, -
"MEAM"_#MEAM, modified EAM potential, "pair_style meam"_pair_meam.html, meam, int
"MISC"_#MISC, miscellanous single-file commands, -, -, -
"MOLECULE"_#MOLECULE, molecular system force fields, "Section 6.6.3"_Section_howto.html#howto_3, peptide, -
"MPIIO"_#MPIIO, MPI parallel I/O dump and restart, "dump"_dump.html, -, -
"MSCG"_#MSCG, multi-scale coarse-graining wrapper, "fix mscg"_fix_mscg.html, mscg, ext
"OPT"_#OPT, optimized pair styles, "Section 5.3.5"_accelerate_opt.html, "Benchmarks"_http://lammps.sandia.gov/bench.html, -
"PERI"_#PERI, Peridynamics models, "pair_style peri"_pair_peri.html, peri, -
"POEMS"_#POEMS, coupled rigid body motion, "fix poems"_fix_poems.html, rigid, int
"PYTHON"_#PYTHON, embed Python code in an input script, "python"_python.html, python, sys
"QEQ"_#QEQ, QEq charge equilibration, "fix qeq"_fix_qeq.html, qeq, -
"REAX"_#REAX, ReaxFF potential (Fortran), "pair_style reax"_pair_reax.html, reax, int
"REPLICA"_#REPLICA, multi-replica methods, "Section 6.6.5"_Section_howto.html#howto_5, tad, -
"RIGID"_#RIGID, rigid bodies and constraints, "fix rigid"_fix_rigid.html, rigid, -
"SHOCK"_#SHOCK, shock loading methods, "fix msst"_fix_msst.html, -, -
"SNAP"_#SNAP, quantum-fitted potential, "pair_style snap"_pair_snap.html, snap, -
"SPIN"_#SPIN, magnetic atomic spin dynamics, "Section 6.6.28"_Section_howto.html#howto_28, SPIN, -
"SRD"_#SRD, stochastic rotation dynamics, "fix srd"_fix_srd.html, srd, -
"VORONOI"_#VORONOI, Voronoi tesselation, "compute voronoi/atom"_compute_voronoi_atom.html, -, ext :tb(ea=c,ca1=l)
[USER packages] :link(table_user),p
Package, Description, Doc page, Example, Library
"USER-ATC"_#USER-ATC, atom-to-continuum coupling, "fix atc"_fix_atc.html, USER/atc, int
"USER-AWPMD"_#USER-AWPMD, wave-packet MD, "pair_style awpmd/cut"_pair_awpmd.html, USER/awpmd, int
"USER-BOCS"_#USER-BOCS, BOCS bottom up coarse graining, "fix bocs"_fix_bocs.html, USER/bocs, -
"USER-CGDNA"_#USER-CGDNA, coarse-grained DNA force fields, src/USER-CGDNA/README, USER/cgdna, -
"USER-CGSDK"_#USER-CGSDK, SDK coarse-graining model, "pair_style lj/sdk"_pair_sdk.html, USER/cgsdk, -
"USER-COLVARS"_#USER-COLVARS, collective variables library, "fix colvars"_fix_colvars.html, USER/colvars, int
"USER-DIFFRACTION"_#USER-DIFFRACTION, virtual x-ray and electron diffraction,"compute xrd"_compute_xrd.html, USER/diffraction, -
"USER-DPD"_#USER-DPD, reactive dissipative particle dynamics, src/USER-DPD/README, USER/dpd, -
"USER-DRUDE"_#USER-DRUDE, Drude oscillators, "tutorial"_tutorial_drude.html, USER/drude, -
"USER-EFF"_#USER-EFF, electron force field,"pair_style eff/cut"_pair_eff.html, USER/eff, -
"USER-FEP"_#USER-FEP, free energy perturbation,"compute fep"_compute_fep.html, USER/fep, -
"USER-H5MD"_#USER-H5MD, dump output via HDF5,"dump h5md"_dump_h5md.html, -, ext
"USER-INTEL"_#USER-INTEL, optimized Intel CPU and KNL styles,"Section 5.3.2"_accelerate_intel.html, "Benchmarks"_http://lammps.sandia.gov/bench.html, -
"USER-LB"_#USER-LB, Lattice Boltzmann fluid,"fix lb/fluid"_fix_lb_fluid.html, USER/lb, -
"USER-MANIFOLD"_#USER-MANIFOLD, motion on 2d surfaces,"fix manifoldforce"_fix_manifoldforce.html, USER/manifold, -
"USER-MEAMC"_#USER-MEAMC, modified EAM potential (C++), "pair_style meam/c"_pair_meam.html, meam, -
"USER-MESO"_#USER-MESO, mesoscale DPD models, "pair_style edpd"_pair_meso.html, USER/meso, -
"USER-MGPT"_#USER-MGPT, fast MGPT multi-ion potentials, "pair_style mgpt"_pair_mgpt.html, USER/mgpt, -
"USER-MISC"_#USER-MISC, single-file contributions, USER-MISC/README, USER/misc, -
"USER-MOFFF"_#USER-MOFFF, styles for "MOF-FF"_MOFplus force field, "pair_style buck6d/coul/gauss"_pair_buck6d_coul_gauss.html, USER/mofff, -
"USER-MOLFILE"_#USER-MOLFILE, "VMD"_vmd_home molfile plug-ins,"dump molfile"_dump_molfile.html, -, ext
"USER-NETCDF"_#USER-NETCDF, dump output via NetCDF,"dump netcdf"_dump_netcdf.html, -, ext
"USER-OMP"_#USER-OMP, OpenMP-enabled styles,"Section 5.3.4"_accelerate_omp.html, "Benchmarks"_http://lammps.sandia.gov/bench.html, -
"USER-PHONON"_#USER-PHONON, phonon dynamical matrix,"fix phonon"_fix_phonon.html, USER/phonon, -
"USER-QMMM"_#USER-QMMM, QM/MM coupling,"fix qmmm"_fix_qmmm.html, USER/qmmm, ext
"USER-QTB"_#USER-QTB, quantum nuclear effects,"fix qtb"_fix_qtb.html "fix qbmsst"_fix_qbmsst.html, qtb, -
"USER-QUIP"_#USER-QUIP, QUIP/libatoms interface,"pair_style quip"_pair_quip.html, USER/quip, ext
"USER-REAXC"_#USER-REAXC, ReaxFF potential (C/C++) ,"pair_style reaxc"_pair_reaxc.html, reax, -
"USER-SCAFACOS"_#USER-SCAFACOS, ScaFaCoS long-range Coulombics,"kspace_style scafacos"_kspace_style.html, USER/scafacos, ext
"USER-SMD"_#USER-SMD, smoothed Mach dynamics,"SMD User Guide"_PDF/SMD_LAMMPS_userguide.pdf, USER/smd, ext
"USER-SMTBQ"_#USER-SMTBQ, second moment tight binding QEq potential,"pair_style smtbq"_pair_smtbq.html, USER/smtbq, -
"USER-SPH"_#USER-SPH, smoothed particle hydrodynamics,"SPH User Guide"_PDF/SPH_LAMMPS_userguide.pdf, USER/sph, -
"USER-TALLY"_#USER-TALLY, pairwise tally computes,"compute XXX/tally"_compute_tally.html, USER/tally, -
"USER-UEF"_#USER-UEF, extensional flow,"fix nvt/uef"_fix_nh_uef.html, USER/uef, -
"USER-VTK"_#USER-VTK, dump output via VTK, "compute vtk"_dump_vtk.html, -, ext :tb(ea=c,ca1=l)
"USER-ATC"_#USER-ATC,
"USER-AWPMD"_#USER-AWPMD,
"USER-BOCS"_#USER-BOCS,
"USER-CGDNA"_#USER-CGDNA,
"USER-CGSDK"_#USER-CGSDK,
"USER-COLVARS"_#USER-COLVARS,
"USER-DIFFRACTION"_#USER-DIFFRACTION,
"USER-DPD"_#USER-DPD,
"USER-DRUDE"_#USER-DRUDE,
"USER-EFF"_#USER-EFF,
"USER-FEP"_#USER-FEP,
"USER-H5MD"_#USER-H5MD,
"USER-INTEL"_#USER-INTEL,
"USER-LB"_#USER-LB,
"USER-MANIFOLD"_#USER-MANIFOLD,
"USER-MEAMC"_#USER-MEAMC,
"USER-MESO"_#USER-MESO,
"USER-MGPT"_#USER-MGPT,
"USER-MISC"_#USER-MISC,
"USER-MOFFF"_#USER-MOFFF,
"USER-MOLFILE"_#USER-MOLFILE,
"USER-NETCDF"_#USER-NETCDF,
"USER-OMP"_#USER-OMP,
"USER-PHONON"_#USER-PHONON,
"USER-QMMM"_#USER-QMMM,
"USER-QTB"_#USER-QTB,
"USER-QUIP"_#USER-QUIP,
"USER-REAXC"_#USER-REAXC,
"USER-SCAFACOS"_#USER-SCAFACOS,
"USER-SMD"_#USER-SMD,
"USER-SMTBQ"_#USER-SMTBQ,
"USER-SPH"_#USER-SPH,
"USER-TALLY"_#USER-TALLY,
"USER-UEF"_#USER-UEF,
"USER-VTK"_#USER-VTK :tb(c=6,ea=c)
:line
:line
@ -382,14 +317,14 @@ GPU package :link(GPU),h4
[Contents:]
Dozens of pair styles and a version of the PPPM long-range Coulombic
solver optimized for GPUs. All such styles have a "gpu" as a
suffix in their style name. The GPU code can be compiled with either
CUDA or OpenCL, however the OpenCL variants are no longer actively
maintained and only the CUDA versions are regularly tested.
"Section 5.3.1"_accelerate_gpu.html gives details of what
hardware and GPU software is required on your system,
and details on how to build and use this package. Its styles can be
invoked at run time via the "-sf gpu" or "-suffix gpu" "command-line
solver optimized for GPUs. All such styles have a "gpu" as a suffix
in their style name. The GPU code can be compiled with either CUDA or
OpenCL, however the OpenCL variants are no longer actively maintained
and only the CUDA versions are regularly tested. The "Speed
gpu"_Speed_gpu.html doc page gives details of what hardware and GPU
software is required on your system, and details on how to build and
use this package. Its styles can be invoked at run time via the "-sf
gpu" or "-suffix gpu" "command-line
switches"_Section_start.html#start_6. See also the "KOKKOS"_#KOKKOS
package, which has GPU-enabled styles.
@ -455,8 +390,8 @@ GPU library.
src/GPU: filenames -> commands
src/GPU/README
lib/gpu/README
"Section 5.3"_Section_accelerate.html#acc_3
"Section 5.3.1"_accelerate_gpu.html
"Speed packages"_Speed_packages.html
"Speed gpu"_Speed_gpu.html.html
"Section 2.6 -sf gpu"_Section_start.html#start_6
"Section 2.6 -pk gpu"_Section_start.html#start_6
"package gpu"_package.html
@ -581,10 +516,10 @@ Dozens of atom, pair, bond, angle, dihedral, improper, fix, compute
styles adapted to compile using the Kokkos library which can convert
them to OpenMP or CUDA code so that they run efficiently on multicore
CPUs, KNLs, or GPUs. All the styles have a "kk" as a suffix in their
style name. "Section 5.3.3"_accelerate_kokkos.html gives details of
what hardware and software is required on your system, and how to
build and use this package. Its styles can be invoked at run time via
the "-sf kk" or "-suffix kk" "command-line
style name. The "Speed kokkos"_Speed_kokkos.html doc page gives
details of what hardware and software is required on your system, and
how to build and use this package. Its styles can be invoked at run
time via the "-sf kk" or "-suffix kk" "command-line
switches"_Section_start.html#start_6. Also see the "GPU"_#GPU,
"OPT"_#OPT, "USER-INTEL"_#USER-INTEL, and "USER-OMP"_#USER-OMP
packages, which have styles optimized for CPUs, KNLs, and GPUs.
@ -651,8 +586,8 @@ make machine :pre
src/KOKKOS: filenames -> commands
src/KOKKOS/README
lib/kokkos/README
"Section 5.3"_Section_accelerate.html#acc_3
"Section 5.3.3"_accelerate_kokkos.html
"Speed packages"_Speed_packages.html
"Speed kokkos"_Speed_kokkos.html
"Section 2.6 -k on ..."_Section_start.html#start_6
"Section 2.6 -sf kk"_Section_start.html#start_6
"Section 2.6 -pk kokkos"_Section_start.html#start_6
@ -1050,9 +985,9 @@ OPT package :link(OPT),h4
A handful of pair styles which are optimized for improved CPU
performance on single or multiple cores. These include EAM, LJ,
CHARMM, and Morse potentials. The styles have an "opt" suffix in
their style name. "Section 5.3.5"_accelerate_opt.html gives details
of how to build and use this package. Its styles can be invoked at
run time via the "-sf opt" or "-suffix opt" "command-line
their style name. The "Speed opt"_Speed_opt.html doc page gives
details of how to build and use this package. Its styles can be
invoked at run time via the "-sf opt" or "-suffix opt" "command-line
switches"_Section_start.html#start_6. See also the "KOKKOS"_#KOKKOS,
"USER-INTEL"_#USER-INTEL, and "USER-OMP"_#USER-OMP packages, which
have styles optimized for CPU performance.
@ -1078,8 +1013,8 @@ CCFLAGS: add -restrict for Intel compilers :ul
[Supporting info:]
src/OPT: filenames -> commands
"Section 5.3"_Section_accelerate.html#acc_3
"Section 5.3.5"_accelerate_opt.html
"Speed packages"_Speed_packages.html
"Speed opt"_Speed_opt.html
"Section 2.6 -sf opt"_Section_start.html#start_6
Pair Styles section of "Section 3.5"_Section_commands.html#cmd_5 for pair styles followed by (t)
"Benchmarks page"_http://lammps.sandia.gov/bench.html of web site :ul
@ -1417,38 +1352,6 @@ examples/snap :ul
:line
SPIN package :link(SPIN),h4
[Contents:]
Model atomic magnetic spins classically, coupled to atoms moving in
the usual manner via MD. Various pair, fix, and compute styles.
[Author:] Julian Tranchida (Sandia).
[Install or un-install:]
make yes-spin
make machine :pre
make no-spin
make machine :pre
[Supporting info:]
src/SPIN: filenames -> commands
"Section 6.28"_Section_howto.html#howto_28
"pair_style spin/dmi"_pair_spin_dmi.html
"pair_style spin/exchange"_pair_spin_exchange.html
"pair_style spin/magelec"_pair_spin_magelec.html
"pair_style spin/neel"_pair_spin_neel.html
"fix nve/spin"_fix_nve_spin.html
"fix precession/spin"_fix_precession_spin.html
"compute spin"_compute_spin.html
examples/SPIN :ul
:line
SRD package :link(SRD),h4
[Contents:]
@ -2067,8 +1970,8 @@ USER-INTEL package :link(USER-INTEL),h4
Dozens of pair, fix, bond, angle, dihedral, improper, and kspace
styles which are optimized for Intel CPUs and KNLs (Knights Landing).
All of them have an "intel" in their style name. "Section
5.3.2"_accelerate_intel.html gives details of what hardware and
All of them have an "intel" in their style name. The "Speed
intel"_Speed_intel.html doc page gives details of what hardware and
compilers are required on your system, and how to build and use this
package. Its styles can be invoked at run time via the "-sf intel" or
"-suffix intel" "command-line switches"_Section_start.html#start_6.
@ -2118,7 +2021,7 @@ hardware target, to produce a separate executable.
You should also typically install the USER-OMP package, as it can be
used in tandem with the USER-INTEL package to good effect, as
explained in "Section 5.3.2"_accelerate_intel.html.
explained on the "Speed intel"_Speed_intel.html doc page.
make yes-user-intel yes-user-omp
make machine :pre
@ -2130,8 +2033,8 @@ make machine :pre
src/USER-INTEL: filenames -> commands
src/USER-INTEL/README
"Section 5.3"_Section_accelerate.html#acc_3
"Section 5.3.2"_accelerate_gpu.html
"Speed packages"_Speed_packages.html
"Speed intel"_Speed_intel.html
"Section 2.6 -sf intel"_Section_start.html#start_6
"Section 2.6 -pk intel"_Section_start.html#start_6
"package intel"_package.html
@ -2477,10 +2380,10 @@ USER-OMP package :link(USER-OMP),h4
Hundreds of pair, fix, compute, bond, angle, dihedral, improper, and
kspace styles which are altered to enable threading on many-core CPUs
via OpenMP directives. All of them have an "omp" in their style name.
"Section 5.3.4"_accelerate_omp.html gives details of what hardware and
compilers are required on your system, and how to build and use this
package. Its styles can be invoked at run time via the "-sf omp" or
"-suffix omp" "command-line switches"_Section_start.html#start_6.
The "Speed omp"_Speed_omp.html doc page gives details of what hardware
and compilers are required on your system, and how to build and use
this package. Its styles can be invoked at run time via the "-sf omp"
or "-suffix omp" "command-line switches"_Section_start.html#start_6.
Also see the "KOKKOS"_#KOKKOS, "OPT"_#OPT, and
"USER-INTEL"_#USER-INTEL packages, which have styles optimized for
CPUs.
@ -2515,8 +2418,8 @@ LINKFLAGS: add -fopenmp :ul
src/USER-OMP: filenames -> commands
src/USER-OMP/README
"Section 5.3"_Section_accelerate.html#acc_3
"Section 5.3.4"_accelerate_omp.html
"Speed packages"_Speed_packages.html
"Speed omp"_Speed_omp.html
"Section 2.6 -sf omp"_Section_start.html#start_6
"Section 2.6 -pk omp"_Section_start.html#start_6
"package omp"_package.html

65
doc/src/Packages_standard.txt Normal file
View File

@ -0,0 +1,65 @@
"Higher level section"_Packages.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
Standard packages :h3
This is the list of standard packages in LAMMPS. The link for each
package name gives more details.
Standard packages are supported by the LAMMPS developers and are
written in a syntax and style consistent with the rest of LAMMPS.
This means the developers will answer questions about them, debug and
fix them if necessary, and keep them compatible with future changes to
LAMMPS.
The "Example" column is a sub-directory in the examples directory of
the distribution which has an input script that uses the package.
E.g. "peptide" refers to the examples/peptide directory; USER/atc
refers to the examples/USER/atc directory. The "Library" column
indicates whether an extra library is needed to build and use the
package:
dash = no library
sys = system library: you likely have it on your machine
int = internal library: provided with LAMMPS, but you may need to build it
ext = external library: you will need to download and install it on your machine :ul
Package, Description, Doc page, Example, Library
"ASPHERE"_Packages_details.html#ASPHERE, aspherical particle models, "Section 6.6.14"_Section_howto.html#howto_14, ellipse, -
"BODY"_Packages_details.html#BODY, body-style particles, "body"_body.html, body, -
"CLASS2"_Packages_details.html#CLASS2, class 2 force fields, "pair_style lj/class2"_pair_class2.html, -, -
"COLLOID"_Packages_details.html#COLLOID, colloidal particles, "atom_style colloid"_atom_style.html, colloid, -
"COMPRESS"_Packages_details.html#COMPRESS, I/O compression, "dump */gz"_dump.html, -, sys
"CORESHELL"_Packages_details.html#CORESHELL, adiabatic core/shell model, "Section 6.6.25"_Section_howto.html#howto_25, coreshell, -
"DIPOLE"_Packages_details.html#DIPOLE, point dipole particles, "pair_style dipole/cut"_pair_dipole.html, dipole, -
"GPU"_Packages_details.html#GPU, GPU-enabled styles, "Section gpu"_Speed_gpu.html, "Benchmarks"_http://lammps.sandia.gov/bench.html, int
"GRANULAR"_Packages_details.html#GRANULAR, granular systems, "Section 6.6.6"_Section_howto.html#howto_6, pour, -
"KIM"_Packages_details.html#KIM, OpenKIM wrapper, "pair_style kim"_pair_kim.html, kim, ext
"KOKKOS"_Packages_details.html#KOKKOS, Kokkos-enabled styles, "Speed kokkos"_Speed_kokkos.html, "Benchmarks"_http://lammps.sandia.gov/bench.html, -
"KSPACE"_Packages_details.html#KSPACE, long-range Coulombic solvers, "kspace_style"_kspace_style.html, peptide, -
"LATTE"_Packages_details.html#LATTE, quantum DFTB forces via LATTE, "fix latte"_fix_latte.html, latte, ext
"MANYBODY"_Packages_details.html#MANYBODY, many-body potentials, "pair_style tersoff"_pair_tersoff.html, shear, -
"MC"_Packages_details.html#MC, Monte Carlo options, "fix gcmc"_fix_gcmc.html, -, -
"MEAM"_Packages_details.html#MEAM, modified EAM potential, "pair_style meam"_pair_meam.html, meam, int
"MISC"_Packages_details.html#MISC, miscellanous single-file commands, -, -, -
"MOLECULE"_Packages_details.html#MOLECULE, molecular system force fields, "Section 6.6.3"_Section_howto.html#howto_3, peptide, -
"MPIIO"_Packages_details.html#MPIIO, MPI parallel I/O dump and restart, "dump"_dump.html, -, -
"MSCG"_Packages_details.html#MSCG, multi-scale coarse-graining wrapper, "fix mscg"_fix_mscg.html, mscg, ext
"OPT"_Packages_details.html#OPT, optimized pair styles, "Speed opt"_Speed_opt.html, "Benchmarks"_http://lammps.sandia.gov/bench.html, -
"PERI"_Packages_details.html#PERI, Peridynamics models, "pair_style peri"_pair_peri.html, peri, -
"POEMS"_Packages_details.html#POEMS, coupled rigid body motion, "fix poems"_fix_poems.html, rigid, int
"PYTHON"_Packages_details.html#PYTHON, embed Python code in an input script, "python"_python.html, python, sys
"QEQ"_Packages_details.html#QEQ, QEq charge equilibration, "fix qeq"_fix_qeq.html, qeq, -
"REAX"_Packages_details.html#REAX, ReaxFF potential (Fortran), "pair_style reax"_pair_reax.html, reax, int
"REPLICA"_Packages_details.html#REPLICA, multi-replica methods, "Section 6.6.5"_Section_howto.html#howto_5, tad, -
"RIGID"_Packages_details.html#RIGID, rigid bodies and constraints, "fix rigid"_fix_rigid.html, rigid, -
"SHOCK"_Packages_details.html#SHOCK, shock loading methods, "fix msst"_fix_msst.html, -, -
"SNAP"_Packages_details.html#SNAP, quantum-fitted potential, "pair_style snap"_pair_snap.html, snap, -
"SRD"_Packages_details.html#SRD, stochastic rotation dynamics, "fix srd"_fix_srd.html, srd, -
"VORONOI"_Packages_details.html#VORONOI, Voronoi tesselation, "compute voronoi/atom"_compute_voronoi_atom.html, -, ext :tb(ea=c,ca1=l)

74
doc/src/Packages_user.txt Normal file
View File

@ -0,0 +1,74 @@
"Higher level section"_Packages.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
User packages :h3
This is a list of user packages in LAMMPS. The link for each package
name gives more details.
User packages have been contributed by users, and begin with the
"user" prefix. If a contribution is a single command (single file),
it is typically in the user-misc package. User packages don't
necessarily meet the requirements of the "standard
packages"_Packages_standard.html. This means the developers will try
to keep things working and usually can answer technical questions
about compiling the package. If you have problems using a specific
feature provided in a user package, you may need to contact the
contributor directly to get help. Information on how to submit
additions you make to LAMMPS as single files or as a standard or user
package is explained on the "Modify contribute"_Modify_contribute.html
doc page.
The "Example" column is a sub-directory in the examples directory of
the distribution which has an input script that uses the package.
E.g. "peptide" refers to the examples/peptide directory; USER/atc
refers to the examples/USER/atc directory. The "Library" column
indicates whether an extra library is needed to build and use the
package:
dash = no library
sys = system library: you likely have it on your machine
int = internal library: provided with LAMMPS, but you may need to build it
ext = external library: you will need to download and install it on your machine :ul
Package, Description, Doc page, Example, Library
"USER-ATC"_Packages_details.html#USER-ATC, atom-to-continuum coupling, "fix atc"_fix_atc.html, USER/atc, int
"USER-AWPMD"_Packages_details.html#USER-AWPMD, wave-packet MD, "pair_style awpmd/cut"_pair_awpmd.html, USER/awpmd, int
"USER-BOCS"_Packages_details.html#USER-BOCS, BOCS bottom up coarse graining, "fix bocs"_fix_bocs.html, USER/bocs, -
"USER-CGDNA"_Packages_details.html#USER-CGDNA, coarse-grained DNA force fields, src/USER-CGDNA/README, USER/cgdna, -
"USER-CGSDK"_Packages_details.html#USER-CGSDK, SDK coarse-graining model, "pair_style lj/sdk"_pair_sdk.html, USER/cgsdk, -
"USER-COLVARS"_Packages_details.html#USER-COLVARS, collective variables library, "fix colvars"_fix_colvars.html, USER/colvars, int
"USER-DIFFRACTION"_Packages_details.html#USER-DIFFRACTION, virtual x-ray and electron diffraction,"compute xrd"_compute_xrd.html, USER/diffraction, -
"USER-DPD"_Packages_details.html#USER-DPD, reactive dissipative particle dynamics, src/USER-DPD/README, USER/dpd, -
"USER-DRUDE"_Packages_details.html#USER-DRUDE, Drude oscillators, "tutorial"_tutorial_drude.html, USER/drude, -
"USER-EFF"_Packages_details.html#USER-EFF, electron force field,"pair_style eff/cut"_pair_eff.html, USER/eff, -
"USER-FEP"_Packages_details.html#USER-FEP, free energy perturbation,"compute fep"_compute_fep.html, USER/fep, -
"USER-H5MD"_Packages_details.html#USER-H5MD, dump output via HDF5,"dump h5md"_dump_h5md.html, -, ext
"USER-INTEL"_Packages_details.html#USER-INTEL, optimized Intel CPU and KNL styles,"Speed intel"_Speed_intel.html, "Benchmarks"_http://lammps.sandia.gov/bench.html, -
"USER-LB"_Packages_details.html#USER-LB, Lattice Boltzmann fluid,"fix lb/fluid"_fix_lb_fluid.html, USER/lb, -
"USER-MANIFOLD"_Packages_details.html#USER-MANIFOLD, motion on 2d surfaces,"fix manifoldforce"_fix_manifoldforce.html, USER/manifold, -
"USER-MEAMC"_Packages_details.html#USER-MEAMC, modified EAM potential (C++), "pair_style meam/c"_pair_meam.html, meam, -
"USER-MESO"_Packages_details.html#USER-MESO, mesoscale DPD models, "pair_style edpd"_pair_meso.html, USER/meso, -
"USER-MGPT"_Packages_details.html#USER-MGPT, fast MGPT multi-ion potentials, "pair_style mgpt"_pair_mgpt.html, USER/mgpt, -
"USER-MISC"_Packages_details.html#USER-MISC, single-file contributions, USER-MISC/README, USER/misc, -
"USER-MOFFF"_Packages_details.html#USER-MOFFF, styles for "MOF-FF"_MOFplus force field, "pair_style buck6d/coul/gauss"_pair_buck6d_coul_gauss.html, USER/mofff, -
"USER-MOLFILE"_Packages_details.html#USER-MOLFILE, "VMD"_vmd_home molfile plug-ins,"dump molfile"_dump_molfile.html, -, ext
"USER-NETCDF"_Packages_details.html#USER-NETCDF, dump output via NetCDF,"dump netcdf"_dump_netcdf.html, -, ext
"USER-OMP"_Packages_details.html#USER-OMP, OpenMP-enabled styles,"Speed omp"_Speed_omp.html, "Benchmarks"_http://lammps.sandia.gov/bench.html, -
"USER-PHONON"_Packages_details.html#USER-PHONON, phonon dynamical matrix,"fix phonon"_fix_phonon.html, USER/phonon, -
"USER-QMMM"_Packages_details.html#USER-QMMM, QM/MM coupling,"fix qmmm"_fix_qmmm.html, USER/qmmm, ext
"USER-QTB"_Packages_details.html#USER-QTB, quantum nuclear effects,"fix qtb"_fix_qtb.html "fix qbmsst"_fix_qbmsst.html, qtb, -
"USER-QUIP"_Packages_details.html#USER-QUIP, QUIP/libatoms interface,"pair_style quip"_pair_quip.html, USER/quip, ext
"USER-REAXC"_Packages_details.html#USER-REAXC, ReaxFF potential (C/C++) ,"pair_style reaxc"_pair_reaxc.html, reax, -
"USER-SMD"_Packages_details.html#USER-SMD, smoothed Mach dynamics,"SMD User Guide"_PDF/SMD_LAMMPS_userguide.pdf, USER/smd, ext
"USER-SMTBQ"_Packages_details.html#USER-SMTBQ, second moment tight binding QEq potential,"pair_style smtbq"_pair_smtbq.html, USER/smtbq, -
"USER-SPH"_Packages_details.html#USER-SPH, smoothed particle hydrodynamics,"SPH User Guide"_PDF/SPH_LAMMPS_userguide.pdf, USER/sph, -
"USER-TALLY"_Packages_details.html#USER-TALLY, pairwise tally computes,"compute XXX/tally"_compute_tally.html, USER/tally, -
"USER-UEF"_Packages_details.html#USER-UEF, extensional flow,"fix nvt/uef"_fix_nh_uef.html, USER/uef, -
"USER-VTK"_Packages_details.html#USER-VTK, dump output via VTK, "compute vtk"_dump_vtk.html, -, ext :tb(ea=c,ca1=l)

79
doc/src/Python.txt Normal file
View File

@ -0,0 +1,79 @@
"Previous Section"_Modify.html - "LAMMPS WWW Site"_lws -
"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
Section"_Errors.html :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
Use Python with LAMMPS :h2
These doc pages describe various ways that LAMMPS and Python can be
used together.
<!-- RST
.. toctree::
Python_overview
.. toctree::
Python_run
Python_shlib
Python_install
Python_mpi
Python_test
Python_library
Python_pylammps
Python_examples
.. toctree::
Python_call
END_RST -->
<!-- HTML_ONLY -->
"Overview of Python and LAMMPS"_Python_overview.html :all(b)
"Run LAMMPS from Python"_Python_run.html
"Build LAMMPS as a shared library"_Python_shlib.html
"Install LAMMPS in Python"_Python_install.html
"Extend Python to run in parallel"_Python_mpi.html
"Test the Python/LAMMPS interface"_Python_test.html
"Python library interface"_Python_library.html
"PyLammps interface"_Python_pylammps.html
"Example Python scripts that use LAMMPS"_Python_examples.html :all(b)
"Call Python from a LAMMPS input script"_Python_call.html :all(b)
<!-- END_HTML_ONLY -->
If you're not familiar with "Python"_http://www.python.org, it's a
powerful scripting and programming language which can do most
everything that lower-level languages like C or C++ can do in fewer
lines of code. The only drawback is slower execution speed. Python
is also easy to use as a "glue" language to drive a program through
its library interface, or to hook multiple pieces of software
together, such as a simulation code plus a visualization tool, or to
run a coupled multiscale or multiphysics model.
See the "Howto_couple"_Howto_couple.html doc page for more ideas about
coupling LAMMPS to other codes. See the "Howto
library"_Howto_library.html doc page for a description of the LAMMPS
library interface provided in src/library.h and src/library.h. That
interface is exposed to Python either when calling LAMMPS from Python
or when calling Python from a LAMMPS input script and then calling
back to LAMMPS from Python code. The library interface is designed to
be easy to add funcionality to. Thus the Python interface to LAMMPS
is also easy to extend as well.
If you create interesting Python scripts that run LAMMPS or
interesting Python functions that can be called from a LAMMPS input
script, that you think would be genearlly useful, please post them as
a pull request to our "GitHub site"_https://github.com/lammps/lammps,
and they can be added to the LAMMPS distribution or webpage.

85
doc/src/Python_call.txt Normal file
View File

@ -0,0 +1,85 @@
"Higher level section"_Python.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
Call Python from a LAMMPS input script :h3
LAMMPS has several commands which can be used to invoke Python
code directly from an input script:
"python"_python.html
"variable python"_variable.html
"fix python/invoke"_fix_python_invoke.html
"pair_style python"_pair_python.html :ul
The "python"_python.html command which can be used to define and
execute a Python function that you write the code for. The Python
function can also be assigned to a LAMMPS python-style variable via
the "variable"_variable.html command. Each time the variable is
evaluated, either in the LAMMPS input script itself, or by another
LAMMPS command that uses the variable, this will trigger the Python
function to be invoked.
The Python code for the function can be included directly in the input
script or in an auxiliary file. The function can have arguments which
are mapped to LAMMPS variables (also defined in the input script) and
it can return a value to a LAMMPS variable. This is thus a mechanism
for your input script to pass information to a piece of Python code,
ask Python to execute the code, and return information to your input
script.
Note that a Python function can be arbitrarily complex. It can import
other Python modules, instantiate Python classes, call other Python
functions, etc. The Python code that you provide can contain more
code than the single function. It can contain other functions or
Python classes, as well as global variables or other mechanisms for
storing state between calls from LAMMPS to the function.
The Python function you provide can consist of "pure" Python code that
only performs operations provided by standard Python. However, the
Python function can also "call back" to LAMMPS through its
Python-wrapped library interface, in the manner described in the
"Python run"_Python_run.html doc page. This means it can issue LAMMPS
input script commands or query and set internal LAMMPS state. As an
example, this can be useful in an input script to create a more
complex loop with branching logic, than can be created using the
simple looping and branching logic enabled by the "next"_next.html and
"if"_if.html commands.
See the "python"_python.html doc page and the "variable"_variable.html
doc page for its python-style variables for more info, including
examples of Python code you can write for both pure Python operations
and callbacks to LAMMPS.
The "fix python/invoke"_fix_python_invoke.html command can execute
Python code at selected timesteps during a simulation run.
The "pair_style python"_pair_python command allows you to define
pairwise potentials as python code which encodes a single pairwise
interaction. This is useful for rapid-developement and debugging of a
new potential.
To use any of these commands, you only need to build LAMMPS with the
PYTHON package installed:
make yes-python
make machine :pre
Note that this will link LAMMPS with the Python library on your
system, which typically requires several auxiliary system libraries to
also be linked. The list of these libraries and the paths to find
them are specified in the lib/python/Makefile.lammps file. You need
to insure that file contains the correct information for your version
of Python and your machine to successfully build LAMMPS. See the
lib/python/README file for more info.
If you want to write Python code with callbacks to LAMMPS, then you
must also follow the steps overviewed in the "Python
run"_Python_run.html doc page. I.e. you must build LAMMPS as a shared
library and insure that Python can find the python/lammps.py file and
the shared library.

81
doc/src/Python_examples.txt Normal file
View File

@ -0,0 +1,81 @@
"Higher level section"_Python.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
Example Python scripts that use LAMMPS :h3
These are the Python scripts included as demos in the python/examples
directory of the LAMMPS distribution, to illustrate the kinds of
things that are possible when Python wraps LAMMPS. If you create your
own scripts, send them to us and we can include them in the LAMMPS
distribution.
trivial.py, read/run a LAMMPS input script thru Python,
demo.py, invoke various LAMMPS library interface routines,
simple.py, run in parallel, similar to examples/COUPLE/simple/simple.cpp,
split.py, same as simple.py but running in parallel on a subset of procs,
gui.py, GUI go/stop/temperature-slider to control LAMMPS,
plot.py, real-time temperature plot with GnuPlot via Pizza.py,
viz_tool.py, real-time viz via some viz package,
vizplotgui_tool.py, combination of viz_tool.py and plot.py and gui.py :tb(c=2)
:line
For the viz_tool.py and vizplotgui_tool.py commands, replace "tool"
with "gl" or "atomeye" or "pymol" or "vmd", depending on what
visualization package you have installed.
Note that for GL, you need to be able to run the Pizza.py GL tool,
which is included in the pizza sub-directory. See the "Pizza.py doc
pages"_pizza for more info:
:link(pizza,http://www.sandia.gov/~sjplimp/pizza.html)
Note that for AtomEye, you need version 3, and there is a line in the
scripts that specifies the path and name of the executable. See the
AtomEye WWW pages "here"_atomeye or "here"_atomeye3 for more details:
http://mt.seas.upenn.edu/Archive/Graphics/A
http://mt.seas.upenn.edu/Archive/Graphics/A3/A3.html :pre
:link(atomeye,http://mt.seas.upenn.edu/Archive/Graphics/A)
:link(atomeye3,http://mt.seas.upenn.edu/Archive/Graphics/A3/A3.html)
The latter link is to AtomEye 3 which has the scriping
capability needed by these Python scripts.
Note that for PyMol, you need to have built and installed the
open-source version of PyMol in your Python, so that you can import it
from a Python script. See the PyMol WWW pages "here"_pymolhome or
"here"_pymolopen for more details:
http://www.pymol.org
http://sourceforge.net/scm/?type=svn&group_id=4546 :pre
:link(pymolhome,http://www.pymol.org)
:link(pymolopen,http://sourceforge.net/scm/?type=svn&group_id=4546)
The latter link is to the open-source version.
Note that for VMD, you need a fairly current version (1.8.7 works for
me) and there are some lines in the pizza/vmd.py script for 4 PIZZA
variables that have to match the VMD installation on your system.
:line
See the python/README file for instructions on how to run them and the
source code for individual scripts for comments about what they do.
Here are screenshots of the vizplotgui_tool.py script in action for
different visualization package options. Click to see larger images:
:image(JPG/screenshot_gl_small.jpg,JPG/screenshot_gl.jpg)
:image(JPG/screenshot_atomeye_small.jpg,JPG/screenshot_atomeye.jpg)
:image(JPG/screenshot_pymol_small.jpg,JPG/screenshot_pymol.jpg)
:image(JPG/screenshot_vmd_small.jpg,JPG/screenshot_vmd.jpg)

74
doc/src/Python_install.txt Normal file
View File

@ -0,0 +1,74 @@
"Higher level section"_Python.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
Installing LAMMPS in Python :h3
For Python to invoke LAMMPS, there are 2 files it needs to know about:
python/lammps.py
src/liblammps.so :ul
Lammps.py is the Python wrapper on the LAMMPS library interface.
Liblammps.so is the shared LAMMPS library that Python loads, as
described above.
You can insure Python can find these files in one of two ways:
set two environment variables
run the python/install.py script :ul
If you set the paths to these files as environment variables, you only
have to do it once. For the csh or tcsh shells, add something like
this to your ~/.cshrc file, one line for each of the two files:
setenv PYTHONPATH $\{PYTHONPATH\}:/home/sjplimp/lammps/python
setenv LD_LIBRARY_PATH $\{LD_LIBRARY_PATH\}:/home/sjplimp/lammps/src :pre
If you use the python/install.py script, you need to invoke it every
time you rebuild LAMMPS (as a shared library) or make changes to the
python/lammps.py file.
You can invoke install.py from the python directory as
% python install.py \[libdir\] \[pydir\] :pre
The optional libdir is where to copy the LAMMPS shared library to; the
default is /usr/local/lib. The optional pydir is where to copy the
lammps.py file to; the default is the site-packages directory of the
version of Python that is running the install script.
Note that libdir must be a location that is in your default
LD_LIBRARY_PATH, like /usr/local/lib or /usr/lib. And pydir must be a
location that Python looks in by default for imported modules, like
its site-packages dir. If you want to copy these files to
non-standard locations, such as within your own user space, you will
need to set your PYTHONPATH and LD_LIBRARY_PATH environment variables
accordingly, as above.
If the install.py script does not allow you to copy files into system
directories, prefix the python command with "sudo". If you do this,
make sure that the Python that root runs is the same as the Python you
run. E.g. you may need to do something like
% sudo /usr/local/bin/python install.py \[libdir\] \[pydir\] :pre
You can also invoke install.py from the make command in the src
directory as
% make install-python :pre
In this mode you cannot append optional arguments. Again, you may
need to prefix this with "sudo". In this mode you cannot control
which Python is invoked by root.
Note that if you want Python to be able to load different versions of
the LAMMPS shared library (see "this section"_#py_5 below), you will
need to manually copy files like liblammps_g++.so into the appropriate
system directory. This is not needed if you set the LD_LIBRARY_PATH
environment variable as described above.

256
doc/src/Python_library.txt Normal file
View File

@ -0,0 +1,256 @@
"Higher level section"_Python.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
Python library interface :h3
As described previously, the Python interface to LAMMPS consists of a
Python "lammps" module, the source code for which is in
python/lammps.py, which creates a "lammps" object, with a set of
methods that can be invoked on that object. The sample Python code
below assumes you have first imported the "lammps" module in your
Python script, as follows:
from lammps import lammps :pre
These are the methods defined by the lammps module. If you look at
the files src/library.cpp and src/library.h you will see they
correspond one-to-one with calls you can make to the LAMMPS library
from a C++ or C or Fortran program, and which are described in
"Section 6.19"_Section_howto.html#howto_19 of the manual.
The python/examples directory has Python scripts which show how Python
can run LAMMPS, grab data, change it, and put it back into LAMMPS.
lmp = lammps() # create a LAMMPS object using the default liblammps.so library
# 4 optional args are allowed: name, cmdargs, ptr, comm
lmp = lammps(ptr=lmpptr) # use lmpptr as previously created LAMMPS object
lmp = lammps(comm=split) # create a LAMMPS object with a custom communicator, requires mpi4py 2.0.0 or later
lmp = lammps(name="g++") # create a LAMMPS object using the liblammps_g++.so library
lmp = lammps(name="g++",cmdargs=list) # add LAMMPS command-line args, e.g. list = \["-echo","screen"\] :pre
lmp.close() # destroy a LAMMPS object :pre
version = lmp.version() # return the numerical version id, e.g. LAMMPS 2 Sep 2015 -> 20150902 :pre
lmp.file(file) # run an entire input script, file = "in.lj"
lmp.command(cmd) # invoke a single LAMMPS command, cmd = "run 100"
lmp.commands_list(cmdlist) # invoke commands in cmdlist = ["run 10", "run 20"]
lmp.commands_string(multicmd) # invoke commands in multicmd = "run 10\nrun 20" :pre
size = lmp.extract_setting(name) # return data type info :pre
xlo = lmp.extract_global(name,type) # extract a global quantity
# name = "boxxlo", "nlocal", etc
# type = 0 = int
# 1 = double :pre
boxlo,boxhi,xy,yz,xz,periodicity,box_change = lmp.extract_box() # extract box info :pre
coords = lmp.extract_atom(name,type) # extract a per-atom quantity
# name = "x", "type", etc
# type = 0 = vector of ints
# 1 = array of ints
# 2 = vector of doubles
# 3 = array of doubles :pre
eng = lmp.extract_compute(id,style,type) # extract value(s) from a compute
v3 = lmp.extract_fix(id,style,type,i,j) # extract value(s) from a fix
# id = ID of compute or fix
# style = 0 = global data
# 1 = per-atom data
# 2 = local data
# type = 0 = scalar
# 1 = vector
# 2 = array
# i,j = indices of value in global vector or array :pre
var = lmp.extract_variable(name,group,flag) # extract value(s) from a variable
# name = name of variable
# group = group ID (ignored for equal-style variables)
# flag = 0 = equal-style variable
# 1 = atom-style variable :pre
value = lmp.get_thermo(name) # return current value of a thermo keyword
natoms = lmp.get_natoms() # total # of atoms as int :pre
flag = lmp.set_variable(name,value) # set existing named string-style variable to value, flag = 0 if successful
lmp.reset_box(boxlo,boxhi,xy,yz,xz) # reset the simulation box size :pre
data = lmp.gather_atoms(name,type,count) # return per-atom property of all atoms gathered into data, ordered by atom ID
# name = "x", "charge", "type", etc
data = lmp.gather_atoms_concat(name,type,count) # ditto, but concatenated atom values from each proc (unordered)
data = lmp.gather_atoms_subset(name,type,count,ndata,ids) # ditto, but for subset of Ndata atoms with IDs :pre
lmp.scatter_atoms(name,type,count,data) # scatter per-atom property to all atoms from data, ordered by atom ID
# name = "x", "charge", "type", etc
# count = # of per-atom values, 1 or 3, etc :pre
lmp.scatter_atoms_subset(name,type,count,ndata,ids,data) # ditto, but for subset of Ndata atoms with IDs :pre
lmp.create_atoms(n,ids,types,x,v,image,shrinkexceed) # create N atoms with IDs, types, x, v, and image flags :pre
:line
The lines
from lammps import lammps
lmp = lammps() :pre
create an instance of LAMMPS, wrapped in a Python class by the lammps
Python module, and return an instance of the Python class as lmp. It
is used to make all subsequent calls to the LAMMPS library.
Additional arguments to lammps() can be used to tell Python the name
of the shared library to load or to pass arguments to the LAMMPS
instance, the same as if LAMMPS were launched from a command-line
prompt.
If the ptr argument is set like this:
lmp = lammps(ptr=lmpptr) :pre
then lmpptr must be an argument passed to Python via the LAMMPS
"python"_python.html command, when it is used to define a Python
function that is invoked by the LAMMPS input script. This mode of
calling Python from LAMMPS is described in the "Python
call"_Python_call.html doc page. The variable lmpptr refers to the
instance of LAMMPS that called the embedded Python interpreter. Using
it as an argument to lammps() allows the returned Python class
instance "lmp" to make calls to that instance of LAMMPS. See the
"python"_python.html command doc page for examples using this syntax.
Note that you can create multiple LAMMPS objects in your Python
script, and coordinate and run multiple simulations, e.g.
from lammps import lammps
lmp1 = lammps()
lmp2 = lammps()
lmp1.file("in.file1")
lmp2.file("in.file2") :pre
The file(), command(), commands_list(), commands_string() methods
allow an input script, a single command, or multiple commands to be
invoked.
The extract_setting(), extract_global(), extract_box(),
extract_atom(), extract_compute(), extract_fix(), and
extract_variable() methods return values or pointers to data
structures internal to LAMMPS.
For extract_global() see the src/library.cpp file for the list of
valid names. New names could easily be added. A double or integer is
returned. You need to specify the appropriate data type via the type
argument.
For extract_atom(), a pointer to internal LAMMPS atom-based data is
returned, which you can use via normal Python subscripting. See the
extract() method in the src/atom.cpp file for a list of valid names.
Again, new names could easily be added if the property you want is not
listed. A pointer to a vector of doubles or integers, or a pointer to
an array of doubles (double **) or integers (int **) is returned. You
need to specify the appropriate data type via the type argument.
For extract_compute() and extract_fix(), the global, per-atom, or
local data calculated by the compute or fix can be accessed. What is
returned depends on whether the compute or fix calculates a scalar or
vector or array. For a scalar, a single double value is returned. If
the compute or fix calculates a vector or array, a pointer to the
internal LAMMPS data is returned, which you can use via normal Python
subscripting. The one exception is that for a fix that calculates a
global vector or array, a single double value from the vector or array
is returned, indexed by I (vector) or I and J (array). I,J are
zero-based indices. The I,J arguments can be left out if not needed.
See "Section 6.15"_Section_howto.html#howto_15 of the manual for a
discussion of global, per-atom, and local data, and of scalar, vector,
and array data types. See the doc pages for individual
"computes"_compute.html and "fixes"_fix.html for a description of what
they calculate and store.
For extract_variable(), an "equal-style or atom-style
variable"_variable.html is evaluated and its result returned.
For equal-style variables a single double value is returned and the
group argument is ignored. For atom-style variables, a vector of
doubles is returned, one value per atom, which you can use via normal
Python subscripting. The values will be zero for atoms not in the
specified group.
The get_thermo() method returns returns the current value of a thermo
keyword as a float.
The get_natoms() method returns the total number of atoms in the
simulation, as an int.
The set_variable() methosd sets an existing string-style variable to a
new string value, so that subsequent LAMMPS commands can access the
variable.
The reset_box() emthods resets the size and shape of the simulation
box, e.g. as part of restoring a previously extracted and saved state
of a simulation.
The gather methods collect peratom info of the requested type (atom
coords, atom types, forces, etc) from all processors, and returns the
same vector of values to each callling processor. The scatter
functions do the inverse. They distribute a vector of peratom values,
passed by all calling processors, to invididual atoms, which may be
owned by different processos.
Note that the data returned by the gather methods,
e.g. gather_atoms("x"), is different from the data structure returned
by extract_atom("x") in four ways. (1) Gather_atoms() returns a
vector which you index as x\[i\]; extract_atom() returns an array
which you index as x\[i\]\[j\]. (2) Gather_atoms() orders the atoms
by atom ID while extract_atom() does not. (3) Gather_atoms() returns
a list of all atoms in the simulation; extract_atoms() returns just
the atoms local to each processor. (4) Finally, the gather_atoms()
data structure is a copy of the atom coords stored internally in
LAMMPS, whereas extract_atom() returns an array that effectively
points directly to the internal data. This means you can change
values inside LAMMPS from Python by assigning a new values to the
extract_atom() array. To do this with the gather_atoms() vector, you
need to change values in the vector, then invoke the scatter_atoms()
method.
For the scatter methods, the array of coordinates passed to must be a
ctypes vector of ints or doubles, allocated and initialized something
like this:
from ctypes import *
natoms = lmp.get_natoms()
n3 = 3*natoms
x = (n3*c_double)()
x\[0\] = x coord of atom with ID 1
x\[1\] = y coord of atom with ID 1
x\[2\] = z coord of atom with ID 1
x\[3\] = x coord of atom with ID 2
...
x\[n3-1\] = z coord of atom with ID natoms
lmp.scatter_atoms("x",1,3,x) :pre
Alternatively, you can just change values in the vector returned by
the gather methods, since they are also ctypes vectors.
:line
As noted above, these Python class methods correspond one-to-one with
the functions in the LAMMPS library interface in src/library.cpp and
library.h. This means you can extend the Python wrapper via the
following steps:
Add a new interface function to src/library.cpp and
src/library.h. :ulb,l
Rebuild LAMMPS as a shared library. :l
Add a wrapper method to python/lammps.py for this interface
function. :l
You should now be able to invoke the new interface function from a
Python script. :l
:ule

67
doc/src/Python_mpi.txt Normal file
View File

@ -0,0 +1,67 @@
"Higher level section"_Python.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
Extending Python to run in parallel :h3
If you wish to run LAMMPS in parallel from Python, you need to extend
your Python with an interface to MPI. This also allows you to
make MPI calls directly from Python in your script, if you desire.
We recommend use of mpi4py:
"PyPar"_https://github.com/daleroberts/pypar :ul
As of version 2.0.0 it allows passing a custom MPI communicator to
the LAMMPS constructor, which means one can easily run one or more
LAMMPS instances on subsets of the total MPI ranks.
To install mpi4py (version mpi4py-2.0.0 as of Oct 2015), unpack it
and from its main directory, type
python setup.py build
sudo python setup.py install :pre
Again, the "sudo" is only needed if required to copy mpi4py files into
your Python distribution's site-packages directory. To install with
user privilege into the user local directory type
python setup.py install --user :pre
If you have successfully installed mpi4py, you should be able to run
Python and type
from mpi4py import MPI :pre
without error. You should also be able to run python in parallel
on a simple test script
% mpirun -np 4 python test.py :pre
where test.py contains the lines
from mpi4py import MPI
comm = MPI.COMM_WORLD
print "Proc %d out of %d procs" % (comm.Get_rank(),comm.Get_size()) :pre
and see one line of output for each processor you run on.
NOTE: To use mpi4py and LAMMPS in parallel from Python, you must
insure both are using the same version of MPI. If you only have one
MPI installed on your system, this is not an issue, but it can be if
you have multiple MPIs. Your LAMMPS build is explicit about which MPI
it is using, since you specify the details in your lo-level
src/MAKE/Makefile.foo file. Mpi4py uses the "mpicc" command to find
information about the MPI it uses to build against. And it tries to
load "libmpi.so" from the LD_LIBRARY_PATH. This may or may not find
the MPI library that LAMMPS is using. If you have problems running
both mpi4py and LAMMPS together, this is an issue you may need to
address, e.g. by moving other MPI installations so that mpi4py finds
the right one.

35
doc/src/Python_overview.txt Normal file
View File

@ -0,0 +1,35 @@
"Previous Section"_Examples.html - "LAMMPS WWW Site"_lws -
"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
Section"_Tools.html :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands.html#comm)
:line
Overview of Python and LAMMPS :h3
LAMMPS can work together with Python in three ways. First, Python can
wrap LAMMPS through the its "library interface"_Howto_library.html, so
that a Python script can create one or more instances of LAMMPS and
launch one or more simulations. In Python lingo, this is "extending"
Python with LAMMPS.
Second, a lower-level Python interface can be used indirectly through
provided PyLammps and IPyLammps wrapper classes, written in Python.
These wrappers try to simplify the usage of LAMMPS in Python by
providing an object-based interface to common LAMMPS functionality.
They also reduces the amount of code necessary to parameterize LAMMPS
scripts through Python and make variables and computes directly
accessible.
Third, LAMMPS can use the Python interpreter, so that a LAMMPS
input script can invoke Python code directly, and pass information
back-and-forth between the input script and Python functions you
write. This Python code can also callback to LAMMPS to query or change
its attributes. In Python lingo, this is "embedding" Python in
LAMMPS. When used in this mode, Python can perform operations that
the simple LAMMPS input script syntax cannot.

14
doc/src/Python_pylammps.txt Normal file
View File

@ -0,0 +1,14 @@
"Higher level section"_Python.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
PyLammps interface :h3
PyLammps is a Python wrapper class which can be created on its own or
use an existing lammps Python object. It has its own "PyLammps
Tutorial"_tutorial_pylammps.html doc page.

40
doc/src/Python_run.txt Normal file
View File

@ -0,0 +1,40 @@
"Higher level section"_Python.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
Run LAMMPS from Python :h3
The LAMMPS distribution includes a python directory with all you need
to run LAMMPS from Python. The python/lammps.py file wraps the LAMMPS
library interface, with one wrapper function per LAMMPS library
function. This file makes it is possible to do the following either
from a Python script, or interactively from a Python prompt: create
one or more instances of LAMMPS, invoke LAMMPS commands or give it an
input script, run LAMMPS incrementally, extract LAMMPS results, an
modify internal LAMMPS variables. From a Python script you can do
this in serial or parallel. Running Python interactively in parallel
does not generally work, unless you have a version of Python that
extends Python to enable multiple instances of Python to read what you
type.
To do all of this, you must first build LAMMPS as a shared library,
then insure that your Python can find the python/lammps.py file and
the shared library.
Two advantages of using Python to run LAMMPS are how concise the
language is, and that it can be run interactively, enabling rapid
development and debugging. If you use it to mostly invoke costly
operations within LAMMPS, such as running a simulation for a
reasonable number of timesteps, then the overhead cost of invoking
LAMMPS thru Python will be negligible.
The Python wrapper for LAMMPS uses the "ctypes" package in Python,
which auto-generates the interface code needed between Python and a
set of C-style library functions. Ctypes is part of standard Python
for versions 2.5 and later. You can check which version of Python you
have by simply typing "python" at a shell prompt.

34
doc/src/Python_shlib.txt Normal file
View File

@ -0,0 +1,34 @@
"Higher level section"_Python.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
Build LAMMPS as a shared library :h3
Instructions on how to build LAMMPS as a shared library are given in
"Section 2.4"_Section_start.html#start_4. A shared library is one
that is dynamically loadable, which is what Python requires to wrap
LAMMPS. On Linux this is a library file that ends in ".so", not ".a".
From the src directory, type
make foo mode=shlib :pre
where foo is the machine target name, such as mpi or serial.
This should create the file liblammps_foo.so in the src directory, as
well as a soft link liblammps.so, which is what the Python wrapper will
load by default. Note that if you are building multiple machine
versions of the shared library, the soft link is always set to the
most recently built version.
NOTE: If you are building LAMMPS with an MPI or FFT library or other
auxiliary libraries (used by various packages), then all of these
extra libraries must also be shared libraries. If the LAMMPS
shared-library build fails with an error complaining about this, see
"Section 2.4"_Section_start.html#start_4 for more details.
Also include CMake info on this

131
doc/src/Python_test.txt Normal file
View File

@ -0,0 +1,131 @@
"Higher level section"_Python.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
Test the Python/LAMMPS interface :h3
To test if LAMMPS is callable from Python, launch Python interactively
and type:
>>> from lammps import lammps
>>> lmp = lammps() :pre
If you get no errors, you're ready to use LAMMPS from Python. If the
2nd command fails, the most common error to see is
OSError: Could not load LAMMPS dynamic library :pre
which means Python was unable to load the LAMMPS shared library. This
typically occurs if the system can't find the LAMMPS shared library or
one of the auxiliary shared libraries it depends on, or if something
about the library is incompatible with your Python. The error message
should give you an indication of what went wrong.
You can also test the load directly in Python as follows, without
first importing from the lammps.py file:
>>> from ctypes import CDLL
>>> CDLL("liblammps.so") :pre
If an error occurs, carefully go thru the steps in "Section
2.4"_Section_start.html#start_4 and above about building a shared
library and about insuring Python can find the necessary two files
it needs.
[Test LAMMPS and Python in serial:] :h4
To run a LAMMPS test in serial, type these lines into Python
interactively from the bench directory:
>>> from lammps import lammps
>>> lmp = lammps()
>>> lmp.file("in.lj") :pre
Or put the same lines in the file test.py and run it as
% python test.py :pre
Either way, you should see the results of running the in.lj benchmark
on a single processor appear on the screen, the same as if you had
typed something like:
lmp_g++ -in in.lj :pre
[Test LAMMPS and Python in parallel:] :h4
To run LAMMPS in parallel, assuming you have installed the
"PyPar"_https://github.com/daleroberts/pypar package as discussed
above, create a test.py file containing these lines:
import pypar
from lammps import lammps
lmp = lammps()
lmp.file("in.lj")
print "Proc %d out of %d procs has" % (pypar.rank(),pypar.size()),lmp
pypar.finalize() :pre
To run LAMMPS in parallel, assuming you have installed the
"mpi4py"_https://bitbucket.org/mpi4py/mpi4py package as discussed
above, create a test.py file containing these lines:
from mpi4py import MPI
from lammps import lammps
lmp = lammps()
lmp.file("in.lj")
me = MPI.COMM_WORLD.Get_rank()
nprocs = MPI.COMM_WORLD.Get_size()
print "Proc %d out of %d procs has" % (me,nprocs),lmp
MPI.Finalize() :pre
You can either script in parallel as:
% mpirun -np 4 python test.py :pre
and you should see the same output as if you had typed
% mpirun -np 4 lmp_g++ -in in.lj :pre
Note that if you leave out the 3 lines from test.py that specify PyPar
commands you will instantiate and run LAMMPS independently on each of
the P processors specified in the mpirun command. In this case you
should get 4 sets of output, each showing that a LAMMPS run was made
on a single processor, instead of one set of output showing that
LAMMPS ran on 4 processors. If the 1-processor outputs occur, it
means that PyPar is not working correctly.
Also note that once you import the PyPar module, PyPar initializes MPI
for you, and you can use MPI calls directly in your Python script, as
described in the PyPar documentation. The last line of your Python
script should be pypar.finalize(), to insure MPI is shut down
correctly.
[Running Python scripts:] :h4
Note that any Python script (not just for LAMMPS) can be invoked in
one of several ways:
% python foo.script
% python -i foo.script
% foo.script :pre
The last command requires that the first line of the script be
something like this:
#!/usr/local/bin/python
#!/usr/local/bin/python -i :pre
where the path points to where you have Python installed, and that you
have made the script file executable:
% chmod +x foo.script :pre
Without the "-i" flag, Python will exit when the script finishes.
With the "-i" flag, you will be left in the Python interpreter when
the script finishes, so you can type subsequent commands. As
mentioned above, you can only run Python interactively when running
Python on a single processor, not in parallel.

391
doc/src/Section_accelerate.txt
View File

@ -1,391 +0,0 @@
"Previous Section"_Section_packages.html - "LAMMPS WWW Site"_lws -
"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
Section"_Section_howto.html :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
5. Accelerating LAMMPS performance :h2
This section describes various methods for improving LAMMPS
performance for different classes of problems running on different
kinds of machines.
There are two thrusts to the discussion that follows. The
first is using code options that implement alternate algorithms
that can speed-up a simulation. The second is to use one
of the several accelerator packages provided with LAMMPS that
contain code optimized for certain kinds of hardware, including
multi-core CPUs, GPUs, and Intel Xeon Phi coprocessors.
5.1 "Measuring performance"_#acc_1 :ulb,l
5.2 "Algorithms and code options to boost performace"_#acc_2 :l
5.3 "Accelerator packages with optimized styles"_#acc_3 :l
5.3.1 "GPU package"_accelerate_gpu.html :l
5.3.2 "USER-INTEL package"_accelerate_intel.html :l
5.3.3 "KOKKOS package"_accelerate_kokkos.html :l
5.3.4 "USER-OMP package"_accelerate_omp.html :l
5.3.5 "OPT package"_accelerate_opt.html :l
5.4 "Comparison of various accelerator packages"_#acc_4 :l
:ule
The "Benchmark page"_http://lammps.sandia.gov/bench.html of the LAMMPS
web site gives performance results for the various accelerator
packages discussed in Section 5.2, for several of the standard LAMMPS
benchmark problems, as a function of problem size and number of
compute nodes, on different hardware platforms.
:line
:line
5.1 Measuring performance :h3,link(acc_1)
Before trying to make your simulation run faster, you should
understand how it currently performs and where the bottlenecks are.
The best way to do this is run the your system (actual number of
atoms) for a modest number of timesteps (say 100 steps) on several
different processor counts, including a single processor if possible.
Do this for an equilibrium version of your system, so that the
100-step timings are representative of a much longer run. There is
typically no need to run for 1000s of timesteps to get accurate
timings; you can simply extrapolate from short runs.
For the set of runs, look at the timing data printed to the screen and
log file at the end of each LAMMPS run. "This
section"_Section_start.html#start_7 of the manual has an overview.
Running on one (or a few processors) should give a good estimate of
the serial performance and what portions of the timestep are taking
the most time. Running the same problem on a few different processor
counts should give an estimate of parallel scalability. I.e. if the
simulation runs 16x faster on 16 processors, its 100% parallel
efficient; if it runs 8x faster on 16 processors, it's 50% efficient.
The most important data to look at in the timing info is the timing
breakdown and relative percentages. For example, trying different
options for speeding up the long-range solvers will have little impact
if they only consume 10% of the run time. If the pairwise time is
dominating, you may want to look at GPU or OMP versions of the pair
style, as discussed below. Comparing how the percentages change as
you increase the processor count gives you a sense of how different
operations within the timestep are scaling. Note that if you are
running with a Kspace solver, there is additional output on the
breakdown of the Kspace time. For PPPM, this includes the fraction
spent on FFTs, which can be communication intensive.
Another important detail in the timing info are the histograms of
atoms counts and neighbor counts. If these vary widely across
processors, you have a load-imbalance issue. This often results in
inaccurate relative timing data, because processors have to wait when
communication occurs for other processors to catch up. Thus the
reported times for "Communication" or "Other" may be higher than they
really are, due to load-imbalance. If this is an issue, you can
uncomment the MPI_Barrier() lines in src/timer.cpp, and recompile
LAMMPS, to obtain synchronized timings.
:line
5.2 General strategies :h3,link(acc_2)
NOTE: this section 5.2 is still a work in progress
Here is a list of general ideas for improving simulation performance.
Most of them are only applicable to certain models and certain
bottlenecks in the current performance, so let the timing data you
generate be your guide. It is hard, if not impossible, to predict how
much difference these options will make, since it is a function of
problem size, number of processors used, and your machine. There is
no substitute for identifying performance bottlenecks, and trying out
various options.
rRESPA
2-FFT PPPM
Staggered PPPM
single vs double PPPM
partial charge PPPM
verlet/split run style
processor command for proc layout and numa layout
load-balancing: balance and fix balance :ul
2-FFT PPPM, also called {analytic differentiation} or {ad} PPPM, uses
2 FFTs instead of the 4 FFTs used by the default {ik differentiation}
PPPM. However, 2-FFT PPPM also requires a slightly larger mesh size to
achieve the same accuracy as 4-FFT PPPM. For problems where the FFT
cost is the performance bottleneck (typically large problems running
on many processors), 2-FFT PPPM may be faster than 4-FFT PPPM.
Staggered PPPM performs calculations using two different meshes, one
shifted slightly with respect to the other. This can reduce force
aliasing errors and increase the accuracy of the method, but also
doubles the amount of work required. For high relative accuracy, using
staggered PPPM allows one to half the mesh size in each dimension as
compared to regular PPPM, which can give around a 4x speedup in the
kspace time. However, for low relative accuracy, using staggered PPPM
gives little benefit and can be up to 2x slower in the kspace
time. For example, the rhodopsin benchmark was run on a single
processor, and results for kspace time vs. relative accuracy for the
different methods are shown in the figure below. For this system,
staggered PPPM (using ik differentiation) becomes useful when using a
relative accuracy of slightly greater than 1e-5 and above.
:c,image(JPG/rhodo_staggered.jpg)
NOTE: Using staggered PPPM may not give the same increase in accuracy
of energy and pressure as it does in forces, so some caution must be
used if energy and/or pressure are quantities of interest, such as
when using a barostat.
:line
5.3 Packages with optimized styles :h3,link(acc_3)
Accelerated versions of various "pair_style"_pair_style.html,
"fixes"_fix.html, "computes"_compute.html, and other commands have
been added to LAMMPS, which will typically run faster than the
standard non-accelerated versions. Some require appropriate hardware
to be present on your system, e.g. GPUs or Intel Xeon Phi
coprocessors.
All of these commands are in packages provided with LAMMPS. An
overview of packages is give in "Section
packages"_Section_packages.html.
These are the accelerator packages
currently in LAMMPS, either as standard or user packages:
"GPU Package"_accelerate_gpu.html : for NVIDIA GPUs as well as OpenCL support
"USER-INTEL Package"_accelerate_intel.html : for Intel CPUs and Intel Xeon Phi
"KOKKOS Package"_accelerate_kokkos.html : for Nvidia GPUs, Intel Xeon Phi, and OpenMP threading
"USER-OMP Package"_accelerate_omp.html : for OpenMP threading and generic CPU optimizations
"OPT Package"_accelerate_opt.html : generic CPU optimizations :tb(s=:)
<!-- RST
.. toctree::
:maxdepth: 1
:hidden:
accelerate_gpu
accelerate_intel
accelerate_kokkos
accelerate_omp
accelerate_opt
END_RST -->
Inverting this list, LAMMPS currently has acceleration support for
three kinds of hardware, via the listed packages:
Many-core CPUs : "USER-INTEL"_accelerate_intel.html, "KOKKOS"_accelerate_kokkos.html, "USER-OMP"_accelerate_omp.html, "OPT"_accelerate_opt.html packages
NVIDIA GPUs : "GPU"_accelerate_gpu.html, "KOKKOS"_accelerate_kokkos.html packages
Intel Phi : "USER-INTEL"_accelerate_intel.html, "KOKKOS"_accelerate_kokkos.html packages :tb(s=:)
Which package is fastest for your hardware may depend on the size
problem you are running and what commands (accelerated and
non-accelerated) are invoked by your input script. While these doc
pages include performance guidelines, there is no substitute for
trying out the different packages appropriate to your hardware.
Any accelerated style has the same name as the corresponding standard
style, except that a suffix is appended. Otherwise, the syntax for
the command that uses the style is identical, their functionality is
the same, and the numerical results it produces should also be the
same, except for precision and round-off effects.
For example, all of these styles are accelerated variants of the
Lennard-Jones "pair_style lj/cut"_pair_lj.html:
"pair_style lj/cut/gpu"_pair_lj.html
"pair_style lj/cut/intel"_pair_lj.html
"pair_style lj/cut/kk"_pair_lj.html
"pair_style lj/cut/omp"_pair_lj.html
"pair_style lj/cut/opt"_pair_lj.html :ul
To see what accelerate styles are currently available, see
"Section 3.5"_Section_commands.html#cmd_5 of the manual. The
doc pages for individual commands (e.g. "pair lj/cut"_pair_lj.html or
"fix nve"_fix_nve.html) also list any accelerated variants available
for that style.
To use an accelerator package in LAMMPS, and one or more of the styles
it provides, follow these general steps. Details vary from package to
package and are explained in the individual accelerator doc pages,
listed above:
build the accelerator library |
only for GPU package |
install the accelerator package |
make yes-opt, make yes-user-intel, etc |
add compile/link flags to Makefile.machine in src/MAKE |
only for USER-INTEL, KOKKOS, USER-OMP, OPT packages |
re-build LAMMPS |
make machine |
prepare and test a regular LAMMPS simulation |
lmp_machine -in in.script; mpirun -np 32 lmp_machine -in in.script |
enable specific accelerator support via '-k on' "command-line switch"_Section_start.html#start_6, |
only needed for KOKKOS package |
set any needed options for the package via "-pk" "command-line switch"_Section_start.html#start_6 or "package"_package.html command, |
only if defaults need to be changed |
use accelerated styles in your input via "-sf" "command-line switch"_Section_start.html#start_6 or "suffix"_suffix.html command | lmp_machine -in in.script -sf gpu
:tb(c=2,s=|)
Note that the first 4 steps can be done as a single command with
suitable make command invocations. This is discussed in "Section
4"_Section_packages.html of the manual, and its use is
illustrated in the individual accelerator sections. Typically these
steps only need to be done once, to create an executable that uses one
or more accelerator packages.
The last 4 steps can all be done from the command-line when LAMMPS is
launched, without changing your input script, as illustrated in the
individual accelerator sections. Or you can add
"package"_package.html and "suffix"_suffix.html commands to your input
script.
NOTE: With a few exceptions, you can build a single LAMMPS executable
with all its accelerator packages installed. Note however that the
USER-INTEL and KOKKOS packages require you to choose one of their
hardware options when building for a specific platform. I.e. CPU or
Phi option for the USER-INTEL package. Or the OpenMP, Cuda, or Phi
option for the KOKKOS package.
These are the exceptions. You cannot build a single executable with:
both the USER-INTEL Phi and KOKKOS Phi options
the USER-INTEL Phi or Kokkos Phi option, and the GPU package :ul
See the examples/accelerate/README and make.list files for sample
Make.py commands that build LAMMPS with any or all of the accelerator
packages. As an example, here is a command that builds with all the
GPU related packages installed (GPU, KOKKOS with Cuda), including
settings to build the needed auxiliary GPU libraries for Kepler GPUs:
Make.py -j 16 -p omp gpu kokkos -cc nvcc wrap=mpi \
-gpu mode=double arch=35 -kokkos cuda arch=35 lib-all file mpi :pre
The examples/accelerate directory also has input scripts that can be
used with all of the accelerator packages. See its README file for
details.
Likewise, the bench directory has FERMI and KEPLER and PHI
sub-directories with Make.py commands and input scripts for using all
the accelerator packages on various machines. See the README files in
those dirs.
As mentioned above, the "Benchmark
page"_http://lammps.sandia.gov/bench.html of the LAMMPS web site gives
performance results for the various accelerator packages for several
of the standard LAMMPS benchmark problems, as a function of problem
size and number of compute nodes, on different hardware platforms.
Here is a brief summary of what the various packages provide. Details
are in the individual accelerator sections.
Styles with a "gpu" suffix are part of the GPU package, and can be run
on NVIDIA GPUs. The speed-up on a GPU depends on a variety of
factors, discussed in the accelerator sections. :ulb,l
Styles with an "intel" suffix are part of the USER-INTEL
package. These styles support vectorized single and mixed precision
calculations, in addition to full double precision. In extreme cases,
this can provide speedups over 3.5x on CPUs. The package also
supports acceleration in "offload" mode to Intel(R) Xeon Phi(TM)
coprocessors. This can result in additional speedup over 2x depending
on the hardware configuration. :l
Styles with a "kk" suffix are part of the KOKKOS package, and can be
run using OpenMP on multicore CPUs, on an NVIDIA GPU, or on an Intel
Xeon Phi in "native" mode. The speed-up depends on a variety of
factors, as discussed on the KOKKOS accelerator page. :l
Styles with an "omp" suffix are part of the USER-OMP package and allow
a pair-style to be run in multi-threaded mode using OpenMP. This can
be useful on nodes with high-core counts when using less MPI processes
than cores is advantageous, e.g. when running with PPPM so that FFTs
are run on fewer MPI processors or when the many MPI tasks would
overload the available bandwidth for communication. :l
Styles with an "opt" suffix are part of the OPT package and typically
speed-up the pairwise calculations of your simulation by 5-25% on a
CPU. :l
:ule
The individual accelerator package doc pages explain:
what hardware and software the accelerated package requires
how to build LAMMPS with the accelerated package
how to run with the accelerated package either via command-line switches or modifying the input script
speed-ups to expect
guidelines for best performance
restrictions :ul
:line
5.4 Comparison of various accelerator packages :h3,link(acc_4)
NOTE: this section still needs to be re-worked with additional KOKKOS
and USER-INTEL information.
The next section compares and contrasts the various accelerator
options, since there are multiple ways to perform OpenMP threading,
run on GPUs, and run on Intel Xeon Phi coprocessors.
All 3 of these packages accelerate a LAMMPS calculation using NVIDIA
hardware, but they do it in different ways.
As a consequence, for a particular simulation on specific hardware,
one package may be faster than the other. We give guidelines below,
but the best way to determine which package is faster for your input
script is to try both of them on your machine. See the benchmarking
section below for examples where this has been done.
[Guidelines for using each package optimally:]
The GPU package allows you to assign multiple CPUs (cores) to a single
GPU (a common configuration for "hybrid" nodes that contain multicore
CPU(s) and GPU(s)) and works effectively in this mode. :ulb,l
The GPU package moves per-atom data (coordinates, forces)
back-and-forth between the CPU and GPU every timestep. The
KOKKOS/CUDA package only does this on timesteps when a CPU calculation
is required (e.g. to invoke a fix or compute that is non-GPU-ized).
Hence, if you can formulate your input script to only use GPU-ized
fixes and computes, and avoid doing I/O too often (thermo output, dump
file snapshots, restart files), then the data transfer cost of the
KOKKOS/CUDA package can be very low, causing it to run faster than the
GPU package. :l
The GPU package is often faster than the KOKKOS/CUDA package, if the
number of atoms per GPU is smaller. The crossover point, in terms of
atoms/GPU at which the KOKKOS/CUDA package becomes faster depends
strongly on the pair style. For example, for a simple Lennard Jones
system the crossover (in single precision) is often about 50K-100K
atoms per GPU. When performing double precision calculations the
crossover point can be significantly smaller. :l
Both packages compute bonded interactions (bonds, angles, etc) on the
CPU. If the GPU package is running with several MPI processes
assigned to one GPU, the cost of computing the bonded interactions is
spread across more CPUs and hence the GPU package can run faster. :l
When using the GPU package with multiple CPUs assigned to one GPU, its
performance depends to some extent on high bandwidth between the CPUs
and the GPU. Hence its performance is affected if full 16 PCIe lanes
are not available for each GPU. In HPC environments this can be the
case if S2050/70 servers are used, where two devices generally share
one PCIe 2.0 16x slot. Also many multi-GPU mainboards do not provide
full 16 lanes to each of the PCIe 2.0 16x slots. :l
:ule
[Differences between the two packages:]
The GPU package accelerates only pair force, neighbor list, and PPPM
calculations. :ulb,l
The GPU package requires neighbor lists to be built on the CPU when using
exclusion lists, hybrid pair styles, or a triclinic simulation box. :l
:ule

64
doc/src/Section_commands.txt
View File

@ -1,4 +1,4 @@
"Previous Section"_Section_start.html - "LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next Section"_Section_packages.html :c
"Previous Section"_Section_start.html - "LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next Section"_Packages.html :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
@ -67,7 +67,7 @@ values are not desired, the "processors"_processors.html and
tell LAMMPS how to map processors to the simulation box.
Many input script errors are detected by LAMMPS and an ERROR or
WARNING message is printed. "This section"_Section_errors.html gives
WARNING message is printed. The "Errors"_Errors.html doc page gives
more information on what errors mean. The documentation for each
command lists restrictions on how the command can be used.
@ -204,10 +204,10 @@ allowed, but that should be sufficient for most use cases.
3.3 Input script structure :h3,link(cmd_3)
This section describes the structure of a typical LAMMPS input script.
The "examples" directory in the LAMMPS distribution contains many
sample input scripts; the corresponding problems are discussed in
"Section 7"_Section_example.html, and animated on the "LAMMPS
WWW Site"_lws.
The examples directory in the LAMMPS distribution contains many sample
input scripts; the corresponding problems are discussed on the
"Examples"_Examples.html doc page, and animated on the "LAMMPS WWW
Site"_lws.
A LAMMPS input script typically has 4 parts:
@ -554,8 +554,8 @@ Fix styles :h3
See the "fix"_fix.html command for one-line descriptions of each style
or click on the style itself for a full description. Some of the
styles have accelerated versions, which can be used if LAMMPS is built
with the "appropriate accelerated package"_Section_accelerate.html.
This is indicated by additional letters in parenthesis: g = GPU, i =
with the "appropriate accelerated package"_Speed_packages.html. This
is indicated by additional letters in parenthesis: g = GPU, i =
USER-INTEL, k = KOKKOS, o = USER-OMP, t = OPT.
"adapt"_fix_adapt.html,
@ -582,7 +582,7 @@ USER-INTEL, k = KOKKOS, o = USER-OMP, t = OPT.
"dt/reset"_fix_dt_reset.html,
"efield"_fix_efield.html,
"ehex"_fix_ehex.html,
"enforce2d"_fix_enforce2d.html,
"enforce2d (k)"_fix_enforce2d.html,
"evaporate"_fix_evaporate.html,
"external"_fix_external.html,
"freeze"_fix_freeze.html,
@ -678,6 +678,8 @@ USER-INTEL, k = KOKKOS, o = USER-OMP, t = OPT.
"vector"_fix_vector.html,
"viscosity"_fix_viscosity.html,
"viscous"_fix_viscous.html,
"wall/body/polygon"_fix_wall_body_polygon.html,
"wall/body/polyhedron"_fix_wall_body_polyhedron.html,
"wall/colloid"_fix_wall.html,
"wall/gran"_fix_wall_gran.html,
"wall/gran/region"_fix_wall_gran_region.html,
@ -773,9 +775,9 @@ See the "compute"_compute.html command for one-line descriptions of
each style or click on the style itself for a full description. Some
of the styles have accelerated versions, which can be used if LAMMPS
is built with the "appropriate accelerated
package"_Section_accelerate.html. This is indicated by additional
letters in parenthesis: g = GPU, i = USER-INTEL, k =
KOKKOS, o = USER-OMP, t = OPT.
package"_Speed_packages.html. This is indicated by additional letters
in parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o = USER-OMP, t =
OPT.
"aggregate/atom"_compute_cluster_atom.html,
"angle"_compute_angle.html,
@ -918,9 +920,9 @@ See the "pair_style"_pair_style.html command for an overview of pair
potentials. Click on the style itself for a full description. Many
of the styles have accelerated versions, which can be used if LAMMPS
is built with the "appropriate accelerated
package"_Section_accelerate.html. This is indicated by additional
letters in parenthesis: g = GPU, i = USER-INTEL, k =
KOKKOS, o = USER-OMP, t = OPT.
package"_Speed_packages.html. This is indicated by additional letters
in parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o = USER-OMP, t =
OPT.
"none"_pair_none.html,
"zero"_pair_zero.html,
@ -930,7 +932,9 @@ KOKKOS, o = USER-OMP, t = OPT.
"airebo (oi)"_pair_airebo.html,
"airebo/morse (oi)"_pair_airebo.html,
"beck (go)"_pair_beck.html,
"body"_pair_body.html,
"body/nparticle"_pair_body_nparticle.html,
"body/rounded/polygon"_pair_body_rounded/polygon.html,
"body/rounded/polyhedron"_pair_body_rounded/polyhedron.html,
"bop"_pair_bop.html,
"born (go)"_pair_born.html,
"born/coul/dsf"_pair_born.html,
@ -965,6 +969,7 @@ KOKKOS, o = USER-OMP, t = OPT.
"dsmc"_pair_dsmc.html,
"eam (gikot)"_pair_eam.html,
"eam/alloy (gikot)"_pair_eam.html,
"eam/cd (o)"_pair_eam.html,
"eam/fs (gikot)"_pair_eam.html,
"eim (o)"_pair_eim.html,
"gauss (go)"_pair_gauss.html,
@ -1065,7 +1070,6 @@ package"_Section_start.html#start_3.
"coul/shield"_pair_coul_shield.html,
"dpd/fdt"_pair_dpd_fdt.html,
"dpd/fdt/energy (k)"_pair_dpd_fdt.html,
"eam/cd (o)"_pair_eam.html,
"edip (o)"_pair_edip.html,
"edip/multi"_pair_edip.html,
"edpd"_pair_meso.html,
@ -1138,9 +1142,9 @@ See the "bond_style"_bond_style.html command for an overview of bond
potentials. Click on the style itself for a full description. Some
of the styles have accelerated versions, which can be used if LAMMPS
is built with the "appropriate accelerated
package"_Section_accelerate.html. This is indicated by additional
letters in parenthesis: g = GPU, i = USER-INTEL, k =
KOKKOS, o = USER-OMP, t = OPT.
package"_Speed_packages.html. This is indicated by additional letters
in parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o = USER-OMP, t =
OPT.
"none"_bond_none.html,
"zero"_bond_zero.html,
@ -1172,9 +1176,9 @@ See the "angle_style"_angle_style.html command for an overview of
angle potentials. Click on the style itself for a full description.
Some of the styles have accelerated versions, which can be used if
LAMMPS is built with the "appropriate accelerated
package"_Section_accelerate.html. This is indicated by additional
letters in parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o =
USER-OMP, t = OPT.
package"_Speed_packages.html. This is indicated by additional letters
in parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o = USER-OMP, t =
OPT.
"none"_angle_none.html,
"zero"_angle_zero.html,
@ -1208,7 +1212,7 @@ See the "dihedral_style"_dihedral_style.html command for an overview
of dihedral potentials. Click on the style itself for a full
description. Some of the styles have accelerated versions, which can
be used if LAMMPS is built with the "appropriate accelerated
package"_Section_accelerate.html. This is indicated by additional
package"_Speed_packages.html. This is indicated by additional
letters in parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o =
USER-OMP, t = OPT.
@ -1243,9 +1247,9 @@ See the "improper_style"_improper_style.html command for an overview
of improper potentials. Click on the style itself for a full
description. Some of the styles have accelerated versions, which can
be used if LAMMPS is built with the "appropriate accelerated
package"_Section_accelerate.html. This is indicated by additional
letters in parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o =
USER-OMP, t = OPT.
package"_Speed_packages.html. This is indicated by additional letters
in parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o = USER-OMP, t =
OPT.
"none"_improper_none.html,
"zero"_improper_zero.html,
@ -1272,9 +1276,9 @@ See the "kspace_style"_kspace_style.html command for an overview of
Kspace solvers. Click on the style itself for a full description.
Some of the styles have accelerated versions, which can be used if
LAMMPS is built with the "appropriate accelerated
package"_Section_accelerate.html. This is indicated by additional
letters in parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o =
USER-OMP, t = OPT.
package"_Speed_packages.html. This is indicated by additional letters
in parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o = USER-OMP, t =
OPT.
"ewald (o)"_kspace_style.html,
"ewald/disp"_kspace_style.html,

2
doc/src/Section_history.txt
View File

@ -1,4 +1,4 @@
"Previous Section"_Section_errors.html - "LAMMPS WWW Site"_lws -
"Previous Section"_Errors.html - "LAMMPS WWW Site"_lws -
"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
Section"_Manual.html :c

79
doc/src/Section_howto.txt
View File

@ -1,4 +1,4 @@
"Previous Section"_Section_accelerate.html - "LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next Section"_Section_example.html :c
"Previous Section"_Speed.html - "LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next Section"_Examples.html :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
@ -40,7 +40,7 @@ This section describes how to perform common tasks using LAMMPS.
6.28 "Magnetic spins"_#howto_28 :all(b)
The example input scripts included in the LAMMPS distribution and
highlighted in "Section 7"_Section_example.html also show how to
highlighted on the "Examples"_Examples.html doc page also show how to
setup and run various kinds of simulations.
:line
@ -188,9 +188,9 @@ used in the CHARMM, AMBER, and DREIDING force fields. Setting
coefficients is done in the input data file via the
"read_data"_read_data.html command or in the input script with
commands like "pair_coeff"_pair_coeff.html or
"bond_coeff"_bond_coeff.html. See "Section 9"_Section_tools.html
for additional tools that can use CHARMM or AMBER to assign force
field coefficients and convert their output into LAMMPS input.
"bond_coeff"_bond_coeff.html. See the "Tools"_Tools.html doc page for
additional tools that can use CHARMM or AMBER to assign force field
coefficients and convert their output into LAMMPS input.
See "(MacKerell)"_#howto-MacKerell for a description of the CHARMM force
field. See "(Cornell)"_#howto-Cornell for a description of the AMBER force
@ -672,10 +672,10 @@ this scenario, LAMMPS is the driver code. During its timestepping,
the fix is invoked, and can make library calls to the other code,
which has been linked to LAMMPS as a library. This is the way the
"POEMS"_poems package that performs constrained rigid-body motion on
groups of atoms is hooked to LAMMPS. See the
"fix poems"_fix_poems.html command for more details. See "this
section"_Section_modify.html of the documentation for info on how to add
a new fix to LAMMPS.
groups of atoms is hooked to LAMMPS. See the "fix
poems"_fix_poems.html command for more details. See the
"Modify"_Modify.html doc page for info on how to add a new fix to
LAMMPS.
:link(poems,http://www.rpi.edu/~anderk5/lab)
@ -696,8 +696,8 @@ processors to start up another program). In the latter case the
stand-alone code could communicate with LAMMPS thru files that the
command writes and reads.
See "Section 10"_Section_modify.html of the documentation for how
to add a new command to LAMMPS.
See the "Modify"_Modify.html doc page for how to add a new command to
LAMMPS.
(3) Use LAMMPS as a library called by another code. In this case the
other code is the driver and calls LAMMPS as needed. Or a wrapper
@ -731,10 +731,10 @@ any other language that supports a vanilla C-like interface). For
example, from C++ you could create one (or more) "instances" of
LAMMPS, pass it an input script to process, or execute individual
commands, all by invoking the correct class methods in LAMMPS. From C
or Fortran you can make function calls to do the same things. See
"Section 11"_Section_python.html of the manual for a description
of the Python wrapper provided with LAMMPS that operates through the
LAMMPS library interface.
or Fortran you can make function calls to do the same things. See the
"Python"_Python.html doc page for a description of the Python wrapper
provided with LAMMPS that operates through the LAMMPS library
interface.
The files src/library.cpp and library.h contain the C-style interface
to LAMMPS. See "Section 6.19"_Section_howto.html#howto_19 of the
@ -762,12 +762,12 @@ simulations can be visualized (and analyzed) in a variety of ways.
LAMMPS snapshots are created by the "dump"_dump.html command which can
create files in several formats. The native LAMMPS dump format is a
text file (see "dump atom" or "dump custom") which can be visualized
by several popular visualization tools. The "dump image"_dump_image.html
and "dump movie"_dump_image.html styles can output internally rendered
images and convert a sequence of them to a movie during the MD run.
Several programs included with LAMMPS as auxiliary tools can convert
between LAMMPS format files and other formats.
See the "Section 9"_Section_tools.html doc page for details.
by several popular visualization tools. The "dump
image"_dump_image.html and "dump movie"_dump_image.html styles can
output internally rendered images and convert a sequence of them to a
movie during the MD run. Several programs included with LAMMPS as
auxiliary tools can convert between LAMMPS format files and other
formats. See the "Tools"_Tools.html doc page for details.
A Python-based toolkit distributed by our group can read native LAMMPS
dump files, including custom dump files with additional columns of
@ -1057,7 +1057,7 @@ rigid bodies composed of finite-size particles :ul
Example input scripts for these kinds of models are in the body,
colloid, dipole, ellipse, line, peri, pour, and tri directories of the
"examples directory"_Section_example.html in the LAMMPS distribution.
"examples directory"_Examples.html in the LAMMPS distribution.
Atom styles :h4
@ -1158,7 +1158,7 @@ styles"_pair_style.html that generate torque:
"pair_style lubricate"_pair_lubricate.html
"pair_style line/lj"_pair_line_lj.html
"pair_style tri/lj"_pair_tri_lj.html
"pair_style body"_pair_body.html :ul
"pair_style body"_pair_body_nparticle.html :ul
The granular pair styles are used with spherical particles. The
dipole pair style is used with the dipole atom style, which could be
@ -1269,7 +1269,7 @@ list of sub-particles. Individual body partices are typically treated
as rigid bodies, and their motion integrated with a command like "fix
nve/body"_fix_nve_body.html. Interactions between pairs of body
particles are computed via a command like "pair_style
body"_pair_body.html.
body"_pair_body_nparticle.html.
:line
@ -1302,8 +1302,8 @@ As discussed below, LAMMPS gives you a variety of ways to determine
what quantities are computed and printed when the thermodynamics,
dump, or fix commands listed above perform output. Throughout this
discussion, note that users can also "add their own computes and fixes
to LAMMPS"_Section_modify.html which can then generate values that can
then be output with these commands.
to LAMMPS"_Modify.html which can then generate values that can then be
output with these commands.
The following sub-sections discuss different LAMMPS command related
to output and the kind of data they operate on and produce:
@ -1824,8 +1824,8 @@ At zero temperature, it is easy to estimate these derivatives by
deforming the simulation box in one of the six directions using the
"change_box"_change_box.html command and measuring the change in the
stress tensor. A general-purpose script that does this is given in the
examples/elastic directory described in "this
section"_Section_example.html.
examples/elastic directory described on the "Examples"_Examples.html
doc page.
Calculating elastic constants at finite temperature is more
challenging, because it is necessary to run a simulation that perfoms
@ -1843,10 +1843,10 @@ converge and requires careful post-processing "(Shinoda)"_#Shinoda1
6.19 Library interface to LAMMPS :link(howto_19),h4
As described in "Section 2.5"_Section_start.html#start_5, LAMMPS
can be built as a library, so that it can be called by another code,
used in a "coupled manner"_Section_howto.html#howto_10 with other
codes, or driven through a "Python interface"_Section_python.html.
As described in "Section 2.5"_Section_start.html#start_5, LAMMPS can
be built as a library, so that it can be called by another code, used
in a "coupled manner"_Section_howto.html#howto_10 with other codes, or
driven through a "Python interface"_Python.html.
All of these methodologies use a C-style interface to LAMMPS that is
provided in the files src/library.cpp and src/library.h. The
@ -1869,9 +1869,9 @@ details.
NOTE: You can write code for additional functions as needed to define
how your code talks to LAMMPS and add them to src/library.cpp and
src/library.h, as well as to the "Python
interface"_Section_python.html. The added functions can access or
change any internal LAMMPS data you wish.
src/library.h, as well as to the "Python interface"_Python.html. The
added functions can access or change any internal LAMMPS data you
wish.
void lammps_open(int, char **, MPI_Comm, void **)
void lammps_open_no_mpi(int, char **, void **)
@ -2322,11 +2322,10 @@ Note that this compute allows the per-atom output of other
"computes"_compute.html, "fixes"_fix.html, and
"variables"_variable.html to be used to define chunk IDs for each
atom. This means you can write your own compute or fix to output a
per-atom quantity to use as chunk ID. See
"Section 10"_Section_modify.html of the documentation for how to
do this. You can also define a "per-atom variable"_variable.html in
the input script that uses a formula to generate a chunk ID for each
atom.
per-atom quantity to use as chunk ID. See the "Modify"_Modify.html
doc page for how to do this. You can also define a "per-atom
variable"_variable.html in the input script that uses a formula to
generate a chunk ID for each atom.
Fix ave/chunk command: :h4

43
doc/src/Section_intro.txt
View File

@ -1,4 +1,6 @@
"Previous Section"_Manual.html - "LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next Section"_Section_start.html :c
"Previous Section"_Manual.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc - "Next
Section"_Section_start.html :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
@ -54,8 +56,8 @@ brief discussion of the open-source philosophy.
LAMMPS is designed to be easy to modify or extend with new
capabilities, such as new force fields, atom types, boundary
conditions, or diagnostics. See "Section 10"_Section_modify.html
for more details.
conditions, or diagnostics. See the "Modify"_Modify.html doc page for
more details.
The current version of LAMMPS is written in C++. Earlier versions
were written in F77 and F90. See
@ -94,8 +96,8 @@ LAMMPS are listed in "this section"_#intro_5.
This section highlights LAMMPS features, with pointers to specific
commands which give more details. If LAMMPS doesn't have your
favorite interatomic potential, boundary condition, or atom type, see
"Section 10"_Section_modify.html, which describes how you can add
it to LAMMPS.
the "Modify"_Modify.html doc page, which describes how you can add it
to LAMMPS.
General features :h4
@ -234,8 +236,8 @@ Multi-replica models :h4
Pre- and post-processing :h4
Various pre- and post-processing serial tools are packaged
with LAMMPS; see these "doc pages"_Section_tools.html. :ulb,l
Various pre- and post-processing serial tools are packaged with
LAMMPS; see the "Tools"_Tools.html doc page for details. :ulb,l
Our group has also written and released a separate toolkit called
"Pizza.py"_pizza which provides tools for doing setup, analysis,
@ -251,7 +253,7 @@ Specialized features :h4
LAMMPS can be built with optional packages which implement a variety
of additional capabilities. An overview of all the packages is "given
here"_Section_packages.html.
here"_Packages.html.
These are some LAMMPS capabilities which you may not think of as
typical classical molecular dynamics options:
@ -296,9 +298,9 @@ visualize your MD simulation
plot your output data :ul
A few tools for pre- and post-processing tasks are provided as part of
the LAMMPS package; they are described in "this
section"_Section_tools.html. However, many people use other codes or
write their own tools for these tasks.
the LAMMPS package; they are described on the "Tools"_Tools.html doc
page. However, many people use other codes or write their own tools
for these tasks.
As noted above, our group has also written and released a separate
toolkit called "Pizza.py"_pizza which addresses some of the listed
@ -327,15 +329,15 @@ topology information and hundreds of force-field coefficients must
typically be specified. We suggest you use a program like
"CHARMM"_charmm or "AMBER"_amber or other molecular builders to setup
such problems and dump its information to a file. You can then
reformat the file as LAMMPS input. Some of the tools in "this
section"_Section_tools.html can assist in this process.
reformat the file as LAMMPS input. Some of the tools described on the
"Tools"_Tools.html doc page can assist in this process.
Similarly, LAMMPS creates output files in a simple format. Most users
post-process these files with their own analysis tools or re-format
them for input into other programs, including visualization packages.
If you are convinced you need to compute something on-the-fly as
LAMMPS runs, see "Section 10"_Section_modify.html for a discussion
of how you can use the "dump"_dump.html and "compute"_compute.html and
LAMMPS runs, see the "Modify"_Modify.html doc page for a discussion of
how you can use the "dump"_dump.html and "compute"_compute.html and
"fix"_fix.html commands to print out data of your choosing. Keep in
mind that complicated computations can slow down the molecular
dynamics timestepping, particularly if the computations are not
@ -429,7 +431,7 @@ Site"_lws, or have a suggestion for something to clarify or include,
send an email to the
"developers"_http://lammps.sandia.gov/authors.html. :l
If you find a bug, "Section 12.2"_Section_errors.html#err_2
If you find a bug, the "Errors bugs"_Errors_bugs.html doc page
describes how to report it. :l
If you publish a paper using LAMMPS results, send the citation (and
@ -442,15 +444,14 @@ directory. :l
The tools sub-directory of the LAMMPS distribution has various
stand-alone codes for pre- and post-processing of LAMMPS data. More
details are given in "Section 9"_Section_tools.html. If you write
a new tool that users will find useful, it can be added to the LAMMPS
details are given on the "Tools"_Tools.html doc page. If you write a
new tool that users will find useful, it can be added to the LAMMPS
distribution. :l
LAMMPS is designed to be easy to extend with new code for features
like potentials, boundary conditions, diagnostic computations, etc.
"This section"_Section_modify.html gives details. If you add a
feature of general interest, it can be added to the LAMMPS
distribution. :l
The "Modify"_Modify.html doc page gives details. If you add a feature
of general interest, it can be added to the LAMMPS distribution. :l
The Benchmark page of the "LAMMPS WWW Site"_lws lists LAMMPS
performance on various platforms. The files needed to run the

827
doc/src/Section_modify.txt
View File

@ -1,827 +0,0 @@
"Previous Section"_Section_tools.html - "LAMMPS WWW Site"_lws -
"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
Section"_Section_python.html :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
10. Modifying & extending LAMMPS :h2
This section describes how to customize LAMMPS by modifying
and extending its source code.
10.1 "Atom styles"_#mod_1
10.2 "Bond, angle, dihedral, improper potentials"_#mod_2
10.3 "Compute styles"_#mod_3
10.4 "Dump styles"_#mod_4
10.5 "Dump custom output options"_#mod_5
10.6 "Fix styles"_#mod_6 which include integrators, \
temperature and pressure control, force constraints, \
boundary conditions, diagnostic output, etc
10.7 "Input script commands"_#mod_7
10.8 "Kspace computations"_#mod_8
10.9 "Minimization styles"_#mod_9
10.10 "Pairwise potentials"_#mod_10
10.11 "Region styles"_#mod_11
10.12 "Body styles"_#mod_12
10.13 "Thermodynamic output options"_#mod_13
10.14 "Variable options"_#mod_14
10.15 "Submitting new features for inclusion in LAMMPS"_#mod_15 :all(b)
LAMMPS is designed in a modular fashion so as to be easy to modify and
extend with new functionality. In fact, about 75% of its source code
is files added in this fashion.
In this section, changes and additions users can make are listed along
with minimal instructions. If you add a new feature to LAMMPS and
think it will be of interest to general users, we encourage you to
submit it to the developers for inclusion in the released version of
LAMMPS. Information about how to do this is provided
"below"_#mod_14.
The best way to add a new feature is to find a similar feature in
LAMMPS and look at the corresponding source and header files to figure
out what it does. You will need some knowledge of C++ to be able to
understand the hi-level structure of LAMMPS and its class
organization, but functions (class methods) that do actual
computations are written in vanilla C-style code and operate on simple
C-style data structures (vectors and arrays).
Most of the new features described in this section require you to
write a new C++ derived class (except for exceptions described below,
where you can make small edits to existing files). Creating a new
class requires 2 files, a source code file (*.cpp) and a header file
(*.h). The derived class must provide certain methods to work as a
new option. Depending on how different your new feature is compared
to existing features, you can either derive from the base class
itself, or from a derived class that already exists. Enabling LAMMPS
to invoke the new class is as simple as putting the two source
files in the src dir and re-building LAMMPS.
The advantage of C++ and its object-orientation is that all the code
and variables needed to define the new feature are in the 2 files you
write, and thus shouldn't make the rest of LAMMPS more complex or
cause side-effect bugs.
Here is a concrete example. Suppose you write 2 files pair_foo.cpp
and pair_foo.h that define a new class PairFoo that computes pairwise
potentials described in the classic 1997 "paper"_#Foo by Foo, et al.
If you wish to invoke those potentials in a LAMMPS input script with a
command like
pair_style foo 0.1 3.5 :pre
then your pair_foo.h file should be structured as follows:
#ifdef PAIR_CLASS
PairStyle(foo,PairFoo)
#else
...
(class definition for PairFoo)
...
#endif :pre
where "foo" is the style keyword in the pair_style command, and
PairFoo is the class name defined in your pair_foo.cpp and pair_foo.h
files.
When you re-build LAMMPS, your new pairwise potential becomes part of
the executable and can be invoked with a pair_style command like the
example above. Arguments like 0.1 and 3.5 can be defined and
processed by your new class.
As illustrated by this pairwise example, many kinds of options are
referred to in the LAMMPS documentation as the "style" of a particular
command.
The instructions below give the header file for the base class that
these styles are derived from. Public variables in that file are ones
used and set by the derived classes which are also used by the base
class. Sometimes they are also used by the rest of LAMMPS. Virtual
functions in the base class header file which are set = 0 are ones you
must define in your new derived class to give it the functionality
LAMMPS expects. Virtual functions that are not set to 0 are functions
you can optionally define.
Additionally, new output options can be added directly to the
thermo.cpp, dump_custom.cpp, and variable.cpp files as explained
below.
Here are additional guidelines for modifying LAMMPS and adding new
functionality:
Think about whether what you want to do would be better as a pre- or
post-processing step. Many computations are more easily and more
quickly done that way. :ulb,l
Don't do anything within the timestepping of a run that isn't
parallel. E.g. don't accumulate a bunch of data on a single processor
and analyze it. You run the risk of seriously degrading the parallel
efficiency. :l
If your new feature reads arguments or writes output, make sure you
follow the unit conventions discussed by the "units"_units.html
command. :l
If you add something you think is truly useful and doesn't impact
LAMMPS performance when it isn't used, send an email to the
"developers"_http://lammps.sandia.gov/authors.html. We might be
interested in adding it to the LAMMPS distribution. See further
details on this at the bottom of this page. :l
:ule
:line
:line
10.1 Atom styles :link(mod_1),h4
Classes that define an "atom style"_atom_style.html are derived from
the AtomVec class and managed by the Atom class. The atom style
determines what attributes are associated with an atom. A new atom
style can be created if one of the existing atom styles does not
define all the attributes you need to store and communicate with
atoms.
Atom_vec_atomic.cpp is a simple example of an atom style.
Here is a brief description of methods you define in your new derived
class. See atom_vec.h for details.
init: one time setup (optional)
grow: re-allocate atom arrays to longer lengths (required)
grow_reset: make array pointers in Atom and AtomVec classes consistent (required)
copy: copy info for one atom to another atom's array locations (required)
pack_comm: store an atom's info in a buffer communicated every timestep (required)
pack_comm_vel: add velocity info to communication buffer (required)
pack_comm_hybrid: store extra info unique to this atom style (optional)
unpack_comm: retrieve an atom's info from the buffer (required)
unpack_comm_vel: also retrieve velocity info (required)
unpack_comm_hybrid: retrieve extra info unique to this atom style (optional)
pack_reverse: store an atom's info in a buffer communicating partial forces (required)
pack_reverse_hybrid: store extra info unique to this atom style (optional)
unpack_reverse: retrieve an atom's info from the buffer (required)
unpack_reverse_hybrid: retrieve extra info unique to this atom style (optional)
pack_border: store an atom's info in a buffer communicated on neighbor re-builds (required)
pack_border_vel: add velocity info to buffer (required)
pack_border_hybrid: store extra info unique to this atom style (optional)
unpack_border: retrieve an atom's info from the buffer (required)
unpack_border_vel: also retrieve velocity info (required)
unpack_border_hybrid: retrieve extra info unique to this atom style (optional)
pack_exchange: store all an atom's info to migrate to another processor (required)
unpack_exchange: retrieve an atom's info from the buffer (required)
size_restart: number of restart quantities associated with proc's atoms (required)
pack_restart: pack atom quantities into a buffer (required)
unpack_restart: unpack atom quantities from a buffer (required)
create_atom: create an individual atom of this style (required)
data_atom: parse an atom line from the data file (required)
data_atom_hybrid: parse additional atom info unique to this atom style (optional)
data_vel: parse one line of velocity information from data file (optional)
data_vel_hybrid: parse additional velocity data unique to this atom style (optional)
memory_usage: tally memory allocated by atom arrays (required) :tb(s=:)
The constructor of the derived class sets values for several variables
that you must set when defining a new atom style, which are documented
in atom_vec.h. New atom arrays are defined in atom.cpp. Search for
the word "customize" and you will find locations you will need to
modify.
NOTE: It is possible to add some attributes, such as a molecule ID, to
atom styles that do not have them via the "fix
property/atom"_fix_property_atom.html command. This command also
allows new custom attributes consisting of extra integer or
floating-point values to be added to atoms. See the "fix
property/atom"_fix_property_atom.html doc page for examples of cases
where this is useful and details on how to initialize, access, and
output the custom values.
New "pair styles"_pair_style.html, "fixes"_fix.html, or
"computes"_compute.html can be added to LAMMPS, as discussed below.
The code for these classes can use the per-atom properties defined by
fix property/atom. The Atom class has a find_custom() method that is
useful in this context:
int index = atom->find_custom(char *name, int &flag); :pre
The "name" of a custom attribute, as specified in the "fix
property/atom"_fix_property_atom.html command, is checked to verify
that it exists and its index is returned. The method also sets flag =
0/1 depending on whether it is an integer or floating-point attribute.
The vector of values associated with the attribute can then be
accessed using the returned index as
int *ivector = atom->ivector\[index\];
double *dvector = atom->dvector\[index\]; :pre
Ivector or dvector are vectors of length Nlocal = # of owned atoms,
which store the attributes of individual atoms.
:line
10.2 Bond, angle, dihedral, improper potentials :link(mod_2),h4
Classes that compute molecular interactions are derived from the Bond,
Angle, Dihedral, and Improper classes. New styles can be created to
add new potentials to LAMMPS.
Bond_harmonic.cpp is the simplest example of a bond style. Ditto for
the harmonic forms of the angle, dihedral, and improper style
commands.
Here is a brief description of common methods you define in your
new derived class. See bond.h, angle.h, dihedral.h, and improper.h
for details and specific additional methods.
init: check if all coefficients are set, calls {init_style} (optional)
init_style: check if style specific conditions are met (optional)
compute: compute the molecular interactions (required)
settings: apply global settings for all types (optional)
coeff: set coefficients for one type (required)
equilibrium_distance: length of bond, used by SHAKE (required, bond only)
equilibrium_angle: opening of angle, used by SHAKE (required, angle only)
write & read_restart: writes/reads coeffs to restart files (required)
single: force and energy of a single bond or angle (required, bond or angle only)
memory_usage: tally memory allocated by the style (optional) :tb(s=:)
:line
10.3 Compute styles :link(mod_3),h4
Classes that compute scalar and vector quantities like temperature
and the pressure tensor, as well as classes that compute per-atom
quantities like kinetic energy and the centro-symmetry parameter
are derived from the Compute class. New styles can be created
to add new calculations to LAMMPS.
Compute_temp.cpp is a simple example of computing a scalar
temperature. Compute_ke_atom.cpp is a simple example of computing
per-atom kinetic energy.
Here is a brief description of methods you define in your new derived
class. See compute.h for details.
init: perform one time setup (required)
init_list: neighbor list setup, if needed (optional)
compute_scalar: compute a scalar quantity (optional)
compute_vector: compute a vector of quantities (optional)
compute_peratom: compute one or more quantities per atom (optional)
compute_local: compute one or more quantities per processor (optional)
pack_comm: pack a buffer with items to communicate (optional)
unpack_comm: unpack the buffer (optional)
pack_reverse: pack a buffer with items to reverse communicate (optional)
unpack_reverse: unpack the buffer (optional)
remove_bias: remove velocity bias from one atom (optional)
remove_bias_all: remove velocity bias from all atoms in group (optional)
restore_bias: restore velocity bias for one atom after remove_bias (optional)
restore_bias_all: same as before, but for all atoms in group (optional)
pair_tally_callback: callback function for {tally}-style computes (optional).
memory_usage: tally memory usage (optional) :tb(s=:)
Tally-style computes are a special case, as their computation is done
in two stages: the callback function is registered with the pair style
and then called from the Pair::ev_tally() function, which is called for
each pair after force and energy has been computed for this pair. Then
the tallied values are retrieved with the standard compute_scalar or
compute_vector or compute_peratom methods. The USER-TALLY package
provides {examples}_compute_tally.html for utilizing this mechanism.
:line
10.4 Dump styles :link(mod_4),h4
10.5 Dump custom output options :link(mod_5),h4
Classes that dump per-atom info to files are derived from the Dump
class. To dump new quantities or in a new format, a new derived dump
class can be added, but it is typically simpler to modify the
DumpCustom class contained in the dump_custom.cpp file.
Dump_atom.cpp is a simple example of a derived dump class.
Here is a brief description of methods you define in your new derived
class. See dump.h for details.
write_header: write the header section of a snapshot of atoms
count: count the number of lines a processor will output
pack: pack a proc's output data into a buffer
write_data: write a proc's data to a file :tb(s=:)
See the "dump"_dump.html command and its {custom} style for a list of
keywords for atom information that can already be dumped by
DumpCustom. It includes options to dump per-atom info from Compute
classes, so adding a new derived Compute class is one way to calculate
new quantities to dump.
Alternatively, you can add new keywords to the dump custom command.
Search for the word "customize" in dump_custom.cpp to see the
half-dozen or so locations where code will need to be added.
:line
10.6 Fix styles :link(mod_6),h4
In LAMMPS, a "fix" is any operation that is computed during
timestepping that alters some property of the system. Essentially
everything that happens during a simulation besides force computation,
neighbor list construction, and output, is a "fix". This includes
time integration (update of coordinates and velocities), force
constraints or boundary conditions (SHAKE or walls), and diagnostics
(compute a diffusion coefficient). New styles can be created to add
new options to LAMMPS.
Fix_setforce.cpp is a simple example of setting forces on atoms to
prescribed values. There are dozens of fix options already in LAMMPS;
choose one as a template that is similar to what you want to
implement.
Here is a brief description of methods you can define in your new
derived class. See fix.h for details.
setmask: determines when the fix is called during the timestep (required)
init: initialization before a run (optional)
setup_pre_exchange: called before atom exchange in setup (optional)
setup_pre_force: called before force computation in setup (optional)
setup: called immediately before the 1st timestep and after forces are computed (optional)
min_setup_pre_force: like setup_pre_force, but for minimizations instead of MD runs (optional)
min_setup: like setup, but for minimizations instead of MD runs (optional)
initial_integrate: called at very beginning of each timestep (optional)
pre_exchange: called before atom exchange on re-neighboring steps (optional)
pre_neighbor: called before neighbor list build (optional)
pre_force: called before pair & molecular forces are computed (optional)
post_force: called after pair & molecular forces are computed and communicated (optional)
final_integrate: called at end of each timestep (optional)
end_of_step: called at very end of timestep (optional)
write_restart: dumps fix info to restart file (optional)
restart: uses info from restart file to re-initialize the fix (optional)
grow_arrays: allocate memory for atom-based arrays used by fix (optional)
copy_arrays: copy atom info when an atom migrates to a new processor (optional)
pack_exchange: store atom's data in a buffer (optional)
unpack_exchange: retrieve atom's data from a buffer (optional)
pack_restart: store atom's data for writing to restart file (optional)
unpack_restart: retrieve atom's data from a restart file buffer (optional)
size_restart: size of atom's data (optional)
maxsize_restart: max size of atom's data (optional)
setup_pre_force_respa: same as setup_pre_force, but for rRESPA (optional)
initial_integrate_respa: same as initial_integrate, but for rRESPA (optional)
post_integrate_respa: called after the first half integration step is done in rRESPA (optional)
pre_force_respa: same as pre_force, but for rRESPA (optional)
post_force_respa: same as post_force, but for rRESPA (optional)
final_integrate_respa: same as final_integrate, but for rRESPA (optional)
min_pre_force: called after pair & molecular forces are computed in minimizer (optional)
min_post_force: called after pair & molecular forces are computed and communicated in minimizer (optional)
min_store: store extra data for linesearch based minimization on a LIFO stack (optional)
min_pushstore: push the minimization LIFO stack one element down (optional)
min_popstore: pop the minimization LIFO stack one element up (optional)
min_clearstore: clear minimization LIFO stack (optional)
min_step: reset or move forward on line search minimization (optional)
min_dof: report number of degrees of freedom {added} by this fix in minimization (optional)
max_alpha: report maximum allowed step size during linesearch minimization (optional)
pack_comm: pack a buffer to communicate a per-atom quantity (optional)
unpack_comm: unpack a buffer to communicate a per-atom quantity (optional)
pack_reverse_comm: pack a buffer to reverse communicate a per-atom quantity (optional)
unpack_reverse_comm: unpack a buffer to reverse communicate a per-atom quantity (optional)
dof: report number of degrees of freedom {removed} by this fix during MD (optional)
compute_scalar: return a global scalar property that the fix computes (optional)
compute_vector: return a component of a vector property that the fix computes (optional)
compute_array: return a component of an array property that the fix computes (optional)
deform: called when the box size is changed (optional)
reset_target: called when a change of the target temperature is requested during a run (optional)
reset_dt: is called when a change of the time step is requested during a run (optional)
modify_param: called when a fix_modify request is executed (optional)
memory_usage: report memory used by fix (optional)
thermo: compute quantities for thermodynamic output (optional) :tb(s=:)
Typically, only a small fraction of these methods are defined for a
particular fix. Setmask is mandatory, as it determines when the fix
will be invoked during the timestep. Fixes that perform time
integration ({nve}, {nvt}, {npt}) implement initial_integrate() and
final_integrate() to perform velocity Verlet updates. Fixes that
constrain forces implement post_force().
Fixes that perform diagnostics typically implement end_of_step(). For
an end_of_step fix, one of your fix arguments must be the variable
"nevery" which is used to determine when to call the fix and you must
set this variable in the constructor of your fix. By convention, this
is the first argument the fix defines (after the ID, group-ID, style).
If the fix needs to store information for each atom that persists from
timestep to timestep, it can manage that memory and migrate the info
with the atoms as they move from processors to processor by
implementing the grow_arrays, copy_arrays, pack_exchange, and
unpack_exchange methods. Similarly, the pack_restart and
unpack_restart methods can be implemented to store information about
the fix in restart files. If you wish an integrator or force
constraint fix to work with rRESPA (see the "run_style"_run_style.html
command), the initial_integrate, post_force_integrate, and
final_integrate_respa methods can be implemented. The thermo method
enables a fix to contribute values to thermodynamic output, as printed
quantities and/or to be summed to the potential energy of the system.
:line
10.7 Input script commands :link(mod_7),h4
New commands can be added to LAMMPS input scripts by adding new
classes that have a "command" method. For example, the create_atoms,
read_data, velocity, and run commands are all implemented in this
fashion. When such a command is encountered in the LAMMPS input
script, LAMMPS simply creates a class with the corresponding name,
invokes the "command" method of the class, and passes it the arguments
from the input script. The command method can perform whatever
operations it wishes on LAMMPS data structures.
The single method your new class must define is as follows:
command: operations performed by the new command :tb(s=:)
Of course, the new class can define other methods and variables as
needed.
:line
10.8 Kspace computations :link(mod_8),h4
Classes that compute long-range Coulombic interactions via K-space
representations (Ewald, PPPM) are derived from the KSpace class. New
styles can be created to add new K-space options to LAMMPS.
Ewald.cpp is an example of computing K-space interactions.
Here is a brief description of methods you define in your new derived
class. See kspace.h for details.
init: initialize the calculation before a run
setup: computation before the 1st timestep of a run
compute: every-timestep computation
memory_usage: tally of memory usage :tb(s=:)
:line
10.9 Minimization styles :link(mod_9),h4
Classes that perform energy minimization derived from the Min class.
New styles can be created to add new minimization algorithms to
LAMMPS.
Min_cg.cpp is an example of conjugate gradient minimization.
Here is a brief description of methods you define in your new derived
class. See min.h for details.
init: initialize the minimization before a run
run: perform the minimization
memory_usage: tally of memory usage :tb(s=:)
:line
10.10 Pairwise potentials :link(mod_10),h4
Classes that compute pairwise interactions are derived from the Pair
class. In LAMMPS, pairwise calculation include manybody potentials
such as EAM or Tersoff where particles interact without a static bond
topology. New styles can be created to add new pair potentials to
LAMMPS.
Pair_lj_cut.cpp is a simple example of a Pair class, though it
includes some optional methods to enable its use with rRESPA.
Here is a brief description of the class methods in pair.h:
compute: workhorse routine that computes pairwise interactions
settings: reads the input script line with arguments you define
coeff: set coefficients for one i,j type pair
init_one: perform initialization for one i,j type pair
init_style: initialization specific to this pair style
write & read_restart: write/read i,j pair coeffs to restart files
write & read_restart_settings: write/read global settings to restart files
single: force and energy of a single pairwise interaction between 2 atoms
compute_inner/middle/outer: versions of compute used by rRESPA :tb(s=:)
The inner/middle/outer routines are optional.
:line
10.11 Region styles :link(mod_11),h4
Classes that define geometric regions are derived from the Region
class. Regions are used elsewhere in LAMMPS to group atoms, delete
atoms to create a void, insert atoms in a specified region, etc. New
styles can be created to add new region shapes to LAMMPS.
Region_sphere.cpp is an example of a spherical region.
Here is a brief description of methods you define in your new derived
class. See region.h for details.
inside: determine whether a point is in the region
surface_interior: determine if a point is within a cutoff distance inside of surc
surface_exterior: determine if a point is within a cutoff distance outside of surf
shape_update : change region shape if set by time-dependent variable :tb(s=:)
:line
10.12 Body styles :link(mod_12),h4
Classes that define body particles are derived from the Body class.
Body particles can represent complex entities, such as surface meshes
of discrete points, collections of sub-particles, deformable objects,
etc.
See "Section 6.14"_Section_howto.html#howto_14 of the manual for
an overview of using body particles and the "body"_body.html doc page
for details on the various body styles LAMMPS supports. New styles
can be created to add new kinds of body particles to LAMMPS.
Body_nparticle.cpp is an example of a body particle that is treated as
a rigid body containing N sub-particles.
Here is a brief description of methods you define in your new derived
class. See body.h for details.
data_body: process a line from the Bodies section of a data file
noutrow: number of sub-particles output is generated for
noutcol: number of values per-sub-particle output is generated for
output: output values for the Mth sub-particle
pack_comm_body: body attributes to communicate every timestep
unpack_comm_body: unpacking of those attributes
pack_border_body: body attributes to communicate when reneighboring is done
unpack_border_body: unpacking of those attributes :tb(s=:)
:line
10.13 Thermodynamic output options :link(mod_13),h4
There is one class that computes and prints thermodynamic information
to the screen and log file; see the file thermo.cpp.
There are two styles defined in thermo.cpp: "one" and "multi". There
is also a flexible "custom" style which allows the user to explicitly
list keywords for quantities to print when thermodynamic info is
output. See the "thermo_style"_thermo_style.html command for a list
of defined quantities.
The thermo styles (one, multi, etc) are simply lists of keywords.
Adding a new style thus only requires defining a new list of keywords.
Search for the word "customize" with references to "thermo style" in
thermo.cpp to see the two locations where code will need to be added.
New keywords can also be added to thermo.cpp to compute new quantities
for output. Search for the word "customize" with references to
"keyword" in thermo.cpp to see the several locations where code will
need to be added.
Note that the "thermo_style custom"_thermo.html command already allows
for thermo output of quantities calculated by "fixes"_fix.html,
"computes"_compute.html, and "variables"_variable.html. Thus, it may
be simpler to compute what you wish via one of those constructs, than
by adding a new keyword to the thermo command.
:line
10.14 Variable options :link(mod_14),h4
There is one class that computes and stores "variable"_variable.html
information in LAMMPS; see the file variable.cpp. The value
associated with a variable can be periodically printed to the screen
via the "print"_print.html, "fix print"_fix_print.html, or
"thermo_style custom"_thermo_style.html commands. Variables of style
"equal" can compute complex equations that involve the following types
of arguments:
thermo keywords = ke, vol, atoms, ...
other variables = v_a, v_myvar, ...
math functions = div(x,y), mult(x,y), add(x,y), ...
group functions = mass(group), xcm(group,x), ...
atom values = x\[123\], y\[3\], vx\[34\], ...
compute values = c_mytemp\[0\], c_thermo_press\[3\], ... :pre
Adding keywords for the "thermo_style custom"_thermo_style.html command
(which can then be accessed by variables) was discussed
"here"_Section_modify.html#mod_13 on this page.
Adding a new math function of one or two arguments can be done by
editing one section of the Variable::evaluate() method. Search for
the word "customize" to find the appropriate location.
Adding a new group function can be done by editing one section of the
Variable::evaluate() method. Search for the word "customize" to find
the appropriate location. You may need to add a new method to the
Group class as well (see the group.cpp file).
Accessing a new atom-based vector can be done by editing one section
of the Variable::evaluate() method. Search for the word "customize"
to find the appropriate location.
Adding new "compute styles"_compute.html (whose calculated values can
then be accessed by variables) was discussed
"here"_Section_modify.html#mod_3 on this page.
:line
:line
10.15 Submitting new features for inclusion in LAMMPS :link(mod_15),h4
We encourage users to submit new features or modifications for
LAMMPS to "the core developers"_http://lammps.sandia.gov/authors.html
so they can be added to the LAMMPS distribution. The preferred way to
manage and coordinate this is as of Fall 2016 via the LAMMPS project on
"GitHub"_https://github.com/lammps/lammps. An alternative is to contact
the LAMMPS developers or the indicated developer of a package or feature
directly and send in your contribution via e-mail.
For any larger modifications or programming project, you are encouraged
to contact the LAMMPS developers ahead of time, in order to discuss
implementation strategies and coding guidelines, that will make it
easier to integrate your contribution and result in less work for
everybody involved. You are also encouraged to search through the list
of "open issues on GitHub"_https://github.com/lammps/lammps/issues and
submit a new issue for a planned feature, so you would not duplicate
the work of others (and possibly get scooped by them) or have your work
duplicated by others.
How quickly your contribution will be integrated
depends largely on how much effort it will cause to integrate and test
it, how much it requires changes to the core codebase, and of how much
interest it is to the larger LAMMPS community. Please see below for a
checklist of typical requirements. Once you have prepared everything,
see "this tutorial"_tutorial_github.html for instructions on how to
submit your changes or new files through a GitHub pull request. If you
prefer to submit patches or full files, you should first make certain,
that your code works correctly with the latest patch-level version of
LAMMPS and contains all bugfixes from it. Then create a gzipped tar
file of all changed or added files or a corresponding patch file using
'diff -u' or 'diff -c' and compress it with gzip. Please only use
gzip compression, as this works well on all platforms.
If the new features/files are broadly useful we may add them as core
files to LAMMPS or as part of a "standard
package"_Section_start.html#start_3. Else we will add them as a
user-contributed file or package. Examples of user packages are in
src sub-directories that start with USER. The USER-MISC package is
simply a collection of (mostly) unrelated single files, which is the
simplest way to have your contribution quickly added to the LAMMPS
distribution. You can see a list of the both standard and user
packages by typing "make package" in the LAMMPS src directory.
Note that by providing us files to release, you are agreeing to make
them open-source, i.e. we can release them under the terms of the GPL,
used as a license for the rest of LAMMPS. See "Section
1.4"_Section_intro.html#intro_4 for details.
With user packages and files, all we are really providing (aside from
the fame and fortune that accompanies having your name in the source
code and on the "Authors page"_http://lammps.sandia.gov/authors.html
of the "LAMMPS WWW site"_lws), is a means for you to distribute your
work to the LAMMPS user community, and a mechanism for others to
easily try out your new feature. This may help you find bugs or make
contact with new collaborators. Note that you're also implicitly
agreeing to support your code which means answer questions, fix bugs,
and maintain it if LAMMPS changes in some way that breaks it (an
unusual event).
NOTE: If you prefer to actively develop and support your add-on
feature yourself, then you may wish to make it available for download
from your own website, as a user package that LAMMPS users can add to
their copy of LAMMPS. See the "Offsite LAMMPS packages and
tools"_http://lammps.sandia.gov/offsite.html page of the LAMMPS web
site for examples of groups that do this. We are happy to advertise
your package and web site from that page. Simply email the
"developers"_http://lammps.sandia.gov/authors.html with info about
your package and we will post it there.
The previous sections of this doc page describe how to add new "style"
files of various kinds to LAMMPS. Packages are simply collections of
one or more new class files which are invoked as a new style within a
LAMMPS input script. If designed correctly, these additions typically
do not require changes to the main core of LAMMPS; they are simply
add-on files. If you think your new feature requires non-trivial
changes in core LAMMPS files, you'll need to "communicate with the
developers"_http://lammps.sandia.gov/authors.html, since we may or may
not want to make those changes. An example of a trivial change is
making a parent-class method "virtual" when you derive a new child
class from it.
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 src dir for
examples. If you are uncertain, please ask.
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. :ulb,l
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, class header files should not import any
system headers outside <stdio.h>, 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.
Header files must [not] import namespaces with {using}.
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. :l
If you want your contribution to be added as a user-contributed
feature, and it's a single file (actually a *.cpp and *.h file) it can
rapidly be added to the USER-MISC directory. Send us the one-line
entry to add to the USER-MISC/README file in that dir, along with the
2 source files. You can do this multiple times if you wish to
contribute several individual features. :l
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. :l
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. :l
You [must] also create a [documentation] file for each new command or
style you are adding to LAMMPS. For simplicity and convenience, the
documentation of groups of closely related commands or styles may be
combined into a single file. This will be one file for a single-file
feature. For a package, it might be several files. These are simple
text files with a specific markup language, that are then auto-converted
to HTML and PDF. The tools for this conversion are included in the
source distribution, and the translation can be as simple as doing
"make html pdf" in the doc folder.
Thus the documentation source files must be in the same format and
style as other *.txt files in the lammps/doc/src directory for similar
commands and styles; use one or more of them as a starting point.
A description of the markup can also be found in
lammps/doc/utils/txt2html/README.html
As appropriate, the text files can include links to equations
(see doc/Eqs/*.tex for examples, we auto-create the associated JPG
files), or figures (see doc/JPG for examples), or even additional PDF
files with further details (see doc/PDF for examples). The doc page
should also include literature citations as appropriate; see the
bottom of doc/fix_nh.txt for examples and the earlier part of the same
file for how to format the cite itself. The "Restrictions" section of
the doc page should indicate that your command is only available if
LAMMPS is built with the appropriate USER-MISC or USER-FOO package.
See other user package doc files for examples of how to do this. The
prerequisite for building the HTML format files are Python 3.x and
virtualenv, the requirement for generating the PDF format manual
is the "htmldoc"_http://www.htmldoc.org/ software. Please run at least
"make html" and carefully inspect and proofread the resulting HTML format
doc page before submitting your code. :l
For a new package (or even a single command) you should include one or
more example scripts demonstrating its use. These should run in no
more than a couple minutes, even on a single processor, and not require
large data files as input. See directories under examples/USER for
examples of input scripts other users provided for their packages.
These example inputs are also required for validating memory accesses
and testing for memory leaks with valgrind :l
If there is a paper of yours describing your feature (either the
algorithm/science behind the feature itself, or its initial usage, or
its implementation in LAMMPS), you can add the citation to the *.cpp
source file. See src/USER-EFF/atom_vec_electron.cpp for an example.
A LaTeX citation is stored in a variable at the top of the file and a
single line of code that references the variable is added to the
constructor of the class. Whenever a user invokes your feature from
their input script, this will cause LAMMPS to output the citation to a
log.cite file and prompt the user to examine the file. Note that you
should only use this for a paper you or your group authored.
E.g. adding a cite in the code for a paper by Nose and Hoover if you
write a fix that implements their integrator is not the intended
usage. That kind of citation should just be in the doc page you
provide. :l
:ule
Finally, as a general rule-of-thumb, the more clear and
self-explanatory you make your documentation and README files, and the
easier you make it for people to get started, e.g. by providing example
scripts, the more likely it is that users will try out your new feature.
:line
:line
:link(Foo)
[(Foo)] Foo, Morefoo, and Maxfoo, J of Classic Potentials, 75, 345 (1997).

867
doc/src/Section_python.txt
View File

@ -1,867 +0,0 @@
"Previous Section"_Section_modify.html - "LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next Section"_Section_errors.html :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
11. Python interface to LAMMPS :h2
LAMMPS can work together with Python in three ways. First, Python can
wrap LAMMPS through the "LAMMPS library
interface"_Section_howto.html#howto_19, so that a Python script can
create one or more instances of LAMMPS and launch one or more
simulations. In Python lingo, this is "extending" Python with LAMMPS.
Second, the low-level Python interface can be used indirectly through the
PyLammps and IPyLammps wrapper classes in Python. These wrappers try to
simplify the usage of LAMMPS in Python by providing an object-based interface
to common LAMMPS functionality. It also reduces the amount of code necessary to
parameterize LAMMPS scripts through Python and makes variables and computes
directly accessible. See "PyLammps interface"_#py_9 for more details.
Third, LAMMPS can use the Python interpreter, so that a LAMMPS input
script can invoke Python code, and pass information back-and-forth
between the input script and Python functions you write. The Python
code can also callback to LAMMPS to query or change its attributes.
In Python lingo, this is "embedding" Python in LAMMPS.
This section describes how to use these three approaches.
11.1 "Overview of running LAMMPS from Python"_#py_1
11.2 "Overview of using Python from a LAMMPS script"_#py_2
11.3 "Building LAMMPS as a shared library"_#py_3
11.4 "Installing the Python wrapper into Python"_#py_4
11.5 "Extending Python with MPI to run in parallel"_#py_5
11.6 "Testing the Python-LAMMPS interface"_#py_6
11.7 "Using LAMMPS from Python"_#py_7
11.8 "Example Python scripts that use LAMMPS"_#py_8
11.9 "PyLammps interface"_#py_9 :ul
If you are not familiar with it, "Python"_http://www.python.org is a
powerful scripting and programming language which can essentially do
anything that faster, lower-level languages like C or C++ can do, but
typically with much fewer lines of code. When used in embedded mode,
Python can perform operations that the simplistic LAMMPS input script
syntax cannot. Python can be also be used as a "glue" language to
drive a program through its library interface, or to hook multiple
pieces of software together, such as a simulation package plus a
visualization package, or to run a coupled multiscale or multiphysics
model.
See "Section 6.10"_Section_howto.html#howto_10 of the manual and
the couple directory of the distribution for more ideas about coupling
LAMMPS to other codes. See "Section
6.19"_Section_howto.html#howto_19 for a description of the LAMMPS
library interface provided in src/library.cpp and src/library.h, and
how to extend it for your needs. As described below, that interface
is what is exposed to Python either when calling LAMMPS from Python or
when calling Python from a LAMMPS input script and then calling back
to LAMMPS from Python code. The library interface is designed to be
easy to add functions to. Thus the Python interface to LAMMPS is also
easy to extend as well.
If you create interesting Python scripts that run LAMMPS or
interesting Python functions that can be called from a LAMMPS input
script, that you think would be useful to other users, please "email
them to the developers"_http://lammps.sandia.gov/authors.html. We can
include them in the LAMMPS distribution.
:line
:line
11.1 Overview of running LAMMPS from Python :link(py_1),h4
The LAMMPS distribution includes a python directory with all you need
to run LAMMPS from Python. The python/lammps.py file wraps the LAMMPS
library interface, with one wrapper function per LAMMPS library
function. This file makes it is possible to do the following either
from a Python script, or interactively from a Python prompt: create
one or more instances of LAMMPS, invoke LAMMPS commands or give it an
input script, run LAMMPS incrementally, extract LAMMPS results, an
modify internal LAMMPS variables. From a Python script you can do
this in serial or parallel. Running Python interactively in parallel
does not generally work, unless you have a version of Python that
extends standard Python to enable multiple instances of Python to read
what you type.
To do all of this, you must first build LAMMPS as a shared library,
then insure that your Python can find the python/lammps.py file and
the shared library. These steps are explained in subsequent sections
11.3 and 11.4. Sections 11.5 and 11.6 discuss using MPI from a
parallel Python program and how to test that you are ready to use
LAMMPS from Python. Section 11.7 lists all the functions in the
current LAMMPS library interface and how to call them from Python.
Section 11.8 gives some examples of coupling LAMMPS to other tools via
Python. For example, LAMMPS can easily be coupled to a GUI or other
visualization tools that display graphs or animations in real time as
LAMMPS runs. Examples of such scripts are included in the python
directory.
Two advantages of using Python to run LAMMPS are how concise the
language is, and that it can be run interactively, enabling rapid
development and debugging of programs. If you use it to mostly invoke
costly operations within LAMMPS, such as running a simulation for a
reasonable number of timesteps, then the overhead cost of invoking
LAMMPS thru Python will be negligible.
The Python wrapper for LAMMPS uses the amazing and magical (to me)
"ctypes" package in Python, which auto-generates the interface code
needed between Python and a set of C interface routines for a library.
Ctypes is part of standard Python for versions 2.5 and later. You can
check which version of Python you have installed, by simply typing
"python" at a shell prompt.
:line
11.2 Overview of using Python from a LAMMPS script :link(py_2),h4
LAMMPS has several commands which can be used to invoke Python
code directly from an input script:
"python"_python.html
"variable python"_variable.html
"fix python/invoke"_fix_python_invoke.html
"pair_style python"_pair_python.html :ul
The "python"_python.html command which can be used to define and
execute a Python function that you write the code for. The Python
function can also be assigned to a LAMMPS python-style variable via
the "variable"_variable.html command. Each time the variable is
evaluated, either in the LAMMPS input script itself, or by another
LAMMPS command that uses the variable, this will trigger the Python
function to be invoked.
The Python code for the function can be included directly in the input
script or in an auxiliary file. The function can have arguments which
are mapped to LAMMPS variables (also defined in the input script) and
it can return a value to a LAMMPS variable. This is thus a mechanism
for your input script to pass information to a piece of Python code,
ask Python to execute the code, and return information to your input
script.
Note that a Python function can be arbitrarily complex. It can import
other Python modules, instantiate Python classes, call other Python
functions, etc. The Python code that you provide can contain more
code than the single function. It can contain other functions or
Python classes, as well as global variables or other mechanisms for
storing state between calls from LAMMPS to the function.
The Python function you provide can consist of "pure" Python code that
only performs operations provided by standard Python. However, the
Python function can also "call back" to LAMMPS through its
Python-wrapped library interface, in the manner described in the
previous section 11.1. This means it can issue LAMMPS input script
commands or query and set internal LAMMPS state. As an example, this
can be useful in an input script to create a more complex loop with
branching logic, than can be created using the simple looping and
branching logic enabled by the "next"_next.html and "if"_if.html
commands.
See the "python"_python.html doc page and the "variable"_variable.html
doc page for its python-style variables for more info, including
examples of Python code you can write for both pure Python operations
and callbacks to LAMMPS.
The "fix python/invoke"_fix_python_invoke.html command can execute
Python code at selected timesteps during a simulation run.
The "pair_style python"_pair_python command allows you to define
pairwise potentials as python code which encodes a single pairwise
interaction. This is useful for rapid-developement and debugging of a
new potential.
To use any of these commands, you only need to build LAMMPS with the
PYTHON package installed:
make yes-python
make machine :pre
Note that this will link LAMMPS with the Python library on your
system, which typically requires several auxiliary system libraries to
also be linked. The list of these libraries and the paths to find
them are specified in the lib/python/Makefile.lammps file. You need
to insure that file contains the correct information for your version
of Python and your machine to successfully build LAMMPS. See the
lib/python/README file for more info.
If you want to write Python code with callbacks to LAMMPS, then you
must also follow the steps overviewed in the preceding section (11.1)
for running LAMMPS from Python. I.e. you must build LAMMPS as a
shared library and insure that Python can find the python/lammps.py
file and the shared library.
:line
11.3 Building LAMMPS as a shared library :link(py_3),h4
Instructions on how to build LAMMPS as a shared library are given in
"Section 2.4"_Section_start.html#start_4. A shared library is one
that is dynamically loadable, which is what Python requires to wrap
LAMMPS. On Linux this is a library file that ends in ".so", not ".a".
From the src directory, type
make foo mode=shlib :pre
where foo is the machine target name, such as linux or g++ or serial.
This should create the file liblammps_foo.so in the src directory, as
well as a soft link liblammps.so, which is what the Python wrapper will
load by default. Note that if you are building multiple machine
versions of the shared library, the soft link is always set to the
most recently built version.
NOTE: If you are building LAMMPS with an MPI or FFT library or other
auxiliary libraries (used by various packages), then all of these
extra libraries must also be shared libraries. If the LAMMPS
shared-library build fails with an error complaining about this, see
"Section 2.4"_Section_start.html#start_4 for more details.
:line
11.4 Installing the Python wrapper into Python :link(py_4),h4
For Python to invoke LAMMPS, there are 2 files it needs to know about:
python/lammps.py
src/liblammps.so :ul
Lammps.py is the Python wrapper on the LAMMPS library interface.
Liblammps.so is the shared LAMMPS library that Python loads, as
described above.
You can insure Python can find these files in one of two ways:
set two environment variables
run the python/install.py script :ul
If you set the paths to these files as environment variables, you only
have to do it once. For the csh or tcsh shells, add something like
this to your ~/.cshrc file, one line for each of the two files:
setenv PYTHONPATH $\{PYTHONPATH\}:/home/sjplimp/lammps/python
setenv LD_LIBRARY_PATH $\{LD_LIBRARY_PATH\}:/home/sjplimp/lammps/src :pre
If you use the python/install.py script, you need to invoke it every
time you rebuild LAMMPS (as a shared library) or make changes to the
python/lammps.py file.
You can invoke install.py from the python directory as
% python install.py \[libdir\] \[pydir\] :pre
The optional libdir is where to copy the LAMMPS shared library to; the
default is /usr/local/lib. The optional pydir is where to copy the
lammps.py file to; the default is the site-packages directory of the
version of Python that is running the install script.
Note that libdir must be a location that is in your default
LD_LIBRARY_PATH, like /usr/local/lib or /usr/lib. And pydir must be a
location that Python looks in by default for imported modules, like
its site-packages dir. If you want to copy these files to
non-standard locations, such as within your own user space, you will
need to set your PYTHONPATH and LD_LIBRARY_PATH environment variables
accordingly, as above.
If the install.py script does not allow you to copy files into system
directories, prefix the python command with "sudo". If you do this,
make sure that the Python that root runs is the same as the Python you
run. E.g. you may need to do something like
% sudo /usr/local/bin/python install.py \[libdir\] \[pydir\] :pre
You can also invoke install.py from the make command in the src
directory as
% make install-python :pre
In this mode you cannot append optional arguments. Again, you may
need to prefix this with "sudo". In this mode you cannot control
which Python is invoked by root.
Note that if you want Python to be able to load different versions of
the LAMMPS shared library (see "this section"_#py_5 below), you will
need to manually copy files like liblammps_g++.so into the appropriate
system directory. This is not needed if you set the LD_LIBRARY_PATH
environment variable as described above.
:line
11.5 Extending Python with MPI to run in parallel :link(py_5),h4
If you wish to run LAMMPS in parallel from Python, you need to extend
your Python with an interface to MPI. This also allows you to
make MPI calls directly from Python in your script, if you desire.
There are several Python packages available that purport to wrap MPI
as a library and allow MPI functions to be called from Python. However,
development on most of them seems to be halted except on:
"mpi4py"_https://bitbucket.org/mpi4py/mpi4py
"PyPar"_https://github.com/daleroberts/pypar :ul
Both packages, PyPar and mpi4py have been successfully tested with
LAMMPS. PyPar is simpler and easy to set up and use, but supports
only a subset of MPI. Mpi4py is more MPI-feature complete, but also a
bit more complex to use. As of version 2.0.0, mpi4py is the only
python MPI wrapper that allows passing a custom MPI communicator to
the LAMMPS constructor, which means one can easily run one or more
LAMMPS instances on subsets of the total MPI ranks.
:line
PyPar requires the ubiquitous "Numpy package"_http://numpy.scipy.org
be installed in your Python. After launching Python, type
import numpy :pre
to see if it is installed. If not, here is how to install it (version
1.3.0b1 as of April 2009). Unpack the numpy tarball and from its
top-level directory, type
python setup.py build
sudo python setup.py install :pre
The "sudo" is only needed if required to copy Numpy files into your
Python distribution's site-packages directory.
To install PyPar (version pypar-2.1.4_94 as of Aug 2012), unpack it
and from its "source" directory, type
python setup.py build
sudo python setup.py install :pre
Again, the "sudo" is only needed if required to copy PyPar files into
your Python distribution's site-packages directory.
If you have successfully installed PyPar, you should be able to run
Python and type
import pypar :pre
without error. You should also be able to run python in parallel
on a simple test script
% mpirun -np 4 python test.py :pre
where test.py contains the lines
import pypar
print "Proc %d out of %d procs" % (pypar.rank(),pypar.size()) :pre
and see one line of output for each processor you run on.
NOTE: To use PyPar and LAMMPS in parallel from Python, you must insure
both are using the same version of MPI. If you only have one MPI
installed on your system, this is not an issue, but it can be if you
have multiple MPIs. Your LAMMPS build is explicit about which MPI it
is using, since you specify the details in your lo-level
src/MAKE/Makefile.foo file. PyPar uses the "mpicc" command to find
information about the MPI it uses to build against. And it tries to
load "libmpi.so" from the LD_LIBRARY_PATH. This may or may not find
the MPI library that LAMMPS is using. If you have problems running
both PyPar and LAMMPS together, this is an issue you may need to
address, e.g. by moving other MPI installations so that PyPar finds
the right one.
:line
To install mpi4py (version mpi4py-2.0.0 as of Oct 2015), unpack it
and from its main directory, type
python setup.py build
sudo python setup.py install :pre
Again, the "sudo" is only needed if required to copy mpi4py files into
your Python distribution's site-packages directory. To install with
user privilege into the user local directory type
python setup.py install --user :pre
If you have successfully installed mpi4py, you should be able to run
Python and type
from mpi4py import MPI :pre
without error. You should also be able to run python in parallel
on a simple test script
% mpirun -np 4 python test.py :pre
where test.py contains the lines
from mpi4py import MPI
comm = MPI.COMM_WORLD
print "Proc %d out of %d procs" % (comm.Get_rank(),comm.Get_size()) :pre
and see one line of output for each processor you run on.
NOTE: To use mpi4py and LAMMPS in parallel from Python, you must
insure both are using the same version of MPI. If you only have one
MPI installed on your system, this is not an issue, but it can be if
you have multiple MPIs. Your LAMMPS build is explicit about which MPI
it is using, since you specify the details in your lo-level
src/MAKE/Makefile.foo file. Mpi4py uses the "mpicc" command to find
information about the MPI it uses to build against. And it tries to
load "libmpi.so" from the LD_LIBRARY_PATH. This may or may not find
the MPI library that LAMMPS is using. If you have problems running
both mpi4py and LAMMPS together, this is an issue you may need to
address, e.g. by moving other MPI installations so that mpi4py finds
the right one.
:line
11.6 Testing the Python-LAMMPS interface :link(py_6),h4
To test if LAMMPS is callable from Python, launch Python interactively
and type:
>>> from lammps import lammps
>>> lmp = lammps() :pre
If you get no errors, you're ready to use LAMMPS from Python. If the
2nd command fails, the most common error to see is
OSError: Could not load LAMMPS dynamic library :pre
which means Python was unable to load the LAMMPS shared library. This
typically occurs if the system can't find the LAMMPS shared library or
one of the auxiliary shared libraries it depends on, or if something
about the library is incompatible with your Python. The error message
should give you an indication of what went wrong.
You can also test the load directly in Python as follows, without
first importing from the lammps.py file:
>>> from ctypes import CDLL
>>> CDLL("liblammps.so") :pre
If an error occurs, carefully go thru the steps in "Section
2.4"_Section_start.html#start_4 and above about building a shared
library and about insuring Python can find the necessary two files
it needs.
[Test LAMMPS and Python in serial:] :h4
To run a LAMMPS test in serial, type these lines into Python
interactively from the bench directory:
>>> from lammps import lammps
>>> lmp = lammps()
>>> lmp.file("in.lj") :pre
Or put the same lines in the file test.py and run it as
% python test.py :pre
Either way, you should see the results of running the in.lj benchmark
on a single processor appear on the screen, the same as if you had
typed something like:
lmp_g++ -in in.lj :pre
[Test LAMMPS and Python in parallel:] :h4
To run LAMMPS in parallel, assuming you have installed the
"PyPar"_https://github.com/daleroberts/pypar package as discussed
above, create a test.py file containing these lines:
import pypar
from lammps import lammps
lmp = lammps()
lmp.file("in.lj")
print "Proc %d out of %d procs has" % (pypar.rank(),pypar.size()),lmp
pypar.finalize() :pre
To run LAMMPS in parallel, assuming you have installed the
"mpi4py"_https://bitbucket.org/mpi4py/mpi4py package as discussed
above, create a test.py file containing these lines:
from mpi4py import MPI
from lammps import lammps
lmp = lammps()
lmp.file("in.lj")
me = MPI.COMM_WORLD.Get_rank()
nprocs = MPI.COMM_WORLD.Get_size()
print "Proc %d out of %d procs has" % (me,nprocs),lmp
MPI.Finalize() :pre
You can either script in parallel as:
% mpirun -np 4 python test.py :pre
and you should see the same output as if you had typed
% mpirun -np 4 lmp_g++ -in in.lj :pre
Note that if you leave out the 3 lines from test.py that specify PyPar
commands you will instantiate and run LAMMPS independently on each of
the P processors specified in the mpirun command. In this case you
should get 4 sets of output, each showing that a LAMMPS run was made
on a single processor, instead of one set of output showing that
LAMMPS ran on 4 processors. If the 1-processor outputs occur, it
means that PyPar is not working correctly.
Also note that once you import the PyPar module, PyPar initializes MPI
for you, and you can use MPI calls directly in your Python script, as
described in the PyPar documentation. The last line of your Python
script should be pypar.finalize(), to insure MPI is shut down
correctly.
[Running Python scripts:] :h4
Note that any Python script (not just for LAMMPS) can be invoked in
one of several ways:
% python foo.script
% python -i foo.script
% foo.script :pre
The last command requires that the first line of the script be
something like this:
#!/usr/local/bin/python
#!/usr/local/bin/python -i :pre
where the path points to where you have Python installed, and that you
have made the script file executable:
% chmod +x foo.script :pre
Without the "-i" flag, Python will exit when the script finishes.
With the "-i" flag, you will be left in the Python interpreter when
the script finishes, so you can type subsequent commands. As
mentioned above, you can only run Python interactively when running
Python on a single processor, not in parallel.
:line
:line
11.7 Using LAMMPS from Python :link(py_7),h4
As described above, the Python interface to LAMMPS consists of a
Python "lammps" module, the source code for which is in
python/lammps.py, which creates a "lammps" object, with a set of
methods that can be invoked on that object. The sample Python code
below assumes you have first imported the "lammps" module in your
Python script, as follows:
from lammps import lammps :pre
These are the methods defined by the lammps module. If you look at
the files src/library.cpp and src/library.h you will see they
correspond one-to-one with calls you can make to the LAMMPS library
from a C++ or C or Fortran program, and which are described in
"Section 6.19"_Section_howto.html#howto_19 of the manual.
The python/examples directory has Python scripts which show how Python
can run LAMMPS, grab data, change it, and put it back into LAMMPS.
lmp = lammps() # create a LAMMPS object using the default liblammps.so library
# 4 optional args are allowed: name, cmdargs, ptr, comm
lmp = lammps(ptr=lmpptr) # use lmpptr as previously created LAMMPS object
lmp = lammps(comm=split) # create a LAMMPS object with a custom communicator, requires mpi4py 2.0.0 or later
lmp = lammps(name="g++") # create a LAMMPS object using the liblammps_g++.so library
lmp = lammps(name="g++",cmdargs=list) # add LAMMPS command-line args, e.g. list = \["-echo","screen"\] :pre
lmp.close() # destroy a LAMMPS object :pre
version = lmp.version() # return the numerical version id, e.g. LAMMPS 2 Sep 2015 -> 20150902 :pre
lmp.file(file) # run an entire input script, file = "in.lj"
lmp.command(cmd) # invoke a single LAMMPS command, cmd = "run 100"
lmp.commands_list(cmdlist) # invoke commands in cmdlist = ["run 10", "run 20"]
lmp.commands_string(multicmd) # invoke commands in multicmd = "run 10\nrun 20" :pre
size = lmp.extract_setting(name) # return data type info :pre
xlo = lmp.extract_global(name,type) # extract a global quantity
# name = "boxxlo", "nlocal", etc
# type = 0 = int
# 1 = double :pre
boxlo,boxhi,xy,yz,xz,periodicity,box_change = lmp.extract_box() # extract box info :pre
coords = lmp.extract_atom(name,type) # extract a per-atom quantity
# name = "x", "type", etc
# type = 0 = vector of ints
# 1 = array of ints
# 2 = vector of doubles
# 3 = array of doubles :pre
eng = lmp.extract_compute(id,style,type) # extract value(s) from a compute
v3 = lmp.extract_fix(id,style,type,i,j) # extract value(s) from a fix
# id = ID of compute or fix
# style = 0 = global data
# 1 = per-atom data
# 2 = local data
# type = 0 = scalar
# 1 = vector
# 2 = array
# i,j = indices of value in global vector or array :pre
var = lmp.extract_variable(name,group,flag) # extract value(s) from a variable
# name = name of variable
# group = group ID (ignored for equal-style variables)
# flag = 0 = equal-style variable
# 1 = atom-style variable :pre
value = lmp.get_thermo(name) # return current value of a thermo keyword
natoms = lmp.get_natoms() # total # of atoms as int :pre
flag = lmp.set_variable(name,value) # set existing named string-style variable to value, flag = 0 if successful
lmp.reset_box(boxlo,boxhi,xy,yz,xz) # reset the simulation box size :pre
data = lmp.gather_atoms(name,type,count) # return per-atom property of all atoms gathered into data, ordered by atom ID
# name = "x", "charge", "type", etc
data = lmp.gather_atoms_concat(name,type,count) # ditto, but concatenated atom values from each proc (unordered)
data = lmp.gather_atoms_subset(name,type,count,ndata,ids) # ditto, but for subset of Ndata atoms with IDs :pre
lmp.scatter_atoms(name,type,count,data) # scatter per-atom property to all atoms from data, ordered by atom ID
# name = "x", "charge", "type", etc
# count = # of per-atom values, 1 or 3, etc :pre
lmp.scatter_atoms_subset(name,type,count,ndata,ids,data) # ditto, but for subset of Ndata atoms with IDs :pre
lmp.create_atoms(n,ids,types,x,v,image,shrinkexceed) # create N atoms with IDs, types, x, v, and image flags :pre
:line
The lines
from lammps import lammps
lmp = lammps() :pre
create an instance of LAMMPS, wrapped in a Python class by the lammps
Python module, and return an instance of the Python class as lmp. It
is used to make all subsequent calls to the LAMMPS library.
Additional arguments to lammps() can be used to tell Python the name
of the shared library to load or to pass arguments to the LAMMPS
instance, the same as if LAMMPS were launched from a command-line
prompt.
If the ptr argument is set like this:
lmp = lammps(ptr=lmpptr) :pre
then lmpptr must be an argument passed to Python via the LAMMPS
"python"_python.html command, when it is used to define a Python
function that is invoked by the LAMMPS input script. This mode of
using Python with LAMMPS is described above in 11.2. The variable
lmpptr refers to the instance of LAMMPS that called the embedded
Python interpreter. Using it as an argument to lammps() allows the
returned Python class instance "lmp" to make calls to that instance of
LAMMPS. See the "python"_python.html command doc page for examples
using this syntax.
Note that you can create multiple LAMMPS objects in your Python
script, and coordinate and run multiple simulations, e.g.
from lammps import lammps
lmp1 = lammps()
lmp2 = lammps()
lmp1.file("in.file1")
lmp2.file("in.file2") :pre
The file(), command(), commands_list(), commands_string() methods
allow an input script, a single command, or multiple commands to be
invoked.
The extract_setting(), extract_global(), extract_box(),
extract_atom(), extract_compute(), extract_fix(), and
extract_variable() methods return values or pointers to data
structures internal to LAMMPS.
For extract_global() see the src/library.cpp file for the list of
valid names. New names could easily be added. A double or integer is
returned. You need to specify the appropriate data type via the type
argument.
For extract_atom(), a pointer to internal LAMMPS atom-based data is
returned, which you can use via normal Python subscripting. See the
extract() method in the src/atom.cpp file for a list of valid names.
Again, new names could easily be added if the property you want is not
listed. A pointer to a vector of doubles or integers, or a pointer to
an array of doubles (double **) or integers (int **) is returned. You
need to specify the appropriate data type via the type argument.
For extract_compute() and extract_fix(), the global, per-atom, or
local data calculated by the compute or fix can be accessed. What is
returned depends on whether the compute or fix calculates a scalar or
vector or array. For a scalar, a single double value is returned. If
the compute or fix calculates a vector or array, a pointer to the
internal LAMMPS data is returned, which you can use via normal Python
subscripting. The one exception is that for a fix that calculates a
global vector or array, a single double value from the vector or array
is returned, indexed by I (vector) or I and J (array). I,J are
zero-based indices. The I,J arguments can be left out if not needed.
See "Section 6.15"_Section_howto.html#howto_15 of the manual for a
discussion of global, per-atom, and local data, and of scalar, vector,
and array data types. See the doc pages for individual
"computes"_compute.html and "fixes"_fix.html for a description of what
they calculate and store.
For extract_variable(), an "equal-style or atom-style
variable"_variable.html is evaluated and its result returned.
For equal-style variables a single double value is returned and the
group argument is ignored. For atom-style variables, a vector of
doubles is returned, one value per atom, which you can use via normal
Python subscripting. The values will be zero for atoms not in the
specified group.
The get_thermo() method returns returns the current value of a thermo
keyword as a float.
The get_natoms() method returns the total number of atoms in the
simulation, as an int.
The set_variable() methosd sets an existing string-style variable to a
new string value, so that subsequent LAMMPS commands can access the
variable.
The reset_box() emthods resets the size and shape of the simulation
box, e.g. as part of restoring a previously extracted and saved state
of a simulation.
The gather methods collect peratom info of the requested type (atom
coords, atom types, forces, etc) from all processors, and returns the
same vector of values to each callling processor. The scatter
functions do the inverse. They distribute a vector of peratom values,
passed by all calling processors, to invididual atoms, which may be
owned by different processos.
Note that the data returned by the gather methods,
e.g. gather_atoms("x"), is different from the data structure returned
by extract_atom("x") in four ways. (1) Gather_atoms() returns a
vector which you index as x\[i\]; extract_atom() returns an array
which you index as x\[i\]\[j\]. (2) Gather_atoms() orders the atoms
by atom ID while extract_atom() does not. (3) Gather_atoms() returns
a list of all atoms in the simulation; extract_atoms() returns just
the atoms local to each processor. (4) Finally, the gather_atoms()
data structure is a copy of the atom coords stored internally in
LAMMPS, whereas extract_atom() returns an array that effectively
points directly to the internal data. This means you can change
values inside LAMMPS from Python by assigning a new values to the
extract_atom() array. To do this with the gather_atoms() vector, you
need to change values in the vector, then invoke the scatter_atoms()
method.
For the scatter methods, the array of coordinates passed to must be a
ctypes vector of ints or doubles, allocated and initialized something
like this:
from ctypes import *
natoms = lmp.get_natoms()
n3 = 3*natoms
x = (n3*c_double)()
x\[0\] = x coord of atom with ID 1
x\[1\] = y coord of atom with ID 1
x\[2\] = z coord of atom with ID 1
x\[3\] = x coord of atom with ID 2
...
x\[n3-1\] = z coord of atom with ID natoms
lmp.scatter_atoms("x",1,3,x) :pre
Alternatively, you can just change values in the vector returned by
the gather methods, since they are also ctypes vectors.
:line
As noted above, these Python class methods correspond one-to-one with
the functions in the LAMMPS library interface in src/library.cpp and
library.h. This means you can extend the Python wrapper via the
following steps:
Add a new interface function to src/library.cpp and
src/library.h. :ulb,l
Rebuild LAMMPS as a shared library. :l
Add a wrapper method to python/lammps.py for this interface
function. :l
You should now be able to invoke the new interface function from a
Python script. Isn't ctypes amazing? :l
:ule
:line
:line
11.8 Example Python scripts that use LAMMPS :link(py_8),h4
These are the Python scripts included as demos in the python/examples
directory of the LAMMPS distribution, to illustrate the kinds of
things that are possible when Python wraps LAMMPS. If you create your
own scripts, send them to us and we can include them in the LAMMPS
distribution.
trivial.py, read/run a LAMMPS input script thru Python,
demo.py, invoke various LAMMPS library interface routines,
simple.py, run in parallel, similar to examples/COUPLE/simple/simple.cpp,
split.py, same as simple.py but running in parallel on a subset of procs,
gui.py, GUI go/stop/temperature-slider to control LAMMPS,
plot.py, real-time temperature plot with GnuPlot via Pizza.py,
viz_tool.py, real-time viz via some viz package,
vizplotgui_tool.py, combination of viz_tool.py and plot.py and gui.py :tb(c=2)
:line
For the viz_tool.py and vizplotgui_tool.py commands, replace "tool"
with "gl" or "atomeye" or "pymol" or "vmd", depending on what
visualization package you have installed.
Note that for GL, you need to be able to run the Pizza.py GL tool,
which is included in the pizza sub-directory. See the "Pizza.py doc
pages"_pizza for more info:
:link(pizza,http://www.sandia.gov/~sjplimp/pizza.html)
Note that for AtomEye, you need version 3, and there is a line in the
scripts that specifies the path and name of the executable. See the
AtomEye WWW pages "here"_atomeye or "here"_atomeye3 for more details:
http://mt.seas.upenn.edu/Archive/Graphics/A
http://mt.seas.upenn.edu/Archive/Graphics/A3/A3.html :pre
:link(atomeye,http://mt.seas.upenn.edu/Archive/Graphics/A)
:link(atomeye3,http://mt.seas.upenn.edu/Archive/Graphics/A3/A3.html)
The latter link is to AtomEye 3 which has the scriping
capability needed by these Python scripts.
Note that for PyMol, you need to have built and installed the
open-source version of PyMol in your Python, so that you can import it
from a Python script. See the PyMol WWW pages "here"_pymolhome or
"here"_pymolopen for more details:
http://www.pymol.org
http://sourceforge.net/scm/?type=svn&group_id=4546 :pre
:link(pymolhome,http://www.pymol.org)
:link(pymolopen,http://sourceforge.net/scm/?type=svn&group_id=4546)
The latter link is to the open-source version.
Note that for VMD, you need a fairly current version (1.8.7 works for
me) and there are some lines in the pizza/vmd.py script for 4 PIZZA
variables that have to match the VMD installation on your system.
:line
See the python/README file for instructions on how to run them and the
source code for individual scripts for comments about what they do.
Here are screenshots of the vizplotgui_tool.py script in action for
different visualization package options. Click to see larger images:
:image(JPG/screenshot_gl_small.jpg,JPG/screenshot_gl.jpg)
:image(JPG/screenshot_atomeye_small.jpg,JPG/screenshot_atomeye.jpg)
:image(JPG/screenshot_pymol_small.jpg,JPG/screenshot_pymol.jpg)
:image(JPG/screenshot_vmd_small.jpg,JPG/screenshot_vmd.jpg)
11.9 PyLammps interface :link(py_9),h4
Please see the "PyLammps Tutorial"_tutorial_pylammps.html.

128
doc/src/Section_start.txt
View File

@ -1,4 +1,6 @@
"Previous Section"_Section_intro.html - "LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next Section"_Section_commands.html :c
"Previous Section"_Section_intro.html - "LAMMPS WWW Site"_lws -
"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
Section"_Section_commands.html :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
@ -117,10 +119,11 @@ lower-case name of the package, e.g. replica or user-misc.
If you want to do one of the following:
use a LAMMPS command that requires an extra library (e.g. "dump image"_dump_image.html)
build with a package that requires an extra library
build with an accelerator package that requires special compiler/linker settings
run on a machine that has its own compilers, settings, or libraries :ul
use a LAMMPS command that requires an extra library (e.g. "dump
image"_dump_image.html) build with a package that requires an extra
library build with an accelerator package that requires special
compiler/linker settings run on a machine that has its own compilers,
settings, or libraries :ul
then building LAMMPS is more complicated. You may need to find where
extra libraries exist on your machine or install them if they don't.
@ -695,8 +698,8 @@ are always included, plus optional packages. Packages are groups of
files that enable a specific set of features. For example, force
fields for molecular systems or granular systems are in packages.
"Section 4"_Section_packages.html in the manual has details about all
the packages, which come in two flavors: [standard] and [user]
The "Packages"_Packages.html doc pages has details about all the
packages, which come in two flavors: [standard] and [user]
packages. It also has specific instructions for building LAMMPS with
any package which requires an extra library. General instructions are
below.
@ -826,45 +829,47 @@ options.
Packages that require extra libraries :h4,link(start_3_3)
A few of the standard and user packages require extra libraries. See
"Section 4"_Section_packages.html for two tables of packages which
indicate which ones require libraries. For each such package, the
Section 4 doc page gives details on how to build the extra library,
including how to download it if necessary. The basic ideas are
summarized here.
the "Packages"_Packages.html doc pages for two tables of packages
which indicate which ones require libraries. For each such package,
the Section 4 doc page gives details on how to build the extra
library, including how to download it if necessary. The basic ideas
are summarized here.
[System libraries:]
Packages in the tables "Section 4"_Section_packages.html with a "sys"
in the last column link to system libraries that typically already
exist on your machine. E.g. the python package links to a system
Python library. If your machine does not have the required library,
you will have to download and install it on your machine, in either
the system or user space.
Packages in the standard and user tables of the
"Packages"_Packages.html doc pages with a "sys" in the last column
link to system libraries that typically already exist on your machine.
E.g. the python package links to a system Python library. If your
machine does not have the required library, you will have to download
and install it on your machine, in either the system or user space.
[Internal libraries:]
Packages in the tables "Section 4"_Section_packages.html with an "int"
in the last column link to internal libraries whose source code is
included with LAMMPS, in the lib/name directory where name is the
package name. You must first build the library in that directory
before building LAMMPS with that package installed. E.g. the gpu
package links to a library you build in the lib/gpu dir. You can
often do the build in one step by typing "make lib-name args=..."
from the src dir, with appropriate arguments. You can leave off the
args to see a help message. See "Section 4"_Section_packages.html for
details for each package.
Packages in the standard and user tables of the
"Packages"_Packages.html doc pages with an "int" in the last column
link to internal libraries whose source code is included with LAMMPS,
in the lib/name directory where name is the package name. You must
first build the library in that directory before building LAMMPS with
that package installed. E.g. the gpu package links to a library you
build in the lib/gpu dir. You can often do the build in one step by
typing "make lib-name args=..." from the src dir, with appropriate
arguments. You can leave off the args to see a help message. See the
"Packages details"_Packages_details.html doc page for details for each
package.
[External libraries:]
Packages in the tables "Section 4"_Section_packages.html with an "ext"
in the last column link to external libraries whose source code is not
included with LAMMPS. You must first download and install the library
before building LAMMPS with that package installed. E.g. the voronoi
package links to the freely available "Voro++ library"_voro_home2. You
can often do the download/build in one step by typing "make lib-name
Packages in the standard and user tables of the
"Packages"_Packages.html doc pages with an "ext" in the last column
link to external libraries whose source code is not included with
LAMMPS. You must first download and install the library before
building LAMMPS with that package installed. E.g. the voronoi package
links to the freely available "Voro++ library"_voro_home2. You can
often do the download/build in one step by typing "make lib-name
args=..." from the src dir, with appropriate arguments. You can leave
off the args to see a help message. See "Section
4"_Section_packages.html for details for each package.
off the args to see a help message. See the "Packages
details"_Packages_details.html doc page for details for each package.
:link(voro_home2,http://math.lbl.gov/voro++)
@ -886,9 +891,9 @@ copied from a lib/name/Makefile.lammps.* file when the library is
built. If those settings are not correct for your machine you will
need to edit or create an appropriate Makefile.lammps file.
Package-specific details for these steps are given in "Section
4"_Section_packages.html an in README files in the lib/name
directories.
Package-specific details for these steps are given on the "Packages
details"_Packages_details.html doc page and in README files in the
lib/name directories.
[Compiler options needed for accelerator packages:]
@ -899,14 +904,14 @@ these accelerator packages for optimal performance requires specific
settings in the Makefile.machine file you use.
A summary of the Makefile.machine settings needed for each of these
packages is given in "Section 4"_Section_packages.html. More info is
given on the doc pages that describe each package in detail:
packages is given on the "Packages"_Packages.html doc pages. More
info is given on the doc pages that describe each package in detail:
5.3.1 "USER-INTEL package"_accelerate_intel.html
5.3.2 "GPU package"_accelerate_intel.html
5.3.3 "KOKKOS package"_accelerate_kokkos.html
5.3.4 "USER-OMP package"_accelerate_omp.html
5.3.5 "OPT package"_accelerate_opt.html :all(b)
"USER-INTEL package"_Speed_intel.html
"GPU package"_Speed_gpu.html
"KOKKOS package"_Speed_kokkos.html
"USER-OMP package"_Speed_omp.html
"OPT package"_Speed_opt.html :all(b)
You can also use or examine the following machine Makefiles in
src/MAKE/OPTIONS, which include the settings. Note that the
@ -930,8 +935,8 @@ Makefile.opt :ul
LAMMPS can be built as either a static or shared library, which can
then be called from another application or a scripting language. See
"this section"_Section_howto.html#howto_10 for more info on coupling
LAMMPS to other codes. See "this section"_Section_python.html for
more info on wrapping and running LAMMPS from Python.
LAMMPS to other codes. See the "Python"_Python.html doc page for more
info on wrapping and running LAMMPS from Python.
Static library :h4
@ -955,15 +960,15 @@ dynamically loaded, e.g. from Python, type
make foo mode=shlib :pre
where foo is the machine name. This kind of library is required when
wrapping LAMMPS with Python; see "Section 11"_Section_python.html
for details. This will use the SHFLAGS and SHLIBFLAGS settings in
wrapping LAMMPS with Python; see the "Python"_Python.html doc page for
details. This will use the SHFLAGS and SHLIBFLAGS settings in
src/MAKE/Makefile.foo and perform the build in the directory
Obj_shared_foo. This is so that each file can be compiled with the
-fPIC flag which is required for inclusion in a shared library. The
build will create the file liblammps_foo.so which another application
can link to dynamically. It will also create a soft link liblammps.so,
which will point to the most recently built shared library. This is
the file the Python wrapper loads by default.
can link to dynamically. It will also create a soft link
liblammps.so, which will point to the most recently built shared
library. This is the file the Python wrapper loads by default.
Note that for a shared library to be usable by a calling program, all
the auxiliary libraries it depends on must also exist as shared
@ -1035,10 +1040,10 @@ src/library.cpp and src/library.h.
See the sample codes in examples/COUPLE/simple for examples of C++ and
C and Fortran codes that invoke LAMMPS thru its library interface.
There are other examples as well in the COUPLE directory which are
discussed in "Section 6.10"_Section_howto.html#howto_10 of the
manual. See "Section 11"_Section_python.html of the manual for a
description of the Python wrapper provided with LAMMPS that operates
through the LAMMPS library interface.
discussed in "Section 6.10"_Section_howto.html#howto_10 of the manual.
See the "Python"_Python.html doc page for a description of the Python
wrapper provided with LAMMPS that operates through the LAMMPS library
interface.
The files src/library.cpp and library.h define the C-style API for
using LAMMPS as a library. See "Section
@ -1177,7 +1182,7 @@ than your working directory, which is probably not what you want.
If LAMMPS encounters errors in the input script or while running a
simulation it will print an ERROR message and stop or a WARNING
message and continue. See "Section 12"_Section_errors.html for a
message and continue. See the "Errors"_Errors.html doc page for a
discussion of the various kinds of errors LAMMPS can or can't detect,
a list of all ERROR and WARNING messages, and what to do about them.
@ -1274,8 +1279,8 @@ Either the full word or an abbreviation can be used for the keywords.
Note that the keywords do not use a leading minus sign. I.e. the
keyword is "t", not "-t". Also note that each of the keywords has a
default setting. Example of when to use these options and what
settings to use on different platforms is given in "Section
5.3"_Section_accelerate.html#acc_3.
settings to use on different platforms is given on the "Speed
kokkos"_Speed_kokkos.html doc page.
d or device
g or gpus
@ -1459,8 +1464,7 @@ cores within each node are ranked in a desired order. Or when using
the "run_style verlet/split"_run_style.html command with 2 partitions
to insure that a specific Kspace processor (in the 2nd partition) is
matched up with a specific set of processors in the 1st partition.
See the "Section 5"_Section_accelerate.html doc pages for
more details.
See the "Speed tips"_Speed_tips.html doc page for more details.
If the keyword {nth} is used with a setting {N}, then it means every
Nth processor will be moved to the end of the ranking. This is useful

64
doc/src/Speed.txt Normal file
View File

@ -0,0 +1,64 @@
"Previous Section"_Package.html - "LAMMPS WWW Site"_lws -
"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
Section"_Section_howto.html :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
Accelerate performance :h2
This section describes various methods for improving LAMMPS
performance for different classes of problems running on different
kinds of machines.
There are two thrusts to the discussion that follows. The first is
using code options that implement alternate algorithms that can
speed-up a simulation. The second is to use one of the several
accelerator packages provided with LAMMPS that contain code optimized
for certain kinds of hardware, including multi-core CPUs, GPUs, and
Intel Xeon Phi coprocessors.
The "Benchmark page"_http://lammps.sandia.gov/bench.html of the LAMMPS
web site gives performance results for the various accelerator
packages discussed on the "Speed packages"_Speed_packages.html doc
page, for several of the standard LAMMPS benchmark problems, as a
function of problem size and number of compute nodes, on different
hardware platforms.
<!-- RST
.. toctree::
Speed_bench
Speed_measure
.. toctree::
Speed_tips
.. toctree::
Speed_packages
Speed_compare
END_RST -->
<!-- HTML_ONLY -->
"Benchmarks"_Speed_bench.html
"Measuring performance"_Speed_measure.html :all(b)
"General tips"_Speed_tips.html :all(b)
"Accelerator packages"_Speed_packages.html
"GPU package"_Speed_gpu.html
"USER-INTEL package"_Speed_intel.html
"KOKKOS package"_Speed_kokkos.html
"USER-OMP package"_Speed_omp.html
"OPT package"_Speed_opt.html
"Comparison of accelerator packages"_Speed_compare.html :all(b)
<!-- END_HTML_ONLY -->

17
doc/src/Section_perf.txt → doc/src/Speed_bench.txt
View File

@ -1,4 +1,5 @@
"Previous Section"_Section_example.html - "LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next Section"_Section_tools.html :c
"Higher level section"_Speed.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
@ -6,12 +7,12 @@
:line
8. Performance & scalability :h2
Benchmarks :h3
Current LAMMPS performance is discussed on the Benchmarks page of the
"LAMMPS WWW Site"_lws where CPU timings and parallel efficiencies are
listed. The page has several sections, which are briefly described
below:
Current LAMMPS performance is discussed on the "Benchmarks
page"_http://lammps.sandia.gov/bench.html of the "LAMMPS website"_lws
where timings and parallel efficiencies are listed. The page has
several sections, which are briefly described below:
CPU performance on 5 standard problems, strong and weak scaling
GPU and Xeon Phi performance on same and related problems
@ -51,8 +52,8 @@ of these 5 problems on 1 or 4 cores of Linux desktop. The bench/FERMI
and bench/KEPLER dirs have input files and scripts and instructions
for running the same (or similar) problems using OpenMP or GPU or Xeon
Phi acceleration options. See the README files in those dirs and the
"Section 5.3"_Section_accelerate.html#acc_3 doc pages for
instructions on how to build LAMMPS and run on that kind of hardware.
"Speed packages"_Speed_packages.html doc pages for instructions on how
to build LAMMPS and run on that kind of hardware.
The bench/POTENTIALS directory has input files which correspond to the
table of results on the

73
doc/src/Speed_compare.txt Normal file
View File

@ -0,0 +1,73 @@
"Higher level section"_Speed.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
Comparison of various accelerator packages :h3
NOTE: this section still needs to be re-worked with additional KOKKOS
and USER-INTEL information.
The next section compares and contrasts the various accelerator
options, since there are multiple ways to perform OpenMP threading,
run on GPUs, and run on Intel Xeon Phi coprocessors.
All 3 of these packages accelerate a LAMMPS calculation using NVIDIA
hardware, but they do it in different ways.
As a consequence, for a particular simulation on specific hardware,
one package may be faster than the other. We give guidelines below,
but the best way to determine which package is faster for your input
script is to try both of them on your machine. See the benchmarking
section below for examples where this has been done.
[Guidelines for using each package optimally:]
The GPU package allows you to assign multiple CPUs (cores) to a single
GPU (a common configuration for "hybrid" nodes that contain multicore
CPU(s) and GPU(s)) and works effectively in this mode. :ulb,l
The GPU package moves per-atom data (coordinates, forces)
back-and-forth between the CPU and GPU every timestep. The
KOKKOS/CUDA package only does this on timesteps when a CPU calculation
is required (e.g. to invoke a fix or compute that is non-GPU-ized).
Hence, if you can formulate your input script to only use GPU-ized
fixes and computes, and avoid doing I/O too often (thermo output, dump
file snapshots, restart files), then the data transfer cost of the
KOKKOS/CUDA package can be very low, causing it to run faster than the
GPU package. :l
The GPU package is often faster than the KOKKOS/CUDA package, if the
number of atoms per GPU is smaller. The crossover point, in terms of
atoms/GPU at which the KOKKOS/CUDA package becomes faster depends
strongly on the pair style. For example, for a simple Lennard Jones
system the crossover (in single precision) is often about 50K-100K
atoms per GPU. When performing double precision calculations the
crossover point can be significantly smaller. :l
Both packages compute bonded interactions (bonds, angles, etc) on the
CPU. If the GPU package is running with several MPI processes
assigned to one GPU, the cost of computing the bonded interactions is
spread across more CPUs and hence the GPU package can run faster. :l
When using the GPU package with multiple CPUs assigned to one GPU, its
performance depends to some extent on high bandwidth between the CPUs
and the GPU. Hence its performance is affected if full 16 PCIe lanes
are not available for each GPU. In HPC environments this can be the
case if S2050/70 servers are used, where two devices generally share
one PCIe 2.0 16x slot. Also many multi-GPU mainboards do not provide
full 16 lanes to each of the PCIe 2.0 16x slots. :l
:ule
[Differences between the two packages:]
The GPU package accelerates only pair force, neighbor list, and PPPM
calculations. :ulb,l
The GPU package requires neighbor lists to be built on the CPU when using
exclusion lists, hybrid pair styles, or a triclinic simulation box. :l
:ule

15
doc/src/accelerate_gpu.txt → doc/src/Speed_gpu.txt
View File

@ -1,5 +1,5 @@
"Previous Section"_Section_packages.html - "LAMMPS WWW Site"_lws -
"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
"Higher level section"_Speed.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
@ -7,9 +7,7 @@
:line
"Return to Section accelerate overview"_Section_accelerate.html
5.3.1 GPU package :h5
GPU package :h3
The GPU package was developed by Mike Brown at ORNL and his
collaborators, particularly Trung Nguyen (ORNL). It provides GPU
@ -72,10 +70,9 @@ Run lammps/lib/gpu/nvc_get_devices (after building the GPU library, see below) t
[Building LAMMPS with the GPU package:]
This requires two steps (a,b): build the GPU library, then build
LAMMPS with the GPU package.
You can do both these steps in one line as described in
"Section 4"_Section_packages.html of the manual.
LAMMPS with the GPU package. You can do both these steps in one line
as described on the "Packages details"_Packages_details.html#GPU doc
page.
Or you can follow these two (a,b) steps:

22
doc/src/accelerate_intel.txt → doc/src/Speed_intel.txt
View File

@ -1,5 +1,5 @@
"Previous Section"_Section_packages.html - "LAMMPS WWW Site"_lws -
"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
"Higher level section"_Speed.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
@ -7,9 +7,7 @@
:line
"Return to Section accelerate overview"_Section_accelerate.html
5.3.2 USER-INTEL package :h5
USER-INTEL package :h3
The USER-INTEL package is maintained by Mike Brown at Intel
Corporation. It provides two methods for accelerating simulations,
@ -188,8 +186,8 @@ can start running so that the CPU pipeline is still being used
efficiently. Although benefits can be seen by launching a MPI task
for every hardware thread, for multinode simulations, we recommend
that OpenMP threads are used for SMT instead, either with the
USER-INTEL package, "USER-OMP package"_accelerate_omp.html, or
"KOKKOS package"_accelerate_kokkos.html. In the example above, up
USER-INTEL package, "USER-OMP package"_Speed_omp.html, or
"KOKKOS package"_Speed_kokkos.html. In the example above, up
to 36X speedups can be observed by using all 36 physical cores with
LAMMPS. By using all 72 hardware threads, an additional 10-30%
performance gain can be achieved.
@ -233,9 +231,9 @@ source /opt/intel/parallel_studio_xe_2016.3.067/psxevars.sh
# or psxevars.csh for C-shell
make intel_cpu_intelmpi :pre
Alternatively this can be done as a single command with
suitable make command invocations. This is discussed in "Section
4"_Section_packages.html of the manual.
Alternatively this can be done as a single command with suitable make
command invocations, as described on the "Packages
details"_Packages_details.html#USER-INTEL doc page.
Note that if you build with support for a Phi coprocessor, the same
binary can be used on nodes with or without coprocessors installed.
@ -391,8 +389,8 @@ performance and/or scalability for simple 2-body potentials such as
lj/cut or when using LRT mode on processors supporting AVX-512.
Not all styles are supported in the USER-INTEL package. You can mix
the USER-INTEL package with styles from the "OPT"_accelerate_opt.html
package or the "USER-OMP package"_accelerate_omp.html. Of course,
the USER-INTEL package with styles from the "OPT"_Speed_opt.html
package or the "USER-OMP package"_Speed_omp.html. Of course,
this requires that these packages were installed at build time. This
can performed automatically by using "-sf hybrid intel opt" or
"-sf hybrid intel omp" command-line options. Alternatively, the "opt"

20
doc/src/accelerate_kokkos.txt → doc/src/Speed_kokkos.txt
View File

@ -1,5 +1,5 @@
"Previous Section"_Section_packages.html - "LAMMPS WWW Site"_lws -
"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
"Higher level section"_Speed.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
@ -7,9 +7,7 @@
:line
"Return to Section accelerate overview"_Section_accelerate.html
5.3.3 KOKKOS package :h5
KOKKOS package :h3
Kokkos is a templated C++ library that provides abstractions to allow
a single implementation of an application kernel (e.g. a pair style) to run efficiently on
@ -85,10 +83,10 @@ make kokkos_phi :pre
[Compile for CPUs and GPUs (with OpenMPI or MPICH):]
NOTE: To build with Kokkos support for NVIDIA GPUs, NVIDIA CUDA software
version 7.5 or later must be installed on your system. See the
discussion for the "GPU"_accelerate_gpu.html package for details of
how to check and do this.
NOTE: To build with Kokkos support for NVIDIA GPUs, NVIDIA CUDA
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.
use a C++11 compatible compiler and set KOKKOS_ARCH variable in
/src/MAKE/OPTIONS/Makefile.kokkos_cuda_mpi for both GPU and CPU as described
@ -434,8 +432,8 @@ migrate during a simulation. KOKKOS_USE_TPLS=hwloc should always be
used if running with KOKKOS_DEVICES=Pthreads for pthreads. It is not
necessary for KOKKOS_DEVICES=OpenMP for OpenMP, because OpenMP
provides alternative methods via environment variables for binding
threads to hardware cores. More info on binding threads to cores is
given in "Section 5.3"_Section_accelerate.html#acc_3.
threads to hardware cores. More info on binding threads to cores is
given on the "Speed omp"_Speed_omp.html doc page.
KOKKOS_USE_TPLS=librt enables use of a more accurate timer mechanism
on most Unix platforms. This library is not available on all

55
doc/src/Speed_measure.txt Normal file
View File

@ -0,0 +1,55 @@
"Higher level section"_Speed.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
Measuring performance :h3
Before trying to make your simulation run faster, you should
understand how it currently performs and where the bottlenecks are.
The best way to do this is run the your system (actual number of
atoms) for a modest number of timesteps (say 100 steps) on several
different processor counts, including a single processor if possible.
Do this for an equilibrium version of your system, so that the
100-step timings are representative of a much longer run. There is
typically no need to run for 1000s of timesteps to get accurate
timings; you can simply extrapolate from short runs.
For the set of runs, look at the timing data printed to the screen and
log file at the end of each LAMMPS run. "This
section"_Section_start.html#start_7 of the manual has an overview.
Running on one (or a few processors) should give a good estimate of
the serial performance and what portions of the timestep are taking
the most time. Running the same problem on a few different processor
counts should give an estimate of parallel scalability. I.e. if the
simulation runs 16x faster on 16 processors, its 100% parallel
efficient; if it runs 8x faster on 16 processors, it's 50% efficient.
The most important data to look at in the timing info is the timing
breakdown and relative percentages. For example, trying different
options for speeding up the long-range solvers will have little impact
if they only consume 10% of the run time. If the pairwise time is
dominating, you may want to look at GPU or OMP versions of the pair
style, as discussed below. Comparing how the percentages change as
you increase the processor count gives you a sense of how different
operations within the timestep are scaling. Note that if you are
running with a Kspace solver, there is additional output on the
breakdown of the Kspace time. For PPPM, this includes the fraction
spent on FFTs, which can be communication intensive.
Another important detail in the timing info are the histograms of
atoms counts and neighbor counts. If these vary widely across
processors, you have a load-imbalance issue. This often results in
inaccurate relative timing data, because processors have to wait when
communication occurs for other processors to catch up. Thus the
reported times for "Communication" or "Other" may be higher than they
really are, due to load-imbalance. If this is an issue, you can
uncomment the MPI_Barrier() lines in src/timer.cpp, and recompile
LAMMPS, to obtain synchronized timings.

13
doc/src/accelerate_omp.txt → doc/src/Speed_omp.txt
View File

@ -1,5 +1,5 @@
"Previous Section"_Section_packages.html - "LAMMPS WWW Site"_lws -
"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
"Higher level section"_Speed.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
@ -7,9 +7,7 @@
:line
"Return to Section 5 overview"_Section_accelerate.html
5.3.4 USER-OMP package :h5
USER-OMP package :h3
The USER-OMP package was developed by Axel Kohlmeyer at Temple
University. It provides multi-threaded versions of most pair styles,
@ -39,7 +37,8 @@ each MPI task running on a CPU.
The lines above illustrate how to include/build with the USER-OMP
package in two steps, using the "make" command. Or how to do it with
one command as described in "Section 4"_Section_packages.html of the manual.
one command as described on the "Packages
details"_Packages_details.html#USER-OMP doc page.
Note that the CCFLAGS and LINKFLAGS settings in Makefile.machine must
include "-fopenmp". Likewise, if you use an Intel compiler, the
@ -100,7 +99,7 @@ task, versus running standard LAMMPS with its standard un-accelerated
styles (in serial or all-MPI parallelization with 1 task/core). This
is because many of the USER-OMP styles contain similar optimizations
to those used in the OPT package, described in "Section
5.3.5"_accelerate_opt.html.
5.3.5"_Speed_opt.html.
With multiple threads/task, the optimal choice of number of MPI
tasks/node and OpenMP threads/task can vary a lot and should always be

11
doc/src/accelerate_opt.txt → doc/src/Speed_opt.txt
View File

@ -1,5 +1,5 @@
"Previous Section"_Section_packages.html - "LAMMPS WWW Site"_lws -
"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
"Higher level section"_Speed.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
@ -7,9 +7,7 @@
:line
"Return to Section accelerate overview"_Section_accelerate.html
5.3.5 OPT package :h5
OPT package :h3
The OPT package was developed by James Fischer (High Performance
Technologies), David Richie, and Vincent Natoli (Stone Ridge
@ -34,7 +32,8 @@ None.
The lines above illustrate how to build LAMMPS with the OPT package in
two steps, using the "make" command. Or how to do it with one command
as described in "Section 4"_Section_packages.html of the manual.
as described on the "Packages details"_Packages_details.html#OPT doc
page.
Note that if you use an Intel compiler to build with the OPT package,
the CCFLAGS setting in your Makefile.machine must include "-restrict".

191
doc/src/Speed_packages.txt Normal file
View File

@ -0,0 +1,191 @@
"Higher level section"_Speed.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
Accelerator packages :h3
Accelerated versions of various "pair_style"_pair_style.html,
"fixes"_fix.html, "computes"_compute.html, and other commands have
been added to LAMMPS, which will typically run faster than the
standard non-accelerated versions. Some require appropriate hardware
to be present on your system, e.g. GPUs or Intel Xeon Phi
coprocessors.
All of these commands are in packages provided with LAMMPS. An
overview of packages is give on the "Packages"_Packages.html doc
pages.
These are the accelerator packages currently in LAMMPS, either as
standard or user packages:
"GPU Package"_Speed_gpu.html : for NVIDIA GPUs as well as OpenCL support
"USER-INTEL Package"_Speed_intel.html : for Intel CPUs and Intel Xeon Phi
"KOKKOS Package"_Speed_kokkos.html : for Nvidia GPUs, Intel Xeon Phi, and OpenMP threading
"USER-OMP Package"_Speed_omp.html : for OpenMP threading and generic CPU optimizations
"OPT Package"_Speed_opt.html : generic CPU optimizations :tb(s=:)
<!-- RST
.. toctree::
:maxdepth: 1
:hidden:
Speed_gpu
Speed_intel
Speed_kokkos
Speed_omp
Speed_opt
END_RST -->
Inverting this list, LAMMPS currently has acceleration support for
three kinds of hardware, via the listed packages:
Many-core CPUs : "USER-INTEL"_Speed_intel.html, "KOKKOS"_Speed_kokkos.html, "USER-OMP"_Speed_omp.html, "OPT"_Speed_opt.html packages
NVIDIA GPUs : "GPU"_Speed_gpu.html, "KOKKOS"_Speed_kokkos.html packages
Intel Phi : "USER-INTEL"_Speed_intel.html, "KOKKOS"_Speed_kokkos.html packages :tb(s=:)
Which package is fastest for your hardware may depend on the size
problem you are running and what commands (accelerated and
non-accelerated) are invoked by your input script. While these doc
pages include performance guidelines, there is no substitute for
trying out the different packages appropriate to your hardware.
Any accelerated style has the same name as the corresponding standard
style, except that a suffix is appended. Otherwise, the syntax for
the command that uses the style is identical, their functionality is
the same, and the numerical results it produces should also be the
same, except for precision and round-off effects.
For example, all of these styles are accelerated variants of the
Lennard-Jones "pair_style lj/cut"_pair_lj.html:
"pair_style lj/cut/gpu"_pair_lj.html
"pair_style lj/cut/intel"_pair_lj.html
"pair_style lj/cut/kk"_pair_lj.html
"pair_style lj/cut/omp"_pair_lj.html
"pair_style lj/cut/opt"_pair_lj.html :ul
To see what accelerate styles are currently available, see
"Section 3.5"_Section_commands.html#cmd_5 of the manual. The
doc pages for individual commands (e.g. "pair lj/cut"_pair_lj.html or
"fix nve"_fix_nve.html) also list any accelerated variants available
for that style.
To use an accelerator package in LAMMPS, and one or more of the styles
it provides, follow these general steps. Details vary from package to
package and are explained in the individual accelerator doc pages,
listed above:
build the accelerator library |
only for GPU package |
install the accelerator package |
make yes-opt, make yes-user-intel, etc |
add compile/link flags to Makefile.machine in src/MAKE |
only for USER-INTEL, KOKKOS, USER-OMP, OPT packages |
re-build LAMMPS |
make machine |
prepare and test a regular LAMMPS simulation |
lmp_machine -in in.script; mpirun -np 32 lmp_machine -in in.script |
enable specific accelerator support via '-k on' "command-line switch"_Section_start.html#start_6, |
only needed for KOKKOS package |
set any needed options for the package via "-pk" "command-line switch"_Section_start.html#start_6 or "package"_package.html command, |
only if defaults need to be changed |
use accelerated styles in your input via "-sf" "command-line switch"_Section_start.html#start_6 or "suffix"_suffix.html command | lmp_machine -in in.script -sf gpu
:tb(c=2,s=|)
Note that the first 4 steps can be done as a single command with
suitable make command invocations. This is discussed on the
"Packages"_Packages.html doc pages, and its use is illustrated in the
individual accelerator sections. Typically these steps only need to
be done once, to create an executable that uses one or more
accelerator packages.
The last 4 steps can all be done from the command-line when LAMMPS is
launched, without changing your input script, as illustrated in the
individual accelerator sections. Or you can add
"package"_package.html and "suffix"_suffix.html commands to your input
script.
NOTE: With a few exceptions, you can build a single LAMMPS executable
with all its accelerator packages installed. Note however that the
USER-INTEL and KOKKOS packages require you to choose one of their
hardware options when building for a specific platform. I.e. CPU or
Phi option for the USER-INTEL package. Or the OpenMP, Cuda, or Phi
option for the KOKKOS package.
These are the exceptions. You cannot build a single executable with:
both the USER-INTEL Phi and KOKKOS Phi options
the USER-INTEL Phi or Kokkos Phi option, and the GPU package :ul
See the examples/accelerate/README and make.list files for sample
Make.py commands that build LAMMPS with any or all of the accelerator
packages. As an example, here is a command that builds with all the
GPU related packages installed (GPU, KOKKOS with Cuda), including
settings to build the needed auxiliary GPU libraries for Kepler GPUs:
Make.py -j 16 -p omp gpu kokkos -cc nvcc wrap=mpi \
-gpu mode=double arch=35 -kokkos cuda arch=35 lib-all file mpi :pre
The examples/accelerate directory also has input scripts that can be
used with all of the accelerator packages. See its README file for
details.
Likewise, the bench directory has FERMI and KEPLER and PHI
sub-directories with Make.py commands and input scripts for using all
the accelerator packages on various machines. See the README files in
those dirs.
As mentioned above, the "Benchmark
page"_http://lammps.sandia.gov/bench.html of the LAMMPS web site gives
performance results for the various accelerator packages for several
of the standard LAMMPS benchmark problems, as a function of problem
size and number of compute nodes, on different hardware platforms.
Here is a brief summary of what the various packages provide. Details
are in the individual accelerator sections.
Styles with a "gpu" suffix are part of the GPU package, and can be run
on NVIDIA GPUs. The speed-up on a GPU depends on a variety of
factors, discussed in the accelerator sections. :ulb,l
Styles with an "intel" suffix are part of the USER-INTEL
package. These styles support vectorized single and mixed precision
calculations, in addition to full double precision. In extreme cases,
this can provide speedups over 3.5x on CPUs. The package also
supports acceleration in "offload" mode to Intel(R) Xeon Phi(TM)
coprocessors. This can result in additional speedup over 2x depending
on the hardware configuration. :l
Styles with a "kk" suffix are part of the KOKKOS package, and can be
run using OpenMP on multicore CPUs, on an NVIDIA GPU, or on an Intel
Xeon Phi in "native" mode. The speed-up depends on a variety of
factors, as discussed on the KOKKOS accelerator page. :l
Styles with an "omp" suffix are part of the USER-OMP package and allow
a pair-style to be run in multi-threaded mode using OpenMP. This can
be useful on nodes with high-core counts when using less MPI processes
than cores is advantageous, e.g. when running with PPPM so that FFTs
are run on fewer MPI processors or when the many MPI tasks would
overload the available bandwidth for communication. :l
Styles with an "opt" suffix are part of the OPT package and typically
speed-up the pairwise calculations of your simulation by 5-25% on a
CPU. :l
:ule
The individual accelerator package doc pages explain:
what hardware and software the accelerated package requires
how to build LAMMPS with the accelerated package
how to run with the accelerated package either via command-line switches or modifying the input script
speed-ups to expect
guidelines for best performance
restrictions :ul

63
doc/src/Speed_tips.txt Normal file
View File

@ -0,0 +1,63 @@
"Higher level section"_Speed.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
General tips :h3
NOTE: this section 5.2 is still a work in progress
Here is a list of general ideas for improving simulation performance.
Most of them are only applicable to certain models and certain
bottlenecks in the current performance, so let the timing data you
generate be your guide. It is hard, if not impossible, to predict how
much difference these options will make, since it is a function of
problem size, number of processors used, and your machine. There is
no substitute for identifying performance bottlenecks, and trying out
various options.
make individual pages for these, or one for PPPM
one for timestepping, etc
one for balancing
or proc layout
rRESPA
2-FFT PPPM
Staggered PPPM
single vs double PPPM
partial charge PPPM
verlet/split run style
processor command for proc layout and numa layout
load-balancing: balance and fix balance :ul
2-FFT PPPM, also called {analytic differentiation} or {ad} PPPM, uses
2 FFTs instead of the 4 FFTs used by the default {ik differentiation}
PPPM. However, 2-FFT PPPM also requires a slightly larger mesh size to
achieve the same accuracy as 4-FFT PPPM. For problems where the FFT
cost is the performance bottleneck (typically large problems running
on many processors), 2-FFT PPPM may be faster than 4-FFT PPPM.
Staggered PPPM performs calculations using two different meshes, one
shifted slightly with respect to the other. This can reduce force
aliasing errors and increase the accuracy of the method, but also
doubles the amount of work required. For high relative accuracy, using
staggered PPPM allows one to half the mesh size in each dimension as
compared to regular PPPM, which can give around a 4x speedup in the
kspace time. However, for low relative accuracy, using staggered PPPM
gives little benefit and can be up to 2x slower in the kspace
time. For example, the rhodopsin benchmark was run on a single
processor, and results for kspace time vs. relative accuracy for the
different methods are shown in the figure below. For this system,
staggered PPPM (using ik differentiation) becomes useful when using a
relative accuracy of slightly greater than 1e-5 and above.
:c,image(JPG/rhodo_staggered.jpg)
NOTE: Using staggered PPPM may not give the same increase in accuracy
of energy and pressure as it does in forces, so some caution must be
used if energy and/or pressure are quantities of interest, such as
when using a barostat.

105
doc/src/Section_tools.txt → doc/src/Tools.txt
View File

@ -1,6 +1,6 @@
"Previous Section"_Section_perf.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc - "Next
Section"_Section_modify.html :c
Section"_Modify.html :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
@ -8,33 +8,34 @@ Section"_Section_modify.html :c
:line
9. Additional tools :h2
Auxiliary tools :h2
LAMMPS is designed to be a computational kernel for performing
molecular dynamics computations. Additional pre- and post-processing
steps are often necessary to setup and analyze a simulation. A
list of such tools can be found on the LAMMPS home page
at "http://lammps.sandia.gov/prepost.html"_http://lammps.sandia.gov/prepost.html
steps are often necessary to setup and analyze a simulation. A list
of such tools can be found on the "LAMMPS webpage"_lws at these links:
A few additional tools are provided with the LAMMPS distribution
and are described in this section.
"Pre/Post processing"_http://lammps.sandia.gov/prepost.html
"Offsite LAMMPS packages & tools"_http://lammps.sandia.gov/offsite.html
"Pizza.py toolkit"_pizza :ul
Our group has also written and released a separate toolkit called
"Pizza.py"_pizza which provides tools for doing setup, analysis,
plotting, and visualization for LAMMPS simulations. Pizza.py is
written in "Python"_python and is available for download from "the
Pizza.py WWW site"_pizza.
The last link for "Pizza.py"_pizza is a Python-based tool developed at
Sandia which provides tools for doing setup, analysis, plotting, and
visualization for LAMMPS simulations.
:link(pizza,http://www.sandia.gov/~sjplimp/pizza.html)
:link(pizza,http://pizza.sandia.gov)
:link(python,http://www.python.org)
Additional tools included in the LAMMPS distribution are described on
this page.
Note that many users write their own setup or analysis tools or use
other existing codes and convert their output to a LAMMPS input format
or vice versa. The tools listed here are included in the LAMMPS
distribution as examples of auxiliary tools. Some of them are not
actively supported by Sandia, as they were contributed by LAMMPS
users. If you have problems using them, we can direct you to the
authors.
actively supported by the LAMMPS developers, as they were contributed
by LAMMPS users. If you have problems using them, we can direct you
to the authors.
The source code for each of these codes is in the tools sub-directory
of the LAMMPS distribution. There is a Makefile (which you may need
@ -71,11 +72,12 @@ own sub-directories with their own Makefiles and/or README files.
"reax"_#reax_tool
"smd"_#smd
"vim"_#vim
"xmgrace"_#xmgrace
"xmgrace"_#xmgrace :ul
:line
:line
amber2lmp tool :h3,link(amber)
amber2lmp tool :h4,link(amber)
The amber2lmp sub-directory contains two Python scripts for converting
files back-and-forth between the AMBER MD code and LAMMPS. See the
@ -90,7 +92,7 @@ necessary modifications yourself.
:line
binary2txt tool :h3,link(binary)
binary2txt tool :h4,link(binary)
The file binary2txt.cpp converts one or more binary LAMMPS dump file
into ASCII text files. The syntax for running the tool is
@ -103,7 +105,7 @@ since binary files are not compatible across all platforms.
:line
ch2lmp tool :h3,link(charmm)
ch2lmp tool :h4,link(charmm)
The ch2lmp sub-directory contains tools for converting files
back-and-forth between the CHARMM MD code and LAMMPS.
@ -128,7 +130,7 @@ Chris Lorenz (chris.lorenz at kcl.ac.uk), King's College London.
:line
chain tool :h3,link(chain)
chain tool :h4,link(chain)
The file chain.f creates a LAMMPS data file containing bead-spring
polymer chains and/or monomer solvent atoms. It uses a text file
@ -145,7 +147,7 @@ system for the "chain benchmark"_Section_perf.html.
:line
colvars tools :h3,link(colvars)
colvars tools :h4,link(colvars)
The colvars directory contains a collection of tools for postprocessing
data produced by the colvars collective variable library.
@ -167,7 +169,7 @@ gmail.com) at ICTP, Italy.
:line
createatoms tool :h3,link(createatoms)
createatoms tool :h4,link(createatoms)
The tools/createatoms directory contains a Fortran program called
createAtoms.f which can generate a variety of interesting crystal
@ -180,7 +182,7 @@ The tool is authored by Xiaowang Zhou (Sandia), xzhou at sandia.gov.
:line
doxygen tool :h3,link(doxygen)
doxygen tool :h4,link(doxygen)
The tools/doxygen directory contains a shell script called
doxygen.sh which can generate a call graph and API lists using
@ -192,7 +194,7 @@ The tool is authored by Nandor Tamaskovics, numericalfreedom at googlemail.com.
:line
drude tool :h3,link(drude)
drude tool :h4,link(drude)
The tools/drude directory contains a Python script called
polarizer.py which can add Drude oscillators to a LAMMPS
@ -205,7 +207,7 @@ at univ-bpclermont.fr, alain.dequidt at univ-bpclermont.fr
:line
eam database tool :h3,link(eamdb)
eam database tool :h4,link(eamdb)
The tools/eam_database directory contains a Fortran program that will
generate EAM alloy setfl potential files for any combination of 16
@ -221,7 +223,7 @@ X. W. Zhou, R. A. Johnson, and H. N. G. Wadley, Phys. Rev. B, 69,
:line
eam generate tool :h3,link(eamgn)
eam generate tool :h4,link(eamgn)
The tools/eam_generate directory contains several one-file C programs
that convert an analytic formula into a tabulated "embedded atom
@ -234,7 +236,7 @@ The source files and potentials were provided by Gerolf Ziegenhain
:line
eff tool :h3,link(eff)
eff tool :h4,link(eff)
The tools/eff directory contains various scripts for generating
structures and post-processing output for simulations using the
@ -245,18 +247,18 @@ These tools were provided by Andres Jaramillo-Botero at CalTech
:line
emacs tool :h3,link(emacs)
emacs tool :h4,link(emacs)
The tools/emacs directory contains a Lips add-on file for Emacs that
enables a lammps-mode for editing of input scripts when using Emacs,
with various highlighting options setup.
The tools/emacs directory contains an Emacs Lisp add-on file for GNU Emacs
that enables a lammps-mode for editing input scripts when using GNU Emacs,
with various highlighting options set up.
These tools were provided by Aidan Thompson at Sandia
(athomps at sandia.gov).
:line
fep tool :h3,link(fep)
fep tool :h4,link(fep)
The tools/fep directory contains Python scripts useful for
post-processing results from performing free-energy perturbation
@ -269,7 +271,7 @@ See README file in the tools/fep directory.
:line
i-pi tool :h3,link(ipi)
i-pi tool :h4,link(ipi)
The tools/i-pi directory contains a version of the i-PI package, with
all the LAMMPS-unrelated files removed. It is provided so that it can
@ -286,7 +288,7 @@ calculations with LAMMPS.
:line
ipp tool :h3,link(ipp)
ipp tool :h4,link(ipp)
The tools/ipp directory contains a Perl script ipp which can be used
to facilitate the creation of a complicated file (say, a lammps input
@ -300,7 +302,7 @@ tools/createatoms tool's input file.
:line
kate tool :h3,link(kate)
kate tool :h4,link(kate)
The file in the tools/kate directory is an add-on to the Kate editor
in the KDE suite that allow syntax highlighting of LAMMPS input
@ -311,7 +313,7 @@ The file was provided by Alessandro Luigi Sellerio
:line
lmp2arc tool :h3,link(arc)
lmp2arc tool :h4,link(arc)
The lmp2arc sub-directory contains a tool for converting LAMMPS output
files to the format for Accelrys' Insight MD code (formerly
@ -327,7 +329,7 @@ Greathouse at Sandia (jagreat at sandia.gov).
:line
lmp2cfg tool :h3,link(cfg)
lmp2cfg tool :h4,link(cfg)
The lmp2cfg sub-directory contains a tool for converting LAMMPS output
files into a series of *.cfg files which can be read into the
@ -338,7 +340,7 @@ This tool was written by Ara Kooser at Sandia (askoose at sandia.gov).
:line
matlab tool :h3,link(matlab)
matlab tool :h4,link(matlab)
The matlab sub-directory contains several "MATLAB"_matlabhome scripts for
post-processing LAMMPS output. The scripts include readers for log
@ -356,7 +358,7 @@ These scripts were written by Arun Subramaniyan at Purdue Univ
:line
micelle2d tool :h3,link(micelle)
micelle2d tool :h4,link(micelle)
The file micelle2d.f creates a LAMMPS data file containing short lipid
chains in a monomer solution. It uses a text file containing lipid
@ -369,11 +371,11 @@ micelle2d < def.micelle2d > data.file :pre
See the def.micelle2d file in the tools directory for an example of a
definition file. This tool was used to create the system for the
"micelle example"_Section_example.html.
"micelle example"_Examples.html.
:line
moltemplate tool :h3,link(moltemplate)
moltemplate tool :h4,link(moltemplate)
The moltemplate sub-directory contains a Python-based tool for
building molecular systems based on a text-file description, and
@ -387,7 +389,7 @@ supports it. It has its own WWW page at
:line
msi2lmp tool :h3,link(msi)
msi2lmp tool :h4,link(msi)
The msi2lmp sub-directory contains a tool for creating LAMMPS template
input and data files from BIOVIA's Materias Studio files (formerly Accelrys'
@ -404,7 +406,7 @@ See the README file in the tools/msi2lmp folder for more information.
:line
phonon tool :h3,link(phonon)
phonon tool :h4,link(phonon)
The phonon sub-directory contains a post-processing tool useful for
analyzing the output of the "fix phonon"_fix_phonon.html command in
@ -419,7 +421,7 @@ University.
:line
polybond tool :h3,link(polybond)
polybond tool :h4,link(polybond)
The polybond sub-directory contains a Python-based tool useful for
performing "programmable polymer bonding". The Python file
@ -433,7 +435,7 @@ This tool was written by Zachary Kraus at Georgia Tech.
:line
pymol_asphere tool :h3,link(pymol)
pymol_asphere tool :h4,link(pymol)
The pymol_asphere sub-directory contains a tool for converting a
LAMMPS dump file that contains orientation info for ellipsoidal
@ -451,7 +453,7 @@ This tool was written by Mike Brown at Sandia.
:line
python tool :h3,link(pythontools)
python tool :h4,link(pythontools)
The python sub-directory contains several Python scripts
that perform common LAMMPS post-processing tasks, such as:
@ -467,7 +469,7 @@ README for more info on Pizza.py and how to use these scripts.
:line
reax tool :h3,link(reax_tool)
reax tool :h4,link(reax_tool)
The reax sub-directory contains stand-alond codes that can
post-process the output of the "fix reax/bonds"_fix_reax_bonds.html
@ -478,7 +480,7 @@ These tools were written by Aidan Thompson at Sandia.
:line
smd tool :h3,link(smd)
smd tool :h4,link(smd)
The smd sub-directory contains a C++ file dump2vtk_tris.cpp and
Makefile which can be compiled and used to convert triangle output
@ -494,7 +496,7 @@ Ernst Mach Institute in Germany (georg.ganzenmueller at emi.fhg.de).
:line
vim tool :h3,link(vim)
vim tool :h4,link(vim)
The files in the tools/vim directory are add-ons to the VIM editor
that allow easier editing of LAMMPS input scripts. See the README.txt
@ -505,7 +507,7 @@ ziegenhain.com)
:line
xmgrace tool :h3,link(xmgrace)
xmgrace tool :h4,link(xmgrace)
The files in the tools/xmgrace directory can be used to plot the
thermodynamic data in LAMMPS log files via the xmgrace plotting
@ -517,4 +519,3 @@ simulation.
See the README file for details.
These files were provided by Vikas Varshney (vv0210 at gmail.com)

11
doc/src/angle_charmm.txt
View File

@ -51,10 +51,9 @@ internally; hence the units of K are in energy/radian^2.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
hardware, as discussed on the "Speed packages"_Speed_packages.html doc
page. The accelerated styles take the same arguments and should
produce the same results, except for round-off and precision issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
@ -66,8 +65,8 @@ by including their suffix, or you can use the "-suffix command-line
switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
See "Speed packages"_Speed_packages.html doc page for more
instructions on how to use the accelerated styles effectively.
:line

11
doc/src/angle_class2.txt
View File

@ -83,10 +83,9 @@ same value from the Ea formula.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
hardware, as discussed on the "Speed packages"_Speed_packages.html doc
page. The accelerated styles take the same arguments and should
produce the same results, except for round-off and precision issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
@ -98,8 +97,8 @@ by including their suffix, or you can use the "-suffix command-line
switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
See the "Speed packages"_Speed_packages.html doc page for more
instructions on how to use the accelerated styles effectively.
:line

11
doc/src/angle_cosine.txt
View File

@ -38,10 +38,9 @@ K (energy) :ul
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
hardware, as discussed on the "Speed packages"_Speed_packages.html doc
page. The accelerated styles take the same arguments and should
produce the same results, except for round-off and precision issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
@ -53,8 +52,8 @@ by including their suffix, or you can use the "-suffix command-line
switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
See the "Speed packages"_Speed_packages.html doc page for more
instructions on how to use the accelerated styles effectively.
:line

11
doc/src/angle_cosine_delta.txt
View File

@ -43,10 +43,9 @@ internally.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
hardware, as discussed on the "Speed packages"_Speed_packages.html doc
page. The accelerated styles take the same arguments and should
produce the same results, except for round-off and precision issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
@ -58,8 +57,8 @@ by including their suffix, or you can use the "-suffix command-line
switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
See the "Speed packages"_Speed_packages.html doc page for more
instructions on how to use the accelerated styles effectively.
:line

11
doc/src/angle_cosine_periodic.txt
View File

@ -51,10 +51,9 @@ geometry.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
hardware, as discussed on the "Speed packages"_Speed_packages.html doc
page. The accelerated styles take the same arguments and should
produce the same results, except for round-off and precision issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
@ -66,8 +65,8 @@ by including their suffix, or you can use the "-suffix command-line
switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
See the "Speed packages"_Speed_packages.html doc page for more
instructions on how to use the accelerated styles effectively.
:line

11
doc/src/angle_cosine_shift.txt
View File

@ -41,10 +41,9 @@ theta (angle) :ul
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
hardware, as discussed on the "Speed packages"_Speed_packages.html doc
page. The accelerated styles take the same arguments and should
produce the same results, except for round-off and precision issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
@ -56,8 +55,8 @@ by including their suffix, or you can use the "-suffix command-line
switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
See the "Speed packages"_Speed_packages.html doc page for more
instructions on how to use the accelerated styles effectively.
:line

11
doc/src/angle_cosine_shift_exp.txt
View File

@ -53,10 +53,9 @@ A (real number) :ul
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
hardware, as discussed on the "Speed packages"_Speed_packages.html doc
page. The accelerated styles take the same arguments and should
produce the same results, except for round-off and precision issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
@ -68,8 +67,8 @@ by including their suffix, or you can use the "-suffix command-line
switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
See the "Speed packages"_Speed_packages.html doc page for more
instructions on how to use the accelerated styles effectively.
:line

11
doc/src/angle_cosine_squared.txt
View File

@ -43,10 +43,9 @@ internally.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
hardware, as discussed on the "Speed packages"_Speed_packages.html doc
page. The accelerated styles take the same arguments and should
produce the same results, except for round-off and precision issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
@ -58,8 +57,8 @@ by including their suffix, or you can use the "-suffix command-line
switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
See the "Speed packages"_Speed_packages.html doc page for more
instructions on how to use the accelerated styles effectively.
:line

28
doc/src/angle_dipole.txt
View File

@ -71,10 +71,9 @@ gamma0 (degrees) :ul
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
hardware, as discussed on the "Speed packages"_Speed_packages.html doc
page. The accelerated styles take the same arguments and should
produce the same results, except for round-off and precision issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
@ -86,8 +85,8 @@ by including their suffix, or you can use the "-suffix command-line
switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
See the "Speed packages"_Speed_packages.html doc page for more
instructions on how to use the accelerated styles effectively.
[Restrictions:]
@ -96,16 +95,17 @@ USER-MISC package. See the "Making LAMMPS"_Section_start.html#start_2_3
section for more info on packages.
NOTE: In the "Angles" section of the data file, the atom ID 'j'
corresponding to the dipole to restrain must come before the atom ID
of the reference atom 'i'. A third atom ID 'k' must also be provided,
although 'k' is just a 'dummy' atom which can be any atom; it may be
useful to choose a convention (e.g., 'k'='i') and adhere to it. For
example, if ID=1 for the dipolar atom to restrain, and ID=2 for the
reference atom, the corresponding line in the "Angles" section of the
data file would read: X X 1 2 2
defining the direction of the dipole vector to restrain must come
before the atom ID of the reference atom 'i'. A third atom ID 'k' must
also be provided to comply with the requirement of a valid angle
definition. This atom ID k should be chosen to be that of an atom
bonded to atom 'i' to avoid errors with "lost angle atoms" when running
in parallel. Since the LAMMPS code checks for valid angle definitions,
cannot use the same atom ID of either 'i' or 'j' (this was allowed
and recommended with older LAMMPS versions).
The "newton" command for intramolecular interactions must be "on"
(which is the default).
(which is the default except when using some accelerator packages).
This angle style should not be used with SHAKE.

11
doc/src/angle_fourier.txt
View File

@ -39,10 +39,9 @@ C2 (real) :ul
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
hardware, as discussed on the "Speed packages"_Speed_packages.html doc
page. The accelerated styles take the same arguments and should
produce the same results, except for round-off and precision issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
@ -54,8 +53,8 @@ by including their suffix, or you can use the "-suffix command-line
switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
See the "Speed packages"_Speed_packages.html doc page for more
instructions on how to use the accelerated styles effectively.
:line

11
doc/src/angle_fourier_simple.txt
View File

@ -38,10 +38,9 @@ n (real) :ul
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
hardware, as discussed on the "Speed packages"_Speed_packages.html doc
page. The accelerated styles take the same arguments and should
produce the same results, except for round-off and precision issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
@ -53,8 +52,8 @@ by including their suffix, or you can use the "-suffix command-line
switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
See the "Speed packages"_Speed_packages.html doc page for more
instructions on how to use the accelerated styles effectively.
:line

11
doc/src/angle_harmonic.txt
View File

@ -45,10 +45,9 @@ internally; hence the units of K are in energy/radian^2.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
hardware, as discussed on the "Speed packages"_Speed_packages.html doc
page. The accelerated styles take the same arguments and should
produce the same results, except for round-off and precision issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
@ -60,8 +59,8 @@ by including their suffix, or you can use the "-suffix command-line
switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
See the "Speed packages"_Speed_packages.html doc page for more
instructions on how to use the accelerated styles effectively.
:line

11
doc/src/angle_quartic.txt
View File

@ -45,10 +45,9 @@ internally; hence the units of K are in energy/radian^2.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
hardware, as discussed on the "Speed packages"_Speed_packages.html doc
page. The accelerated styles take the same arguments and should
produce the same results, except for round-off and precision issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
@ -60,8 +59,8 @@ by including their suffix, or you can use the "-suffix command-line
switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
See the "Speed packages"_Speed_packages.html doc page for more
instructions on how to use the accelerated styles effectively.
:line

11
doc/src/angle_table.txt
View File

@ -124,10 +124,9 @@ one that matches the specified keyword.
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
hardware, as discussed on the "Speed packages"_Speed_packages.html doc
page. The accelerated styles take the same arguments and should
produce the same results, except for round-off and precision issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
@ -139,8 +138,8 @@ by including their suffix, or you can use the "-suffix command-line
switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
See the "Speed packages"_Speed_packages.html doc page for more
instructions on how to use the accelerated styles effectively.
:line

14
doc/src/atom_style.txt
View File

@ -255,16 +255,16 @@ with another molecular style that stores bond,angle,etc info on a
per-atom basis.
LAMMPS can be extended with new atom styles as well as new body
styles; see "this section"_Section_modify.html.
styles; see the "Modify"_Modify.html doc page.
:line
Styles with a {kk} suffix are functionally the same as the
corresponding style without the suffix. They have been optimized to
run faster, depending on your available hardware, as discussed in
"Section 5"_Section_accelerate.html of the manual. The
accelerated styles take the same arguments and should produce the same
results, except for round-off and precision issues.
run faster, depending on your available hardware, as discussed in on
the "Speed packages"_Speed_packages.html doc page. The accelerated
styles take the same arguments and should produce the same results,
except for round-off and precision issues.
Note that other acceleration packages in LAMMPS, specifically the GPU,
USER-INTEL, USER-OMP, and OPT packages do not use accelerated atom
@ -279,8 +279,8 @@ by including their suffix, or you can use the "-suffix command-line
switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
See the "Speed packages"_Speed_packages.html doc page for more
instructions on how to use the accelerated styles effectively.
[Restrictions:]

262
doc/src/body.txt
View File

@ -27,19 +27,17 @@ styles supported by LAMMPS are as follows. The name in the first
column is used as the {bstyle} argument for the "atom_style
body"_atom_style.html command.
{nparticle} | rigid body with N sub-particles |
{rounded/polygon} | 2d convex polygon with N vertices :tb(c=2,s=|)
{nparticle} : rigid body with N sub-particles
{rounded/polygon} : 2d polygons with N vertices
{rounded/polyhedron} : 3d polyhedra with N vertices, E edges and F faces :tb(s=:)
The body style determines what attributes are stored for each body and
thus how they can be used to compute pairwise body/body or
bond/non-body (point particle) interactions. More details of each
style are described below.
NOTE: The rounded/polygon style listed in the table above and
described below has not yet been relesed in LAMMPS. It will be soon.
We hope to add more styles in the future. See "Section
10.12"_Section_modify.html#mod_12 for details on how to add a new body
More styles may be added in the future. See the "Modify
body"_Modify_body.html doc page for details on how to add a new body
style to the code.
:line
@ -61,7 +59,7 @@ the simple particles.
By contrast, when body particles are used, LAMMPS treats an entire
body as a single particle for purposes of computing pairwise
interactions, building neighbor lists, migrating particles between
processors, outputting particles to a dump file, etc. This means that
processors, output of particles to a dump file, etc. This means that
interactions between pairs of bodies or between a body and non-body
(point) particle need to be encoded in an appropriate pair style. If
such a pair style were to mimic the "fix rigid"_fix_rigid.html model,
@ -72,17 +70,20 @@ single body/body interaction was computed.
Thus it only makes sense to use body particles and develop such a pair
style, when particle/particle interactions are more complex than what
the "fix rigid"_fix_rigid.html command can already calculate. For
example, if particles have one or more of the following attributes:
example, consider particles with one or more of the following
attributes:
represented by a surface mesh
represented by a collection of geometric entities (e.g. planes + spheres)
deformable
internal stress that induces fragmentation :ul
then the interaction between pairs of particles is likely to be more
complex than the summation of simple sub-particle interactions. An
example is contact or frictional forces between particles with planar
surfaces that inter-penetrate.
For these models, the interaction between pairs of particles is likely
to be more complex than the summation of simple pairwise interactions.
An example is contact or frictional forces between particles with
planar surfaces that inter-penetrate. Likewise, the body particle may
store internal state, such as a stress tensor used to compute a
fracture criterion.
These are additional LAMMPS commands that can be used with body
particles of different styles
@ -130,7 +131,9 @@ x1 y1 z1
...
xN yN zN :pre
N is the number of sub-particles in the body particle. M = 6 + 3*N.
where M = 6 + 3*N, and N is the number of sub-particles in the body
particle.
The integer line has a single value N. The floating point line(s)
list 6 moments of inertia followed by the coordinates of the N
sub-particles (x1 to zN) as 3N values. These values can be listed on
@ -175,15 +178,18 @@ The {bflag2} argument is ignored.
[Specifics of body style rounded/polygon:]
NOTE: Aug 2016 - This body style has not yet been added to LAMMPS.
The info below is a placeholder.
The {rounded/polygon} body style represents body particles as a 2d
polygon with a variable number of N vertices. This style can only be
used for 2d models; see the "boundary"_boundary.html command. See the
"pair_style body/rounded/polygon" doc page for a diagram of two
squares with rounded circles at the vertices. Special cases for N = 1
(circle) and N = 2 (rod with rounded ends) can also be specified.
The {rounded/polygon} body style represents body particles as a convex
polygon with a variable number N > 2 of vertices, which can only be
used for 2d models. One example use of this body style is for 2d
discrete element models, as described in "Fraige"_#Fraige. Similar to
body style {nparticle}, the atom_style body command for this body
style takes two additional arguments:
One use of this body style is for 2d discrete element models, as
described in "Fraige"_#body-Fraige.
Similar to body style {nparticle}, the atom_style body command for
this body style takes two additional arguments:
atom_style body rounded/polygon Nmin Nmax
Nmin = minimum # of vertices in any body in the system
@ -203,17 +209,20 @@ x1 y1 z1
...
xN yN zN
i j j k k ...
radius :pre
diameter :pre
N is the number of vertices in the body particle. M = 6 + 3*N + 2*N +
1. The integer line has a single value N. The floating point line(s)
where M = 6 + 3*N + 2*N + 1, and N is the number of vertices in the
body particle.
The integer line has a single value N. The floating point line(s)
list 6 moments of inertia followed by the coordinates of the N
vertices (x1 to zN) as 3N values, followed by 2N vertex indices
corresponding to the end points of the N edges, followed by a single
radius value = the smallest circle encompassing the polygon. That
last value is used to facilitate the body/body contact detection.
These floating-point values can be listed on as many lines as you
wish; see the "read_data"_read_data.html command for more details.
vertices (x1 to zN) as 3N values (with z = 0.0 for each), followed by
2N vertex indices corresponding to the end points of the N edges,
followed by a single diameter value = the rounded diameter of the
circle that surrounds each vertex. The diameter value can be different
for each body particle. These floating-point values can be listed on
as many lines as you wish; see the "read_data"_read_data.html command
for more details.
The 6 moments of inertia (ixx,iyy,izz,ixy,ixz,iyz) should be the
values consistent with the current orientation of the rigid body
@ -225,8 +234,11 @@ from the center-of-mass of the body particle. The center-of-mass
position of the particle is specified by the x,y,z values in the
{Atoms} section of the data file.
For example, the following information would specify a square
particles whose edge length is sqrt(2):
For example, the following information would specify a square particle
whose edge length is sqrt(2) and rounded diameter is 1.0. The
orientation of the square is aligned with the xy coordinate axes which
is consistent with the 6 moments of inertia: ixx iyy izz ixy ixz iyz =
1 1 4 0 0 0. Note that only Izz matters in 2D simulations.
3 1 27
4
@ -235,12 +247,178 @@ particles whose edge length is sqrt(2):
-0.7071 0.7071 0
0.7071 0.7071 0
0.7071 -0.7071 0
0 1 1 2 2 3 3 0
0 1
1 2
2 3
3 0
1.0 :pre
A rod in 2D, whose length is 4.0, mass 1.0, rounded at two ends
by circles of diameter 0.5, is specified as follows:
1 1 13
2
1 1 1.33333 0 0 0
-2 0 0
2 0 0
0.5 :pre
A disk, whose diameter is 3.0, mass 1.0, is specified as follows:
1 1 10
1
1 1 4.5 0 0 0
0 0 0
3.0 :pre
The "pair_style body/rounded/polygon"_pair_body_rounded_polygon.html
command can be used with this body style to compute body/body
interactions.
interactions. The "fix wall/body/polygon"_fix_wall_body_polygon.html
command can be used with this body style to compute the interaction of
body particles with a wall.
:line
[Specifics of body style rounded/polyhedron:]
The {rounded/polyhedron} body style represents body particles as a 3d
polyhedron with a variable number of N vertices, E edges and F faces.
This style can only be used for 3d models; see the
"boundary"_boundary.html command. See the "pair_style
body/rounded/polygon" doc page for a diagram of a two 2d squares with
rounded circles at the vertices. A 3d cube with rounded spheres at
the 8 vertices and 12 rounded edges would be similar. Special cases
for N = 1 (sphere) and N = 2 (rod with rounded ends) can also be
specified.
This body style is for 3d discrete element models, as described in
"Wang"_#body-Wang.
Similar to body style {rounded/polygon}, the atom_style body command
for this body style takes two additional arguments:
atom_style body rounded/polyhedron Nmin Nmax
Nmin = minimum # of vertices in any body in the system
Nmax = maximum # of vertices in any body in the system :pre
The Nmin and Nmax arguments are used to bound the size of data
structures used internally by each particle.
When the "read_data"_read_data.html command reads a data file for this
body style, the following information must be provided for each entry
in the {Bodies} section of the data file:
atom-ID 3 M
N E F
ixx iyy izz ixy ixz iyz
x1 y1 z1
...
xN yN zN
0 1
1 2
2 3
...
0 1 2 -1
0 2 3 -1
...
1 2 3 4
diameter :pre
where M = 6 + 3*N + 2*E + 4*F + 1, and N is the number of vertices in
the body particle, E = number of edges, F = number of faces.
The integer line has three values: number of vertices (N), number of
edges (E) and number of faces (F). The floating point line(s) list 6
moments of inertia followed by the coordinates of the N vertices (x1
to zN) as 3N values, followed by 2N vertex indices corresponding to
the end points of the E edges, then 4*F vertex indices defining F
faces. The last value is the diameter value = the rounded diameter of
the sphere that surrounds each vertex. The diameter value can be
different for each body particle. These floating-point values can be
listed on as many lines as you wish; see the
"read_data"_read_data.html command for more details. Because the
maxmimum vertices per face is hard-coded to be 4
(i.e. quadrilaterals), faces with more than 4 vertices need to be
split into triangles or quadrilaterals. For triangular faces, the
last vertex index should be set to -1.
The ordering of the 4 vertices within a face should follow
the right-hand rule so that the normal vector of the face points
outwards from the center of mass.
The 6 moments of inertia (ixx,iyy,izz,ixy,ixz,iyz) should be the
values consistent with the current orientation of the rigid body
around its center of mass. The values are with respect to the
simulation box XYZ axes, not with respect to the principal axes of the
rigid body itself. LAMMPS performs the latter calculation internally.
The coordinates of each vertex are specified as its x,y,z displacement
from the center-of-mass of the body particle. The center-of-mass
position of the particle is specified by the x,y,z values in the
{Atoms} section of the data file.
For example, the following information would specify a cubic particle
whose edge length is 2.0 and rounded diameter is 0.5.
The orientation of the cube is aligned with the xyz coordinate axes
which is consistent with the 6 moments of inertia: ixx iyy izz ixy ixz
iyz = 0.667 0.667 0.667 0 0 0.
1 3 79
8 12 6
0.667 0.667 0.667 0 0 0
1 1 1
1 -1 1
-1 -1 1
-1 1 1
1 1 -1
1 -1 -1
-1 -1 -1
-1 1 -1
0 1
1 2
2 3
3 0
4 5
5 6
6 7
7 4
0 4
1 5
2 6
3 7
0 1 2 3
4 5 6 7
0 1 5 4
1 2 6 5
2 3 7 6
3 0 4 7
0.5 :pre
A rod in 3D, whose length is 4.0, mass 1.0 and rounded at two ends
by circles of diameter 0.5, is specified as follows:
1 1 13
2
0 1.33333 1.33333 0 0 0
-2 0 0
2 0 0
0.5 :pre
A sphere whose diameter is 3.0 and mass 1.0, is specified as follows:
1 1 10
1
0.9 0.9 0.9 0 0 0
0 0 0
3.0 :pre
The "pair_style
body/rounded/polhedron"_pair_body_rounded_polyhedron.html command can
be used with this body style to compute body/body interactions. The
"fix wall/body/polyhedron"_fix_wall_body_polygon.html command can be
used with this body style to compute the interaction of body particles
with a wall.
:line
For output purposes via the "compute
body/local"_compute_body_local.html and "dump local"_dump.html
@ -257,10 +435,10 @@ the body particle itself. These values are calculated using the
current COM and orientation of the body particle.
For images created by the "dump image"_dump_image.html command, if the
{body} keyword is set, then each body particle is drawn as a convex
polygon consisting of N line segments. Note that the line segments
are drawn between the N vertices, which does not correspond exactly to
the physical extent of the body (because the "pair_style
{body} keyword is set, then each body particle is drawn as a polygon
consisting of N line segments. Note that the line segments are drawn
between the N vertices, which does not correspond exactly to the
physical extent of the body (because the "pair_style
rounded/polygon"_pair_body_rounded_polygon.html defines finite-size
spheres at those point and the line segments between the spheres are
tangent to the spheres). The drawn diameter of each line segment is
@ -269,6 +447,10 @@ determined by the {bflag1} parameter for the {body} keyword. The
:line
:link(Fraige)
:link(body-Fraige)
[(Fraige)] F. Y. Fraige, P. A. Langston, A. J. Matchett, J. Dodds,
Particuology, 6, 455 (2008).
:link(body-Wang)
[(Wang)] J. Wang, H. S. Yu, P. A. Langston, F. Y. Fraige, Granular
Matter, 13, 1 (2011).

11
doc/src/bond_class2.txt
View File

@ -44,10 +44,9 @@ K4 (energy/distance^4) :ul
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
hardware, as discussed on the "Speed packages"_Speed_packages.html doc
page. The accelerated styles take the same arguments and should
produce the same results, except for round-off and precision issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
@ -59,8 +58,8 @@ by including their suffix, or you can use the "-suffix command-line
switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
See the "Speed packages"_Speed_packages.html doc page for more
instructions on how to use the accelerated styles effectively.
:line

11
doc/src/bond_fene.txt
View File

@ -47,10 +47,9 @@ sigma (distance) :ul
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
hardware, as discussed on the "Speed packages"_Speed_packages.html doc
page. The accelerated styles take the same arguments and should
produce the same results, except for round-off and precision issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
@ -62,8 +61,8 @@ by including their suffix, or you can use the "-suffix command-line
switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
See the "Speed packages"_Speed_packages.html doc page for more
instructions on how to use the accelerated styles effectively.
:line

11
doc/src/bond_fene_expand.txt
View File

@ -50,10 +50,9 @@ delta (distance) :ul
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
hardware, as discussed on the "Speed packages"_Speed_packages.html doc
page. The accelerated styles take the same arguments and should
produce the same results, except for round-off and precision issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
@ -65,8 +64,8 @@ by including their suffix, or you can use the "-suffix command-line
switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
See the "Speed packages"_Speed_packages.html doc page for more
instructions on how to use the accelerated styles effectively.
:line

11
doc/src/bond_gromos.txt
View File

@ -40,10 +40,9 @@ r0 (distance) :ul
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
hardware, as discussed on the "Speed packages"_Speed_packages.html doc
page. The accelerated styles take the same arguments and should
produce the same results, except for round-off and precision issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
@ -55,8 +54,8 @@ by including their suffix, or you can use the "-suffix command-line
switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
See the "Speed packages"_Speed_packages.html doc page for more
instructions on how to use the accelerated styles effectively.
:line

11
doc/src/bond_harmonic.txt
View File

@ -42,10 +42,9 @@ r0 (distance) :ul
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
hardware, as discussed on the "Speed packages"_Speed_packages.html doc
page. The accelerated styles take the same arguments and should
produce the same results, except for round-off and precision issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
@ -57,8 +56,8 @@ by including their suffix, or you can use the "-suffix command-line
switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
See the "Speed packages"_Speed_packages.html doc page for more
instructions on how to use the accelerated styles effectively.
:line

11
doc/src/bond_harmonic_shift.txt
View File

@ -43,10 +43,9 @@ rc (distance) :ul
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
hardware, as discussed on the "Speed packages"_Speed_packages.html doc
page. The accelerated styles take the same arguments and should
produce the same results, except for round-off and precision issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
@ -58,8 +57,8 @@ by including their suffix, or you can use the "-suffix command-line
switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
See the "Speed packages"_Speed_packages.html doc page for more
instructions on how to use the accelerated styles effectively.
:line

11
doc/src/bond_harmonic_shift_cut.txt
View File

@ -43,10 +43,9 @@ rc (distance) :ul
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
hardware, as discussed on the "Speed packages"_Speed_packages.html doc
page. The accelerated styles take the same arguments and should
produce the same results, except for round-off and precision issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
@ -58,8 +57,8 @@ by including their suffix, or you can use the "-suffix command-line
switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
See the "Speed packages"_Speed_packages.html doc page for more
instructions on how to use the accelerated styles effectively.
:line

11
doc/src/bond_morse.txt
View File

@ -41,10 +41,9 @@ r0 (distance) :ul
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
hardware, as discussed on the "Speed packages"_Speed_packages.html doc
page. The accelerated styles take the same arguments and should
produce the same results, except for round-off and precision issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
@ -56,8 +55,8 @@ by including their suffix, or you can use the "-suffix command-line
switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
See the "Speed packages"_Speed_packages.html doc page for more
instructions on how to use the accelerated styles effectively.
:line

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