jianmu
/
lammps
forked from lijiext/lammps
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Merge branch 'master' into master

This commit is contained in:
oywg11 2018-09-12 22:13:43 +03:00 committed by GitHub
parent 01beaf38a1 6ae4bdead5
commit 7054800932
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1952 changed files with 193829 additions and 31567 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

70
.github/CODEOWNERS vendored
View File

@ -16,6 +16,9 @@ src/COMPRESS/* @akohlmey
src/GPU/* @ndtrung81
src/KOKKOS/* @stanmoore1
src/KIM/* @ellio167
src/LATTE/* @cnegre
src/MESSAGE/* @sjplimp
src/SPIN/* @julient31
src/USER-CGDNA/* @ohenrich
src/USER-CGSDK/* @akohlmey
src/USER-COLVARS/* @giacomofiorin
@ -30,19 +33,86 @@ src/USER-PHONON/* @lingtikong
src/USER-OMP/* @akohlmey
src/USER-QMMM/* @akohlmey
src/USER-REAXC/* @hasanmetin
src/USER-SCAFACOS/* @rhalver
src/USER-TALLY/* @akohlmey
src/USER-UEF/* @danicholson
src/USER-VTK/* @rbberger
# individual files in packages
src/GPU/pair_vashishta_gpu.* @andeplane
src/KOKKOS/pair_vashishta_kokkos.* @andeplane
src/MANYBODY/pair_vashishta_table.* @andeplane
src/MANYBODY/pair_atm.* @sergeylishchuk
src/USER-MISC/fix_bond_react.* @jrgissing
src/USER-MISC/*_grem.* @dstelter92
src/USER-MISC/compute_stress_mop*.* @RomainVermorel
# core LAMMPS classes
src/lammps.* @sjplimp
src/pointers.h @sjplimp
src/atom.* @sjplimp
src/atom_vec.* @sjplimp
src/angle.* @sjplimp
src/bond.* @sjplimp
src/comm*.* @sjplimp
src/compute.* @sjplimp
src/dihedral.* @sjplimp
src/domain.* @sjplimp
src/dump*.* @sjplimp
src/error.* @sjplimp
src/finish.* @sjplimp
src/fix.* @sjplimp
src/force.* @sjplimp
src/group.* @sjplimp
src/improper.* @sjplimp
src/kspace.* @sjplimp
src/lmptyp.h @sjplimp
src/library.* @sjplimp
src/main.cpp @sjplimp
src/memory.* @sjplimp
src/modify.* @sjplimp
src/molecule.* @sjplimp
src/my_page.h @sjplimp
src/my_pool_chunk.h @sjplimp
src/npair*.* @sjplimp
src/ntopo*.* @sjplimp
src/nstencil*.* @sjplimp
src/neighbor.* @sjplimp
src/nbin*.* @sjplimp
src/neigh_*.* @sjplimp
src/output.* @sjplimp
src/pair.* @sjplimp
src/rcb.* @sjplimp
src/random_*.* @sjplimp
src/region*.* @sjplimp
src/rcb.* @sjplimp
src/read*.* @sjplimp
src/rerun.* @sjplimp
src/run.* @sjplimp
src/respa.* @sjplimp
src/set.* @sjplimp
src/special.* @sjplimp
src/suffix.h @sjplimp
src/thermo.* @sjplimp
src/universe.* @sjplimp
src/update.* @sjplimp
src/variable.* @sjplimp
src/verlet.* @sjplimp
src/velocity.* @sjplimp
src/write_data.* @sjplimp
src/write_restart.* @sjplimp
# overrides for specific files
src/dump_movie.* @akohlmey
src/exceptions.h @rbberger
src/fix_nh.* @athomps
src/info.* @akohlmey @rbberger
src/timer.* @akohlmey
# tools
tools/msi2lmp/* @akohlmey
tools/emacs/* @HaoZeke
# cmake
cmake/* @junghans @rbberger

2
.gitignore vendored
View File

@ -1,6 +1,7 @@
*~
*.o
*.so
*.lo
*.cu_o
*.ptx
*_ptx.h
@ -32,6 +33,7 @@ log.cite
.Trashes
ehthumbs.db
Thumbs.db
.clang-format
#cmake
/build*

17
README
View File

@ -25,7 +25,7 @@ The LAMMPS distribution includes the following files and directories:
README this file
LICENSE the GNU General Public License (GPL)
bench benchmark problems
couple code coupling examples using LAMMPS as a library
cmake CMake build system
doc documentation
examples simple test problems
lib libraries LAMMPS can be linked with
@ -36,7 +36,14 @@ tools pre- and post-processing tools
Point your browser at any of these files to get started:
doc/Manual.html the LAMMPS manual
doc/Section_intro.html hi-level introduction to LAMMPS
doc/Section_start.html how to build and use LAMMPS
doc/Developer.pdf LAMMPS developer guide
http://lammps.sandia.gov/doc/Manual.html the LAMMPS manual
http://lammps.sandia.gov/doc/Intro.html hi-level introduction
http://lammps.sandia.gov/doc/Build.html how to build LAMMPS
http://lammps.sandia.gov/doc/Run_head.html how to run LAMMPS
http://lammps.sandia.gov/doc/Developer.pdf LAMMPS developer guide
You can also create these doc pages locally:
% cd doc
% make html # creates HTML pages in doc/html
% make pdf # creates Manual.pdf and Developer.pdf

805
cmake/CMakeLists.txt
View File

File diff suppressed because it is too large Load Diff

48
cmake/FindLAMMPS.cmake.in Normal file
View File

@ -0,0 +1,48 @@
# - Find liblammps
# Find the native liblammps headers and libraries.
#
# The following variables will set:
# LAMMPS_INCLUDE_DIRS - where to find lammps/library.h, etc.
# LAMMPS_LIBRARIES - List of libraries when using lammps.
# LAMMPS_API_DEFINES - lammps library api defines
# LAMMPS_VERSION - lammps library version
# LAMMPS_FOUND - True if liblammps found.
#
# In addition a LAMMPS::LAMMPS imported target is getting created.
#
# LAMMPS - Large-scale Atomic/Molecular Massively Parallel Simulator
# http://lammps.sandia.gov, Sandia National Laboratories
# Steve Plimpton, sjplimp@sandia.gov
#
# Copyright (2003) Sandia Corporation. Under the terms of Contract
# DE-AC04-94AL85000 with Sandia Corporation, the U.S. Government retains
# certain rights in this software. This software is distributed under
# the GNU General Public License.
#
# See the README file in the top-level LAMMPS directory.
#
find_package(PkgConfig)
pkg_check_modules(PC_LAMMPS liblammps@LAMMPS_LIB_SUFFIX@)
find_path(LAMMPS_INCLUDE_DIR lammps/library.h HINTS ${PC_LAMMPS_INCLUDE_DIRS} @CMAKE_INSTALL_FULL_INCLUDEDIR@)
set(LAMMPS_VERSION @LAMMPS_VERSION@)
set(LAMMPS_API_DEFINES @LAMMPS_API_DEFINES@)
find_library(LAMMPS_LIBRARY NAMES lammps@LAMMPS_LIB_SUFFIX@ HINTS ${PC_LAMMPS_LIBRARY_DIRS} @CMAKE_INSTALL_FULL_LIBDIR@)
set(LAMMPS_INCLUDE_DIRS "${LAMMPS_INCLUDE_DIR}")
set(LAMMPS_LIBRARIES "${LAMMPS_LIBRARY}")
include(FindPackageHandleStandardArgs)
# handle the QUIETLY and REQUIRED arguments and set LAMMPS_FOUND to TRUE
# if all listed variables are TRUE
find_package_handle_standard_args(LAMMPS REQUIRED_VARS LAMMPS_LIBRARY LAMMPS_INCLUDE_DIR VERSION_VAR LAMMPS_VERSION)
mark_as_advanced(LAMMPS_INCLUDE_DIR LAMMPS_LIBRARY)
if(LAMMPS_FOUND AND NOT TARGET LAMMPS::LAMMPS)
add_library(LAMMPS::LAMMPS UNKNOWN IMPORTED)
set_target_properties(LAMMPS::LAMMPS PROPERTIES IMPORTED_LOCATION "${LAMMPS_LIBRARY}" INTERFACE_INCLUDE_DIRECTORIES "${LAMMPS_INCLUDE_DIR}" INTERFACE_COMPILE_DEFINITIONS "${LAMMPS_API_DEFINES}")
endif()

4
cmake/Modules/FindQUIP.cmake
View File

@ -1,8 +1,8 @@
# - Find quip
# Find the native QUIP libraries.
#
# QUIP_LIBRARIES - List of libraries when using fftw3.
# QUIP_FOUND - True if fftw3 found.
# QUIP_LIBRARIES - List of libraries of the QUIP package
# QUIP_FOUND - True if QUIP library was found.
#
find_library(QUIP_LIBRARY NAMES quip)

46
cmake/Modules/FindTBB.cmake Normal file
View File

@ -0,0 +1,46 @@
# - Find parts of TBB
# Find the native TBB headers and libraries.
#
# TBB_INCLUDE_DIRS - where to find tbb.h, etc.
# TBB_LIBRARIES - List of libraries when using tbb.
# TBB_FOUND - True if tbb found.
#
########################################################
# TBB
# TODO use more generic FindTBB
find_path(TBB_INCLUDE_DIR NAMES tbb/tbb.h PATHS $ENV{TBBROOT}/include)
find_library(TBB_LIBRARY NAMES tbb PATHS $ENV{TBBROOT}/lib/intel64/gcc4.7
$ENV{TBBROOT}/lib/intel64/gcc4.4
$ENV{TBBROOT}/lib/intel64/gcc4.1)
set(TBB_LIBRARIES ${TBB_LIBRARY})
set(TBB_INCLUDE_DIRS ${TBB_INCLUDE_DIR})
include(FindPackageHandleStandardArgs)
# handle the QUIETLY and REQUIRED arguments and set TBB_FOUND to TRUE
# if all listed variables are TRUE
find_package_handle_standard_args(TBB DEFAULT_MSG TBB_LIBRARY TBB_INCLUDE_DIR)
mark_as_advanced(TBB_INCLUDE_DIR TBB_LIBRARY )
########################################################
# TBB Malloc
find_path(TBB_MALLOC_INCLUDE_DIR NAMES tbb/tbb.h PATHS $ENV{TBBROOT}/include)
find_library(TBB_MALLOC_LIBRARY NAMES tbbmalloc PATHS $ENV{TBBROOT}/lib/intel64/gcc4.7
$ENV{TBBROOT}/lib/intel64/gcc4.4
$ENV{TBBROOT}/lib/intel64/gcc4.1)
set(TBB_MALLOC_LIBRARIES ${TBB_MALLOC_LIBRARY})
set(TBB_MALLOC_INCLUDE_DIRS ${TBB_MALLOC_INCLUDE_DIR})
include(FindPackageHandleStandardArgs)
# handle the QUIETLY and REQUIRED arguments and set TBB_MALLOC_FOUND to TRUE
# if all listed variables are TRUE
find_package_handle_standard_args(TBB_MALLOC DEFAULT_MSG TBB_MALLOC_LIBRARY TBB_MALLOC_INCLUDE_DIR)
mark_as_advanced(TBB_MALLOC_INCLUDE_DIR TBB_MALLOC_LIBRARY )

8
cmake/Modules/FindZMQ.cmake Normal file
View File

@ -0,0 +1,8 @@
find_path(ZMQ_INCLUDE_DIR zmq.h)
find_library(ZMQ_LIBRARY NAMES zmq)
set(ZMQ_LIBRARIES ${ZMQ_LIBRARY})
set(ZMQ_INCLUDE_DIRS ${ZMQ_INCLUDE_DIR})
include(FindPackageHandleStandardArgs)
find_package_handle_standard_args(ZMQ DEFAULT_MSG ZMQ_LIBRARY ZMQ_INCLUDE_DIR)

72
cmake/Modules/StyleHeaderUtils.cmake
View File

@ -45,15 +45,16 @@ function(FindStyleHeadersExt path style_class extension headers sources)
endfunction(FindStyleHeadersExt)
function(CreateStyleHeader path filename)
math(EXPR N "${ARGC}-2")
set(temp "")
if(N GREATER 0)
math(EXPR ARG_END "${ARGC}-1")
foreach(IDX RANGE 2 ${ARG_END})
list(GET ARGV ${IDX} FNAME)
if(ARGC GREATER 2)
list(REMOVE_AT ARGV 0 1)
set(header_list)
foreach(FNAME ${ARGV})
get_filename_component(FNAME ${FNAME} NAME)
list(APPEND header_list ${FNAME})
endforeach()
list(SORT header_list)
foreach(FNAME ${header_list})
set(temp "${temp}#include \"${FNAME}\"\n")
endforeach()
endif()
@ -84,19 +85,23 @@ function(RegisterNPairStyle path)
AddStyleHeader(${path} NPAIR)
endfunction(RegisterNPairStyle)
function(RegisterFixStyle path)
AddStyleHeader(${path} FIX)
endfunction(RegisterFixStyle)
function(RegisterStyles search_path)
FindStyleHeaders(${search_path} ANGLE_CLASS angle_ ANGLE ) # angle ) # force
FindStyleHeaders(${search_path} ATOM_CLASS atom_vec_ ATOM_VEC ) # atom ) # atom atom_vec_hybrid
FindStyleHeaders(${search_path} BODY_CLASS body_ BODY ) # body ) # atom_vec_body
FindStyleHeaders(${search_path} BOND_CLASS bond_ BOND ) # bond ) # force
FindStyleHeaders(${search_path} COMMAND_CLASS "" COMMAND ) # command ) # input
FindStyleHeaders(${search_path} COMMAND_CLASS "[^.]" COMMAND ) # command ) # input
FindStyleHeaders(${search_path} COMPUTE_CLASS compute_ COMPUTE ) # compute ) # modify
FindStyleHeaders(${search_path} DIHEDRAL_CLASS dihedral_ DIHEDRAL ) # dihedral ) # force
FindStyleHeaders(${search_path} DUMP_CLASS dump_ DUMP ) # dump ) # output write_dump
FindStyleHeaders(${search_path} FIX_CLASS fix_ FIX ) # fix ) # modify
FindStyleHeaders(${search_path} IMPROPER_CLASS improper_ IMPROPER ) # improper ) # force
FindStyleHeaders(${search_path} INTEGRATE_CLASS "" INTEGRATE ) # integrate ) # update
FindStyleHeaders(${search_path} KSPACE_CLASS "" KSPACE ) # kspace ) # force
FindStyleHeaders(${search_path} INTEGRATE_CLASS "[^.]" INTEGRATE ) # integrate ) # update
FindStyleHeaders(${search_path} KSPACE_CLASS "[^.]" KSPACE ) # kspace ) # force
FindStyleHeaders(${search_path} MINIMIZE_CLASS min_ MINIMIZE ) # minimize ) # update
FindStyleHeaders(${search_path} NBIN_CLASS nbin_ NBIN ) # nbin ) # neighbor
FindStyleHeaders(${search_path} NPAIR_CLASS npair_ NPAIR ) # npair ) # neighbor
@ -107,35 +112,6 @@ function(RegisterStyles search_path)
FindStyleHeaders(${search_path} REGION_CLASS region_ REGION ) # region ) # domain
endfunction(RegisterStyles)
function(RemovePackageHeader headers pkg_header)
get_property(hlist GLOBAL PROPERTY ${headers})
list(REMOVE_ITEM hlist ${pkg_header})
set_property(GLOBAL PROPERTY ${headers} "${hlist}")
endfunction(RemovePackageHeader)
function(DetectAndRemovePackageHeader fname)
RemovePackageHeader(ANGLE ${fname})
RemovePackageHeader(ATOM_VEC ${fname})
RemovePackageHeader(BODY ${fname})
RemovePackageHeader(BOND ${fname})
RemovePackageHeader(COMMAND ${fname})
RemovePackageHeader(COMPUTE ${fname})
RemovePackageHeader(DIHEDRAL ${fname})
RemovePackageHeader(DUMP ${fname})
RemovePackageHeader(FIX ${fname})
RemovePackageHeader(IMPROPER ${fname})
RemovePackageHeader(INTEGRATE ${fname})
RemovePackageHeader(KSPACE ${fname})
RemovePackageHeader(MINIMIZE ${fname})
RemovePackageHeader(NBIN ${fname})
RemovePackageHeader(NPAIR ${fname})
RemovePackageHeader(NSTENCIL ${fname})
RemovePackageHeader(NTOPO ${fname})
RemovePackageHeader(PAIR ${fname})
RemovePackageHeader(READER ${fname})
RemovePackageHeader(REGION ${fname})
endfunction(DetectAndRemovePackageHeader)
function(RegisterStylesExt search_path extension sources)
FindStyleHeadersExt(${search_path} ANGLE_CLASS ${extension} ANGLE ${sources})
FindStyleHeadersExt(${search_path} ATOM_CLASS ${extension} ATOM_VEC ${sources})
@ -181,3 +157,21 @@ function(GenerateStyleHeaders output_path)
GenerateStyleHeader(${output_path} READER reader ) # read_dump
GenerateStyleHeader(${output_path} REGION region ) # domain
endfunction(GenerateStyleHeaders)
function(DetectBuildSystemConflict lammps_src_dir)
if(ARGC GREATER 1)
list(REMOVE_AT ARGV 0)
foreach(SRC_FILE ${ARGV})
get_filename_component(FILENAME ${SRC_FILE} NAME)
if(EXISTS ${lammps_src_dir}/${FILENAME})
message(FATAL_ERROR "\n########################################################################\n"
"Found package(s) installed by the make-based build system\n"
"\n"
"Please run\n"
"make -C ${lammps_src_dir} no-all purge\n"
"to uninstall\n"
"########################################################################")
endif()
endforeach()
endif()
endfunction(DetectBuildSystemConflict)

196
cmake/README.md
View File

@ -22,6 +22,7 @@ tasks, act as a reference and provide examples of typical use cases.
* [Building LAMMPS using cmake](#building-lammps-using-cmake-1)
* [Prerequisites](#prerequisites)
* [Build directory vs. Source Directory](#build-directory-vs-source-directory)
* [Defining and using presets](#defining-and-using-presets)
* [Reference](#reference)
* [Common CMAKE Configuration Options](#common-cmake-configuration-options)
* [LAMMPS Configuration Options](#lammps-configuration-options)
@ -61,7 +62,7 @@ should get you started.
git clone https://github.com/lammps/lammps.git
mkdir lammps/build
cd lammps/build
cmake ../cmake [-DOPTION_A=VALUE_A -DOPTION_B=VALUE_B ...]
cmake [-D OPTION_A=VALUE_A -D OPTION_B=VALUE_B ...] ../cmake
make
```
@ -150,6 +151,31 @@ build directory.
```
make
```
# Defining and using presets
The CMake build exposes a lot of different options. In the old build system
some of the package selections were possible by using special make target like
`make yes-std` or `make no-lib`. Achieving the same result with cmake requires
specifying all options manually. This can quickly become a very long command
line that is hard to handle. While these could be stored in a simple script
file, there is another way of defining "presets" to compile LAMMPS in a certain
way.
A preset is a regular CMake script file that can use constructs such as
variables, lists and for-loops to manipulate configuration options and create
an [*initial cache*](https://cmake.org/cmake/help/v3.12/manual/cmake.1.html).
Options must be set with the `CACHE` and `FORCE` flag to ensure they are
considered even during a second cmake run.
Such a file can then be passed to cmake via the `-C` flag. Several examples of
presets can be found in the `cmake/presets` folder.
```bash
# build LAMMPS with all "standard" packages which don't use libraries and enable GPU package
mkdir build
cd build
cmake -C ../cmake/presets/std_nolib.cmake -D PKG_GPU=on ../cmake
```
# Reference
@ -239,6 +265,26 @@ make
</dl>
</td>
</tr>
<tr>
<td><code>BUILD_LIB</code></td>
<td>control whether to build LAMMPS as a library</td>
<td>
<dl>
<dt><code>off</code> (default)</dt>
<dt><code>on</code></dt>
</dl>
</td>
</tr>
<tr>
<td><code>BUILD_EXE</code></td>
<td>control whether to build LAMMPS executable</td>
<td>
<dl>
<dt><code>on</code> (default)</dt>
<dt><code>off</code></dt>
</dl>
</td>
</tr>
<tr>
<td><code>BUILD_SHARED_LIBS</code></td>
<td>control whether to build LAMMPS as a shared-library</td>
@ -249,6 +295,16 @@ make
</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>
@ -279,8 +335,8 @@ make
`mpicxx` in your path and use this MPI implementation.</td>
<td>
<dl>
<dt><code>off</code> (default)</dt>
<dt><code>on</code></dt>
<dt><code>on</code> (default, if found)</dt>
<dt><code>off</code></dt>
</dl>
</td>
</tr>
@ -289,8 +345,8 @@ make
<td>control whether to build LAMMPS with OpenMP support.</td>
<td>
<dl>
<dt><code>off</code> (default)</dt>
<dt><code>on</code></dt>
<dt><code>on</code> (default, if found)</dt>
<dt><code>off</code></dt>
</dl>
</td>
</tr>
@ -374,16 +430,6 @@ make
</tr>
</thead>
<tbody>
<tr>
<td><code>ENABLE_ALL</code></td>
<td>Enable all default packages</td>
<td>
<dl>
<dt><code>off</code> (default)</dt>
<dt><code>on</code></dt>
</dl>
</td>
</tr>
<tr>
<td><code>PKG_ASPHERE</code></td>
<td>Computes, time-integration fixes, and pair styles for aspherical particle models including ellipsoids, 2d lines, and 3d triangles.</td>
@ -1245,7 +1291,7 @@ providing the identical features and USER interface.</strong></p>
</td>
<td>
<dl>
<dt><code>KISSFFT</code></dt>
<dt><code>KISS</code></dt>
<dt><code>FFTW3</code></dt>
<dt><code>FFTW2</code></dt>
<dt><code>MKL</code></dt>
@ -1253,13 +1299,13 @@ providing the identical features and USER interface.</strong></p>
</td>
</tr>
<tr>
<td><code>PACK_ARRAY</code></td>
<td><code>FFT_PACK</code></td>
<td>Optimization for FFT</td>
<td>
<dl>
<dt><code>PACK_ARRAY</code></dt>
<dt><code>PACK_POINTER</code></dt>
<dt><code>PACK_MEMCPY</code></dt>
<dt><code>array (default)</code></dt>
<dt><code>pointer</code></dt>
<dt><code>memcpy</code></dt>
</dl>
</td>
</tr>
@ -1351,6 +1397,29 @@ TODO
### PYTHON Package
### USER-INTEL Package
<table>
<thead>
<tr>
<th>Option</th>
<th>Description</th>
<th>Values</th>
</tr>
</thead>
<tbody>
<tr>
<td><code>INTEL_ARCH</code></td>
<td>Target architecture for USER-INTEL package</td>
<td>
<dl>
<dt><code>cpu</code> (default)</dt>
<dt><code>knl</code></dt>
</dl>
</td>
</tr>
</tbody>
</table>
### GPU Package
The GPU package builds a support library which can either use OpenCL or CUDA as
@ -1370,8 +1439,8 @@ target API.
<td>API used by GPU package</td>
<td>
<dl>
<dt><code>OpenCL</code> (default)</dt>
<dt><code>CUDA</code></dt>
<dt><code>opencl</code> (default)</dt>
<dt><code>cuda</code></dt>
</dl>
</td>
</tr>
@ -1380,9 +1449,9 @@ target API.
<td>Precision size used by GPU package kernels</td>
<td>
<dl>
<dt><code>SINGLE_DOUBLE</code></dt>
<dt><code>SINGLE_SINGLE</code></dt>
<dt><code>DOUBLE_DOUBLE</code></dt>
<dt><code>mixed</code> (default)</dt>
<dt><code>single</code></dt>
<dt><code>double</code></dt>
</dl>
</td>
</tr>
@ -1391,12 +1460,12 @@ target API.
<td>Tuning target for OpenCL driver code</td>
<td>
<dl>
<dt><code>GENERIC</code> (default)</dt>
<dt><code>INTEL</code> (Intel CPU)</dt>
<dt><code>PHI</code> (Intel Xeon Phi)</dt>
<dt><code>FERMI</code> (NVIDIA)</dt>
<dt><code>KEPLER</code> (NVIDIA)</dt>
<dt><code>CYPRESS</code> (AMD)</dt>
<dt><code>generic</code> (default)</dt>
<dt><code>intel</code> (Intel CPU)</dt>
<dt><code>phi</code> (Intel Xeon Phi)</dt>
<dt><code>fermi</code> (NVIDIA)</dt>
<dt><code>kepler</code> (NVIDIA)</dt>
<dt><code>cypress</code> (AMD)</dt>
</dl>
</td>
</tr>
@ -1405,11 +1474,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>
@ -1491,6 +1560,16 @@ Requires a Eigen3 installation
</tr>
</thead>
<tbody>
<tr>
<td><code>WITH_JPEG</code></td>
<td>Enables/Disable JPEG support in LAMMPS</td>
<td>
<dl>
<dt><code>yes</code> (default, if found)</dt>
<dt><code>no</code></dt>
</dl>
</td>
</tr>
<tr>
<td><code>JPEG_INCLUDE_DIR</code></td>
<td></td>
@ -1518,6 +1597,16 @@ Requires a Eigen3 installation
</tr>
</thead>
<tbody>
<tr>
<td><code>WITH_PNG</code></td>
<td>Enables/Disable PNG support in LAMMPS</td>
<td>
<dl>
<dt><code>yes</code> (default, if found)</dt>
<dt><code>no</code></dt>
</dl>
</td>
</tr>
<tr>
<td><code>PNG_INCLUDE_DIR</code></td>
<td></td>
@ -1546,6 +1635,16 @@ requires `gzip` to be in your `PATH`
</tr>
</thead>
<tbody>
<tr>
<td><code>WITH_GZIP</code></td>
<td>Enables/Disable GZIP support in LAMMPS</td>
<td>
<dl>
<dt><code>yes</code> (default, if found)</dt>
<dt><code>no</code></dt>
</dl>
</td>
</tr>
<tr>
<td><code>GZIP_EXECUTABLE</code></td>
<td></td>
@ -1568,6 +1667,16 @@ requires `ffmpeg` to be in your `PATH`
</tr>
</thead>
<tbody>
<tr>
<td><code>WITH_FFMPEG</code></td>
<td>Enables/Disable FFMPEG support in LAMMPS</td>
<td>
<dl>
<dt><code>yes</code> (default, if found)</dt>
<dt><code>no</code></dt>
</dl>
</td>
</tr>
<tr>
<td><code>FFMPEG_EXECUTABLE</code></td>
<td></td>
@ -1580,8 +1689,13 @@ requires `ffmpeg` to be in your `PATH`
## Compilers
By default, `cmake` will use your environment C/C++/Fortran compilers for a build. It uses the `CC`, `CXX` and `FC` environment variables to detect which compilers should be used. However, these values
will be cached after the first run of `cmake`. Subsequent runs of `cmake` will ignore changes in these environment variables. To ensure the correct values are used you avoid the cache by setting the `CMAKE_C_COMPILER`, `CMAKE_CXX_COMPILER`, `CMAKE_Fortran_COMPILER` options directly.
By default, `cmake` will use your environment C/C++/Fortran compilers for a
build. It uses the `CC`, `CXX` and `FC` environment variables to detect which
compilers should be used. However, these values will be cached after the first
run of `cmake`. Subsequent runs of `cmake` will ignore changes in these
environment variables. To ensure the correct values are used you avoid the
cache by setting the `CMAKE_C_COMPILER`, `CMAKE_CXX_COMPILER`,
`CMAKE_Fortran_COMPILER` options directly.
<table>
<thead>
@ -1617,20 +1731,20 @@ will be cached after the first run of `cmake`. Subsequent runs of `cmake` will i
### Building with GNU Compilers
```bash
cmake ../cmake -DCMAKE_C_COMPILER=gcc -DCMAKE_CXX_COMPILER=g++ -DCMAKE_Fortran_COMPILER=gfortran
cmake -D CMAKE_C_COMPILER=gcc -D CMAKE_CXX_COMPILER=g++ -D CMAKE_Fortran_COMPILER=gfortran ../cmake
```
### Building with Intel Compilers
```bash
cmake ../cmake -DCMAKE_C_COMPILER=icc -DCMAKE_CXX_COMPILER=icpc -DCMAKE_Fortran_COMPILER=ifort
cmake -D CMAKE_C_COMPILER=icc -D CMAKE_CXX_COMPILER=icpc -D CMAKE_Fortran_COMPILER=ifort ../cmake
```
### Building with LLVM/Clang Compilers
```bash
cmake ../cmake -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_Fortran_COMPILER=flang
cmake -D CMAKE_C_COMPILER=clang -D CMAKE_CXX_COMPILER=clang++ -D CMAKE_Fortran_COMPILER=flang ../cmake
```

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
cmake/pkgconfig/liblammps.pc.in
View File

@ -4,15 +4,15 @@
# after you added @CMAKE_INSTALL_FULL_LIBDIR@/pkg-config to PKG_CONFIG_PATH,
# e.g. export PKG_CONFIG_PATH=@CMAKE_INSTALL_FULL_LIBDIR@/pkgconfig
prefix=@CMAKE_INSTALL_FULL_PREFIX@
prefix=@CMAKE_INSTALL_PREFIX@
libdir=@CMAKE_INSTALL_FULL_LIBDIR@
includedir=@CMAKE_INSTALL_FULL_INCLUDEDIR@
Name: liblammps@LAMMPS_MACHINE@
Description: Large-scale Atomic/Molecular Massively Parallel Simulator Library
URL: http://lammps.sandia.gov
Version:
Version: @LAMMPS_VERSION@
Requires:
Libs: -L${libdir} -llammps@LAMMPS_MACHINE@
Libs: -L${libdir} -llammps@LAMMPS_LIB_SUFFIX@
Libs.private: -lm
Cflags: -I${includedir} @LAMMPS_API_DEFINES@

22
cmake/presets/all_off.cmake Normal file
View File

@ -0,0 +1,22 @@
set(STANDARD_PACKAGES ASPHERE BODY CLASS2 COLLOID COMPRESS CORESHELL DIPOLE GPU
GRANULAR KIM KOKKOS KSPACE LATTE MANYBODY MC MEAM MISC
MOLECULE MPIIO MSCG OPT PERI POEMS
PYTHON QEQ REAX REPLICA RIGID SHOCK SNAP SRD VORONOI)
set(USER_PACKAGES USER-ATC USER-AWPMD USER-BOCS USER-CGDNA USER-CGSDK USER-COLVARS
USER-DIFFRACTION USER-DPD USER-DRUDE USER-EFF USER-FEP USER-H5MD
USER-INTEL USER-LB USER-MANIFOLD USER-MEAMC USER-MESO
USER-MGPT USER-MISC USER-MOFFF USER-MOLFILE
USER-NETCDF USER-OMP USER-PHONON USER-QMMM USER-QTB
USER-QUIP USER-REAXC USER-SMD USER-SMTBQ USER-SPH USER-TALLY
USER-UEF USER-VTK)
set(PACKAGES_WITH_LIB COMPRESS GPU KIM KOKKOS LATTE MEAM MPIIO MSCG POEMS PYTHON REAX VORONOI
USER-ATC USER-AWPMD USER-COLVARS USER-H5MD USER-LB USER-MOLFILE
USER-NETCDF USER-QMMM USER-QUIP USER-SMD USER-VTK)
set(ALL_PACKAGES ${STANDARD_PACKAGES} ${USER_PACKAGES})
foreach(PKG ${ALL_PACKAGES})
set(PKG_${PKG} OFF CACHE BOOL "" FORCE)
endforeach()

22
cmake/presets/all_on.cmake Normal file
View File

@ -0,0 +1,22 @@
set(STANDARD_PACKAGES ASPHERE BODY CLASS2 COLLOID COMPRESS CORESHELL DIPOLE GPU
GRANULAR KIM KOKKOS KSPACE LATTE MANYBODY MC MEAM MISC
MOLECULE MPIIO MSCG OPT PERI POEMS
PYTHON QEQ REAX REPLICA RIGID SHOCK SNAP SRD VORONOI)
set(USER_PACKAGES USER-ATC USER-AWPMD USER-BOCS USER-CGDNA USER-CGSDK USER-COLVARS
USER-DIFFRACTION USER-DPD USER-DRUDE USER-EFF USER-FEP USER-H5MD
USER-INTEL USER-LB USER-MANIFOLD USER-MEAMC USER-MESO
USER-MGPT USER-MISC USER-MOFFF USER-MOLFILE
USER-NETCDF USER-OMP USER-PHONON USER-QMMM USER-QTB
USER-QUIP USER-REAXC USER-SMD USER-SMTBQ USER-SPH USER-TALLY
USER-UEF USER-VTK)
set(PACKAGES_WITH_LIB COMPRESS GPU KIM KOKKOS LATTE MEAM MPIIO MSCG POEMS PYTHON REAX VORONOI
USER-ATC USER-AWPMD USER-COLVARS USER-H5MD USER-LB USER-MOLFILE
USER-NETCDF USER-QMMM USER-QUIP USER-SMD USER-VTK)
set(ALL_PACKAGES ${STANDARD_PACKAGES} ${USER_PACKAGES})
foreach(PKG ${ALL_PACKAGES})
set(PKG_${PKG} ON CACHE BOOL "" FORCE)
endforeach()

69
cmake/presets/manual_selection.cmake Normal file
View File

@ -0,0 +1,69 @@
set(PKG_ASPHERE OFF CACHE BOOL "" FORCE)
set(PKG_BODY OFF CACHE BOOL "" FORCE)
set(PKG_CLASS2 OFF CACHE BOOL "" FORCE)
set(PKG_COLLOID OFF CACHE BOOL "" FORCE)
set(PKG_COMPRESS OFF CACHE BOOL "" FORCE)
set(PKG_CORESHELL OFF CACHE BOOL "" FORCE)
set(PKG_DIPOLE OFF CACHE BOOL "" FORCE)
set(PKG_GPU OFF CACHE BOOL "" FORCE)
set(PKG_GRANULAR OFF CACHE BOOL "" FORCE)
set(PKG_KIM OFF CACHE BOOL "" FORCE)
set(PKG_KOKKOS OFF CACHE BOOL "" FORCE)
set(PKG_KSPACE OFF CACHE BOOL "" FORCE)
set(PKG_LATTE OFF CACHE BOOL "" FORCE)
set(PKG_LIB OFF CACHE BOOL "" FORCE)
set(PKG_MANYBODY OFF CACHE BOOL "" FORCE)
set(PKG_MC OFF CACHE BOOL "" FORCE)
set(PKG_MEAM OFF CACHE BOOL "" FORCE)
set(PKG_MISC OFF CACHE BOOL "" FORCE)
set(PKG_MOLECULE OFF CACHE BOOL "" FORCE)
set(PKG_MPIIO OFF CACHE BOOL "" FORCE)
set(PKG_MSCG OFF CACHE BOOL "" FORCE)
set(PKG_OPT OFF CACHE BOOL "" FORCE)
set(PKG_PERI OFF CACHE BOOL "" FORCE)
set(PKG_POEMS OFF CACHE BOOL "" FORCE)
set(PKG_PYTHOFF OFF CACHE BOOL "" FORCE)
set(PKG_QEQ OFF CACHE BOOL "" FORCE)
set(PKG_REAX OFF CACHE BOOL "" FORCE)
set(PKG_REPLICA OFF CACHE BOOL "" FORCE)
set(PKG_RIGID OFF CACHE BOOL "" FORCE)
set(PKG_SHOCK OFF CACHE BOOL "" FORCE)
set(PKG_SNAP OFF CACHE BOOL "" FORCE)
set(PKG_SRD OFF CACHE BOOL "" FORCE)
set(PKG_VOROFFOI OFF CACHE BOOL "" FORCE)
set(PKG_USER OFF CACHE BOOL "" FORCE)
set(PKG_USER-ATC OFF CACHE BOOL "" FORCE)
set(PKG_USER-AWPMD OFF CACHE BOOL "" FORCE)
set(PKG_USER-BOCS OFF CACHE BOOL "" FORCE)
set(PKG_USER-CGDNA OFF CACHE BOOL "" FORCE)
set(PKG_USER-CGSDK OFF CACHE BOOL "" FORCE)
set(PKG_USER-COLVARS OFF CACHE BOOL "" FORCE)
set(PKG_USER-DIFFRACTIOFF OFF CACHE BOOL "" FORCE)
set(PKG_USER-DPD OFF CACHE BOOL "" FORCE)
set(PKG_USER-DRUDE OFF CACHE BOOL "" FORCE)
set(PKG_USER-EFF OFF CACHE BOOL "" FORCE)
set(PKG_USER-FEP OFF CACHE BOOL "" FORCE)
set(PKG_USER-H5MD OFF CACHE BOOL "" FORCE)
set(PKG_USER-INTEL OFF CACHE BOOL "" FORCE)
set(PKG_USER-LB OFF CACHE BOOL "" FORCE)
set(PKG_USER-MANIFOLD OFF CACHE BOOL "" FORCE)
set(PKG_USER-MEAMC OFF CACHE BOOL "" FORCE)
set(PKG_USER-MESO OFF CACHE BOOL "" FORCE)
set(PKG_USER-MGPT OFF CACHE BOOL "" FORCE)
set(PKG_USER-MISC OFF CACHE BOOL "" FORCE)
set(PKG_USER-MOFFF OFF CACHE BOOL "" FORCE)
set(PKG_USER-MOLFILE OFF CACHE BOOL "" FORCE)
set(PKG_USER-NETCDF OFF CACHE BOOL "" FORCE)
set(PKG_USER-OMP OFF CACHE BOOL "" FORCE)
set(PKG_USER-PHOFFOFF OFF CACHE BOOL "" FORCE)
set(PKG_USER-QMMM OFF CACHE BOOL "" FORCE)
set(PKG_USER-QTB OFF CACHE BOOL "" FORCE)
set(PKG_USER-QUIP OFF CACHE BOOL "" FORCE)
set(PKG_USER-REAXC OFF CACHE BOOL "" FORCE)
set(PKG_USER-SMD OFF CACHE BOOL "" FORCE)
set(PKG_USER-SMTBQ OFF CACHE BOOL "" FORCE)
set(PKG_USER-SPH OFF CACHE BOOL "" FORCE)
set(PKG_USER-TALLY OFF CACHE BOOL "" FORCE)
set(PKG_USER-UEF OFF CACHE BOOL "" FORCE)
set(PKG_USER-VTK OFF CACHE BOOL "" FORCE)

22
cmake/presets/nolib.cmake Normal file
View File

@ -0,0 +1,22 @@
set(STANDARD_PACKAGES ASPHERE BODY CLASS2 COLLOID COMPRESS CORESHELL DIPOLE GPU
GRANULAR KIM KOKKOS KSPACE LATTE MANYBODY MC MEAM MISC
MOLECULE MPIIO MSCG OPT PERI POEMS
PYTHON QEQ REAX REPLICA RIGID SHOCK SNAP SRD VORONOI)
set(USER_PACKAGES USER-ATC USER-AWPMD USER-BOCS USER-CGDNA USER-CGSDK USER-COLVARS
USER-DIFFRACTION USER-DPD USER-DRUDE USER-EFF USER-FEP USER-H5MD
USER-INTEL USER-LB USER-MANIFOLD USER-MEAMC USER-MESO
USER-MGPT USER-MISC USER-MOFFF USER-MOLFILE
USER-NETCDF USER-OMP USER-PHONON USER-QMMM USER-QTB
USER-QUIP USER-REAXC USER-SMD USER-SMTBQ USER-SPH USER-TALLY
USER-UEF USER-VTK)
set(PACKAGES_WITH_LIB COMPRESS GPU KIM KOKKOS LATTE MEAM MPIIO MSCG POEMS PYTHON REAX VORONOI
USER-ATC USER-AWPMD USER-COLVARS USER-H5MD USER-LB USER-MOLFILE
USER-NETCDF USER-QMMM USER-QUIP USER-SMD USER-VTK)
set(ALL_PACKAGES ${STANDARD_PACKAGES} ${USER_PACKAGES})
foreach(PKG ${PACKAGES_WITH_LIB})
set(PKG_${PKG} OFF CACHE BOOL "" FORCE)
endforeach()

22
cmake/presets/std.cmake Normal file
View File

@ -0,0 +1,22 @@
set(STANDARD_PACKAGES ASPHERE BODY CLASS2 COLLOID COMPRESS CORESHELL DIPOLE GPU
GRANULAR KIM KOKKOS KSPACE LATTE MANYBODY MC MEAM MISC
MOLECULE MPIIO MSCG OPT PERI POEMS
PYTHON QEQ REAX REPLICA RIGID SHOCK SNAP SRD VORONOI)
set(USER_PACKAGES USER-ATC USER-AWPMD USER-BOCS USER-CGDNA USER-CGSDK USER-COLVARS
USER-DIFFRACTION USER-DPD USER-DRUDE USER-EFF USER-FEP USER-H5MD
USER-INTEL USER-LB USER-MANIFOLD USER-MEAMC USER-MESO
USER-MGPT USER-MISC USER-MOFFF USER-MOLFILE
USER-NETCDF USER-OMP USER-PHONON USER-QMMM USER-QTB
USER-QUIP USER-REAXC USER-SMD USER-SMTBQ USER-SPH USER-TALLY
USER-UEF USER-VTK)
set(PACKAGES_WITH_LIB COMPRESS GPU KIM KOKKOS LATTE MEAM MPIIO MSCG POEMS PYTHON REAX VORONOI
USER-ATC USER-AWPMD USER-COLVARS USER-H5MD USER-LB USER-MOLFILE
USER-NETCDF USER-QMMM USER-QUIP USER-SMD USER-VTK)
set(ALL_PACKAGES ${STANDARD_PACKAGES} ${USER_PACKAGES})
foreach(PKG ${STANDARD_PACKAGES})
set(PKG_${PKG} ON CACHE BOOL "" FORCE)
endforeach()

26
cmake/presets/std_nolib.cmake Normal file
View File

@ -0,0 +1,26 @@
set(STANDARD_PACKAGES ASPHERE BODY CLASS2 COLLOID COMPRESS CORESHELL DIPOLE GPU
GRANULAR KIM KOKKOS KSPACE LATTE MANYBODY MC MEAM MISC
MOLECULE MPIIO MSCG OPT PERI POEMS
PYTHON QEQ REAX REPLICA RIGID SHOCK SNAP SRD VORONOI)
set(USER_PACKAGES USER-ATC USER-AWPMD USER-BOCS USER-CGDNA USER-CGSDK USER-COLVARS
USER-DIFFRACTION USER-DPD USER-DRUDE USER-EFF USER-FEP USER-H5MD
USER-INTEL USER-LB USER-MANIFOLD USER-MEAMC USER-MESO
USER-MGPT USER-MISC USER-MOFFF USER-MOLFILE
USER-NETCDF USER-OMP USER-PHONON USER-QMMM USER-QTB
USER-QUIP USER-REAXC USER-SMD USER-SMTBQ USER-SPH USER-TALLY
USER-UEF USER-VTK)
set(PACKAGES_WITH_LIB COMPRESS GPU KIM KOKKOS LATTE MEAM MPIIO MSCG POEMS PYTHON REAX VORONOI
USER-ATC USER-AWPMD USER-COLVARS USER-H5MD USER-LB USER-MOLFILE
USER-NETCDF USER-QMMM USER-QUIP USER-SMD USER-VTK)
set(ALL_PACKAGES ${STANDARD_PACKAGES} ${USER_PACKAGES})
foreach(PKG ${STANDARD_PACKAGES})
set(PKG_${PKG} ON CACHE BOOL "" FORCE)
endforeach()
foreach(PKG ${PACKAGES_WITH_LIB})
set(PKG_${PKG} OFF CACHE BOOL "" FORCE)
endforeach()

22
cmake/presets/user.cmake Normal file
View File

@ -0,0 +1,22 @@
set(STANDARD_PACKAGES ASPHERE BODY CLASS2 COLLOID COMPRESS CORESHELL DIPOLE GPU
GRANULAR KIM KOKKOS KSPACE LATTE MANYBODY MC MEAM MISC
MOLECULE MPIIO MSCG OPT PERI POEMS
PYTHON QEQ REAX REPLICA RIGID SHOCK SNAP SRD VORONOI)
set(USER_PACKAGES USER-ATC USER-AWPMD USER-BOCS USER-CGDNA USER-CGSDK USER-COLVARS
USER-DIFFRACTION USER-DPD USER-DRUDE USER-EFF USER-FEP USER-H5MD
USER-INTEL USER-LB USER-MANIFOLD USER-MEAMC USER-MESO
USER-MGPT USER-MISC USER-MOFFF USER-MOLFILE
USER-NETCDF USER-OMP USER-PHONON USER-QMMM USER-QTB
USER-QUIP USER-REAXC USER-SMD USER-SMTBQ USER-SPH USER-TALLY
USER-UEF USER-VTK)
set(PACKAGES_WITH_LIB COMPRESS GPU KIM KOKKOS LATTE MEAM MPIIO MSCG POEMS PYTHON REAX VORONOI
USER-ATC USER-AWPMD USER-COLVARS USER-H5MD USER-LB USER-MOLFILE
USER-NETCDF USER-QMMM USER-QUIP USER-SMD USER-VTK)
set(ALL_PACKAGES ${STANDARD_PACKAGES} ${USER_PACKAGES})
foreach(PKG ${USER_PACKAGES})
set(PKG_${PKG} ON CACHE BOOL "" FORCE)
endforeach()

15
doc/Makefile
View File

@ -31,7 +31,7 @@ SPHINXEXTRA = -j $(shell $(PYTHON) -c 'import multiprocessing;print(multiprocess
SOURCES=$(filter-out $(wildcard src/lammps_commands*.txt) src/lammps_support.txt src/lammps_tutorials.txt,$(wildcard src/*.txt))
OBJECTS=$(SOURCES:src/%.txt=$(RSTDIR)/%.rst)
.PHONY: help clean-all clean epub html pdf old venv spelling anchor_check
.PHONY: help clean-all clean epub mobi html pdf old venv spelling anchor_check
# ------------------------------------------
@ -42,6 +42,8 @@ help:
@echo " old create old-style HTML doc pages in old dir"
@echo " fetch fetch HTML and PDF files from LAMMPS web site"
@echo " epub create ePUB format manual for e-book readers"
@echo " mobi convert ePUB to MOBI format manual for e-book readers (e.g. Kindle)"
@echo " (requires ebook-convert tool from calibre)"
@echo " clean remove all intermediate RST files"
@echo " clean-all reset the entire build environment"
@echo " txt2html build txt2html tool"
@ -49,11 +51,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:
@ -106,6 +108,11 @@ epub: $(OBJECTS)
@rm -rf epub
@echo "Build finished. The ePUB manual file is created."
mobi: epub
@rm -f LAMMPS.mobi
@ebook-convert LAMMPS.epub LAMMPS.mobi
@echo "Conversion finished. The MOBI manual file is created."
pdf: utils/txt2html/txt2html.exe
@(\
set -e; \
@ -157,7 +164,7 @@ $(RSTDIR)/%.rst : src/%.txt $(TXT2RST)
@(\
mkdir -p $(RSTDIR) ; \
. $(VENV)/bin/activate ;\
txt2rst $< > $@ ;\
txt2rst -v $< > $@ ;\
deactivate ;\
)

45
doc/lammps.1 Normal file
View File

@ -0,0 +1,45 @@
.TH LAMMPS "2018-08-22"
.SH NAME
.B LAMMPS
\- Molecular Dynamics Simulator.
.SH SYNOPSIS
.B lmp
-in in.file
or
mpirun \-np 2
.B lmp
-in in.file
.SH DESCRIPTION
.B LAMMPS
LAMMPS is a classical molecular dynamics code, and an acronym for Large-scale
Atomic/Molecular Massively Parallel Simulator. LAMMPS has potentials for soft
materials (biomolecules, polymers) and solid-state materials (metals,
semiconductors) and coarse-grained or mesoscopic systems. It can be used to
model atoms or, more generically, as a parallel particle simulator at the
atomic, meso, or continuum scale.
See http://lammps.sandia.gov/ for documentation.
.SH OPTIONS
See https://lammps.sandia.gov/doc/Run_options.html for details on
command-line options.
.SH COPYRIGHT
© 2003--2018 Sandia Corporation
This package is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This package is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
On Debian systems, the complete text of the GNU General
Public License can be found in `/usr/share/common-licenses/GPL-2'.

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

@ -0,0 +1,49 @@
"Previous Section"_Install.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc - "Next Section"_Run_head.html :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
Build LAMMPS :h2
LAMMPS can be built as an executable or library from source code via
either traditional makefiles (which may require manual editing)
for use with GNU make or gmake, or a build environment generated by CMake
(Unix Makefiles, Xcode, Visual Studio, KDevelop or more). As an
alternative you can download a package with pre-built executables
as described on the "Install"_Install.html doc page.
<!-- RST
.. toctree::
:maxdepth: 1
Build_cmake
Build_make
Build_link
Build_basics
Build_settings
Build_package
Build_extras
Build_windows
END_RST -->
<!-- HTML_ONLY -->
"Build LAMMPS with CMake"_Build_cmake.html
"Build LAMMPS with make"_Build_make.html
"Link LAMMPS as a library to another code"_Build_link.html
"Basic build options"_Build_basics.html
"Optional build settings"_Build_settings.html
"Include packages in build"_Build_package.html
"Packages with extra build options"_Build_extras.html
"Notes for building LAMMPS on Windows"_Build_windows.html :all(b)
If you have problems building LAMMPS, it is often due to software
issues on your local machine. If you can, find a local expert to
help. If you're still stuck, send an email to the "LAMMPS mail
list"_http://lammps.sandia.gov/mail.html.

319
doc/src/Build_basics.txt Normal file
View File

@ -0,0 +1,319 @@
"Higher level section"_Build.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
Basic build options :h3
The following topics are covered on this page, for building both with
CMake and make:
"Serial vs parallel build"_#serial
"Choice of compiler and compile/link options"_#compile
"Build LAMMPS as an executable or a library"_#exe
"Build the LAMMPS documentation"_#doc
"Install LAMMPS after a build"_#install :ul
:line
Serial vs parallel build :h4,link(serial)
LAMMPS can be built to run in parallel using the ubiquitous "MPI
(message-passing
interface)"_https://en.wikipedia.org/wiki/Message_Passing_Interface
library. Or it can built to run on a single processor (serial)
without MPI. It can also be built with support for OpenMP threading
(see more discussion below).
[CMake variables]:
-D BUILD_MPI=value # yes or no, default is yes if CMake finds MPI, else no
-D BUILD_OMP=value # yes or no (default)
-D LAMMPS_MACHINE=name # name = mpi, serial, mybox, titan, laptop, etc
# no default value :pre
The executable created by CMake (after running make) is lmp_name. If
the LAMMPS_MACHINE variable is not specified, the executable is just
lmp. Using BUILD_MPI=no will produce a serial executable.
[Traditional make]:
cd lammps/src
make mpi # parallel build, produces lmp_mpi using Makefile.mpi
make serial # serial build, produces lmp_serial using Makefile/serial
make mybox :pre # uses Makefile.mybox to produce lmp_mybox :pre
Serial build (see src/MAKE/Makefile.serial):
MPI_INC = -I../STUBS
MPI_PATH = -L../STUBS
MPI_LIB = -lmpi_stubs :pre
For a parallel build, if MPI is installed on your system in the usual
place (e.g. under /usr/local), you do not need to specify the 3
variables MPI_INC, MPI_PATH, MPI_LIB. The MPI wrapper on the compiler
(e.g. mpicxx, mpiCC) knows where to find the needed include and
library files. Failing this, these 3 variables can be used to specify
where the mpi.h file (MPI_INC), and the MPI library files (MPI_PATH)
are found, and the name of the library files (MPI_LIB).
For a serial build, you need to specify the 3 variables, as shown
above.
For a serial LAMMPS build, use the dummy MPI library provided in
src/STUBS. You also need to build the STUBS library for your platform
before making LAMMPS itself. A "make serial" build does this for.
Otherwise, type "make mpi-stubs" from the src directory, or "make"
from the src/STUBS dir. If the build fails, you will need to edit the
STUBS/Makefile for your platform.
The file STUBS/mpi.c provides a CPU timer function called MPI_Wtime()
that calls gettimeofday() . If your system doesn't support
gettimeofday() , you'll need to insert code to call another timer.
Note that the ANSI-standard function clock() rolls over after an hour
or so, and is therefore insufficient for timing long LAMMPS
simulations.
[CMake and make info]:
If you are installing MPI yourself, we recommend MPICH2 from Argonne
National Laboratory or OpenMPI. MPICH can be downloaded from the
"Argonne MPI site"_http://www.mcs.anl.gov/research/projects/mpich2/.
OpenMPI can be downloaded from the "OpenMPI
site"_http://www.open-mpi.org. Other MPI packages should also work.
If you are running on a large parallel machine, your system admins or
the vendor should have already installed a version of MPI, which is
likely to be faster than a self-installed MPICH or OpenMPI, so find
out how to build and link with it.
The majority of OpenMP (threading) support in LAMMPS is provided by
the USER-OMP package; see the "Speed omp"_Speed_omp.html doc page for
details. The USER-INTEL package also provides OpenMP support (it is
compatible with USER-OMP) and adds vectorization support when compiled
with the Intel compilers on top of that. Also, the KOKKOS package can
be compiled for using OpenMP threading.
However, there are a few commands in LAMMPS that have native OpenMP
support. These are commands in the MPIIO, SNAP, USER-DIFFRACTION, and
USER-DPD packages. In addition some packages support OpenMP threading
indirectly through the libraries they interface to: e.g. LATTE and
USER-COLVARS. See the "Packages details"_Packages_details.html doc
page for more info on these packages and the doc pages for their
respective commands for OpenMP threading info.
For CMake, if you use BUILD_OMP=yes, you can use these packages and
turn on their native OpenMP support and turn on their native OpenMP
support at run time, by setting the OMP_NUM_THREADS environment
variable before you launch LAMMPS.
For building via conventional make, the CCFLAGS and LINKFLAGS
variables in Makefile.machine need to include the compiler flag that
enables OpenMP. For GNU compilers it is -fopenmp. For (recent) Intel
compilers it is -qopenmp. If you are using a different compiler,
please refer to its documentation.
:line
Choice of compiler and compile/link options :h4,link(compile)
The choice of compiler and compiler flags can be important for
performance. Vendor compilers can produce faster code than
open-source compilers like GNU. On boxes with Intel CPUs, we suggest
trying the "Intel C++ compiler"_intel.
:link(intel,https://software.intel.com/en-us/intel-compilers)
On parallel clusters or supercomputers which use "modules" for their
compile/link environments, you can often access different compilers by
simply loading the appropriate module before building LAMMPS.
[CMake variables]:
-D CMAKE_CXX_COMPILER=name # name of C++ compiler
-D CMAKE_C_COMPILER=name # name of C compiler
-D CMAKE_Fortran_COMPILER=name # name of Fortran compiler :pre
-D CMAKE_CXX_FlAGS=string # flags to use with C++ compiler
-D CMAKE_C_FlAGS=string # flags to use with C compiler
-D CMAKE_Fortran_FlAGS=string # flags to use with Fortran compiler :pre
By default CMake will use a compiler it finds and it will add
optimization flags appropriate to that compiler and any "accelerator
packages"_Speed_packages.html you have included in the build.
You can tell CMake to look for a specific compiler with these variable
settings. Likewise you can specify the FLAGS variables if you want to
experiment with alternate optimization flags. You should specify all
3 compilers, so that the small number of LAMMPS source files written
in C or Fortran are built with a compiler consistent with the one used
for all the C++ files:
Building with GNU Compilers:
cmake ../cmake -DCMAKE_C_COMPILER=gcc -DCMAKE_CXX_COMPILER=g++ -DCMAKE_Fortran_COMPILER=gfortran
Building with Intel Compilers:
cmake ../cmake -DCMAKE_C_COMPILER=icc -DCMAKE_CXX_COMPILER=icpc -DCMAKE_Fortran_COMPILER=ifort
Building with LLVM/Clang Compilers:
cmake ../cmake -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_Fortran_COMPILER=flang :pre
NOTE: When the cmake command completes, it prints info to the screen
as to which compilers it is using, and what flags will be used in the
compilation. Note that if the top-level compiler is mpicxx, it is
simply a wrapper on a real compiler. The underlying compiler info is
what will be listed in the CMake output. You should check to insure
you are using the compiler and optimization flags are the ones you
want.
[Makefile.machine settings]:
Parallel build (see src/MAKE/Makefile.mpi):
CC = mpicxx
CCFLAGS = -g -O3
LINK = mpicxx
LINKFLAGS = -g -O :pre
Serial build (see src/MAKE/Makefile.serial):
CC = g++
CCFLAGS = -g -O3
LINK = g++
LINKFLAGS = -g -O :pre
The "compiler/linker settings" section of a Makefile.machine lists
compiler and linker settings for your C++ compiler, including
optimization flags. You should always use mpicxx or mpiCC for
a parallel build, since these compiler wrappers will include
a variety of settings appropriate for your MPI installation.
NOTE: If you build LAMMPS with any "accelerator
packages"_Speed_packages.html included, they have specific
optimization flags that are either required or recommended for optimal
performance. You need to include these in the CCFLAGS and LINKFLAGS
settings above. For details, see the individual package doc pages
listed on the "Speed packages"_Speed_packages.html doc page. Or
examine these files in the src/MAKE/OPTIONS directory. They
correspond to each of the 5 accelerator packages and their hardware
variants:
Makefile.opt # OPT package
Makefile.omp # USER-OMP package
Makefile.intel_cpu # USER-INTEL package for CPUs
Makefile.intel_coprocessor # USER-INTEL package for KNLs
Makefile.gpu # GPU package
Makefile.kokkos_cuda_mpi # KOKKOS package for GPUs
Makefile.kokkos_omp # KOKKOS package for CPUs (OpenMP)
Makefile.kokkos_phi # KOKKOS package for KNLs (OpenMP) :pre
:line
Build LAMMPS as an executable or a library :h4,link(exe)
LAMMPS can be built as either an executable or as a static or shared
library. The LAMMPS library can be called from another application or
a scripting language. See the "Howto couple"_Howto_couple.html doc
page for more info on coupling LAMMPS to other codes. See the
"Python"_Python_head.html doc page for more info on wrapping and
running LAMMPS from Python via its library interface.
[CMake variables]:
-D BUILD_EXE=value # yes (default) or no
-D BUILD_LIB=value # yes or no (default)
-D BUILD_SHARED_LIBS=value # yes or no (default) :pre
Setting BUILD_EXE=no will not produce an executable. Setting
BUILD_LIB=yes will produce a static library named liblammps.a.
Setting both BUILD_LIB=yes and BUILD_SHARED_LIBS=yes will produce a
shared library named liblammps.so.
[Traditional make]:
cd lammps/src
make machine # build LAMMPS executable lmp_machine
make mode=lib machine # build LAMMPS static lib liblammps_machine.a
make mode=shlib machine # build LAMMPS shared lib liblammps_machine.so :pre
The two library builds also create generic soft links, named
liblammps.a and liblammps.so, which point to the liblammps_machine
files.
[CMake and make info]:
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
libraries. This will be the case for libraries included with LAMMPS,
such as the dummy MPI library in src/STUBS or any package libraries in
the lib/packages directory, since they are always built as shared
libraries using the -fPIC switch. However, if a library like MPI or
FFTW does not exist as a shared library, the shared library build will
generate an error. This means you will need to install a shared
library version of the auxiliary library. The build instructions for
the library should tell you how to do this.
As an example, here is how to build and install the "MPICH
library"_mpich, a popular open-source version of MPI, distributed by
Argonne National Lab, as a shared library in the default
/usr/local/lib location:
:link(mpich,http://www-unix.mcs.anl.gov/mpi)
./configure --enable-shared
make
make install :pre
You may need to use "sudo make install" in place of the last line if
you do not have write privileges for /usr/local/lib. The end result
should be the file /usr/local/lib/libmpich.so.
:line
Build the LAMMPS documentation :h4,link(doc)
[CMake variable]:
-D BUILD_DOC=value # yes or no (default) :pre
This will create the HTML doc pages within the CMake build directory.
The reason to do this is if you want to "install" LAMMPS on a system
after the CMake build via "make install", and include the doc pages in
the install.
[Traditional make]:
cd lammps/doc
make html # html doc pages
make pdf # single Manual.pdf file :pre
This will create a lammps/doc/html dir with the HTML doc pages so that
you can browse them locally on your system. Type "make" from the
lammps/doc dir to see other options.
NOTE: You can also download a tarball of the documention for the
current LAMMPS version (HTML and PDF files), from the website
"download page"_http://lammps.sandia.gov/download.html.
:line
Install LAMMPS after a build :h4,link(install)
After building LAMMPS, you may wish to copy the LAMMPS executable of
library, along with other LAMMPS files (library header, doc files) to
a globally visible place on your system, for others to access. Note
that you may need super-user privileges (e.g. sudo) if the directory
you want to copy files to is protected.
[CMake variable]:
cmake -D CMAKE_INSTALL_PREFIX=path \[options ...\] ../cmake
make # perform make after CMake command
make install # perform the installation into prefix :pre
[Traditional make]:
There is no "install" option in the src/Makefile for LAMMPS. If you
wish to do this you will need to first build LAMMPS, then manually
copy the desired LAMMPS files to the appropriate system directories.

196
doc/src/Build_cmake.txt Normal file
View File

@ -0,0 +1,196 @@
"Higher level section"_Build.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
Build LAMMPS with CMake :h3
This page is a short summary of how to use CMake to build LAMMPS.
Details on CMake variables that enable specific LAMMPS build options
are given on the pages linked to from the "Build"_Build.html doc page.
Richard Berger (Temple U) has also written a "more comprehensive
guide"_https://github.com/lammps/lammps/blob/master/cmake/README.md
for how to use CMake to build LAMMPS. If you are new to CMake it is a
good place to start.
:line
Building LAMMPS with CMake is a two-step process. First you use CMake
to create a build environment in a new directory. On Linux systems,
this will be based on makefiles for use with make. Then you use the
make command to build LAMMPS, which uses the created
Makefile(s). Example:
cd lammps # change to the LAMMPS distribution directory
mkdir build; cd build # create a new directory (folder) for build
cmake ../cmake \[options ...\] # configuration with (command-line) cmake
make # compilation :pre
The cmake command will detect available features, enable selected
packages and options, and will generate the build environment. The make
command will then compile and link LAMMPS, producing (by default) an
executable called "lmp" and a library called "liblammps.a" in the
"build" folder.
If your machine has multiple CPU cores (most do these days), using a
command like "make -jN" (with N being the number of available local
CPU cores) can be much faster. If you plan to do development on
LAMMPS or need to re-compile LAMMPS repeatedly, installation of the
ccache (= Compiler Cache) software may speed up compilation even more.
After compilation, you can optionally copy the LAMMPS executable and
library into your system folders (by default under /usr/local) with:
make install # optional, copy LAMMPS executable & library elsewhere :pre
:line
There are 3 variants of CMake: a command-line version (cmake), a text mode
UI version (ccmake), and a graphical GUI version (cmake-GUI). You can use
any of them interchangeably to configure and create the LAMMPS build
environment. On Linux all the versions produce a Makefile as their
output. See more details on each below.
You can specify a variety of options with any of the 3 versions, which
affect how the build is performed and what is included in the LAMMPS
executable. Links to pages explaining all the options are listed on
the "Build"_Build.html doc page.
You must perform the CMake build system generation and compilation in
a new directory you create. It can be anywhere on your local machine.
In these Build pages we assume that you are building in a directory
called "lammps/build". You can perform separate builds independently
with different options, so long as you perform each of them in a
separate directory you create. All the auxiliary files created by one
build process (executable, object files, log files, etc) are stored in
this directory or sub-directories within it that CMake creates.
NOTE: To perform a CMake build, no packages can be installed or a
build been previously attempted in the LAMMPS src directory by using
"make" commands to "perform a conventional LAMMPS
build"_Build_make.html. CMake detects if this is the case and
generates an error, telling you to type "make no-all purge" in the src
directory to un-install all packages. The purge removes all the *.h
files auto-generated by make.
You must have CMake version 2.8 or later on your system to build
LAMMPS. A handful of LAMMPS packages (KOKKOS, LATTE, MSCG) require a
later version. CMake will print a message telling you if a later
version is required. Installation instructions for CMake are below.
After the initial build, if you edit LAMMPS source files, or add your
own new files to the source directory, you can just re-type make from
your build directory and it will re-compile only the files that have
changed. If you want to change CMake options you can run cmake (or
ccmake or cmake-gui) again from the same build directory and alter
various options; see details below. Or you can remove the entire build
folder, recreate the directory and start over.
:line
[Command-line version of CMake]:
cmake \[options ...\] /path/to/lammps/cmake # build from any dir
cmake \[options ...\] ../cmake # build from lammps/build :pre
The cmake command takes one required argument, which is the LAMMPS
cmake directory which contains the CMakeLists.txt file.
The argument can be preceeded or followed by various CMake
command-line options. Several useful ones are:
-D CMAKE_INSTALL_PREFIX=path # where to install LAMMPS executable/lib if desired
-D CMAKE_BUILD_TYPE=type # type = Release or Debug
-G output # style of output CMake generates
-DVARIABLE=value # setting for a LAMMPS feature to enable
-D VARIABLE=value # ditto, but cannot come after CMakeLists.txt dir :pre
All the LAMMPS-specific -D variables that a LAMMPS build supports are
described on the pages linked to from the "Build"_Build.html doc page.
All of these variable names are upper-case and their values are
lower-case, e.g. -D LAMMPS_SIZES=smallbig. For boolean values, any of
these forms can be used: yes/no, on/off, 1/0.
On Unix/Linux machines, CMake generates a Makefile by default to
perform the LAMMPS build. Alternate forms of build info can be
generated via the -G switch, e.g. Visual Studio on a Windows machine,
Xcode on MacOS, or KDevelop on Linux. Type "cmake --help" to see the
"Generator" styles of output your system supports.
NOTE: When CMake runs, it prints configuration info to the screen.
You should review this to verify all the features you requested were
enabled, including packages. You can also see what compilers and
compile options will be used for the build. Any errors in CMake
variable syntax will also be flagged, e.g. mis-typed variable names or
variable values.
CMake creates a CMakeCache.txt file when it runs. This stores all the
settings, so that when running CMake again you can use the current
folder '.' instead of the path to the LAMMPS cmake folder as the
required argument to the CMake command. Either way the existing
settings will be inherited unless the CMakeCache.txt file is removed.
If you later want to change a setting you can rerun cmake in the build
directory with different setting. Please note that some automatically
detected variables will not change their value when you rerun cmake.
In these cases it is usually better to first remove all the
files/directories in the build directory, or start with a fresh build
directory.
:line
[Curses version (terminal-style menu) of CMake]:
ccmake ../cmake :pre
You initiate the configuration and build environment generation steps
separately. For the first you have to type [c], for the second you
have to type [g]. You may need to type [c] multiple times, and may be
required to edit some of the entries of CMake configuration variables
in between. Please see the "ccmake
manual"_https://cmake.org/cmake/help/latest/manual/ccmake.1.html for
more information.
:line
[GUI version of CMake]:
cmake-gui ../cmake :pre
You initiate the configuration and build environment generation steps
separately. For the first you have to click on the [Configure] button,
for the second you have to click on the [Generate] button. You may
need to click on [Configure] multiple times, and may be required to
edit some of the entries of CMake configuration variables in between.
Please see the "cmake-gui
manual"_https://cmake.org/cmake/help/latest/manual/cmake-gui.1.html
for more information.
:line
[Installing CMake]
Check if your machine already has CMake installed:
which cmake # do you have it?
which cmake3 # version 3 may have this name
cmake --version # what specific version you have :pre
On clusters or supercomputers which use environment modules to manage
software packages, do this:
module list # is a cmake module already loaded?
module avail # is a cmake module available?
module load cmake3 # load cmake module with appropriate name :pre
Most Linux distributions offer pre-compiled cmake packages through
their package management system. If you do not have CMake or a new
enough version, you can download the latest version at
"https://cmake.org/download/"_https://cmake.org/download/.
Instructions on how to install it on various platforms can be found
"on this page"_https://cmake.org/install/.

1026
doc/src/Build_extras.txt Normal file
View File

File diff suppressed because it is too large Load Diff

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

@ -0,0 +1,85 @@
"Higher level section"_Build.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
Link LAMMPS as a library to another code :h3
LAMMPS can be used as a library by another application, including
Python scripts. The files src/library.cpp and library.h define the
C-style API for using LAMMPS as a library. See the "Howto
library"_Howto_library.html doc page for a description of the
interface and how to extend it for your needs.
The "Build basics"_Build_basics.html doc page explains how to build
LAMMPS as either a shared or static library. This results in one of
these 2 files:
liblammps.so # shared library
liblammps.a # static library
:line
[Link with LAMMPS as a static library]:
The calling application can link to LAMMPS as a static library with a
link command like this:
g++ caller.o -L/home/sjplimp/lammps/src -llammps -o caller
The -L argument is the path to where the liblammps.a file is. The
-llammps argument is shorthand for the file liblammps.a.
:line
[Link with LAMMPS as a shared library]:
If you wish to link to liblammps.so, the operating system finds shared
libraries to load at run-time using the environment variable
LD_LIBRARY_PATH. To enable this you can do one of two things:
(1) Copy the liblammps.so file to a location the system can find it,
such as /usr/local/lib. I.e. a directory already listed in your
LD_LIBRARY_PATH variable. You can type
printenv LD_LIBRARY_PATH :pre
to see what directories are in that list.
(2) Add the LAMMPS src directory (or the directory you perform CMake
build in) to your LD_LIBRARY_PATH, so that the current version of the
shared library is always available to programs that use it.
For the csh or tcsh shells, you would add something like this to your
~/.cshrc file:
setenv LD_LIBRARY_PATH $\{LD_LIBRARY_PATH\}:/home/sjplimp/lammps/src :pre
:line
[Calling the LAMMPS library]:
Either flavor of library (static or shared) allows one or more LAMMPS
objects to be instantiated from the calling program.
When used from a C++ program, all of LAMMPS is wrapped in a LAMMPS_NS
namespace; you can safely use any of its classes and methods from
within the calling code, as needed.
When used from a C or Fortran program, the library has a simple
C-style interface, provided in src/library.cpp and src/library.h.
See the "Python library"_Python_library.html doc page for a
description of the Python interface to LAMMPS, which wraps the C-style
interface.
See the sample codes in examples/COUPLE/simple for examples of C++ and
C and Fortran codes that invoke LAMMPS thru its library interface.
Other examples in the COUPLE directory use coupling ideas discussed on
the "Howto couple"_Howto_couple.html doc page.

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

@ -0,0 +1,85 @@
"Higher level section"_Build.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
Build LAMMPS with make :h3
Building LAMMPS with traditional makefiles requires that you have a
Makefile."machine" file appropriate for your system in the src/MAKE,
src/MAKE/MACHINES, src/MAKE/OPTIONS, or src/MAKE/MINE directory (see
below). It can include various options for customizing your LAMMPS
build with a number of global compilation options and features.
To include LAMMPS packages (i.e. optional commands and styles) you
must install them first, as discussed on the "Build
package"_Build_package.html doc page. If the packages require
provided or external libraries, you must build those libraries before
building LAMMPS. Building "LAMMPS with CMake"_Build_cmake.html can
automate all of this for many types of machines, especially
workstations, desktops and laptops, so we suggest you try it first.
These commands perform a default LAMMPS build, producing the LAMMPS
executable lmp_serial or lmp_mpi in lammps/src:
cd lammps/src
make serial # build a serial LAMMPS executable
make mpi # build a parallel LAMMPS executable with MPI
make # see a variety of make options :pre
This initial compilation can take a long time, since LAMMPS is a large
project with many features. If your machine has multiple CPU cores
(most do these days), using a command like "make -jN mpi" (with N =
the number of available CPU cores) can be much faster. If you plan to
do development on LAMMPS or need to re-compile LAMMPS repeatedly, the
installation of the ccache (= Compiler Cache) software may speed up
compilation even more.
After the initial build, whenever you edit LAMMPS source files, or add
or remove new files to the source directory (e.g. by installing or
uninstalling packages), you must re-compile and relink the LAMMPS
executable with the same "make" command. This makefiles dependencies
should insure that only the subset of files that need to be are
re-compiled.
NOTE: When you build LAMMPS for the first time, a long list of *.d
files will be printed out rapidly. This is not an error; it is the
Makefile doing its normal creation of dependencies.
:line
The lammps/src/MAKE tree contains all the Makefile.machine files
included in the LAMMPS distribution. Typing "make machine" uses
Makefile.machine. Thus the "make serial" or "make mpi" lines above
use Makefile.serial and Makefile.mpi. Others are in these dirs:
OPTIONS # Makefiles which enable specific options
MACHINES # Makefiles for specific machines
MINE # customized Makefiles you create (you may need to create this folder) :pre
Typing "make" lists all the available Makefile.machine files. A file
with the same name can appear in multiple folders (not a good idea).
The order the dirs are searched is as follows: src/MAKE/MINE,
src/MAKE, src/MAKE/OPTIONS, src/MAKE/MACHINES. This gives preference
to a customized file you put in src/MAKE/MINE.
Makefiles you may wish to try include these (some require a package
first be installed). Many of these include specific compiler flags
for optimized performance. Please note, however, that some of these
customized machine Makefile are contributed by users. Since both
compilers, OS configurations, and LAMMPS itself keep changing, their
settings may become outdated:
make mac # build serial LAMMPS on a Mac
make mac_mpi # build parallel LAMMPS on a Mac
make intel_cpu # build with the USER-INTEL package optimized for CPUs
make knl # build with the USER-INTEL package optimized for KNLs
make opt # build with the OPT package optimized for CPUs
make omp # build with the USER-OMP package optimized for OpenMP
make kokkos_omp # build with the KOKKOS package for OpenMP
make kokkos_cuda_mpi # build with the KOKKOS package for GPUs
make kokkos_phi # build with the KOKKOS package for KNLs :pre

225
doc/src/Build_package.txt Normal file
View File

@ -0,0 +1,225 @@
"Higher level section"_Build.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
Include packages in build :h3
In LAMMPS, a package is a group of files that enable a specific set of
features. For example, force fields for molecular systems or
rigid-body constraints are in packages. In the src directory, each
package is a sub-directory with the package name in capital letters.
An overview of packages is given on the "Packages"_Packages.html doc
page. Brief overviews of each package are on the "Packages
details"_Packages_details.html doc page.
When building LAMMPS, you can choose to include or exclude each
package. In general there is no need to include a package if you
never plan to use its features.
If you get a run-time error that a LAMMPS command or style is
"Unknown", it is often because the command is contained in a package,
and your build did not include that package. Running LAMMPS with the
"-h command-line switch"_Run_options.html will print all the included
packages and commands for that executable.
For the majority of packages, if you follow the single step below to
include it, you can then build LAMMPS exactly the same as you would
without any packages installed. A few packages may require additional
steps, as explained on the "Build extras"_Build_extras.html doc page.
These links take you to the extra instructions for those select
packages:
"COMPRESS"_Build_extras.html#compress,
"GPU"_Build_extras.html#gpu,
"KIM"_Build_extras.html#kim,
"KOKKOS"_Build_extras.html#kokkos,
"LATTE"_Build_extras.html#latte,
"MEAM"_Build_extras.html#meam,
"MESSAGE"_Build_extras.html#message,
"MSCG"_Build_extras.html#mscg,
"OPT"_Build_extras.html#opt,
"POEMS"_Build_extras.html#poems,
"PYTHON"_Build_extras.html#python,
"REAX"_Build_extras.html#reax,
"VORONOI"_Build_extras.html#voronoi,
"USER-ATC"_Build_extras.html#user-atc,
"USER-AWPMD"_Build_extras.html#user-awpmd,
"USER-COLVARS"_Build_extras.html#user-colvars,
"USER-H5MD"_Build_extras.html#user-h5md,
"USER-INTEL"_Build_extras.html#user-intel,
"USER-MOLFILE"_Build_extras.html#user-molfile,
"USER-NETCDF"_Build_extras.html#user-netcdf,
"USER-OMP"_Build_extras.html#user-omp,
"USER-QMMM"_Build_extras.html#user-qmmm,
"USER-QUIP"_Build_extras.html#user-quip,
"USER-SCAFACOS"_Build_extras.html#user-scafacos,
"USER-SMD"_Build_extras.html#user-smd,
"USER-VTK"_Build_extras.html#user-vtk :tb(c=6,ea=c,a=l)
The mechanism for including packages is simple but different for CMake
versus make.
[CMake variables]:
-D PKG_NAME=value # yes or no (default) :pre
Examples:
-D PKG_MANYBODY=yes
-D PKG_USER-INTEL=yes :pre
All standard and user packages are included the same way. Note that
USER packages have a hyphen between USER and the rest of the package
name, not an underscore.
See the shortcut section below for how to install many packages at
once with CMake.
NOTE: If you toggle back and forth between building with CMake vs
make, no packages in the src directory can be installed when you
invoke cmake. CMake will give an error if that is not the case,
indicating how you can un-install all packages in the src dir.
[Traditional make]:
cd lammps/src
make ps # check which packages are currently installed
make yes-name # install a package with name
make no-name # un-install a package with name
make mpi # build LAMMPS with whatever packages are now installed :pre
Examples:
make no-rigid
make yes-user-intel :pre
All standard and user packages are included the same way.
See the shortcut section below for how to install many packages at
once with make.
NOTE: You must always re-build LAMMPS (via make) after installing or
un-installing a package, for the action to take effect.
NOTE: You cannot install or un-install packages and build LAMMPS in a
single make command with multiple targets, e.g. make yes-colloid mpi.
This is because the make procedure creates a list of source files that
will be out-of-date for the build if the package configuration changes
within the same command. You can include or exclude multiple packages
in a single make command, e.g. make yes-colloid no-manybody.
[CMake and make info]:
Any package can be included or excluded in a LAMMPS build, independent
of all other packages. However, some packages include files derived
from files in other packages. LAMMPS checks for this and does the
right thing. Individual files are only included if their dependencies
are already included. Likewise, if a package is excluded, other files
dependent on that package are also excluded.
When you download a LAMMPS tarball or download LAMMPS source files
from the Git or SVN repositories, no packages are pre-installed in the
src directory.
NOTE: Prior to Aug 2018, if you downloaded a tarball, 3 packages
(KSPACE, MANYBODY, MOLECULE) were pre-installed in the src directory.
That is no longer the case, so that CMake will build as-is without the
need to un-install those packages.
:line
[CMake shortcuts for installing many packages]:
Instead of specifying all the CMake options via the command-line,
CMake allows initializing the variable cache using script files. These
are regular CMake files which can manipulate and set variables, and
can also contain control flow constructs.
LAMMPS includes several of these files to define configuration
"presets", similar to the options that exist for the Make based
system. Using these files you can enable/disable portions of the
available packages in LAMMPS. If you need a custom preset you can take
one of them as a starting point and customize it to your needs.
cmake -C ../cmake/presets/all_on.cmake \[OPTIONS\] ../cmake | enable all packages
cmake -C ../cmake/presets/all_off.cmake \[OPTIONS\] ../cmake | disable all packages
cmake -C ../cmake/presets/std.cmake \[OPTIONS\] ../cmake | enable standard packages
cmake -C ../cmake/presets/user.cmake \[OPTIONS\] ../cmake | enable user packages
cmake -C ../cmake/presets/std_nolib.cmake \[OPTIONS\] ../cmake | enable standard packages that do not require extra libraries
cmake -C ../cmake/presets/nolib.cmake \[OPTIONS\] ../cmake | disable all packages that do not require extra libraries
cmake -C ../cmake/presets/manual_selection.cmake \[OPTIONS\] ../cmake | example of how to create a manual selection of packages :tb(s=|,a=l)
NOTE: Running cmake this way manipulates the variable cache in your
current build directory. You can combine presets and options with
multiple cmake runs.
[Example:]
# build LAMMPS with all "standard" packages which don't
# use libraries and enable GPU package
mkdir build
cd build
cmake -C ../cmake/presets/std_nolib.cmake -D PKG_GPU=on ../cmake :pre
:line
[Make shortcuts for installing many packages]:
The following commands are useful for managing package source files
and their installation when building LAMMPS via traditional make.
Just type "make" in lammps/src to see a one-line summary.
These commands install/un-install sets of packages:
make yes-all | install all packages
make no-all | un-install all packages
make yes-standard or make yes-std | install standard packages
make no-standard or make no-std| un-install standard packages
make yes-user | install user packages
make no-user | un-install user packages
make yes-lib | install packages that require extra libraries
make no-lib | un-install packages that require extra libraries
make yes-ext | install packages that require external libraries
make no-ext | un-install packages that require external libraries :tb(s=|,a=l)
which install/un-install various sets of packages. Typing "make
package" will list all the these commands.
NOTE: Installing or un-installing a package works by simply copying
files back and forth between the main src directory and
sub-directories with the package name (e.g. src/KSPACE, src/USER-ATC),
so that the files are included or excluded when LAMMPS is built.
The following make commands help manage files that exist in both the
src directory and in package sub-directories. You do not normally
need to use these commands unless you are editing LAMMPS files or are
"installing a patch"_Install_patch.html downloaded from the LAMMPS web
site.
Type "make package-status" or "make ps" to show which packages are
currently installed. For those that are installed, it will list any
files that are different in the src directory and package
sub-directory.
Type "make package-installed" or "make pi" to show which packages are
currently installed, without listing the status of packages that are
not installed.
Type "make package-update" or "make pu" to overwrite src files with
files from the package sub-directories if the package is installed.
It should be used after a "patch has been applied"_Install_patch.html,
since patches only update the files in the package sub-directory, but
not the src files.
Type "make package-overwrite" to overwrite files in the package
sub-directories with src files.
Type "make package-diff" to list all differences between pairs of
files in both the src dir and a package dir.

341
doc/src/Build_settings.txt Normal file
View File

@ -0,0 +1,341 @@
"Higher level section"_Build.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
Optional build settings :h3
LAMMPS can be built with several optional settings. Each sub-section
explain how to do this for building both with CMake and make.
"FFT library"_#fft for use with the "kspace_style pppm"_kspace_style.html command
"Size of LAMMPS data types"_#size
"Read or write compressed files"_#gzip
"Output of JPG and PNG files"_#graphics via the "dump image"_dump_image.html command
"Output of movie files"_#graphics via the "dump_movie"_dump_image.html command
"Memory allocation alignment"_#align
"Workaround for long long integers"_#longlong
"Error handling exceptions"_#exceptions when using LAMMPS as a library :all(b)
:line
FFT library :h4,link(fft)
When the KSPACE package is included in a LAMMPS build, the
"kspace_style pppm"_kspace_style.html command performs 3d FFTs which
require use of an FFT library to compute 1d FFTs. The KISS FFT
library is included with LAMMPS but other libraries can be faster.
LAMMPS can use them if they are available on your system.
[CMake variables]:
-D FFT=value # FFTW3 or MKL or KISS, default is FFTW3 if found, else KISS
-D FFT_SINGLE=value # yes or no (default), no = double precision
-D FFT_PACK=value # array (default) or pointer or memcpy :pre
NOTE: The values for the FFT variable must be in upper-case. This is
an exception to the rule that all CMake variables can be specified
with lower-case values.
Usually these settings are all that is needed. If CMake cannot find
the FFT library, you can set these variables:
-D FFTW3_INCLUDE_DIRS=path # path to FFTW3 include files
-D FFTW3_LIBRARIES=path # path to FFTW3 libraries
-D MKL_INCLUDE_DIRS=path # ditto for Intel MKL library
-D MKL_LIBRARIES=path :pre
[Makefile.machine settings]:
FFT_INC = -DFFT_FFTW3 # -DFFT_FFTW3, -DFFT_FFTW (same as -DFFT_FFTW3), -DFFT_MKL, or -DFFT_KISS
# default is KISS if not specified
FFT_INC = -DFFT_SINGLE # do not specify for double precision
FFT_INC = -DFFT_PACK_ARRAY # or -DFFT_PACK_POINTER or -DFFT_PACK_MEMCPY :pre
# default is FFT_PACK_ARRAY if not specified
FFT_INC = -I/usr/local/include
FFT_PATH = -L/usr/local/lib
FFT_LIB = -lfftw3 # FFTW3 double precision
FFT_LIB = -lfftw3 -lfftw3f # FFTW3 single precision
FFT_LIB = -lmkl_intel_lp64 -lmkl_sequential -lmkl_core # MKL with Intel compiler
FFT_LIB = -lmkl_gf_lp64 -lmkl_sequential -lmkl_core # MKL with GNU compier :pre
As with CMake, you do not need to set paths in FFT_INC or FFT_PATH, if
make can find the FFT header and library files. You must specify
FFT_LIB with the appropriate FFT libraries to include in the link.
[CMake and make info]:
The "KISS FFT library"_http://kissfft.sf.net is included in the LAMMPS
distribution. It is portable across all platforms. Depending on the
size of the FFTs and the number of processors used, the other
libraries listed here can be faster.
However, note that long-range Coulombics are only a portion of the
per-timestep CPU cost, FFTs are only a portion of long-range
Coulombics, and 1d FFTs are only a portion of the FFT cost (parallel
communication can be costly). A breakdown of these timings is printed
to the screen at the end of a run using the "kspace_style
pppm"_kspace_style.html command. The "Run output"_Run_output.html
doc page gives more details.
FFTW is a fast, portable FFT library that should also work on any
platform and can be faster than the KISS FFT library. You can
download it from "www.fftw.org"_http://www.fftw.org. LAMMPS requires
version 3.X; the legacy version 2.1.X is no longer supported.
Building FFTW for your box should be as simple as ./configure; make;
make install. The install command typically requires root privileges
(e.g. invoke it via sudo), unless you specify a local directory with
the "--prefix" option of configure. Type "./configure --help" to see
various options.
The Intel MKL math library is part of the Intel compiler suite. It
can be used with the Intel or GNU compiler (see FFT_LIB setting above).
Performing 3d FFTs in parallel can be time consuming due to data
access and required communication. This cost can be reduced by
performing single-precision FFTs instead of double precision. Single
precision means the real and imaginary parts of a complex datum are
4-byte floats. Double precision means they are 8-byte doubles. Note
that Fourier transform and related PPPM operations are somewhat less
sensitive to floating point truncation errors and thus the resulting
error is less than the difference in precision. Using the -DFFT_SINGLE
setting trades off a little accuracy for reduced memory use and
parallel communication costs for transposing 3d FFT data.
When using -DFFT_SINGLE with FFTW3 you may need to build the FFTW
library a second time with support for single-precision.
For FFTW3, do the following, which should produce the additional
library libfftw3f.a
make clean
./configure --enable-single; make; make install :pre
Performing 3d FFTs requires communication to transpose the 3d FFT
grid. The data packing/unpacking for this can be done in one of 3
modes (ARRAY, POINTER, MEMCPY) as set by the FFT_PACK syntax above.
Depending on the machine, the size of the FFT grid, the number of
processors used, one option may be slightly faster. The default is
ARRAY mode.
:line
Size of LAMMPS data types :h4,link(size)
LAMMPS has a few integer data types which can be defined as 4-byte or
8-byte integers. The default setting of "smallbig" is almost always
adequate.
[CMake variable]:
-D LAMMPS_SIZES=value # smallbig (default) or bigbig or smallsmall :pre
[Makefile.machine setting]:
LMP_INC = -DLAMMPS_SMALLBIG # or -DLAMMPS_BIGBIG or -DLAMMPS_SMALLSMALL :pre
# default is LAMMMPS_SMALLBIG if not specified
[CMake and make info]:
The default "smallbig" setting allows for simulations with:
total atom count = 2^63 atoms (about 9e18)
total timesteps = 2^63 (about 9e18)
atom IDs = 2^31 (about 2 billion)
image flags = roll over at 512 :ul
The "bigbig" setting increases the latter two limits. It allows for:
total atom count = 2^63 atoms (about 9e18)
total timesteps = 2^63 (about 9e18)
atom IDs = 2^63 (about 9e18)
image flags = roll over at about 1 million (2^20) :ul
The "smallsmall" setting is only needed if your machine does not
support 8-byte integers. It allows for:
total atom count = 2^31 atoms (about 2 billion)
total timesteps = 2^31 (about 2 billion)
atom IDs = 2^31 (about 2 billion)
image flags = roll over at 512 (2^9) :ul
Atom IDs are not required for atomic systems which do not store bond
topology information, though IDs are enabled by default. The
"atom_modify id no"_atom_modify.html command will turn them off. Atom
IDs are required for molecular systems with bond topology (bonds,
angles, dihedrals, etc). Thus if you model a molecular system with
more than 2 billion atoms, you need the "bigbig" setting.
Image flags store 3 values per atom which count the number of times an
atom has moved through the periodic box in each dimension. See the
"dump"_dump.html doc page for a discussion. If an atom moves through
the periodic box more than this limit, the value will "roll over",
e.g. from 511 to -512, which can cause diagnostics like the
mean-squared displacement, as calculated by the "compute
msd"_compute_msd.html command, to be faulty.
Note that the USER-ATC package is not currently compatible with the
"bigbig" setting.
Also note that the GPU package requires its lib/gpu library to be
compiled with the same size setting, or the link will fail. A CMake
build does this automatically. When building with make, the setting
in whichever lib/gpu/Makefile is used must be the same as above.
:line
Output of JPG, PNG, and movie files :h4,link(graphics)
The "dump image"_dump_image.html command has options to output JPEG or
PNG image files. Likewise the "dump movie"_dump_image.html command
outputs movie files in MPEG format. Using these options requires the
following settings:
[CMake variables]:
-D WITH_JPEG=value # yes or no
# default = yes if CMake finds JPEG files, else no
-D WITH_PNG=value # yes or no
# default = yes if CMake finds PNG and ZLIB files, else no
-D WITH_FFMPEG=value # yes or no
# default = yes if CMake can find ffmpeg, else no :pre
Usually these settings are all that is needed. If CMake cannot find
the graphics header, library, executable files, you can set these
variables:
-D JPEG_INCLUDE_DIR=path # path to jpeglib.h header file
-D JPEG_LIBRARIES=path # path to libjpeg.a (.so) file
-D PNG_INCLUDE_DIR=path # path to png.h header file
-D PNG_LIBRARIES=path # path to libpng.a (.so) file
-D ZLIB_INCLUDE_DIR=path # path to zlib.h header file
-D ZLIB_LIBRARIES=path # path to libz.a (.so) file
-D FFMPEG_EXECUTABLE=path # path to ffmpeg executable :pre
[Makefile.machine settings]:
LMP_INC = -DLAMMPS_JPEG
LMP_INC = -DLAMMPS_PNG
LMP_INC = -DLAMMPS_FFMPEG :pre
JPG_INC = -I/usr/local/include # path to jpeglib.h, png.h, zlib.h header files if make cannot find them
JPG_PATH = -L/usr/lib # paths to libjpeg.a, libpng.a, libz.a (.so) files if make cannot find them
JPG_LIB = -ljpeg -lpng -lz # library names :pre
As with CMake, you do not need to set JPG_INC or JPG_PATH, if make can
find the graphics header and library files. You must specify JPG_LIB
with a list of graphics libraries to include in the link. You must
insure ffmpeg is in a directory where LAMMPS can find it at runtime,
i.e. a dir in your PATH environment variable.
[CMake and make info]:
Using ffmpeg to output movie files requires that your machine
supports the "popen" function in the standard runtime library.
NOTE: On some clusters with high-speed networks, using the fork()
library calls (required by popen()) can interfere with the fast
communication library and lead to simulations using ffmpeg to hang or
crash.
:line
Read or write compressed files :h4,link(gzip)
If this option is enabled, large files can be read or written with
gzip compression by several LAMMPS commands, including
"read_data"_read_data.html, "rerun"_rerun.html, and "dump"_dump.html.
[CMake variables]:
-D WITH_GZIP=value # yes or no
# default is yes if CMake can find gzip, else no
-D GZIP_EXECUTABLE=path # path to gzip executable if CMake cannot find it :pre
[Makefile.machine setting]:
LMP_INC = -DLAMMPS_GZIP :pre
[CMake and make info]:
This option requires that your machine supports the "popen()" function
in the standard runtime library and that a gzip executable can be
found by LAMMPS during a run.
NOTE: On some clusters with high-speed networks, using the fork()
library calls (required by popen()) can interfere with the fast
communication library and lead to simulations using compressed output
or input to hang or crash. For selected operations, compressed file
I/O is also available using a compression library instead, which is
what the "COMPRESS package"_Packages_details.html#PKG-COMPRESS enables.
:line
Memory allocation alignment :h4,link(align)
This setting enables the use of the posix_memalign() call instead of
malloc() when LAMMPS allocates large chunks or memory. This can make
vector instructions on CPUs more efficient, if dynamically allocated
memory is aligned on larger-than-default byte boundaries.
On most current systems, the malloc() implementation returns
pointers that are aligned to 16-byte boundaries. Using SSE vector
instructions efficiently, however, requires memory blocks being
aligned on 64-byte boundaries.
[CMake variable]:
-D LAMMPS_MEMALIGN=value # 0, 8, 16, 32, 64 (default) :pre
Use a LAMMPS_MEMALIGN value of 0 to disable using posix_memalign()
and revert to using the malloc() C-library function instead. When
compiling LAMMPS for Windows systems, malloc() will always be used
and this setting ignored.
[Makefile.machine setting]:
LMP_INC = -DLAMMPS_MEMALIGN=value # 8, 16, 32, 64 :pre
Do not set -DLAMMPS_MEMALIGN, if you want to have memory allocated
with the malloc() function call instead. -DLAMMPS_MEMALIGN [cannot]
be used on Windows, as it does use different function calls for
allocating aligned memory, that are not compatible with how LAMMPS
manages its dynamical memory.
:line
Workaround for long long integers :h4,link(longlong)
If your system or MPI version does not recognize "long long" data
types, the following setting will be needed. It converts "long long"
to a "long" data type, which should be the desired 8-byte integer on
those systems:
[CMake variable]:
-D LAMMPS_LONGLONG_TO_LONG=value # yes or no (default) :pre
[Makefile.machine setting]:
LMP_INC = -DLAMMPS_LONGLONG_TO_LONG :pre
:line
Exception handling when using LAMMPS as a library :h4,link(exceptions)
This setting is useful when external codes drive LAMMPS as a library.
With this option enabled LAMMPS errors do not kill the caller.
Instead, the call stack is unwound and control returns to the caller,
e.g. to Python.
[CMake variable]:
-D LAMMPS_EXCEPTIONS=value # yes or no (default) :pre
[Makefile.machine setting]:
LMP_INC = -DLAMMPS_EXCEPTIONS :pre

97
doc/src/Build_windows.txt Normal file
View File

@ -0,0 +1,97 @@
"Higher level section"_Build.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
Notes for building LAMMPS on Windows :h3
"General remarks"_#generic
"Running Linux on Windows"_#linux
"Using GNU GCC ported to Windows"_#gnu
"Using a cross-compiler"_#cross :ul
:line
General remarks :h4,link(generic)
LAMMPS is developed and tested primarily on Linux machines. The vast
majority of HPC clusters and supercomputers today runs on Linux as well.
Thus portability to other platforms is desired, but not always achieved.
The LAMMPS developers strongly rely on LAMMPS users giving feedback and
providing assistance in resolving portability issues. This particularly
true for compiling LAMMPS on Windows, since this platform has significant
differences with some low-level functionality.
Running Linux on Windows :h4,link(linux)
So before trying to build LAMMPS on Windows, please consider if using
the pre-compiled Windows binary packages are sufficient for your needs
(as an aside, those packages themselves are build on a Linux machine
using cross-compilers). If it is necessary for your to compile LAMMPS
on a Windows machine (e.g. because it is your main desktop), please also
consider using a virtual machine software and run a Linux virtual machine,
or - if have a recently updated Windows 10 installation - consider using
the Windows subsystem for Linux, which allows to run a bash shell from
Ubuntu and from there on, you can pretty much use that shell like you
are running on an Ubuntu Linux machine (e.g. installing software via
apt-get). For more details on that, please see "this tutorial"_Howto_bash.html
Using GNU GCC ported to Windows :h4,link(gnu)
One option for compiling LAMMPS on Windows natively, that has been known
to work in the past is to install a bash shell, unix shell utilities,
perl, GNU make, and a GNU compiler ported to Windows. The Cygwin package
provides a unix/linux interface to low-level Windows functions, so LAMMPS
can be compiled on Windows. The necessary (minor) modifications to LAMMPS
are included, but may not always up-to-date for recently added functionality
and the corresponding new code. A machine makefile for using cygwin for
the old build system is provided. The CMake build system is untested
for this; you will have to request that makefiles are generated and
manually set the compiler.
When compiling for Windows [not] set the -DLAMMPS_MEMALIGN define
in the LMP_INC makefile variable and add -lwsock32 -lpsapi to the linker
flags in LIB makefile variable. Try adding -static-libgcc or -static or
both to the linker flags when your resulting LAMMPS Windows executable
complains about missing .dll files. The CMake configuration should set
this up automatically, but is untested.
In case of problems, you are recommended to contact somebody with
experience in using cygwin. If you do come across portability problems
requiring changes to the LAMMPS source code, or figure out corrections
yourself, please report them on the lammps-users mailing list, or file
them as an issue or pull request on the LAMMPS github project.
Using a cross-compiler :h4,link(cross)
If you need to provide custom LAMMPS binaries for Windows, but do not
need to do the compilation on Windows, please consider using a Linux
to Windows cross-compiler. This is how currently the Windows binary
packages are created by the LAMMPS developers. Because of that, this is
probably the currently best tested and supported way to build LAMMPS
executables for Windows. There are makefiles provided for the
traditional build system, but CMake has also been successfully tested
using the mingw32-cmake and mingw64-cmake wrappers that are bundled
with the cross-compiler environment on Fedora machines.
Please keep in mind, though, that this only applies to compiling LAMMPS.
Whether the resulting binaries do work correctly is no tested by the
LAMMPS developers. We instead rely on the feedback of the users
of these pre-compiled LAMMPS packages for Windows. We will try to resolve
issues to the best of our abilities if we become aware of them. However
this is subject to time constraints and focus on HPC platforms.
Native Visual C++ support :h4,link(native)
Support for the Visual C++ compilers is currently not available. The
CMake build system is capable of creating suitable a Visual Studio
style build environment, but the LAMMPS code itself is not fully ported
to support Visual C++. Volunteers to take on this task are welcome.

53
doc/src/Commands.txt Normal file
View File

@ -0,0 +1,53 @@
"Previous Section"_Run_head.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)
:link(lc,Commands_all.html#comm)
:line
Commands :h2
These pages describe how a LAMMPS input script is formatted and the
commands in it are used to define a LAMMPS simulation.
<!-- RST
.. toctree::
:maxdepth: 1
Commands_input
Commands_parse
Commands_structure
Commands_category
.. toctree::
:maxdepth: 1
Commands_all
Commands_fix
Commands_compute
Commands_pair
Commands_bond
Commands_kspace
END_RST -->
<!-- HTML_ONLY -->
"LAMMPS input scripts"_Commands_input.html
"Parsing rules for input scripts"_Commands_parse.html
"Input script structure"_Commands_structure.html
"Commands by category"_Commands_category.html :all(b)
"All commands"_Commands_all.html
"Fix commands"_Commands_fix.html
"Compute commands"_Commands_compute.html
"Pair commands"_Commands_pair.html
"Bond, angle, dihedral, improper commands"_Commands_bond.html
"KSpace solvers"_Commands_kspace.html :all(b)
<!-- END_HTML_ONLY -->

130
doc/src/Commands_all.txt Normal file
View File

@ -0,0 +1,130 @@
"Higher level section"_Commands.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
"All commands"_Commands_all.html,
"Fix styles"_Commands_fix.html,
"Compute styles"_Commands_compute.html,
"Pair styles"_Commands_pair.html,
"Bond styles"_Commands_bond.html,
"Angle styles"_Commands_bond.html#angle,
"Dihedral styles"_Commands_bond.html#dihedral,
"Improper styles"_Commands_bond.html#improper,
"KSpace styles"_Commands_kspace.html :tb(c=3,ea=c)
All commands :h3
An alphabetic list of all LAMMPS commands.
"angle_coeff"_angle_coeff.html,
"angle_style"_angle_style.html,
"atom_modify"_atom_modify.html,
"atom_style"_atom_style.html,
"balance"_balance.html,
"bond_coeff"_bond_coeff.html,
"bond_style"_bond_style.html,
"bond_write"_bond_write.html,
"boundary"_boundary.html,
"box"_box.html,
"change_box"_change_box.html,
"clear"_clear.html,
"comm_modify"_comm_modify.html,
"comm_style"_comm_style.html,
"compute"_compute.html,
"compute_modify"_compute_modify.html,
"create_atoms"_create_atoms.html,
"create_bonds"_create_bonds.html,
"create_box"_create_box.html,
"delete_atoms"_delete_atoms.html,
"delete_bonds"_delete_bonds.html,
"dielectric"_dielectric.html,
"dihedral_coeff"_dihedral_coeff.html,
"dihedral_style"_dihedral_style.html,
"dimension"_dimension.html,
"displace_atoms"_displace_atoms.html,
"dump"_dump.html,
"dump image"_dump_image.html,
"dump_modify"_dump_modify.html,
"dump movie"_dump_image.html,
"dump netcdf"_dump_netcdf.html,
"dump netcdf/mpiio"_dump_netcdf.html,
"dump vtk"_dump_vtk.html,
"echo"_echo.html,
"fix"_fix.html,
"fix_modify"_fix_modify.html,
"group"_group.html,
"group2ndx"_group2ndx.html,
"if"_if.html,
"info"_info.html,
"improper_coeff"_improper_coeff.html,
"improper_style"_improper_style.html,
"include"_include.html,
"jump"_jump.html,
"kspace_modify"_kspace_modify.html,
"kspace_style"_kspace_style.html,
"label"_label.html,
"lattice"_lattice.html,
"log"_log.html,
"mass"_mass.html,
"message"_message.html,
"minimize"_minimize.html,
"min_modify"_min_modify.html,
"min_style"_min_style.html,
"molecule"_molecule.html,
"ndx2group"_group2ndx.html,
"neb"_neb.html,
"neigh_modify"_neigh_modify.html,
"neighbor"_neighbor.html,
"newton"_newton.html,
"next"_next.html,
"package"_package.html,
"pair_coeff"_pair_coeff.html,
"pair_modify"_pair_modify.html,
"pair_style"_pair_style.html,
"pair_write"_pair_write.html,
"partition"_partition.html,
"prd"_prd.html,
"print"_print.html,
"processors"_processors.html,
"python"_python.html,
"quit"_quit.html,
"read_data"_read_data.html,
"read_dump"_read_dump.html,
"read_restart"_read_restart.html,
"region"_region.html,
"replicate"_replicate.html,
"rerun"_rerun.html,
"reset_ids"_reset_ids.html,
"reset_timestep"_reset_timestep.html,
"restart"_restart.html,
"run"_run.html,
"run_style"_run_style.html,
"server"_server.html,
"set"_set.html,
"shell"_shell.html,
"special_bonds"_special_bonds.html,
"suffix"_suffix.html,
"tad"_tad.html,
"temper"_temper.html,
"temper/grem"_temper_grem.html,
"temper/npt"_temper_npt.html,
"thermo"_thermo.html,
"thermo_modify"_thermo_modify.html,
"thermo_style"_thermo_style.html,
"timer"_timer.html,
"timestep"_timestep.html,
"uncompute"_uncompute.html,
"undump"_undump.html,
"unfix"_unfix.html,
"units"_units.html,
"variable"_variable.html,
"velocity"_velocity.html,
"write_coeff"_write_coeff.html,
"write_data"_write_data.html,
"write_dump"_write_dump.html,
"write_restart"_write_restart.html :tb(c=6,ea=c)

124
doc/src/Commands_bond.txt Normal file
View File

@ -0,0 +1,124 @@
"Higher level section"_Commands.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
"All commands"_Commands_all.html,
"Fix styles"_Commands_fix.html,
"Compute styles"_Commands_compute.html,
"Pair styles"_Commands_pair.html,
"Bond styles"_Commands_bond.html#bond,
"Angle styles"_Commands_bond.html#angle,
"Dihedral styles"_Commands_bond.html#dihedral,
"Improper styles"_Commands_bond.html#improper,
"KSpace styles"_Commands_kspace.html :tb(c=3,ea=c)
Bond, angle, dihedral, and improper commands :h3
:line
Bond_style potentials :h3,link(bond)
All LAMMPS "bond_style"_bond_style.html commands. Some styles have
accelerated versions. 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,
"hybrid"_bond_hybrid.html :tb(c=3,ea=c)
"class2 (ko)"_bond_class2.html,
"fene (iko)"_bond_fene.html,
"fene/expand (o)"_bond_fene_expand.html,
"gromos (o)"_bond_gromos.html,
"harmonic (ko)"_bond_harmonic.html,
"harmonic/shift (o)"_bond_harmonic_shift.html,
"harmonic/shift/cut (o)"_bond_harmonic_shift_cut.html,
"morse (o)"_bond_morse.html,
"nonlinear (o)"_bond_nonlinear.html,
"oxdna/fene"_bond_oxdna.html,
"oxdna2/fene"_bond_oxdna.html,
"quartic (o)"_bond_quartic.html,
"table (o)"_bond_table.html :tb(c=4,ea=c)
:line
Angle_style potentials :h3,link(angle)
All LAMMPS "angle_style"_angle_style.html commands. Some styles have
accelerated versions. 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,
"hybrid"_angle_hybrid.html :tb(c=3,ea=c)
"charmm (ko)"_angle_charmm.html,
"class2 (ko)"_angle_class2.html,
"cosine (o)"_angle_cosine.html,
"cosine/delta (o)"_angle_cosine_delta.html,
"cosine/periodic (o)"_angle_cosine_periodic.html,
"cosine/shift (o)"_angle_cosine_shift.html,
"cosine/shift/exp (o)"_angle_cosine_shift_exp.html,
"cosine/squared (o)"_angle_cosine_squared.html,
"dipole (o)"_angle_dipole.html,
"fourier (o)"_angle_fourier.html,
"fourier/simple (o)"_angle_fourier_simple.html,
"harmonic (iko)"_angle_harmonic.html,
"quartic (o)"_angle_quartic.html,
"sdk"_angle_sdk.html,
"table (o)"_angle_table.html :tb(c=4,ea=c)
:line
Dihedral_style potentials :h3,link(dihedral)
All LAMMPS "dihedral_style"_dihedral_style.html commands. Some styles
have accelerated versions. This is indicated by additional letters in
parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o = USER-OMP, t =
OPT.
"none"_dihedral_none.html,
"zero"_dihedral_zero.html,
"hybrid"_dihedral_hybrid.html :tb(c=3,ea=c)
"charmm (iko)"_dihedral_charmm.html,
"charmmfsw"_dihedral_charmm.html,
"class2 (ko)"_dihedral_class2.html,
"cosine/shift/exp (o)"_dihedral_cosine_shift_exp.html,
"fourier (io)"_dihedral_fourier.html,
"harmonic (io)"_dihedral_harmonic.html,
"helix (o)"_dihedral_helix.html,
"multi/harmonic (o)"_dihedral_multi_harmonic.html,
"nharmonic (o)"_dihedral_nharmonic.html,
"opls (iko)"_dihedral_opls.html,
"quadratic (o)"_dihedral_quadratic.html,
"spherical (o)"_dihedral_spherical.html,
"table (o)"_dihedral_table.html,
"table/cut"_dihedral_table_cut.html :tb(c=4,ea=c)
:line
Improper_style potentials :h3,link(improper)
All LAMMPS "improper_style"_improper_style.html commands. Some styles
have accelerated versions. 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,
"hybrid"_improper_hybrid.html :tb(c=3,ea=c)
"class2 (ko)"_improper_class2.html,
"cossq (o)"_improper_cossq.html,
"cvff (io)"_improper_cvff.html,
"distance"_improper_distance.html,
"fourier (o)"_improper_fourier.html,
"harmonic (iko)"_improper_harmonic.html,
"ring (o)"_improper_ring.html,
"umbrella (o)"_improper_umbrella.html :tb(c=4,ea=c)

141
doc/src/Commands_category.txt Normal file
View File

@ -0,0 +1,141 @@
"Higher level section"_Commands.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
Commands by category :h3
This page lists most of the LAMMPS commands, grouped by category. The
"Commands all"_Commands_all.html doc page lists all commands
alphabetically. It also includes long lists of style options for
entries that appear in the following categories as a single command
(fix, compute, pair, etc).
Initialization:
"newton"_newton.html,
"package"_package.html,
"processors"_processors.html,
"suffix"_suffix.html,
"units"_units.html :ul
Setup simulation box:
"boundary"_boundary.html,
"box"_box.html,
"change_box"_change_box.html,
"create_box"_create_box.html,
"dimension"_dimension.html,
"lattice"_lattice.html,
"region"_region.html :ul
Setup atoms:
"atom_modify"_atom_modify.html,
"atom_style"_atom_style.html,
"balance"_balance.html,
"create_atoms"_create_atoms.html,
"create_bonds"_create_bonds.html,
"delete_atoms"_delete_atoms.html,
"delete_bonds"_delete_bonds.html,
"displace_atoms"_displace_atoms.html,
"group"_group.html,
"mass"_mass.html,
"molecule"_molecule.html,
"read_data"_read_data.html,
"read_dump"_read_dump.html,
"read_restart"_read_restart.html,
"replicate"_replicate.html,
"set"_set.html,
"velocity"_velocity.html :ul
Force fields:
"angle_coeff"_angle_coeff.html,
"angle_style"_angle_style.html,
"bond_coeff"_bond_coeff.html,
"bond_style"_bond_style.html,
"bond_write"_bond_write.html,
"dielectric"_dielectric.html,
"dihedral_coeff"_dihedral_coeff.html,
"dihedral_style"_dihedral_style.html,
"improper_coeff"_improper_coeff.html,
"improper_style"_improper_style.html,
"kspace_modify"_kspace_modify.html,
"kspace_style"_kspace_style.html,
"pair_coeff"_pair_coeff.html,
"pair_modify"_pair_modify.html,
"pair_style"_pair_style.html,
"pair_write"_pair_write.html,
"special_bonds"_special_bonds.html :ul
Settings:
"comm_modify"_comm_modify.html,
"comm_style"_comm_style.html,
"info"_info.html,
"min_modify"_min_modify.html,
"min_style"_min_style.html,
"neigh_modify"_neigh_modify.html,
"neighbor"_neighbor.html,
"partition"_partition.html,
"reset_timestep"_reset_timestep.html,
"run_style"_run_style.html,
"timer"_timer.html,
"timestep"_timestep.html :ul
Operations within timestepping (fixes) and diagnostics (computes):
"compute"_compute.html,
"compute_modify"_compute_modify.html,
"fix"_fix.html,
"fix_modify"_fix_modify.html,
"uncompute"_uncompute.html,
"unfix"_unfix.html :ul
Output:
"dump image"_dump_image.html,
"dump movie"_dump_image.html,
"dump"_dump.html,
"dump_modify"_dump_modify.html,
"restart"_restart.html,
"thermo"_thermo.html,
"thermo_modify"_thermo_modify.html,
"thermo_style"_thermo_style.html,
"undump"_undump.html,
"write_coeff"_write_coeff.html,
"write_data"_write_data.html,
"write_dump"_write_dump.html,
"write_restart"_write_restart.html :ul
Actions:
"minimize"_minimize.html,
"neb"_neb.html,
"prd"_prd.html,
"rerun"_rerun.html,
"run"_run.html,
"tad"_tad.html,
"temper"_temper.html :ul
Input script control:
"clear"_clear.html,
"echo"_echo.html,
"if"_if.html,
"include"_include.html,
"jump"_jump.html,
"label"_label.html,
"log"_log.html,
"next"_next.html,
"print"_print.html,
"python"_python.html,
"quit"_quit.html,
"shell"_shell.html,
"variable"_variable.html :ul

155
doc/src/Commands_compute.txt Normal file
View File

@ -0,0 +1,155 @@
"Higher level section"_Commands.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
"All commands"_Commands_all.html,
"Fix styles"_Commands_fix.html,
"Compute styles"_Commands_compute.html,
"Pair styles"_Commands_pair.html,
"Bond styles"_Commands_bond.html,
"Angle styles"_Commands_bond.html#angle,
"Dihedral styles"_Commands_bond.html#dihedral,
"Improper styles"_Commands_bond.html#improper,
"KSpace styles"_Commands_kspace.html :tb(c=3,ea=c)
Compute commands :h3
An alphabetic list of all LAMMPS "compute"_compute.html commands.
Some styles have accelerated versions. This is indicated by
additional letters in parenthesis: g = GPU, i = USER-INTEL, k =
KOKKOS, o = USER-OMP, t = OPT.
"ackland/atom"_compute_ackland_atom.html,
"aggregate/atom"_compute_cluster_atom.html,
"angle"_compute_angle.html,
"angle/local"_compute_angle_local.html,
"angmom/chunk"_compute_angmom_chunk.html,
"basal/atom"_compute_basal_atom.html,
"body/local"_compute_body_local.html,
"bond"_compute_bond.html,
"bond/local"_compute_bond_local.html,
"centro/atom"_compute_centro_atom.html,
"chunk/atom"_compute_chunk_atom.html,
"chunk/spread/atom"_compute_chunk_spread_atom.html,
"cluster/atom"_compute_cluster_atom.html,
"cna/atom"_compute_cna_atom.html,
"cnp/atom"_compute_cnp_atom.html,
"com"_compute_com.html,
"com/chunk"_compute_com_chunk.html,
"contact/atom"_compute_contact_atom.html,
"coord/atom"_compute_coord_atom.html,
"damage/atom"_compute_damage_atom.html,
"dihedral"_compute_dihedral.html,
"dihedral/local"_compute_dihedral_local.html,
"dilatation/atom"_compute_dilatation_atom.html,
"dipole/chunk"_compute_dipole_chunk.html,
"displace/atom"_compute_displace_atom.html,
"dpd"_compute_dpd.html,
"dpd/atom"_compute_dpd_atom.html,
"edpd/temp/atom"_compute_edpd_temp_atom.html,
"entropy/atom"_compute_entropy_atom.html,
"erotate/asphere"_compute_erotate_asphere.html,
"erotate/rigid"_compute_erotate_rigid.html,
"erotate/sphere"_compute_erotate_sphere.html,
"erotate/sphere/atom"_compute_erotate_sphere_atom.html,
"event/displace"_compute_event_displace.html,
"fep"_compute_fep.html,
"force/tally"_compute_tally.html,
"fragment/atom"_compute_cluster_atom.html,
"global/atom"_compute_global_atom.html,
"group/group"_compute_group_group.html,
"gyration"_compute_gyration.html,
"gyration/chunk"_compute_gyration_chunk.html,
"heat/flux"_compute_heat_flux.html,
"heat/flux/tally"_compute_tally.html,
"hexorder/atom"_compute_hexorder_atom.html,
"improper"_compute_improper.html,
"improper/local"_compute_improper_local.html,
"inertia/chunk"_compute_inertia_chunk.html,
"ke"_compute_ke.html,
"ke/atom"_compute_ke_atom.html,
"ke/atom/eff"_compute_ke_atom_eff.html,
"ke/eff"_compute_ke_eff.html,
"ke/rigid"_compute_ke_rigid.html,
"meso/e/atom"_compute_meso_e_atom.html,
"meso/rho/atom"_compute_meso_rho_atom.html,
"meso/t/atom"_compute_meso_t_atom.html,
"msd"_compute_msd.html,
"msd/chunk"_compute_msd_chunk.html,
"msd/nongauss"_compute_msd_nongauss.html,
"omega/chunk"_compute_omega_chunk.html,
"orientorder/atom"_compute_orientorder_atom.html,
"pair"_compute_pair.html,
"pair/local"_compute_pair_local.html,
"pe"_compute_pe.html,
"pe/atom"_compute_pe_atom.html,
"pe/mol/tally"_compute_tally.html,
"pe/tally"_compute_tally.html,
"plasticity/atom"_compute_plasticity_atom.html,
"pressure"_compute_pressure.html,
"pressure/uef"_compute_pressure_uef.html,
"property/atom"_compute_property_atom.html,
"property/chunk"_compute_property_chunk.html,
"property/local"_compute_property_local.html,
"rdf"_compute_rdf.html,
"reduce"_compute_reduce.html,
"reduce/chunk"_compute_reduce_chunk.html,
"reduce/region"_compute_reduce.html,
"rigid/local"_compute_rigid_local.html,
"saed"_compute_saed.html,
"slice"_compute_slice.html,
"smd/contact/radius"_compute_smd_contact_radius.html,
"smd/damage"_compute_smd_damage.html,
"smd/hourglass/error"_compute_smd_hourglass_error.html,
"smd/internal/energy"_compute_smd_internal_energy.html,
"smd/plastic/strain"_compute_smd_plastic_strain.html,
"smd/plastic/strain/rate"_compute_smd_plastic_strain_rate.html,
"smd/rho"_compute_smd_rho.html,
"smd/tlsph/defgrad"_compute_smd_tlsph_defgrad.html,
"smd/tlsph/dt"_compute_smd_tlsph_dt.html,
"smd/tlsph/num/neighs"_compute_smd_tlsph_num_neighs.html,
"smd/tlsph/shape"_compute_smd_tlsph_shape.html,
"smd/tlsph/strain"_compute_smd_tlsph_strain.html,
"smd/tlsph/strain/rate"_compute_smd_tlsph_strain_rate.html,
"smd/tlsph/stress"_compute_smd_tlsph_stress.html,
"smd/triangle/mesh/vertices"_compute_smd_triangle_mesh_vertices.html,
"smd/ulsph/num/neighs"_compute_smd_ulsph_num_neighs.html,
"smd/ulsph/strain"_compute_smd_ulsph_strain.html,
"smd/ulsph/strain/rate"_compute_smd_ulsph_strain_rate.html,
"smd/ulsph/stress"_compute_smd_ulsph_stress.html,
"smd/vol"_compute_smd_vol.html,
"sna/atom"_compute_sna_atom.html,
"snad/atom"_compute_sna_atom.html,
"snav/atom"_compute_sna_atom.html,
"spin"_compute_spin.html,
"stress/atom"_compute_stress_atom.html,
"stress/tally"_compute_tally.html,
"tdpd/cc/atom"_compute_tdpd_cc_atom.html,
"temp (k)"_compute_temp.html,
"temp/asphere"_compute_temp_asphere.html,
"temp/body"_compute_temp_body.html,
"temp/chunk"_compute_temp_chunk.html,
"temp/com"_compute_temp_com.html,
"temp/deform"_compute_temp_deform.html,
"temp/deform/eff"_compute_temp_deform_eff.html,
"temp/drude"_compute_temp_drude.html,
"temp/eff"_compute_temp_eff.html,
"temp/partial"_compute_temp_partial.html,
"temp/profile"_compute_temp_profile.html,
"temp/ramp"_compute_temp_ramp.html,
"temp/region"_compute_temp_region.html,
"temp/region/eff"_compute_temp_region_eff.html,
"temp/rotate"_compute_temp_rotate.html,
"temp/sphere"_compute_temp_sphere.html,
"temp/uef"_compute_temp_uef.html,
"ti"_compute_ti.html,
"torque/chunk"_compute_torque_chunk.html,
"vacf"_compute_vacf.html,
"vcm/chunk"_compute_vcm_chunk.html,
"voronoi/atom"_compute_voronoi_atom.html,
"xrd"_compute_xrd.html :tb(c=6,ea=c)

229
doc/src/Commands_fix.txt Normal file
View File

@ -0,0 +1,229 @@
"Higher level section"_Commands.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
"All commands"_Commands_all.html,
"Fix styles"_Commands_fix.html,
"Compute styles"_Commands_compute.html,
"Pair styles"_Commands_pair.html,
"Bond styles"_Commands_bond.html,
"Angle styles"_Commands_bond.html#angle,
"Dihedral styles"_Commands_bond.html#dihedral,
"Improper styles"_Commands_bond.html#improper,
"KSpace styles"_Commands_kspace.html :tb(c=3,ea=c)
Fix commands :h3
An alphabetic list of all LAMMPS "fix"_fix.html commands. Some styles
have accelerated versions. This is indicated by additional letters in
parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o = USER-OMP, t =
OPT.
"adapt"_fix_adapt.html,
"adapt/fep"_fix_adapt_fep.html,
"addforce"_fix_addforce.html,
"addtorque"_fix_addtorque.html,
"append/atoms"_fix_append_atoms.html,
"atc"_fix_atc.html,
"atom/swap"_fix_atom_swap.html,
"ave/atom"_fix_ave_atom.html,
"ave/chunk"_fix_ave_chunk.html,
"ave/correlate"_fix_ave_correlate.html,
"ave/correlate/long"_fix_ave_correlate_long.html,
"ave/histo"_fix_ave_histo.html,
"ave/histo/weight"_fix_ave_histo.html,
"ave/time"_fix_ave_time.html,
"aveforce"_fix_aveforce.html,
"balance"_fix_balance.html,
"bond/break"_fix_bond_break.html,
"bond/create"_fix_bond_create.html,
"bond/react"_fix_bond_react.html,
"bond/swap"_fix_bond_swap.html,
"box/relax"_fix_box_relax.html,
"cmap"_fix_cmap.html,
"colvars"_fix_colvars.html,
"controller"_fix_controller.html,
"deform (k)"_fix_deform.html,
"deposit"_fix_deposit.html,
"dpd/energy (k)"_fix_dpd_energy.html,
"drag"_fix_drag.html,
"drude"_fix_drude.html,
"drude/transform/direct"_fix_drude_transform.html,
"drude/transform/reverse"_fix_drude_transform.html,
"dt/reset"_fix_dt_reset.html,
"edpd/source"_fix_dpd_source.html,
"efield"_fix_efield.html,
"ehex"_fix_ehex.html,
"enforce2d (k)"_fix_enforce2d.html,
"eos/cv"_fix_eos_cv.html,
"eos/table"_fix_eos_table.html,
"eos/table/rx (k)"_fix_eos_table_rx.html,
"evaporate"_fix_evaporate.html,
"external"_fix_external.html,
"filter/corotate"_fix_filter_corotate.html,
"flow/gauss"_fix_flow_gauss.html,
"freeze"_fix_freeze.html,
"gcmc"_fix_gcmc.html,
"gld"_fix_gld.html,
"gle"_fix_gle.html,
"gravity (o)"_fix_gravity.html,
"grem"_fix_grem.html,
"halt"_fix_halt.html,
"heat"_fix_heat.html,
"imd"_fix_imd.html,
"indent"_fix_indent.html,
"ipi"_fix_ipi.html,
"langevin (k)"_fix_langevin.html,
"langevin/drude"_fix_langevin_drude.html,
"langevin/eff"_fix_langevin_eff.html,
"langevin/spin"_fix_langevin_spin.html,
"latte"_fix_latte.html,
"lb/fluid"_fix_lb_fluid.html,
"lb/momentum"_fix_lb_momentum.html,
"lb/pc"_fix_lb_pc.html,
"lb/rigid/pc/sphere"_fix_lb_rigid_pc_sphere.html,
"lb/viscous"_fix_lb_viscous.html,
"lineforce"_fix_lineforce.html,
"manifoldforce"_fix_manifoldforce.html,
"meso"_fix_meso.html,
"meso/stationary"_fix_meso_stationary.html,
"momentum (k)"_fix_momentum.html,
"move"_fix_move.html,
"mscg"_fix_mscg.html,
"msst"_fix_msst.html,
"mvv/dpd"_fix_mvv_dpd.html,
"mvv/edpd"_fix_mvv_dpd.html,
"mvv/tdpd"_fix_mvv_dpd.html,
"neb"_fix_neb.html,
"nph (ko)"_fix_nh.html,
"nph/asphere (o)"_fix_nph_asphere.html,
"nph/body"_fix_nph_body.html,
"nph/eff"_fix_nh_eff.html,
"nph/sphere (o)"_fix_nph_sphere.html,
"nphug (o)"_fix_nphug.html,
"npt (kio)"_fix_nh.html,
"npt/asphere (o)"_fix_npt_asphere.html,
"npt/body"_fix_npt_body.html,
"npt/eff"_fix_nh_eff.html,
"npt/sphere (o)"_fix_npt_sphere.html,
"npt/uef"_fix_nh_uef.html,
"nve (kio)"_fix_nve.html,
"nve/asphere (i)"_fix_nve_asphere.html,
"nve/asphere/noforce"_fix_nve_asphere_noforce.html,
"nve/body"_fix_nve_body.html,
"nve/dot"_fix_nve_dot.html,
"nve/dotc/langevin"_fix_nve_dotc_langevin.html,
"nve/eff"_fix_nve_eff.html,
"nve/limit"_fix_nve_limit.html,
"nve/line"_fix_nve_line.html,
"nve/manifold/rattle"_fix_nve_manifold_rattle.html,
"nve/noforce"_fix_nve_noforce.html,
"nve/sphere (o)"_fix_nve_sphere.html,
"nve/spin"_fix_nve_spin.html,
"nve/tri"_fix_nve_tri.html,
"nvk"_fix_nvk.html,
"nvt (iko)"_fix_nh.html,
"nvt/asphere (o)"_fix_nvt_asphere.html,
"nvt/body"_fix_nvt_body.html,
"nvt/eff"_fix_nh_eff.html,
"nvt/manifold/rattle"_fix_nvt_manifold_rattle.html,
"nvt/sllod (io)"_fix_nvt_sllod.html,
"nvt/sllod/eff"_fix_nvt_sllod_eff.html,
"nvt/sphere (o)"_fix_nvt_sphere.html,
"nvt/uef"_fix_nh_uef.html,
"oneway"_fix_oneway.html,
"orient/bcc"_fix_orient.html,
"orient/fcc"_fix_orient.html,
"phonon"_fix_phonon.html,
"pimd"_fix_pimd.html,
"planeforce"_fix_planeforce.html,
"poems"_fix_poems.html,
"pour"_fix_pour.html,
"precession/spin"_fix_precession_spin.html,
"press/berendsen"_fix_press_berendsen.html,
"print"_fix_print.html,
"property/atom (k)"_fix_property_atom.html,
"python/invoke"_fix_python_invoke.html,
"python/move"_fix_python_move.html,
"qbmsst"_fix_qbmsst.html,
"qeq/comb (o)"_fix_qeq_comb.html,
"qeq/dynamic"_fix_qeq.html,
"qeq/fire"_fix_qeq.html,
"qeq/point"_fix_qeq.html,
"qeq/reax (ko)"_fix_qeq_reax.html,
"qeq/shielded"_fix_qeq.html,
"qeq/slater"_fix_qeq.html,
"qmmm"_fix_qmmm.html,
"qtb"_fix_qtb.html,
"rattle"_fix_shake.html,
"reax/bonds"_fix_reax_bonds.html,
"reax/c/bonds (k)"_fix_reax_bonds.html,
"reax/c/species (k)"_fix_reaxc_species.html,
"recenter"_fix_recenter.html,
"restrain"_fix_restrain.html,
"rhok"_fix_rhok.html,
"rigid (o)"_fix_rigid.html,
"rigid/nph (o)"_fix_rigid.html,
"rigid/npt (o)"_fix_rigid.html,
"rigid/nve (o)"_fix_rigid.html,
"rigid/nvt (o)"_fix_rigid.html,
"rigid/small (o)"_fix_rigid.html,
"rigid/small/nph"_fix_rigid.html,
"rigid/small/npt"_fix_rigid.html,
"rigid/small/nve"_fix_rigid.html,
"rigid/small/nvt"_fix_rigid.html,
"rx (k)"_fix_rx.html,
"saed/vtk"_fix_saed_vtk.html,
"setforce (k)"_fix_setforce.html,
"shake"_fix_shake.html,
"shardlow (k)"_fix_shardlow.html,
"smd"_fix_smd.html,
"smd/adjust/dt"_fix_smd_adjust_dt.html,
"smd/integrate/tlsph"_fix_smd_integrate_tlsph.html,
"smd/integrate/ulsph"_fix_smd_integrate_ulsph.html,
"smd/move/triangulated/surface"_fix_smd_move_triangulated_surface.html,
"smd/setvel"_fix_smd_setvel.html,
"smd/wall/surface"_fix_smd_wall_surface.html,
"spring"_fix_spring.html,
"spring/chunk"_fix_spring_chunk.html,
"spring/rg"_fix_spring_rg.html,
"spring/self"_fix_spring_self.html,
"srd"_fix_srd.html,
"store/force"_fix_store_force.html,
"store/state"_fix_store_state.html,
"tdpd/source"_fix_dpd_source.html,
"temp/berendsen"_fix_temp_berendsen.html,
"temp/csld"_fix_temp_csvr.html,
"temp/csvr"_fix_temp_csvr.html,
"temp/rescale"_fix_temp_rescale.html,
"temp/rescale/eff"_fix_temp_rescale_eff.html,
"tfmc"_fix_tfmc.html,
"thermal/conductivity"_fix_thermal_conductivity.html,
"ti/spring"_fix_ti_spring.html,
"tmd"_fix_tmd.html,
"ttm"_fix_ttm.html,
"ttm/mod"_fix_ttm.html,
"tune/kspace"_fix_tune_kspace.html,
"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/ees"_fix_wall_ees.html,
"wall/gran"_fix_wall_gran.html,
"wall/gran/region"_fix_wall_gran_region.html,
"wall/harmonic"_fix_wall.html,
"wall/lj1043"_fix_wall.html,
"wall/lj126"_fix_wall.html,
"wall/lj93 (k)"_fix_wall.html,
"wall/piston"_fix_wall_piston.html,
"wall/reflect (k)"_fix_wall_reflect.html,
"wall/region"_fix_wall_region.html,
"wall/region/ees"_fix_wall_ees.html,
"wall/srd"_fix_wall_srd.html :tb(c=8,ea=c)

60
doc/src/Commands_input.txt Normal file
View File

@ -0,0 +1,60 @@
"Higher level section"_Commands.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
LAMMPS input scripts :h3
LAMMPS executes by reading commands from a input script (text file),
one line at a time. When the input script ends, LAMMPS exits. Each
command causes LAMMPS to take some action. It may set an internal
variable, read in a file, or run a simulation. Most commands have
default settings, which means you only need to use the command if you
wish to change the default.
In many cases, the ordering of commands in an input script is not
important. However the following rules apply:
(1) LAMMPS does not read your entire input script and then perform a
simulation with all the settings. Rather, the input script is read
one line at a time and each command takes effect when it is read.
Thus this sequence of commands:
timestep 0.5
run 100
run 100 :pre
does something different than this sequence:
run 100
timestep 0.5
run 100 :pre
In the first case, the specified timestep (0.5 fs) is used for two
simulations of 100 timesteps each. In the 2nd case, the default
timestep (1.0 fs) is used for the 1st 100 step simulation and a 0.5 fs
timestep is used for the 2nd one.
(2) Some commands are only valid when they follow other commands. For
example you cannot set the temperature of a group of atoms until atoms
have been defined and a group command is used to define which atoms
belong to the group.
(3) Sometimes command B will use values that can be set by command A.
This means command A must precede command B in the input script if it
is to have the desired effect. For example, the
"read_data"_read_data.html command initializes the system by setting
up the simulation box and assigning atoms to processors. If default
values are not desired, the "processors"_processors.html and
"boundary"_boundary.html commands need to be used before read_data to
tell LAMMPS how to map processors to the simulation box.
Many input script errors are detected by LAMMPS and an ERROR or
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.

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

@ -0,0 +1,37 @@
"Higher level section"_Commands.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands.html)
:line
"All commands"_Commands_all.html,
"Fix styles"_Commands_fix.html,
"Compute styles"_Commands_compute.html,
"Pair styles"_Commands_pair.html,
"Bond styles"_Commands_bond.html,
"Angle styles"_Commands_bond.html#angle,
"Dihedral styles"_Commands_bond.html#dihedral,
"Improper styles"_Commands_bond.html#improper,
"KSpace styles"_Commands_kspace.html :tb(c=3,ea=c)
KSpace solvers :h3
All LAMMPS "kspace_style"_kspace_style.html solvers. Some styles have
accelerated versions. 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,
"msm (o)"_kspace_style.html,
"msm/cg (o)"_kspace_style.html,
"pppm (gok)"_kspace_style.html,
"pppm/cg (o)"_kspace_style.html,
"pppm/disp (i)"_kspace_style.html,
"pppm/disp/tip4p"_kspace_style.html,
"pppm/stagger"_kspace_style.html,
"pppm/tip4p (o)"_kspace_style.html,
"scafacos"_kspace_style.html :tb(c=4,ea=c)

232
doc/src/Commands_pair.txt Normal file
View File

@ -0,0 +1,232 @@
"Higher level section"_Commands.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
"All commands"_Commands_all.html,
"Fix styles"_Commands_fix.html,
"Compute styles"_Commands_compute.html,
"Pair styles"_Commands_pair.html,
"Bond styles"_Commands_bond.html,
"Angle styles"_Commands_bond.html#angle,
"Dihedral styles"_Commands_bond.html#dihedral,
"Improper styles"_Commands_bond.html#improper,
"KSpace styles"_Commands_kspace.html :tb(c=3,ea=c)
Pair_style potentials :h3
All LAMMPS "pair_style"_pair_style.html commands. Some styles have
accelerated versions. 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,
"hybrid"_pair_hybrid.html,
"hybrid/overlay (k)"_pair_hybrid.html :tb(c=4,ea=c)
"adp (o)"_pair_adp.html,
"agni (o)"_pair_agni.html,
"airebo (oi)"_pair_airebo.html,
"airebo/morse (oi)"_pair_airebo.html,
"atm"_pair_atm.html,
"awpmd/cut"_pair_awpmd.html,
"beck (go)"_pair_beck.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,
"born/coul/dsf/cs"_pair_born.html,
"born/coul/long (go)"_pair_born.html,
"born/coul/long/cs"_pair_born.html,
"born/coul/msm (o)"_pair_born.html,
"born/coul/wolf (go)"_pair_born.html,
"born/coul/wolf/cs"_pair_born.html,
"brownian (o)"_pair_brownian.html,
"brownian/poly (o)"_pair_brownian.html,
"buck (giko)"_pair_buck.html,
"buck/coul/cut (giko)"_pair_buck.html,
"buck/coul/long (giko)"_pair_buck.html,
"buck/coul/long/cs"_pair_buck.html,
"buck/coul/msm (o)"_pair_buck.html,
"buck/long/coul/long (o)"_pair_buck_long.html,
"buck/mdf"_pair_mdf.html,
"colloid (go)"_pair_colloid.html,
"comb (o)"_pair_comb.html,
"comb3"_pair_comb.html,
"coul/cut (gko)"_pair_coul.html,
"coul/cut/soft (o)"_pair_lj_soft.html,
"coul/debye (gko)"_pair_coul.html,
"coul/diel (o)"_pair_coul_diel.html,
"coul/dsf (gko)"_pair_coul.html,
"coul/long (gko)"_pair_coul.html,
"coul/long/cs"_pair_coul.html,
"coul/long/soft (o)"_pair_lj_soft.html,
"coul/msm"_pair_coul.html,
"coul/shield"_pair_coul_shield.html,
"coul/streitz"_pair_coul.html,
"coul/wolf (ko)"_pair_coul.html,
"coul/wolf/cs"_pair_coul.html,
"dpd (gio)"_pair_dpd.html,
"dpd/fdt"_pair_dpd_fdt.html,
"dpd/fdt/energy (k)"_pair_dpd_fdt.html,
"dpd/tstat (go)"_pair_dpd.html,
"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,
"edip (o)"_pair_edip.html,
"edip/multi"_pair_edip.html,
"edpd"_pair_meso.html,
"eff/cut"_pair_eff.html,
"eim (o)"_pair_eim.html,
"exp6/rx (k)"_pair_exp6_rx.html,
"extep"_pair_extep.html,
"gauss (go)"_pair_gauss.html,
"gauss/cut"_pair_gauss.html,
"gayberne (gio)"_pair_gayberne.html,
"gran/hertz/history (o)"_pair_gran.html,
"gran/hooke (o)"_pair_gran.html,
"gran/hooke/history (o)"_pair_gran.html,
"gw"_pair_gw.html,
"gw/zbl"_pair_gw.html,
"hbond/dreiding/lj (o)"_pair_hbond_dreiding.html,
"hbond/dreiding/morse (o)"_pair_hbond_dreiding.html,
"ilp/graphene/hbn"_pair_ilp_graphene_hbn.html,
"kim"_pair_kim.html,
"kolmogorov/crespi/full"_pair_kolmogorov_crespi_full.html,
"kolmogorov/crespi/z"_pair_kolmogorov_crespi_z.html,
"lcbop"_pair_lcbop.html,
"lennard/mdf"_pair_mdf.html,
"line/lj"_pair_line_lj.html,
"list"_pair_list.html,
"lj/charmm/coul/charmm (iko)"_pair_charmm.html,
"lj/charmm/coul/charmm/implicit (ko)"_pair_charmm.html,
"lj/charmm/coul/long (giko)"_pair_charmm.html,
"lj/charmm/coul/long/soft (o)"_pair_charmm.html,
"lj/charmm/coul/msm"_pair_charmm.html,
"lj/charmmfsw/coul/charmmfsh"_pair_charmm.html,
"lj/charmmfsw/coul/long"_pair_charmm.html,
"lj/class2 (gko)"_pair_class2.html,
"lj/class2/coul/cut (ko)"_pair_class2.html,
"lj/class2/coul/long (gko)"_pair_class2.html,
"lj/cubic (go)"_pair_lj_cubic.html,
"lj/cut (gikot)"_pair_lj.html,
"lj/cut/coul/cut (gko)"_pair_lj.html,
"lj/cut/coul/cut/soft (o)"_pair_lj_soft.html,
"lj/cut/coul/debye (gko)"_pair_lj.html,
"lj/cut/coul/dsf (gko)"_pair_lj.html,
"lj/cut/coul/long (gikot)"_pair_lj.html,
"lj/cut/coul/long/cs"_pair_lj.html,
"lj/cut/coul/long/soft (o)"_pair_lj_soft.html,
"lj/cut/coul/msm (go)"_pair_lj.html,
"lj/cut/coul/wolf (o)"_pair_lj.html,
"lj/cut/dipole/cut (go)"_pair_dipole.html,
"lj/cut/dipole/long"_pair_dipole.html,
"lj/cut/dipole/sf (go)"_pair_dipole.html,
"lj/cut/soft (o)"_pair_lj_soft.html,
"lj/cut/thole/long (o)"_pair_thole.html,
"lj/cut/tip4p/cut (o)"_pair_lj.html,
"lj/cut/tip4p/long (ot)"_pair_lj.html,
"lj/cut/tip4p/long/soft (o)"_pair_lj_soft.html,
"lj/expand (gko)"_pair_lj_expand.html,
"lj/gromacs (gko)"_pair_gromacs.html,
"lj/gromacs/coul/gromacs (ko)"_pair_gromacs.html,
"lj/long/coul/long (io)"_pair_lj_long.html,
"lj/long/dipole/long"_pair_dipole.html,
"lj/long/tip4p/long"_pair_lj_long.html,
"lj/mdf"_pair_mdf.html,
"lj/sdk (gko)"_pair_sdk.html,
"lj/sdk/coul/long (go)"_pair_sdk.html,
"lj/sdk/coul/msm (o)"_pair_sdk.html,
"lj/smooth (o)"_pair_lj_smooth.html,
"lj/smooth/linear (o)"_pair_lj_smooth_linear.html,
"lj96/cut (go)"_pair_lj96.html,
"lubricate (o)"_pair_lubricate.html,
"lubricate/poly (o)"_pair_lubricate.html,
"lubricateU"_pair_lubricateU.html,
"lubricateU/poly"_pair_lubricateU.html,
"mdpd"_pair_meso.html,
"mdpd/rhosum"_pair_meso.html,
"meam"_pair_meam.html,
"meam/c"_pair_meam.html,
"meam/spline (o)"_pair_meam_spline.html,
"meam/sw/spline"_pair_meam_sw_spline.html,
"mgpt"_pair_mgpt.html,
"mie/cut (o)"_pair_mie.html,
"momb"_pair_momb.html,
"morse (gkot)"_pair_morse.html,
"morse/smooth/linear"_pair_morse.html,
"morse/soft"_pair_morse.html,
"multi/lucy"_pair_multi_lucy.html,
"multi/lucy/rx (k)"_pair_multi_lucy_rx.html,
"nb3b/harmonic (o)"_pair_nb3b_harmonic.html,
"nm/cut (o)"_pair_nm.html,
"nm/cut/coul/cut (o)"_pair_nm.html,
"nm/cut/coul/long (o)"_pair_nm.html,
"oxdna/coaxstk"_pair_oxdna.html,
"oxdna/excv"_pair_oxdna.html,
"oxdna/hbond"_pair_oxdna.html,
"oxdna/stk"_pair_oxdna.html,
"oxdna/xstk"_pair_oxdna.html,
"oxdna2/coaxstk"_pair_oxdna2.html,
"oxdna2/dh"_pair_oxdna2.html,
"oxdna2/excv"_pair_oxdna2.html,
"oxdna2/stk"_pair_oxdna2.html,
"peri/eps"_pair_peri.html,
"peri/lps (o)"_pair_peri.html,
"peri/pmb (o)"_pair_peri.html,
"peri/ves"_pair_peri.html,
"polymorphic"_pair_polymorphic.html,
"python"_pair_python.html,
"quip"_pair_quip.html,
"reax"_pair_reax.html,
"reax/c (ko)"_pair_reaxc.html,
"rebo (oi)"_pair_airebo.html,
"resquared (go)"_pair_resquared.html,
"smd/hertz"_pair_smd_hertz.html,
"smd/tlsph"_pair_smd_tlsph.html,
"smd/triangulated/surface"_pair_smd_triangulated_surface.html,
"smd/ulsph"_pair_smd_ulsph.html,
"smtbq"_pair_smtbq.html,
"snap (k)"_pair_snap.html,
"snap (k)"_pair_snap.html,
"soft (go)"_pair_soft.html,
"sph/heatconduction"_pair_sph_heatconduction.html,
"sph/idealgas"_pair_sph_idealgas.html,
"sph/lj"_pair_sph_lj.html,
"sph/rhosum"_pair_sph_rhosum.html,
"sph/taitwater"_pair_sph_taitwater.html,
"sph/taitwater/morris"_pair_sph_taitwater_morris.html,
"spin/dmi"_pair_spin_dmi.html,
"spin/exchange"_pair_spin_exchange.html,
"spin/magelec"_pair_spin_magelec.html,
"spin/neel"_pair_spin_neel.html,
"srp"_pair_srp.html,
"sw (giko)"_pair_sw.html,
"table (gko)"_pair_table.html,
"table/rx (k)"_pair_table_rx.html,
"tdpd"_pair_meso.html,
"tersoff (giko)"_pair_tersoff.html,
"tersoff/mod (gko)"_pair_tersoff_mod.html,
"tersoff/mod/c (o)"_pair_tersoff_mod.html,
"tersoff/table (o)"_pair_tersoff.html,
"tersoff/zbl (gko)"_pair_tersoff_zbl.html,
"thole"_pair_thole.html,
"tip4p/cut (o)"_pair_coul.html,
"tip4p/long (o)"_pair_coul.html,
"tip4p/long/soft (o)"_pair_lj_soft.html,
"tri/lj"_pair_tri_lj.html,
"ufm (got)"_pair_ufm.html,
"vashishta (ko)"_pair_vashishta.html,
"vashishta/table (o)"_pair_vashishta.html,
"yukawa (gok)"_pair_yukawa.html,
"yukawa/colloid (go)"_pair_yukawa_colloid.html,
"zbl (gok)"_pair_zbl.html :tb(c=4,ea=c)

136
doc/src/Commands_parse.txt Normal file
View File

@ -0,0 +1,136 @@
"Higher level section"_Commands.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
Parsing rules for input scripts :h3
Each non-blank line in the input script is treated as a command.
LAMMPS commands are case sensitive. Command names are lower-case, as
are specified command arguments. Upper case letters may be used in
file names or user-chosen ID strings.
Here are 6 rules for how each line in the input script is parsed by
LAMMPS:
(1) If the last printable character on the line is a "&" character,
the command is assumed to continue on the next line. The next line is
concatenated to the previous line by removing the "&" character and
line break. This allows long commands to be continued across two or
more lines. See the discussion of triple quotes in (6) for how to
continue a command across multiple line without using "&" characters.
(2) All characters from the first "#" character onward are treated as
comment and discarded. See an exception in (6). Note that a
comment after a trailing "&" character will prevent the command from
continuing on the next line. Also note that for multi-line commands a
single leading "#" will comment out the entire command.
(3) The line is searched repeatedly for $ characters, which indicate
variables that are replaced with a text string. See an exception in
(6).
If the $ is followed by curly brackets, then the variable name is the
text inside the curly brackets. If no curly brackets follow the $,
then the variable name is the single character immediately following
the $. Thus $\{myTemp\} and $x refer to variable names "myTemp" and
"x".
How the variable is converted to a text string depends on what style
of variable it is; see the "variable"_variable.html doc page for details.
It can be a variable that stores multiple text strings, and return one
of them. The returned text string can be multiple "words" (space
separated) which will then be interpreted as multiple arguments in the
input command. The variable can also store a numeric formula which
will be evaluated and its numeric result returned as a string.
As a special case, if the $ is followed by parenthesis, then the text
inside the parenthesis is treated as an "immediate" variable and
evaluated as an "equal-style variable"_variable.html. This is a way
to use numeric formulas in an input script without having to assign
them to variable names. For example, these 3 input script lines:
variable X equal (xlo+xhi)/2+sqrt(v_area)
region 1 block $X 2 INF INF EDGE EDGE
variable X delete :pre
can be replaced by
region 1 block $((xlo+xhi)/2+sqrt(v_area)) 2 INF INF EDGE EDGE :pre
so that you do not have to define (or discard) a temporary variable X.
Additionally, the "immediate" variable expression may be followed by a
colon, followed by a C-style format string, e.g. ":%f" or ":%.10g".
The format string must be appropriate for a double-precision
floating-point value. The format string is used to output the result
of the variable expression evaluation. If a format string is not
specified a high-precision "%.20g" is used as the default.
This can be useful for formatting print output to a desired precision:
print "Final energy per atom: $(pe/atoms:%10.3f) eV/atom" :pre
Note that neither the curly-bracket or immediate form of variables can
contain nested $ characters for other variables to substitute for.
Thus you cannot do this:
variable a equal 2
variable b2 equal 4
print "B2 = $\{b$a\}" :pre
Nor can you specify this $($x-1.0) for an immediate variable, but
you could use $(v_x-1.0), since the latter is valid syntax for an
"equal-style variable"_variable.html.
See the "variable"_variable.html command for more details of how
strings are assigned to variables and evaluated, and how they can be
used in input script commands.
(4) The line is broken into "words" separated by whitespace (tabs,
spaces). Note that words can thus contain letters, digits,
underscores, or punctuation characters.
(5) The first word is the command name. All successive words in the
line are arguments.
(6) If you want text with spaces to be treated as a single argument,
it can be enclosed in either single or double or triple quotes. A
long single argument enclosed in single or double quotes can span
multiple lines if the "&" character is used, as described above. When
the lines are concatenated together (and the "&" characters and line
breaks removed), the text will become a single line. If you want
multiple lines of an argument to retain their line breaks, the text
can be enclosed in triple quotes, in which case "&" characters are not
needed. For example:
print "Volume = $v"
print 'Volume = $v'
if "$\{steps\} > 1000" then quit
variable a string "red green blue &
purple orange cyan"
print """
System volume = $v
System temperature = $t
""" :pre
In each case, the single, double, or triple quotes are removed when
the single argument they enclose is stored internally.
See the "dump modify format"_dump_modify.html, "print"_print.html,
"if"_if.html, and "python"_python.html commands for examples.
A "#" or "$" character that is between quotes will not be treated as a
comment indicator in (2) or substituted for as a variable in (3).
NOTE: If the argument is itself a command that requires a quoted
argument (e.g. using a "print"_print.html command as part of an
"if"_if.html or "run every"_run.html command), then single, double, or
triple quotes can be nested in the usual manner. See the doc pages
for those commands for examples. Only one of level of nesting is
allowed, but that should be sufficient for most use cases.

95
doc/src/Commands_structure.txt Normal file
View File

@ -0,0 +1,95 @@
"Higher level section"_Commands.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
Input script structure :h3
This page describes the structure of a typical LAMMPS input script.
The examples directory in the LAMMPS distribution contains many sample
input scripts; it is discussed on the "Examples"_Examples.html doc
page.
A LAMMPS input script typically has 4 parts:
Initialization
Atom definition
Settings
Run a simulation :ol
The last 2 parts can be repeated as many times as desired. I.e. run a
simulation, change some settings, run some more, etc. Each of the 4
parts is now described in more detail. Remember that almost all
commands need only be used if a non-default value is desired.
(1) Initialization
Set parameters that need to be defined before atoms are created or
read-in from a file.
The relevant commands are "units"_units.html,
"dimension"_dimension.html, "newton"_newton.html,
"processors"_processors.html, "boundary"_boundary.html,
"atom_style"_atom_style.html, "atom_modify"_atom_modify.html.
If force-field parameters appear in the files that will be read, these
commands tell LAMMPS what kinds of force fields are being used:
"pair_style"_pair_style.html, "bond_style"_bond_style.html,
"angle_style"_angle_style.html, "dihedral_style"_dihedral_style.html,
"improper_style"_improper_style.html.
(2) Atom definition
There are 3 ways to define atoms in LAMMPS. Read them in from a data
or restart file via the "read_data"_read_data.html or
"read_restart"_read_restart.html commands. These files can contain
molecular topology information. Or create atoms on a lattice (with no
molecular topology), using these commands: "lattice"_lattice.html,
"region"_region.html, "create_box"_create_box.html,
"create_atoms"_create_atoms.html. The entire set of atoms can be
duplicated to make a larger simulation using the
"replicate"_replicate.html command.
(3) Settings
Once atoms and molecular topology are defined, a variety of settings
can be specified: force field coefficients, simulation parameters,
output options, etc.
Force field coefficients are set by these commands (they can also be
set in the read-in files): "pair_coeff"_pair_coeff.html,
"bond_coeff"_bond_coeff.html, "angle_coeff"_angle_coeff.html,
"dihedral_coeff"_dihedral_coeff.html,
"improper_coeff"_improper_coeff.html,
"kspace_style"_kspace_style.html, "dielectric"_dielectric.html,
"special_bonds"_special_bonds.html.
Various simulation parameters are set by these commands:
"neighbor"_neighbor.html, "neigh_modify"_neigh_modify.html,
"group"_group.html, "timestep"_timestep.html,
"reset_timestep"_reset_timestep.html, "run_style"_run_style.html,
"min_style"_min_style.html, "min_modify"_min_modify.html.
Fixes impose a variety of boundary conditions, time integration, and
diagnostic options. The "fix"_fix.html command comes in many flavors.
Various computations can be specified for execution during a
simulation using the "compute"_compute.html,
"compute_modify"_compute_modify.html, and "variable"_variable.html
commands.
Output options are set by the "thermo"_thermo.html, "dump"_dump.html,
and "restart"_restart.html commands.
(4) Run a simulation
A molecular dynamics simulation is run using the "run"_run.html
command. Energy minimization (molecular statics) is performed using
the "minimize"_minimize.html command. A parallel tempering
(replica-exchange) simulation can be run using the
"temper"_temper.html command.

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Õ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/fix_integration_spin_stdecomposition.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 50 KiB

40
doc/src/Eqs/fix_integration_spin_stdecomposition.tex Normal file
View File

@ -0,0 +1,40 @@
\documentclass[preview]{standalone}
\usepackage{varwidth}
\usepackage[utf8x]{inputenc}
\usepackage{amsmath,amssymb,amsthm,bm,tikz}
\usetikzlibrary{automata,arrows,shapes,snakes}
\begin{document}
\begin{varwidth}{50in}
\begin{tikzpicture}
%Global
\node (v1) at (0,6.0) [draw,thick,minimum width=0.2cm,minimum height=0.2cm] { $\bm{v} \leftarrow \bm{v}+L_v.\Delta t/2$ };
\node (s1) at (0,4.5) [draw,thick,minimum width=0.2cm,minimum height=0.2cm] { $\bm{s} \leftarrow \bm{s}+L_s.\Delta t/2$ };
\node (r) at (0,3.0) [draw,thick,minimum width=0.2cm,minimum height=0.2cm] { $\bm{r} \leftarrow \bm{r}+L_r.\Delta t$ };
\node (s2) at (0,1.5) [draw,thick,minimum width=0.2cm,minimum height=0.2cm] { $\bm{s} \leftarrow \bm{s}+L_s.\Delta t/2$ };
\node (v2) at (0,0.0) [draw,thick,minimum width=0.2cm,minimum height=0.2cm] { $\bm{v} \leftarrow \bm{v}+L_v.\Delta t/2$ };
\draw[line width=2pt, ->] (v1) -- (s1);
\draw[line width=2pt, ->] (s1) -- (r);
\draw[line width=2pt, ->] (r) -- (s2);
\draw[line width=2pt, ->] (s2) -- (v2);
%Spin
\node (s01) at (6,6.0) [draw,thick,minimum width=0.2cm,minimum height=0.2cm] {$\bm{s}_0 \leftarrow \bm{s}_0+L_{s_0}.\Delta t/4$ };
\node (sN1) at (6,4.5) [draw,thick,minimum width=0.2cm,minimum height=0.2cm] {$\bm{s}_{\rm N-1}\leftarrow\bm{s}_{\rm N-1}+L_{s_{\rm N-1}}.\Delta t/4$};
\node (sN) at (6,3.0) [draw,thick,minimum width=0.2cm,minimum height=0.2cm] {$\bm{s}_{\rm N} \leftarrow \bm{s}_{\rm N}+L_{s_{\rm N}}.\Delta t/2$ };
\node (sN2) at (6,1.5) [draw,thick,minimum width=0.2cm,minimum height=0.2cm] {$\bm{s}_{\rm N-1}\leftarrow\bm{s}_{\rm N-1}+L_{s_{\rm N-1}}.\Delta t/4$};
\node (s02) at (6,0.0) [draw,thick,minimum width=0.2cm,minimum height=0.2cm] {$\bm{s}_0 \leftarrow \bm{s}_0+L_{s_0}.\Delta t/4$ };
\draw[line width=2pt,dashed, ->] (s01) -- (sN1);
\draw[line width=2pt, ->] (sN1) -- (sN);
\draw[line width=2pt, ->] (sN) -- (sN2);
\draw[line width=2pt,dashed, ->] (sN2) -- (s02);
%from Global to Spin
\draw[line width=2pt, dashed, ->] (s1) -- (s01.west);
\draw[line width=2pt, dashed, ->] (s1) -- (s02.west);
\end{tikzpicture}
\end{varwidth}
\end{document}

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

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 8.9 KiB

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

@ -0,0 +1,14 @@
\documentclass[preview]{standalone}
\usepackage{varwidth}
\usepackage[utf8x]{inputenc}
\usepackage{amsmath, amssymb, graphics, setspace}
\begin{document}
\begin{varwidth}{50in}
\begin{equation}
\frac{d \vec{s}_{i}}{dt} = \frac{1}{\left(1+\lambda^2 \right)} \left( \left(
\vec{\omega}_{i} +\vec{\eta} \right) \times \vec{s}_{i} + \lambda\, \vec{s}_{i}
\times\left( \vec{\omega}_{i} \times\vec{s}_{i} \right) \right), \nonumber
\end{equation}
\end{varwidth}
\end{document}

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

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 5.9 KiB

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

@ -0,0 +1,11 @@
\documentclass[preview]{standalone}
\usepackage{varwidth}
\usepackage[utf8x]{inputenc}
\usepackage{amsmath,amssymb,amsthm,bm}
\begin{document}
\begin{varwidth}{50in}
\begin{equation}
\bm{H}_{aniso} = -\sum_{{ i}=1}^{N} K_{an}(\bm{r}_{i})\, \left( \vec{s}_{i} \cdot \vec{n}_{i} \right)^2, \nonumber
\end{equation}
\end{varwidth}
\end{document}

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

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 6.4 KiB

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

@ -0,0 +1,11 @@
\documentclass[preview]{standalone}
\usepackage{varwidth}
\usepackage[utf8x]{inputenc}
\usepackage{amsmath,amssymb,amsthm,bm}
\begin{document}
\begin{varwidth}{50in}
\begin{equation}
\bm{H}_{zeeman} = -\mu_{B}\mu_0\sum_{i=0}^{N}g_{i} \vec{s}_{i} \cdot \vec{H}_{ext} \nonumber
\end{equation}
\end{varwidth}
\end{document}

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

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 5.3 KiB

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

@ -0,0 +1,9 @@
\documentclass[12pt]{article}
\begin{document}
\begin{equation}
E=\nu\frac{1+3\cos\gamma_1\cos\gamma_2\cos\gamma_3}{r_{12}^3r_{23}^3r_{31}^3}
\end{equation}
\end{document}

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_entropy.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 8.7 KiB

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

@ -0,0 +1,10 @@
\documentclass[12pt]{article}
\begin{document}
\thispagestyle{empty}
$$
s_S^i=-2\pi\rho k_B \int\limits_0^{r_m} \left [ g(r) \ln g(r) - g(r) + 1 \right ] r^2 dr ,
$$
\end{document}

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

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 8.3 KiB

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

@ -0,0 +1,10 @@
\documentclass[12pt]{article}
\begin{document}
\thispagestyle{empty}
$$
g_m^i(r) = \frac{1}{4 \pi \rho r^2} \sum\limits_{j} \frac{1}{\sqrt{2 \pi \sigma^2}} e^{-(r-r_{ij})^2/(2\sigma^2)} ,
$$
\end{document}

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

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 5.6 KiB

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

@ -0,0 +1,10 @@
\documentclass[12pt]{article}
\begin{document}
\thispagestyle{empty}
$$
\bar{s}_S^i = \frac{\sum_j s_S^j + s_S^i}{N + 1} ,
$$
\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 Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 7.7 KiB

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

@ -0,0 +1,16 @@
\documentclass[preview]{standalone}
\usepackage{varwidth}
\usepackage[utf8x]{inputenc}
\usepackage{amsmath,amssymb,amsthm,bm}
\begin{document}
\begin{varwidth}{50in}
\begin{equation}
\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
\end{equation}
\end{varwidth}
\end{document}
\vec{D}\left(r_{ij}\right)
{\rm ~and~} \vec{D}\left(r_{ij}\right) = \vec{e}_{ij} \times \vec{D}

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

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 13 KiB

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

@ -0,0 +1,16 @@
\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} {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_function.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 10 KiB

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

@ -0,0 +1,13 @@
\documentclass[preview]{standalone}
\usepackage{varwidth}
\usepackage[utf8x]{inputenc}
\usepackage{amsmath, amssymb, graphics, setspace}
\begin{document}
\begin{varwidth}{50in}
\begin{equation}
{J}\left( r_{ij} \right) = 4 a \left( \frac{r_{ij}}{d} \right)^2 \left( 1 - b \left( \frac{r_{ij}}{d} \right)^2 \right) e^{-\left( \frac{r_{ij}}{d}
\right)^2 }\Theta (R_c - r_{ij}) \nonumber
\end{equation}
\end{varwidth}
\end{document}

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

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 5.8 KiB

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

@ -0,0 +1,11 @@
\documentclass[preview]{standalone}
\usepackage{varwidth}
\usepackage[utf8x]{inputenc}
\usepackage{amsmath,amssymb,amsthm,bm}
\begin{document}
\begin{varwidth}{50in}
\begin{equation}
\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}

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

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 13 KiB

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

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

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

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 10 KiB

12
doc/src/Eqs/pair_spin_me_interaction.tex Normal file
View File

@ -0,0 +1,12 @@
\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\vec{D}(r_{ij}) ~~{\rm and}~~
\vec{F}_i = -\sum_{j}^{Neighb} \frac{\partial D(r_{ij})}{\partial r_{ij}} \left(\vec{s}_{i}\times \vec{s}_{j} \right) \cdot \vec{r}_{ij}, \nonumber
\end{equation}
\end{varwidth}
\end{document}

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

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 5.8 KiB

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

@ -0,0 +1,13 @@
\documentclass[preview]{standalone}
\usepackage{varwidth}
\usepackage[utf8x]{inputenc}
\usepackage{amsmath,amssymb,amsthm,bm}
\begin{document}
\begin{varwidth}{50in}
\begin{eqnarray}
g_1(r_{ij}) &=& g(r_{ij}) + \frac{12}{35} q(r_{ij}) \nonumber \\
q_1(r_{ij}) &=& \frac{9}{5} q(r_{ij}) \nonumber \\
q_2(r_{ij}) &=& - \frac{2}{5} q(r_{ij}) \nonumber
\end{eqnarray}
\end{varwidth}
\end{document}

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

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 11 KiB

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

@ -0,0 +1,16 @@
\documentclass[preview]{standalone}
\usepackage{varwidth}
\usepackage[utf8x]{inputenc}
\usepackage{amsmath,amssymb,amsthm,bm}
\begin{document}
\begin{varwidth}{50in}
\begin{equation}
\mathcal{H}_{N\acute{e}el}=-\sum_{{ i,j=1,i\neq j}}^N g_1(r_{ij})\left(({\bm e}_{ij}\cdot {\bm s}_{i})({\bm e}_{ij}
\cdot {\bm s}_{j})-\frac{{\bm s}_{i}\cdot{\bm s}_{j}}{3} \right)
+q_1(r_{ij})\left( ({\bm e}_{ij}\cdot {\bm s}_{i})^2 -\frac{{\bm s}_{i}\cdot{\bm s}_{j}}{3}\right)
\left( ({\bm e}_{ij}\cdot {\bm s}_{i})^2 -\frac{{\bm s}_{i}\cdot{\bm s}_{j}}{3} \right)
+ q_2(r_{ij}) \Big( ({\bm e}_{ij}\cdot {\bm s}_{i}) ({\bm e}_{ij}\cdot {\bm s}_{j})^3 + ({\bm e}_{ij}\cdot
{\bm s}_{j}) ({\bm e}_{ij}\cdot {\bm s}_{i})^3\Big) \nonumber
\end{equation}
\end{varwidth}
\end{document}

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

@ -0,0 +1,38 @@
"Previous Section"_Python_head.html - "LAMMPS WWW Site"_lws -
"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
Section"_Manual.html :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
: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::
:maxdepth: 1
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,Commands_all.html)
: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,Commands_all.html)
: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 swith"_Run_options.html. The installation and
compilation of optional packages is explained on the "Build
packages"_Build_package.html doc page.
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"_Errors_bugs.html) 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.

1113
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,Commands_all.html)
: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 like 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

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

@ -1,12 +1,14 @@
"Previous Section"_Section_howto.html - "LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next Section"_Section_perf.html :c
"Previous Section"_Howto.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,Section_commands.html#comm)
:link(lc,Commands_all.html)
: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
@ -110,10 +112,10 @@ web site.
If you uncomment the "dump image"_dump_image.html line(s) in the input
script a series of JPG images will be produced by the run (assuming
you built LAMMPS with JPG support; see "Section
2.2"_Section_start.html#start_2 for details). These can be viewed
individually or turned into a movie or animated by tools like
ImageMagick or QuickTime or various Windows-based tools. See the
you built LAMMPS with JPG support; see the
"Build_settings"_Build_settings.html doc page for details). These can
be viewed individually or turned into a movie or animated by tools
like ImageMagick or QuickTime or various Windows-based tools. See the
"dump image"_dump_image.html doc page for more details. E.g. this
Imagemagick command would create a GIF file suitable for viewing in a
browser.
@ -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.

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

@ -0,0 +1,191 @@
"Previous Section"_Performance.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)
:link(lc,Commands.html#comm)
:line
Howto discussions :h2
These doc pages describe how to perform various tasks with LAMMPS,
both for users and developers. The
"glossary"_http://lammps.sandia.gov website page also lists MD
terminology with links to corresponding LAMMPS manual pages. The
example input scripts included in the examples dir of the LAMMPS
distribution and highlighted on the "Examples"_Examples.html doc page
also show how to setup and run various kinds of simulations.
Tutorials howto :h3
<!-- RST
.. toctree::
:name: tutorials
:maxdepth: 1
Howto_github
Howto_pylammps
Howto_bash
END_RST -->
<!-- HTML_ONLY -->
"Using GitHub with LAMMPS"_Howto_github.html
"PyLAMMPS interface to LAMMPS"_Howto_pylammps.html
"Using LAMMPS with bash on Windows"_Howto_bash.html :all(b)
<!-- END_HTML_ONLY -->
General howto :h3
<!-- RST
.. toctree::
:name: general
:maxdepth: 1
Howto_restart
Howto_viz
Howto_multiple
Howto_replica
Howto_library
Howto_couple
Howto_client_server
END_RST -->
<!-- HTML_ONLY -->
"Restart a simulation"_Howto_restart.html
"Visualize LAMMPS snapshots"_Howto_viz.html
"Run multiple simulations from one input script"_Howto_multiple.html
"Multi-replica simulations"_Howto_replica.html
"Library interface to LAMMPS"_Howto_library.html
"Couple LAMMPS to other codes"_Howto_couple.html
"Using LAMMPS in client/server mode"_Howto_client_server.html :all(b)
<!-- END_HTML_ONLY -->
Settings howto :h3
<!-- RST
.. toctree::
:name: settings
:maxdepth: 1
Howto_2d
Howto_triclinic
Howto_thermostat
Howto_barostat
Howto_walls
Howto_nemd
Howto_dispersion
END_RST -->
<!-- HTML_ONLY -->
"2d simulations"_Howto_2d.html
"Triclinic (non-orthogonal) simulation boxes"_Howto_triclinic.html
"Thermostats"_Howto_thermostat.html
"Barostats"_Howto_barostat.html
"Walls"_Howto_walls.html
"NEMD simulations"_Howto_nemd.html
"Long-range dispersion settings"_Howto_dispersion.html :all(b)
<!-- END_HTML_ONLY -->
Analysis howto :h3
<!-- RST
.. toctree::
:name: analysis
:maxdepth: 1
Howto_output
Howto_chunk
Howto_temperature
Howto_elastic
Howto_kappa
Howto_viscosity
Howto_diffusion
END_RST -->
<!-- HTML_ONLY -->
"Output from LAMMPS (thermo, dumps, computes, fixes, variables)"_Howto_output.html
"Use chunks to calculate system properties"_Howto_chunk.html :all(b)
"Calculate temperature"_Howto_temperature.html
"Calculate elastic constants"_Howto_elastic.html
"Calculate thermal conductivity"_Howto_kappa.html
"Calculate viscosity"_Howto_viscosity.html
"Calculate a diffusion coefficient"_Howto_diffusion.html :all(b)
<!-- END_HTML_ONLY -->
Force fields howto :h3
<!-- RST
.. toctree::
:name: force
:maxdepth: 1
Howto_bioFF
Howto_tip3p
Howto_tip4p
Howto_spc
END_RST -->
<!-- HTML_ONLY -->
"CHARMM, AMBER, and DREIDING force fields"_Howto_bioFF.html
"TIP3P water model"_Howto_tip3p.html
"TIP4P water model"_Howto_tip4p.html
"SPC water model"_Howto_spc.html :all(b)
<!-- END_HTML_ONLY -->
Packages howto :h3
<!-- RST
.. toctree::
:name: packages
:maxdepth: 1
Howto_spherical
Howto_granular
Howto_body
Howto_polarizable
Howto_coreshell
Howto_drude
Howto_drude2
Howto_manifold
Howto_spins
END_RST -->
<!-- HTML_ONLY -->
"Finite-size spherical and aspherical particles"_Howto_spherical.html
"Granular models"_Howto_granular.html
"Body style particles"_Howto_body.html
"Polarizable models"_Howto_polarizable.html
"Adiabatic core/shell model"_Howto_coreshell.html
"Drude induced dipoles"_Howto_drude.html
"Drude induced dipoles (extended)"_Howto_drude2.html
"Manifolds (surfaces)"_Howto_manifold.html
"Magnetic spins"_Howto_spins.html :all(b)
<!-- END_HTML_ONLY -->

48
doc/src/Howto_2d.txt Normal file
View File

@ -0,0 +1,48 @@
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
2d simulations :h3
Use the "dimension"_dimension.html command to specify a 2d simulation.
Make the simulation box periodic in z via the "boundary"_boundary.html
command. This is the default.
If using the "create box"_create_box.html command to define a
simulation box, set the z dimensions narrow, but finite, so that the
create_atoms command will tile the 3d simulation box with a single z
plane of atoms - e.g.
"create box"_create_box.html 1 -10 10 -10 10 -0.25 0.25 :pre
If using the "read data"_read_data.html command to read in a file of
atom coordinates, set the "zlo zhi" values to be finite but narrow,
similar to the create_box command settings just described. For each
atom in the file, assign a z coordinate so it falls inside the
z-boundaries of the box - e.g. 0.0.
Use the "fix enforce2d"_fix_enforce2d.html command as the last
defined fix to insure that the z-components of velocities and forces
are zeroed out every timestep. The reason to make it the last fix is
so that any forces induced by other fixes will be zeroed out.
Many of the example input scripts included in the LAMMPS distribution
are for 2d models.
NOTE: Some models in LAMMPS treat particles as finite-size spheres, as
opposed to point particles. See the "atom_style
sphere"_atom_style.html and "fix nve/sphere"_fix_nve_sphere.html
commands for details. By default, for 2d simulations, such particles
will still be modeled as 3d spheres, not 2d discs (circles), meaning
their moment of inertia will be that of a sphere. If you wish to
model them as 2d discs, see the "set density/disc"_set.html command
and the {disc} option for the "fix nve/sphere"_fix_nve_sphere.html,
"fix nvt/sphere"_fix_nvt_sphere.html, "fix
nph/sphere"_fix_nph_sphere.html, "fix npt/sphere"_fix_npt_sphere.html
commands.

75
doc/src/Howto_barostat.txt Normal file
View File

@ -0,0 +1,75 @@
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
Barostats :h3
Barostatting means controlling the pressure in an MD simulation.
"Thermostatting"_Howto_thermostat.html means controlling the
temperature of the particles. Since the pressure includes a kinetic
component due to particle velocities, both these operations require
calculation of the temperature. Typically a target temperature (T)
and/or pressure (P) is specified by the user, and the thermostat or
barostat attempts to equilibrate the system to the requested T and/or
P.
Barostatting in LAMMPS is performed by "fixes"_fix.html. Two
barosttating methods are currently available: Nose-Hoover (npt and
nph) and Berendsen:
"fix npt"_fix_nh.html
"fix npt/sphere"_fix_npt_sphere.html
"fix npt/asphere"_fix_npt_asphere.html
"fix nph"_fix_nh.html
"fix press/berendsen"_fix_press_berendsen.html :ul
The "fix npt"_fix_nh.html commands include a Nose-Hoover thermostat
and barostat. "Fix nph"_fix_nh.html is just a Nose/Hoover barostat;
it does no thermostatting. Both "fix nph"_fix_nh.html and "fix
press/berendsen"_fix_press_berendsen.html can be used in conjunction
with any of the thermostatting fixes.
As with the "thermostats"_Howto_thermostat.html, "fix npt"_fix_nh.html
and "fix nph"_fix_nh.html only use translational motion of the
particles in computing T and P and performing thermo/barostatting.
"Fix npt/sphere"_fix_npt_sphere.html and "fix
npt/asphere"_fix_npt_asphere.html thermo/barostat using not only
translation velocities but also rotational velocities for spherical
and aspherical particles.
All of the barostatting fixes use the "compute
pressure"_compute_pressure.html compute to calculate a current
pressure. By default, this compute is created with a simple "compute
temp"_compute_temp.html (see the last argument of the "compute
pressure"_compute_pressure.html command), which is used to calculated
the kinetic component of the pressure. The barostatting fixes can
also use temperature computes that remove bias for the purpose of
computing the kinetic component which contributes to the current
pressure. See the doc pages for the individual fixes and for the
"fix_modify"_fix_modify.html command for instructions on how to assign
a temperature or pressure compute to a barostatting fix.
NOTE: As with the thermostats, the Nose/Hoover methods ("fix
npt"_fix_nh.html and "fix nph"_fix_nh.html) perform time integration.
"Fix press/berendsen"_fix_press_berendsen.html does NOT, so it should
be used with one of the constant NVE fixes or with one of the NVT
fixes.
Thermodynamic output, which can be setup via the
"thermo_style"_thermo_style.html command, often includes pressure
values. As explained on the doc page for the
"thermo_style"_thermo_style.html command, the default pressure is
setup by the thermo command itself. It is NOT the pressure associated
with any barostatting fix you have defined or with any compute you
have defined that calculates a pressure. The doc pages for the
barostatting fixes explain the ID of the pressure compute they create.
Thus if you want to view these pressures, you need to specify them
explicitly via the "thermo_style custom"_thermo_style.html command.
Or you can use the "thermo_modify"_thermo_modify.html command to
re-define what pressure compute is used for default thermodynamic
output.

3
doc/src/tutorial_bash_on_windows.txt → doc/src/Howto_bash.txt Normal file → Executable file
View File

@ -2,7 +2,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:link(lc,Commands_all.html)
:line
@ -10,6 +10,7 @@ Using LAMMPS with Bash on Windows :h3
[written by Richard Berger]
:line
Starting with Windows 10 you can install Linux tools directly in Windows. This
allows you to compile LAMMPS following the same procedure as on a real Ubuntu
Linux installation. Software can be easily installed using the package manager

105
doc/src/Howto_bioFF.txt Normal file
View File

@ -0,0 +1,105 @@
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
CHARMM, AMBER, and DREIDING force fields :h3
A force field has 2 parts: the formulas that define it and the
coefficients used for a particular system. Here we only discuss
formulas implemented in LAMMPS that correspond to formulas commonly
used in the CHARMM, AMBER, 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 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
field.
:link(charmm,http://www.scripps.edu/brooks)
:link(amber,http://amber.scripps.edu)
These style choices compute force field formulas that are consistent
with common options in CHARMM or AMBER. See each command's
documentation for the formula it computes.
"bond_style"_bond_harmonic.html harmonic
"angle_style"_angle_charmm.html charmm
"dihedral_style"_dihedral_charmm.html charmmfsh
"dihedral_style"_dihedral_charmm.html charmm
"pair_style"_pair_charmm.html lj/charmmfsw/coul/charmmfsh
"pair_style"_pair_charmm.html lj/charmmfsw/coul/long
"pair_style"_pair_charmm.html lj/charmm/coul/charmm
"pair_style"_pair_charmm.html lj/charmm/coul/charmm/implicit
"pair_style"_pair_charmm.html lj/charmm/coul/long :ul
"special_bonds"_special_bonds.html charmm
"special_bonds"_special_bonds.html amber :ul
NOTE: For CHARMM, newer {charmmfsw} or {charmmfsh} styles were
released in March 2017. We recommend they be used instead of the
older {charmm} styles. See discussion of the differences on the "pair
charmm"_pair_charmm.html and "dihedral charmm"_dihedral_charmm.html
doc pages.
DREIDING is a generic force field developed by the "Goddard
group"_http://www.wag.caltech.edu at Caltech and is useful for
predicting structures and dynamics of organic, biological and
main-group inorganic molecules. The philosophy in DREIDING is to use
general force constants and geometry parameters based on simple
hybridization considerations, rather than individual force constants
and geometric parameters that depend on the particular combinations of
atoms involved in the bond, angle, or torsion terms. DREIDING has an
"explicit hydrogen bond term"_pair_hbond_dreiding.html to describe
interactions involving a hydrogen atom on very electronegative atoms
(N, O, F).
See "(Mayo)"_#howto-Mayo for a description of the DREIDING force field
These style choices compute force field formulas that are consistent
with the DREIDING force field. See each command's
documentation for the formula it computes.
"bond_style"_bond_harmonic.html harmonic
"bond_style"_bond_morse.html morse :ul
"angle_style"_angle_harmonic.html harmonic
"angle_style"_angle_cosine.html cosine
"angle_style"_angle_cosine_periodic.html cosine/periodic :ul
"dihedral_style"_dihedral_charmm.html charmm
"improper_style"_improper_umbrella.html umbrella :ul
"pair_style"_pair_buck.html buck
"pair_style"_pair_buck.html buck/coul/cut
"pair_style"_pair_buck.html buck/coul/long
"pair_style"_pair_lj.html lj/cut
"pair_style"_pair_lj.html lj/cut/coul/cut
"pair_style"_pair_lj.html lj/cut/coul/long :ul
"pair_style"_pair_hbond_dreiding.html hbond/dreiding/lj
"pair_style"_pair_hbond_dreiding.html hbond/dreiding/morse :ul
"special_bonds"_special_bonds.html dreiding :ul
:line
:link(howto-MacKerell)
[(MacKerell)] MacKerell, Bashford, Bellott, Dunbrack, Evanseck, Field,
Fischer, Gao, Guo, Ha, et al, J Phys Chem, 102, 3586 (1998).
:link(howto-Cornell)
[(Cornell)] Cornell, Cieplak, Bayly, Gould, Merz, Ferguson,
Spellmeyer, Fox, Caldwell, Kollman, JACS 117, 5179-5197 (1995).
:link(howto-Mayo)
[(Mayo)] Mayo, Olfason, Goddard III, J Phys Chem, 94, 8897-8909
(1990).

280
doc/src/body.txt → doc/src/Howto_body.txt
View File

@ -1,24 +1,24 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
"Higher level section"_Howto.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)
:link(lc,Commands_all.html)
:line
Body particles :h2
Body particles :h3
[Overview:]
This doc page is not about a LAMMPS input script command, but about
body particles, which are generalized finite-size particles.
In LAMMPS, body particles are generalized finite-size particles.
Individual body particles can represent complex entities, such as
surface meshes of discrete points, collections of sub-particles,
deformable objects, etc. Note that other kinds of finite-size
spherical and aspherical particles are also supported by LAMMPS, such
as spheres, ellipsoids, line segments, and triangles, but they are
simpler entities that body particles. See "Section
6.14"_Section_howto.html#howto_14 for a general overview of all
simpler entities that body particles. See the "Howto
spherical"_Howto_spherical.html doc page for a general overview of all
these particle types.
Body particles are used via the "atom_style body"_atom_style.html
@ -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
@ -148,8 +151,8 @@ center-of-mass position of the particle is specified by the x,y,z
values in the {Atoms} section of the data file, as is the total mass
of the body particle.
The "pair_style body"_pair_body.html command can be used with this
body style to compute body/body and body/non-body interactions.
The "pair_style body/nparticle"_pair_body_nparticle.html command can be used
with this body style to compute body/body and body/non-body interactions.
For output purposes via the "compute
body/local"_compute_body_local.html and "dump local"_dump.html
@ -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
maximum number of 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).

195
doc/src/Howto_chunk.txt Normal file
View File

@ -0,0 +1,195 @@
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
Use chunks to calculate system properties :h3
In LAMMS, "chunks" are collections of atoms, as defined by the
"compute chunk/atom"_compute_chunk_atom.html command, which assigns
each atom to a chunk ID (or to no chunk at all). The number of chunks
and the assignment of chunk IDs to atoms can be static or change over
time. Examples of "chunks" are molecules or spatial bins or atoms
with similar values (e.g. coordination number or potential energy).
The per-atom chunk IDs can be used as input to two other kinds of
commands, to calculate various properties of a system:
"fix ave/chunk"_fix_ave_chunk.html
any of the "compute */chunk"_compute.html commands :ul
Here, each of the 4 kinds of chunk-related commands is briefly
overviewed. Then some examples are given of how to compute different
properties with chunk commands.
Compute chunk/atom command: :h4
This compute can assign atoms to chunks of various styles. Only atoms
in the specified group and optional specified region are assigned to a
chunk. Here are some possible chunk definitions:
atoms in same molecule | chunk ID = molecule ID |
atoms of same atom type | chunk ID = atom type |
all atoms with same atom property (charge, radius, etc) | chunk ID = output of compute property/atom |
atoms in same cluster | chunk ID = output of "compute cluster/atom"_compute_cluster_atom.html command |
atoms in same spatial bin | chunk ID = bin ID |
atoms in same rigid body | chunk ID = molecule ID used to define rigid bodies |
atoms with similar potential energy | chunk ID = output of "compute pe/atom"_compute_pe_atom.html |
atoms with same local defect structure | chunk ID = output of "compute centro/atom"_compute_centro_atom.html or "compute coord/atom"_compute_coord_atom.html command :tb(s=|,c=2)
Note that chunk IDs are integer values, so for atom properties or
computes that produce a floating point value, they will be truncated
to an integer. You could also use the compute in a variable that
scales the floating point value to spread it across multiple integers.
Spatial bins can be of various kinds, e.g. 1d bins = slabs, 2d bins =
pencils, 3d bins = boxes, spherical bins, cylindrical bins.
This compute also calculates the number of chunks {Nchunk}, which is
used by other commands to tally per-chunk data. {Nchunk} can be a
static value or change over time (e.g. the number of clusters). The
chunk ID for an individual atom can also be static (e.g. a molecule
ID), or dynamic (e.g. what spatial bin an atom is in as it moves).
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 the "Modify"_Modify.html
doc pages for info on 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
This fix takes the ID of a "compute
chunk/atom"_compute_chunk_atom.html command as input. For each chunk,
it then sums one or more specified per-atom values over the atoms in
each chunk. The per-atom values can be any atom property, such as
velocity, force, charge, potential energy, kinetic energy, stress,
etc. Additional keywords are defined for per-chunk properties like
density and temperature. More generally any per-atom value generated
by other "computes"_compute.html, "fixes"_fix.html, and "per-atom
variables"_variable.html, can be summed over atoms in each chunk.
Similar to other averaging fixes, this fix allows the summed per-chunk
values to be time-averaged in various ways, and output to a file. The
fix produces a global array as output with one row of values per
chunk.
Compute */chunk commands: :h4
The following computes operate on chunks of atoms to produce per-chunk
values. Any compute whose style name ends in "/chunk" is in this
category:
"compute com/chunk"_compute_com_chunk.html
"compute gyration/chunk"_compute_gyration_chunk.html
"compute inertia/chunk"_compute_inertia_chunk.html
"compute msd/chunk"_compute_msd_chunk.html
"compute property/chunk"_compute_property_chunk.html
"compute temp/chunk"_compute_temp_chunk.html
"compute torque/chunk"_compute_vcm_chunk.html
"compute vcm/chunk"_compute_vcm_chunk.html :ul
They each take the ID of a "compute
chunk/atom"_compute_chunk_atom.html command as input. As their names
indicate, they calculate the center-of-mass, radius of gyration,
moments of inertia, mean-squared displacement, temperature, torque,
and velocity of center-of-mass for each chunk of atoms. The "compute
property/chunk"_compute_property_chunk.html command can tally the
count of atoms in each chunk and extract other per-chunk properties.
The reason these various calculations are not part of the "fix
ave/chunk command"_fix_ave_chunk.html, is that each requires a more
complicated operation than simply summing and averaging over per-atom
values in each chunk. For example, many of them require calculation
of a center of mass, which requires summing mass*position over the
atoms and then dividing by summed mass.
All of these computes produce a global vector or global array as
output, wih one or more values per chunk. The output can be used in
various ways:
As input to the "fix ave/time"_fix_ave_time.html command, which can
write the values to a file and optionally time average them. :ulb,l
As input to the "fix ave/histo"_fix_ave_histo.html command to
histogram values across chunks. E.g. a histogram of cluster sizes or
molecule diffusion rates. :l
As input to special functions of "equal-style
variables"_variable.html, like sum() and max() and ave(). E.g. to
find the largest cluster or fastest diffusing molecule or average
radius-of-gyration of a set of molecules (chunks). :l,ule
Other chunk commands: :h4
"compute chunk/spread/atom"_compute_chunk_spread_atom.html
"compute reduce/chunk"_compute_reduce_chunk.html :ul
The "compute chunk/spread/atom"_compute_chunk_spread_atom.html command
spreads per-chunk values to each atom in the chunk, producing per-atom
values as its output. This can be useful for outputting per-chunk
values to a per-atom "dump file"_dump.html. Or for using an atom's
associated chunk value in an "atom-style variable"_variable.html.
The "compute reduce/chunk"_compute_reduce_chunk.html command reduces a
peratom value across the atoms in each chunk to produce a value per
chunk. When used with the "compute
chunk/spread/atom"_compute_chunk_spread_atom.html command it can
create peratom values that induce a new set of chunks with a second
"compute chunk/atom"_compute_chunk_atom.html command.
Example calculations with chunks :h4
Here are examples using chunk commands to calculate various
properties:
(1) Average velocity in each of 1000 2d spatial bins:
compute cc1 all chunk/atom bin/2d x 0.0 0.1 y lower 0.01 units reduced
fix 1 all ave/chunk 100 10 1000 cc1 vx vy file tmp.out :pre
(2) Temperature in each spatial bin, after subtracting a flow
velocity:
compute cc1 all chunk/atom bin/2d x 0.0 0.1 y lower 0.1 units reduced
compute vbias all temp/profile 1 0 0 y 10
fix 1 all ave/chunk 100 10 1000 cc1 temp bias vbias file tmp.out :pre
(3) Center of mass of each molecule:
compute cc1 all chunk/atom molecule
compute myChunk all com/chunk cc1
fix 1 all ave/time 100 1 100 c_myChunk\[*\] file tmp.out mode vector :pre
(4) Total force on each molecule and ave/max across all molecules:
compute cc1 all chunk/atom molecule
fix 1 all ave/chunk 1000 1 1000 cc1 fx fy fz file tmp.out
variable xave equal ave(f_1\[2\])
variable xmax equal max(f_1\[2\])
thermo 1000
thermo_style custom step temp v_xave v_xmax :pre
(5) Histogram of cluster sizes:
compute cluster all cluster/atom 1.0
compute cc1 all chunk/atom c_cluster compress yes
compute size all property/chunk cc1 count
fix 1 all ave/histo 100 1 100 0 20 20 c_size mode vector ave running beyond ignore file tmp.histo :pre
(6) An example of using a per-chunk value to apply per-atom forces to
compress individual polymer chains (molecules) in a mixture, is
explained on the "compute
chunk/spread/atom"_compute_chunk_spread_atom.html command doc page.
(7) An example of using one set of per-chunk values for molecule
chunks, to create a 2nd set of micelle-scale chunks (clustered
molecules, due to hydrophobicity), is explained on the "compute
chunk/reduce"_compute_reduce_chunk.html command doc page.

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

@ -0,0 +1,131 @@
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
Using LAMMPS in client/server mode :h3
Client/server coupling of two codes is where one code is the "client"
and sends request messages to a "server" code. The server responds to
each request with a reply message. This enables the two codes to work
in tandem to perform a simulation. LAMMPS can act as either a client
or server code.
Some advantages of client/server coupling are that the two codes run
as stand-alone executables; they are not linked together. Thus
neither code needs to have a library interface. This often makes it
easier to run the two codes on different numbers of processors. If a
message protocol (format and content) is defined for a particular kind
of simulation, then in principle any code that implements the
client-side protocol can be used in tandem with any code that
implements the server-side protocol, without the two codes needing to
know anything more specific about each other.
A simple example of client/server coupling is where LAMMPS is the
client code performing MD timestepping. Each timestep it sends a
message to a server quantum code containing current coords of all the
atoms. The quantum code computes energy and forces based on the
coords. It returns them as a message to LAMMPS, which completes the
timestep.
Alternate methods for code coupling with LAMMPS are described on
the "Howto couple"_Howto_couple.html doc page.
LAMMPS support for client/server coupling is in its "MESSAGE
package"_Packages_details.html#PKG-MESSAGE which implements several
commands that enable LAMMPS to act as a client or server, as discussed
below. The MESSAGE package also wraps a client/server library called
CSlib which enables two codes to exchange messages in different ways,
either via files, sockets, or MPI. The CSlib is provided with LAMMPS
in the lib/message dir. The CSlib has its own
"website"_http://cslib.sandia.gov with documentation and test
programs.
NOTE: For client/server coupling to work between LAMMPS and another
code, the other code also has to use the CSlib. This can sometimes be
done without any modifications to the other code by simply wrapping it
with a Python script that exchanges CSlib messages with LAMMPS and
prepares input for or processes output from the other code. The other
code also has to implement a matching protocol for the format and
content of messages that LAMMPS exchanges with it.
These are the commands currently in the MESSAGE package for two
protocols, MD and MC (Monte Carlo). New protocols can easily be
defined and added to this directory, where LAMMPS acts as either the
client or server.
"message"_message.html
"fix client md"_fix_client_md.html = LAMMPS is a client for running MD
"server md"_server_md.html = LAMMPS is a server for computing MD forces
"server mc"_server_mc.html = LAMMPS is a server for computing a Monte Carlo energy :ul
The server doc files give details of the message protocols
for data that is exchanged bewteen the client and server.
These example directories illustrate how to use LAMMPS as either a
client or server code:
examples/message
examples/COUPLE/README
examples/COUPLE/lammps_mc
examples/COUPLE/lammps_vasp :ul
The examples/message dir couples a client instance of LAMMPS to a
server instance of LAMMPS.
The lammps_mc dir shows how to couple LAMMPS as a server to a simple
Monte Carlo client code as the driver.
The lammps_vasp dir shows how to couple LAMMPS as a client code
running MD timestepping to VASP acting as a server providing quantum
DFT forces, thru a Python wrapper script on VASP.
Here is how to launch a client and server code together for any of the
4 modes of message exchange that the "message"_message.html command
and the CSlib support. Here LAMMPS is used as both the client and
server code. Another code could be subsitituted for either.
The examples below show launching both codes from the same window (or
batch script), using the "&" character to launch the first code in the
background. For all modes except {mpi/one}, you could also launch the
codes in separate windows on your desktop machine. It does not
matter whether you launch the client or server first.
In these examples either code can be run on one or more processors.
If running in a non-MPI mode (file or zmq) you can launch a code on a
single processor without using mpirun.
IMPORTANT: If you run in mpi/two mode, you must launch both codes via
mpirun, even if one or both of them runs on a single processor. This
is so that MPI can figure out how to connect both MPI processes
together to exchange MPI messages between them.
For message exchange in {file}, {zmq}, or {mpi/two} modes:
% mpirun -np 1 lmp_mpi -log log.client < in.client &
% mpirun -np 2 lmp_mpi -log log.server < in.server :pre
% mpirun -np 4 lmp_mpi -log log.client < in.client &
% mpirun -np 1 lmp_mpi -log log.server < in.server :pre
% mpirun -np 2 lmp_mpi -log log.client < in.client &
% mpirun -np 4 lmp_mpi -log log.server < in.server :pre
For message exchange in {mpi/one} mode:
Launch both codes in a single mpirun command:
mpirun -np 2 lmp_mpi -mpicolor 0 -in in.message.client -log log.client : -np 4 lmp_mpi -mpicolor 1 -in in.message.server -log log.server :pre
The two -np values determine how many procs the client and the server
run on.
A LAMMPS executable run in this manner must use the -mpicolor color
command-line option as their its option, where color is an integer
label that will be used to distinguish one executable from another in
the multiple executables that the mpirun command launches. In this
example the client was colored with a 0, and the server with a 1.

253
doc/src/Howto_coreshell.txt Normal file
View File

@ -0,0 +1,253 @@
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
Adiabatic core/shell model :h3
The adiabatic core-shell model by "Mitchell and
Fincham"_#MitchellFincham is a simple method for adding polarizability
to a system. In order to mimic the electron shell of an ion, a
satellite particle is attached to it. This way the ions are split into
a core and a shell where the latter is meant to react to the
electrostatic environment inducing polarizability. See the "Howto
polarizable"_Howto_polarizable.html doc page for a discussion of all
the polarizable models available in LAMMPS.
Technically, shells are attached to the cores by a spring force f =
k*r where k is a parametrized spring constant and r is the distance
between the core and the shell. The charges of the core and the shell
add up to the ion charge, thus q(ion) = q(core) + q(shell). This
setup introduces the ion polarizability (alpha) given by
alpha = q(shell)^2 / k. In a
similar fashion the mass of the ion is distributed on the core and the
shell with the core having the larger mass.
To run this model in LAMMPS, "atom_style"_atom_style.html {full} can
be used since atom charge and bonds are needed. Each kind of
core/shell pair requires two atom types and a bond type. The core and
shell of a core/shell pair should be bonded to each other with a
harmonic bond that provides the spring force. For example, a data file
for NaCl, as found in examples/coreshell, has this format:
432 atoms # core and shell atoms
216 bonds # number of core/shell springs :pre
4 atom types # 2 cores and 2 shells for Na and Cl
2 bond types :pre
0.0 24.09597 xlo xhi
0.0 24.09597 ylo yhi
0.0 24.09597 zlo zhi :pre
Masses # core/shell mass ratio = 0.1 :pre
1 20.690784 # Na core
2 31.90500 # Cl core
3 2.298976 # Na shell
4 3.54500 # Cl shell :pre
Atoms :pre
1 1 2 1.5005 0.00000000 0.00000000 0.00000000 # core of core/shell pair 1
2 1 4 -2.5005 0.00000000 0.00000000 0.00000000 # shell of core/shell pair 1
3 2 1 1.5056 4.01599500 4.01599500 4.01599500 # core of core/shell pair 2
4 2 3 -0.5056 4.01599500 4.01599500 4.01599500 # shell of core/shell pair 2
(...) :pre
Bonds # Bond topology for spring forces :pre
1 2 1 2 # spring for core/shell pair 1
2 2 3 4 # spring for core/shell pair 2
(...) :pre
Non-Coulombic (e.g. Lennard-Jones) pairwise interactions are only
defined between the shells. Coulombic interactions are defined
between all cores and shells. If desired, additional bonds can be
specified between cores.
The "special_bonds"_special_bonds.html command should be used to
turn-off the Coulombic interaction within core/shell pairs, since that
interaction is set by the bond spring. This is done using the
"special_bonds"_special_bonds.html command with a 1-2 weight = 0.0,
which is the default value. It needs to be considered whether one has
to adjust the "special_bonds"_special_bonds.html weighting according
to the molecular topology since the interactions of the shells are
bypassed over an extra bond.
Note that this core/shell implementation does not require all ions to
be polarized. One can mix core/shell pairs and ions without a
satellite particle if desired.
Since the core/shell model permits distances of r = 0.0 between the
core and shell, a pair style with a "cs" suffix needs to be used to
implement a valid long-range Coulombic correction. Several such pair
styles are provided in the CORESHELL package. See "this doc
page"_pair_cs.html for details. All of the core/shell enabled pair
styles require the use of a long-range Coulombic solver, as specified
by the "kspace_style"_kspace_style.html command. Either the PPPM or
Ewald solvers can be used.
For the NaCL example problem, these pair style and bond style settings
are used:
pair_style born/coul/long/cs 20.0 20.0
pair_coeff * * 0.0 1.000 0.00 0.00 0.00
pair_coeff 3 3 487.0 0.23768 0.00 1.05 0.50 #Na-Na
pair_coeff 3 4 145134.0 0.23768 0.00 6.99 8.70 #Na-Cl
pair_coeff 4 4 405774.0 0.23768 0.00 72.40 145.40 #Cl-Cl :pre
bond_style harmonic
bond_coeff 1 63.014 0.0
bond_coeff 2 25.724 0.0 :pre
When running dynamics with the adiabatic core/shell model, the
following issues should be considered. The relative motion of
the core and shell particles corresponds to the polarization,
hereby an instantaneous relaxation of the shells is approximated
and a fast core/shell spring frequency ensures a nearly constant
internal kinetic energy during the simulation.
Thermostats can alter this polarization behaviour, by scaling the
internal kinetic energy, meaning the shell will not react freely to
its electrostatic environment.
Therefore it is typically desirable to decouple the relative motion of
the core/shell pair, which is an imaginary degree of freedom, from the
real physical system. To do that, the "compute
temp/cs"_compute_temp_cs.html command can be used, in conjunction with
any of the thermostat fixes, such as "fix nvt"_fix_nh.html or "fix
langevin"_fix_langevin.html. This compute uses the center-of-mass velocity
of the core/shell pairs to calculate a temperature, and insures that
velocity is what is rescaled for thermostatting purposes. This
compute also works for a system with both core/shell pairs and
non-polarized ions (ions without an attached satellite particle). The
"compute temp/cs"_compute_temp_cs.html command requires input of two
groups, one for the core atoms, another for the shell atoms.
Non-polarized ions which might also be included in the treated system
should not be included into either of these groups, they are taken
into account by the {group-ID} (2nd argument) of the compute. The
groups can be defined using the "group {type}"_group.html command.
Note that to perform thermostatting using this definition of
temperature, the "fix modify temp"_fix_modify.html command should be
used to assign the compute to the thermostat fix. Likewise the
"thermo_modify temp"_thermo_modify.html command can be used to make
this temperature be output for the overall system.
For the NaCl example, this can be done as follows:
group cores type 1 2
group shells type 3 4
compute CSequ all temp/cs cores shells
fix thermoberendsen all temp/berendsen 1427 1427 0.4 # thermostat for the true physical system
fix thermostatequ all nve # integrator as needed for the berendsen thermostat
fix_modify thermoberendsen temp CSequ
thermo_modify temp CSequ # output of center-of-mass derived temperature :pre
The pressure for the core/shell system is computed via the regular
LAMMPS convention by "treating the cores and shells as individual
particles"_#MitchellFincham2. For the thermo output of the pressure
as well as for the application of a barostat, it is necessary to
use an additional "pressure"_compute_pressure.html compute based on
the default "temperature"_compute_temp.html and specifying it as a
second argument in "fix modify"_fix_modify.html and
"thermo_modify"_thermo_modify.html resulting in:
(...)
compute CSequ all temp/cs cores shells
compute thermo_press_lmp all pressure thermo_temp # pressure for individual particles
thermo_modify temp CSequ press thermo_press_lmp # modify thermo to regular pressure
fix press_bar all npt temp 300 300 0.04 iso 0 0 0.4
fix_modify press_bar temp CSequ press thermo_press_lmp # pressure modification for correct kinetic scalar :pre
If "compute temp/cs"_compute_temp_cs.html is used, the decoupled
relative motion of the core and the shell should in theory be
stable. However numerical fluctuation can introduce a small
momentum to the system, which is noticable over long trajectories.
Therefore it is recommendable to use the "fix
momentum"_fix_momentum.html command in combination with "compute
temp/cs"_compute_temp_cs.html when equilibrating the system to
prevent any drift.
When initializing the velocities of a system with core/shell pairs, it
is also desirable to not introduce energy into the relative motion of
the core/shell particles, but only assign a center-of-mass velocity to
the pairs. This can be done by using the {bias} keyword of the
"velocity create"_velocity.html command and assigning the "compute
temp/cs"_compute_temp_cs.html command to the {temp} keyword of the
"velocity"_velocity.html command, e.g.
velocity all create 1427 134 bias yes temp CSequ
velocity all scale 1427 temp CSequ :pre
To maintain the correct polarizability of the core/shell pairs, the
kinetic energy of the internal motion shall remain nearly constant.
Therefore the choice of spring force and mass ratio need to ensure
much faster relative motion of the 2 atoms within the core/shell pair
than their center-of-mass velocity. This allows the shells to
effectively react instantaneously to the electrostatic environment and
limits energy transfer to or from the core/shell oscillators.
This fast movement also dictates the timestep that can be used.
The primary literature of the adiabatic core/shell model suggests that
the fast relative motion of the core/shell pairs only allows negligible
energy transfer to the environment.
The mentioned energy transfer will typically lead to a small drift
in total energy over time. This internal energy can be monitored
using the "compute chunk/atom"_compute_chunk_atom.html and "compute
temp/chunk"_compute_temp_chunk.html commands. The internal kinetic
energies of each core/shell pair can then be summed using the sum()
special function of the "variable"_variable.html command. Or they can
be time/averaged and output using the "fix ave/time"_fix_ave_time.html
command. To use these commands, each core/shell pair must be defined
as a "chunk". If each core/shell pair is defined as its own molecule,
the molecule ID can be used to define the chunks. If cores are bonded
to each other to form larger molecules, the chunks can be identified
by the "fix property/atom"_fix_property_atom.html via assigning a
core/shell ID to each atom using a special field in the data file read
by the "read_data"_read_data.html command. This field can then be
accessed by the "compute property/atom"_compute_property_atom.html
command, to use as input to the "compute
chunk/atom"_compute_chunk_atom.html command to define the core/shell
pairs as chunks.
For example if core/shell pairs are the only molecules:
read_data NaCl_CS_x0.1_prop.data
compute prop all property/atom molecule
compute cs_chunk all chunk/atom c_prop
compute cstherm all temp/chunk cs_chunk temp internal com yes cdof 3.0 # note the chosen degrees of freedom for the core/shell pairs
fix ave_chunk all ave/time 10 1 10 c_cstherm file chunk.dump mode vector :pre
For example if core/shell pairs and other molecules are present:
fix csinfo all property/atom i_CSID # property/atom command
read_data NaCl_CS_x0.1_prop.data fix csinfo NULL CS-Info # atom property added in the data-file
compute prop all property/atom i_CSID
(...) :pre
The additional section in the date file would be formatted like this:
CS-Info # header of additional section :pre
1 1 # column 1 = atom ID, column 2 = core/shell ID
2 1
3 2
4 2
5 3
6 3
7 4
8 4
(...) :pre
:line
:link(MitchellFincham)
[(Mitchell and Fincham)] Mitchell, Fincham, J Phys Condensed Matter,
5, 1031-1038 (1993).
:link(MitchellFincham2)
[(Fincham)] Fincham, Mackrodt and Mitchell, J Phys Condensed Matter,
6, 393-404 (1994).

116
doc/src/Howto_couple.txt Normal file
View File

@ -0,0 +1,116 @@
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
Coupling LAMMPS to other codes :h3
LAMMPS is designed to allow it to be coupled to other codes. For
example, a quantum mechanics code might compute forces on a subset of
atoms and pass those forces to LAMMPS. Or a continuum finite element
(FE) simulation might use atom positions as boundary conditions on FE
nodal points, compute a FE solution, and return interpolated forces on
MD atoms.
LAMMPS can be coupled to other codes in at least 4 ways. Each has
advantages and disadvantages, which you'll have to think about in the
context of your application.
:line
(1) Define a new "fix"_fix.html command that calls the other code. In
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 the
"Modify"_Modify.html doc pages for info on how to add a new fix to
LAMMPS.
:link(poems,http://www.rpi.edu/~anderk5/lab)
:line
(2) Define a new LAMMPS command that calls the other code. This is
conceptually similar to method (1), but in this case LAMMPS and the
other code are on a more equal footing. Note that now the other code
is not called during the timestepping of a LAMMPS run, but between
runs. The LAMMPS input script can be used to alternate LAMMPS runs
with calls to the other code, invoked via the new command. The
"run"_run.html command facilitates this with its {every} option, which
makes it easy to run a few steps, invoke the command, run a few steps,
invoke the command, etc.
In this scenario, the other code can be called as a library, as in
(1), or it could be a stand-alone code, invoked by a system() call
made by the command (assuming your parallel machine allows one or more
processors to start up another program). In the latter case the
stand-alone code could communicate with LAMMPS thru files that the
command writes and reads.
See the "Modify command"_Modify_command.html doc page for info on how
to add a new command to LAMMPS.
:line
(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
code could link and call both LAMMPS and another code as libraries.
Again, the "run"_run.html command has options that allow it to be
invoked with minimal overhead (no setup or clean-up) if you wish to do
multiple short runs, driven by another program.
Examples of driver codes that call LAMMPS as a library are included in
the examples/COUPLE directory of the LAMMPS distribution; see
examples/COUPLE/README for more details:
simple: simple driver programs in C++ and C which invoke LAMMPS as a
library :ulb,l
lammps_quest: coupling of LAMMPS and "Quest"_quest, to run classical
MD with quantum forces calculated by a density functional code :l
lammps_spparks: coupling of LAMMPS and "SPPARKS"_spparks, to couple
a kinetic Monte Carlo model for grain growth using MD to calculate
strain induced across grain boundaries :l
:ule
:link(quest,http://dft.sandia.gov/Quest)
:link(spparks,http://www.sandia.gov/~sjplimp/spparks.html)
The "Build basics"_Build_basics.html doc page describes how to build
LAMMPS as a library. Once this is done, you can interface with LAMMPS
either via C++, C, Fortran, or Python (or 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 the "Python"_Python_head.html doc
pages 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 the "Howto library"_Howto_library.html doc page for a
description of the interface and how to extend it for your needs.
Note that the lammps_open() function that creates an instance of
LAMMPS takes an MPI communicator as an argument. This means that
instance of LAMMPS will run on the set of processors in the
communicator. Thus the calling code can run LAMMPS on all or a subset
of processors. For example, a wrapper script might decide to
alternate between LAMMPS and another code, allowing them both to run
on all the processors. Or it might allocate half the processors to
LAMMPS and half to the other code and run both codes simultaneously
before syncing them up periodically. Or it might instantiate multiple
instances of LAMMPS to perform different calculations.
:line
(4) Couple LAMMPS with another code in a client/server mode. This is
described on the "Howto client/server"_Howto_client_server.html doc
page.

31
doc/src/Howto_diffusion.txt Normal file
View File

@ -0,0 +1,31 @@
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
Calculate diffusion coefficients :h3
The diffusion coefficient D of a material can be measured in at least
2 ways using various options in LAMMPS. See the examples/DIFFUSE
directory for scripts that implement the 2 methods discussed here for
a simple Lennard-Jones fluid model.
The first method is to measure the mean-squared displacement (MSD) of
the system, via the "compute msd"_compute_msd.html command. The slope
of the MSD versus time is proportional to the diffusion coefficient.
The instantaneous MSD values can be accumulated in a vector via the
"fix vector"_fix_vector.html command, and a line fit to the vector to
compute its slope via the "variable slope"_variable.html function, and
thus extract D.
The second method is to measure the velocity auto-correlation function
(VACF) of the system, via the "compute vacf"_compute_vacf.html
command. The time-integral of the VACF is proportional to the
diffusion coefficient. The instantaneous VACF values can be
accumulated in a vector via the "fix vector"_fix_vector.html command,
and time integrated via the "variable trap"_variable.html function,
and thus extract D.

108
doc/src/Howto_dispersion.txt Normal file
View File

@ -0,0 +1,108 @@
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
Long-range dispersion settings :h3
The PPPM method computes interactions by splitting the pair potential
into two parts, one of which is computed in a normal pairwise fashion,
the so-called real-space part, and one of which is computed using the
Fourier transform, the so called reciprocal-space or kspace part. For
both parts, the potential is not computed exactly but is approximated.
Thus, there is an error in both parts of the computation, the
real-space and the kspace error. The just mentioned facts are true
both for the PPPM for Coulomb as well as dispersion interactions. The
deciding difference - and also the reason why the parameters for
pppm/disp have to be selected with more care - is the impact of the
errors on the results: The kspace error of the PPPM for Coulomb and
dispersion interaction and the real-space error of the PPPM for
Coulomb interaction have the character of noise. In contrast, the
real-space error of the PPPM for dispersion has a clear physical
interpretation: the underprediction of cohesion. As a consequence, the
real-space error has a much stronger effect than the kspace error on
simulation results for pppm/disp. Parameters must thus be chosen in a
way that this error is much smaller than the kspace error.
When using pppm/disp and not making any specifications on the PPPM
parameters via the kspace modify command, parameters will be tuned
such that the real-space error and the kspace error are equal. This
will result in simulations that are either inaccurate or slow, both of
which is not desirable. For selecting parameters for the pppm/disp
that provide fast and accurate simulations, there are two approaches,
which both have their up- and downsides.
The first approach is to set desired real-space an kspace accuracies
via the {kspace_modify force/disp/real} and {kspace_modify
force/disp/kspace} commands. Note that the accuracies have to be
specified in force units and are thus dependent on the chosen unit
settings. For real units, 0.0001 and 0.002 seem to provide reasonable
accurate and efficient computations for the real-space and kspace
accuracies. 0.002 and 0.05 work well for most systems using lj
units. PPPM parameters will be generated based on the desired
accuracies. The upside of this approach is that it usually provides a
good set of parameters and will work for both the {kspace_modify diff
ad} and {kspace_modify diff ik} options. The downside of the method
is that setting the PPPM parameters will take some time during the
initialization of the simulation.
The second approach is to set the parameters for the pppm/disp
explicitly using the {kspace_modify mesh/disp}, {kspace_modify
order/disp}, and {kspace_modify gewald/disp} commands. This approach
requires a more experienced user who understands well the impact of
the choice of parameters on the simulation accuracy and
performance. This approach provides a fast initialization of the
simulation. However, it is sensitive to errors: A combination of
parameters that will perform well for one system might result in
far-from-optimal conditions for other simulations. For example,
parameters that provide accurate and fast computations for
all-atomistic force fields can provide insufficient accuracy or
united-atomistic force fields (which is related to that the latter
typically have larger dispersion coefficients).
To avoid inaccurate or inefficient simulations, the pppm/disp stops
simulations with an error message if no action is taken to control the
PPPM parameters. If the automatic parameter generation is desired and
real-space and kspace accuracies are desired to be equal, this error
message can be suppressed using the {kspace_modify disp/auto yes}
command.
A reasonable approach that combines the upsides of both methods is to
make the first run using the {kspace_modify force/disp/real} and
{kspace_modify force/disp/kspace} commands, write down the PPPM
parameters from the outut, and specify these parameters using the
second approach in subsequent runs (which have the same composition,
force field, and approximately the same volume).
Concerning the performance of the pppm/disp there are two more things
to consider. The first is that when using the pppm/disp, the cutoff
parameter does no longer affect the accuracy of the simulation
(subject to that gewald/disp is adjusted when changing the cutoff).
The performance can thus be increased by examining different values
for the cutoff parameter. A lower bound for the cutoff is only set by
the truncation error of the repulsive term of pair potentials.
The second is that the mixing rule of the pair style has an impact on
the computation time when using the pppm/disp. Fastest computations
are achieved when using the geometric mixing rule. Using the
arithmetic mixing rule substantially increases the computational cost.
The computational overhead can be reduced using the {kspace_modify
mix/disp geom} and {kspace_modify splittol} commands. The first
command simply enforces geometric mixing of the dispersion
coefficients in kspace computations. This introduces some error in
the computations but will also significantly speed-up the
simulations. The second keyword sets the accuracy with which the
dispersion coefficients are approximated using a matrix factorization
approach. This may result in better accuracy then using the first
command, but will usually also not provide an equally good increase of
efficiency.
Finally, pppm/disp can also be used when no mixing rules apply.
This can be achieved using the {kspace_modify mix/disp none} command.
Note that the code does not check automatically whether any mixing
rule is fulfilled. If mixing rules do not apply, the user will have
to specify this command explicitly.

77
doc/src/Howto_drude.txt Normal file
View File

@ -0,0 +1,77 @@
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
Drude induced dipoles :h3
The thermalized Drude model represents induced dipoles by a pair of
charges (the core atom and the Drude particle) connected by a harmonic
spring. See the "Howto polarizable"_Howto_polarizable.html doc page
for a discussion of all the polarizable models available in LAMMPS.
The Drude model has a number of features aimed at its use in
molecular systems ("Lamoureux and Roux"_#howto-Lamoureux):
Thermostating of the additional degrees of freedom associated with the
induced dipoles at very low temperature, in terms of the reduced
coordinates of the Drude particles with respect to their cores. This
makes the trajectory close to that of relaxed induced dipoles. :ulb,l
Consistent definition of 1-2 to 1-4 neighbors. A core-Drude particle
pair represents a single (polarizable) atom, so the special screening
factors in a covalent structure should be the same for the core and
the Drude particle. Drude particles have to inherit the 1-2, 1-3, 1-4
special neighbor relations from their respective cores. :l
Stabilization of the interactions between induced dipoles. Drude
dipoles on covalently bonded atoms interact too strongly due to the
short distances, so an atom may capture the Drude particle of a
neighbor, or the induced dipoles within the same molecule may align
too much. To avoid this, damping at short range can be done by Thole
functions (for which there are physical grounds). This Thole damping
is applied to the point charges composing the induced dipole (the
charge of the Drude particle and the opposite charge on the core, not
to the total charge of the core atom). :l,ule
A detailed tutorial covering the usage of Drude induced dipoles in
LAMMPS is on the "Howto drude2e"_Howto_drude2.html doc page.
As with the core-shell model, the cores and Drude particles should
appear in the data file as standard atoms. The same holds for the
springs between them, which are described by standard harmonic bonds.
The nature of the atoms (core, Drude particle or non-polarizable) is
specified via the "fix drude"_fix_drude.html command. The special
list of neighbors is automatically refactored to account for the
equivalence of core and Drude particles as regards special 1-2 to 1-4
screening. It may be necessary to use the {extra/special/per/atom}
keyword of the "read_data"_read_data.html command. If using "fix
shake"_fix_shake.html, make sure no Drude particle is in this fix
group.
There are two ways to thermostat the Drude particles at a low
temperature: use either "fix langevin/drude"_fix_langevin_drude.html
for a Langevin thermostat, or "fix
drude/transform/*"_fix_drude_transform.html for a Nose-Hoover
thermostat. The former requires use of the command "comm_modify vel
yes"_comm_modify.html. The latter requires two separate integration
fixes like {nvt} or {npt}. The correct temperatures of the reduced
degrees of freedom can be calculated using the "compute
temp/drude"_compute_temp_drude.html. This requires also to use the
command {comm_modify vel yes}.
Short-range damping of the induced dipole interactions can be achieved
using Thole functions through the "pair style
thole"_pair_thole.html in "pair_style hybrid/overlay"_pair_hybrid.html
with a Coulomb pair style. It may be useful to use {coul/long/cs} or
similar from the CORESHELL package if the core and Drude particle come
too close, which can cause numerical issues.
:line
:link(howto-Lamoureux)
[(Lamoureux and Roux)] G. Lamoureux, B. Roux, J. Chem. Phys 119, 3025 (2003)

2
doc/src/tutorial_drude.txt → doc/src/Howto_drude2.txt
View File

@ -9,7 +9,7 @@
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:link(lc,Commands_all.html)
:line

47
doc/src/Howto_elastic.txt Normal file
View File

@ -0,0 +1,47 @@
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
Calculate elastic constants :h3
Elastic constants characterize the stiffness of a material. The formal
definition is provided by the linear relation that holds between the
stress and strain tensors in the limit of infinitesimal deformation.
In tensor notation, this is expressed as s_ij = C_ijkl * e_kl, where
the repeated indices imply summation. s_ij are the elements of the
symmetric stress tensor. e_kl are the elements of the symmetric strain
tensor. C_ijkl are the elements of the fourth rank tensor of elastic
constants. In three dimensions, this tensor has 3^4=81 elements. Using
Voigt notation, the tensor can be written as a 6x6 matrix, where C_ij
is now the derivative of s_i w.r.t. e_j. Because s_i is itself a
derivative w.r.t. e_i, it follows that C_ij is also symmetric, with at
most 7*6/2 = 21 distinct elements.
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 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
time averages of differential properties. One way to do this is to
measure the change in average stress tensor in an NVT simulations when
the cell volume undergoes a finite deformation. In order to balance
the systematic and statistical errors in this method, the magnitude of
the deformation must be chosen judiciously, and care must be taken to
fully equilibrate the deformed cell before sampling the stress
tensor. Another approach is to sample the triclinic cell fluctuations
that occur in an NPT simulation. This method can also be slow to
converge and requires careful post-processing "(Shinoda)"_#Shinoda1
:line
:link(Shinoda1)
[(Shinoda)] Shinoda, Shiga, and Mikami, Phys Rev B, 69, 134103 (2004).

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