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

Merge branch 'master' into user-cgdna

This commit is contained in:
Oliver Henrich 2020-01-24 14:21:55 +00:00
parent 23febc7101 30444b344b
commit 899a654161
394 changed files with 2062845 additions and 25235 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
.github/CODEOWNERS vendored
View File

@ -111,6 +111,7 @@ src/exceptions.h @rbberger
src/fix_nh.* @athomps
src/info.* @akohlmey @rbberger
src/timer.* @akohlmey
src/min* @sjplimp @stanmoore1
# tools
tools/msi2lmp/* @akohlmey

6
.github/CONTRIBUTING.md vendored
View File

@ -68,12 +68,12 @@ How quickly your contribution will be integrated depends largely on how much eff
Here is a checklist of steps you need to follow to submit a single file or user package for our consideration. Following these steps will save both you and us time. See existing files in packages in the source directory for examples. If you are uncertain, please ask on the lammps-users mailing list.
* All source files you provide must compile with the most current version of LAMMPS with multiple configurations. In particular you need to test compiling LAMMPS from scratch with `-DLAMMPS_BIGBIG` set in addition to the default `-DLAMMPS_SMALLBIG` setting. Your code will need to work correctly in serial and in parallel using MPI.
* For consistency with the rest of LAMMPS and especially, if you want your contribution(s) to be added to main LAMMPS code or one of its standard packages, it needs to be written in a style compatible with other LAMMPS source files. This means: 2-character indentation per level, no tabs, no lines over 80 characters. I/O is done via the C-style stdio library, style class header files should not import any system headers, STL containers should be avoided in headers, and forward declarations used where possible or needed. All added code should be placed into the LAMMPS_NS namespace or a sub-namespace; global or static variables should be avoided, as they conflict with the modular nature of LAMMPS and the C++ class structure. There MUST NOT be any "using namespace XXX;" statements in headers. In the implementation file (<name>.cpp) system includes should be placed in angular brackets (<>) and for c-library functions the C++ style header files should be included (<cstdio> instead of <stdio.h>, or <cstring> instead of <string.h>). This all is so the developers can more easily understand, integrate, and maintain your contribution and reduce conflicts with other parts of LAMMPS. This basically means that the code accesses data structures, performs its operations, and is formatted similar to other LAMMPS source files, including the use of the error class for error and warning messages.
* Source, style name, and documentation file should follow the following naming convention: style names should be lowercase and words separated by a forward slash; for a new fix style 'foo/bar', the class should be named FixFooBar, the name of the source files should be 'fix_foo_bar.h' and 'fix_foo_bar.cpp' and the corresponding documentation should be in a file 'fix_foo_bar.txt'.
* For consistency with the rest of LAMMPS and especially, if you want your contribution(s) to be added to main LAMMPS code or one of its standard packages, it needs to be written in a style compatible with other LAMMPS source files. This means: 2-character indentation per level, no tabs, no trailing whitespace, no lines over 80 characters. I/O is done via the C-style stdio library, style class header files should not import any system headers, STL containers should be avoided in headers, and forward declarations used where possible or needed. All added code should be placed into the LAMMPS_NS namespace or a sub-namespace; global or static variables should be avoided, as they conflict with the modular nature of LAMMPS and the C++ class structure. There MUST NOT be any "using namespace XXX;" statements in headers. In the implementation file (<name>.cpp) system includes should be placed in angular brackets (<>) and for c-library functions the C++ style header files should be included (<cstdio> instead of <stdio.h>, or <cstring> instead of <string.h>). This all is so the developers can more easily understand, integrate, and maintain your contribution and reduce conflicts with other parts of LAMMPS. This basically means that the code accesses data structures, performs its operations, and is formatted similar to other LAMMPS source files, including the use of the error class for error and warning messages.
* Source, style name, and documentation file should follow the following naming convention: style names should be lowercase and words separated by a forward slash; for a new fix style 'foo/bar', the class should be named FixFooBar, the name of the source files should be 'fix_foo_bar.h' and 'fix_foo_bar.cpp' and the corresponding documentation should be in a file 'fix_foo_bar.rst'.
* If you want your contribution to be added as a user-contributed feature, and it is a single file (actually a `<name>.cpp` and `<name>.h` file) it can be rapidly added to the USER-MISC directory. Include the one-line entry to add to the USER-MISC/README file in that directory, along with the 2 source files. You can do this multiple times if you wish to contribute several individual features.
* If you want your contribution to be added as a user-contribution and it is several related features, it is probably best to make it a user package directory with a name like USER-FOO. In addition to your new files, the directory should contain a README text file. The README should contain your name and contact information and a brief description of what your new package does. If your files depend on other LAMMPS style files also being installed (e.g. because your file is a derived class from the other LAMMPS class), then an Install.sh file is also needed to check for those dependencies. See other README and Install.sh files in other USER directories as examples. Send us a tarball of this USER-FOO directory.
* Your new source files need to have the LAMMPS copyright, GPL notice, and your name and email address at the top, like other user-contributed LAMMPS source files. They need to create a class that is inside the LAMMPS namespace. If the file is for one of the USER packages, including USER-MISC, then we are not as picky about the coding style (see above). I.e. the files do not need to be in the same stylistic format and syntax as other LAMMPS files, though that would be nice for developers as well as users who try to read your code.
* You **must** also create or extend a documentation file for each new command or style you are adding to LAMMPS. For simplicity and convenience, the documentation of groups of closely related commands or styles may be combined into a single file. This will be one file for a single-file feature. For a package, it might be several files. These are simple text files with a specific markup language, that are then auto-converted to HTML and PDF. The tools for this conversion are included in the source distribution, and the translation can be as simple as doing "make html pdf" in the doc folder. Thus the documentation source files must be in the same format and style as other `<name>.txt` files in the lammps/doc/src directory for similar commands and styles; use one or more of them as a starting point. A description of the markup can also be found in `lammps/doc/utils/txt2html/README.html` As appropriate, the text files can include links to equations (see doc/Eqs/*.tex for examples, we auto-create the associated JPG files), or figures (see doc/JPG for examples), or even additional PDF files with further details (see doc/PDF for examples). The doc page should also include literature citations as appropriate; see the bottom of doc/fix_nh.txt for examples and the earlier part of the same file for how to format the cite itself. The "Restrictions" section of the doc page should indicate that your command is only available if LAMMPS is built with the appropriate USER-MISC or USER-FOO package. See other user package doc files for examples of how to do this. The prerequisite for building the HTML format files are Python 3.x and virtualenv, the requirement for generating the PDF format manual is the htmldoc software. Please run at least "make html" and carefully inspect and proofread the resulting HTML format doc page before submitting your code.
* You **must** also create or extend a documentation file for each new command or style you are adding to LAMMPS. For simplicity and convenience, the documentation of groups of closely related commands or styles may be combined into a single file. This will be one file for a single-file feature. For a package, it might be several files. These are files in the [reStructuredText](https://docutils.sourceforge.io/rst.html) markup language, that are then converted to HTML and PDF. The tools for this conversion are included in the source distribution, and the translation can be as simple as doing "make html pdf" in the doc folder. Thus the documentation source files must be in the same format and style as other `<name>.rst` files in the lammps/doc/src directory for similar commands and styles; use one or more of them as a starting point. An introduction to reStructuredText can be found at [https://docutils.sourceforge.io/docs/user/rst/quickstart.html](https://docutils.sourceforge.io/docs/user/rst/quickstart.html). As appropriate, the text files can include mathematical expressions in MathJAX markup or links to equations (see doc/Eqs/*.tex for examples, we auto-create the associated JPG files), or figures (see doc/JPG for examples), or even additional PDF files with further details (see doc/PDF for examples). The doc page should also include literature citations as appropriate; see the bottom of doc/fix_nh.rst for examples and the earlier part of the same file for how to format the cite itself. The "Restrictions" section of the doc page should indicate that your command is only available if LAMMPS is built with the appropriate USER-MISC or USER-FOO package. See other user package doc files for examples of how to do this. The prerequisite for building the HTML format files are Python 3.x and virtualenv. Please run at least `make html` and `make spelling` and carefully inspect and proofread the resulting HTML format doc page as well as the output produced to the screen. Make sure that all spelling errors are fixed or the necessary false positives are added to the `doc/utils/sphinx-config/false_positives.txt` file. For new styles, those usually also need to be added to lists on the respective overview pages. This can be checked for also with `make style_check`.
* For a new package (or even a single command) you should include one or more example scripts demonstrating its use. These should run in no more than a couple minutes, even on a single processor, and not require large data files as input. See directories under examples/USER for examples of input scripts other users provided for their packages. These example inputs are also required for validating memory accesses and testing for memory leaks with valgrind
* If there is a paper of yours describing your feature (either the algorithm/science behind the feature itself, or its initial usage, or its implementation in LAMMPS), you can add the citation to the *.cpp source file. See src/USER-EFF/atom_vec_electron.cpp for an example. A LaTeX citation is stored in a variable at the top of the file and a single line of code that references the variable is added to the constructor of the class. Whenever a user invokes your feature from their input script, this will cause LAMMPS to output the citation to a log.cite file and prompt the user to examine the file. Note that you should only use this for a paper you or your group authored. E.g. adding a cite in the code for a paper by Nose and Hoover if you write a fix that implements their integrator is not the intended usage. That kind of citation should just be in the doc page you provide.

3
cmake/CMakeLists.txt
View File

@ -588,8 +588,9 @@ if(BUILD_TOOLS)
install(TARGETS binary2txt DESTINATION ${CMAKE_INSTALL_BINDIR})
# ninja-build currently does not support fortran. thus we skip building this tool
if(NOT CMAKE_GENERATOR STREQUAL "Ninja")
if(CMAKE_GENERATOR STREQUAL "Ninja")
message(STATUS "Skipping building 'chain.x' with Ninja build tool due to lack of Fortran support")
else()
enable_language(Fortran)
add_executable(chain.x ${LAMMPS_TOOLS_DIR}/chain.f)
target_link_libraries(chain.x ${CMAKE_Fortran_IMPLICIT_LINK_LIBRARIES})

6
cmake/Modules/FindNetCDF.cmake
View File

@ -46,10 +46,14 @@ endif()
find_path (NETCDF_INCLUDE_DIR netcdf.h
HINTS "${NETCDF_DIR}/include")
mark_as_advanced (NETCDF_INCLUDE_DIR)
set (NETCDF_C_INCLUDE_DIRS ${NETCDF_INCLUDE_DIR})
string(REGEX REPLACE "/include/?$" ""
NETCDF_LIB_HINT ${NETCDF_INCLUDE_DIR})
find_library (NETCDF_LIBRARY NAMES netcdf
HINTS "${NETCDF_DIR}/lib")
HINTS "${NETCDF_DIR}" "${NETCDF_LIB_HINT}" PATH_SUFFIXES lib lib64)
mark_as_advanced (NETCDF_LIBRARY)
set (NETCDF_C_LIBRARIES ${NETCDF_LIBRARY})

55
cmake/Modules/FindPNetCDF.cmake Normal file
View File

@ -0,0 +1,55 @@
# source: https://ftp.space.dtu.dk/pub/Ioana/pism0.6.1-10/CMake/FindPNetCDF.cmake
# license: GPL v3 (https://ftp.space.dtu.dk/pub/Ioana/pism0.6.1-10/COPYING)
#
# - Find PNetCDF
# Find the native PNetCDF includes and library
#
# PNETCDF_INCLUDES - where to find netcdf.h, etc
# PNETCDF_LIBRARIES - Link these libraries when using NetCDF
# PNETCDF_FOUND - True if PNetCDF was found
#
# Normal usage would be:
# find_package (PNetCDF REQUIRED)
# target_link_libraries (uses_pnetcdf ${PNETCDF_LIBRARIES})
if (PNETCDF_INCLUDES AND PNETCDF_LIBRARIES)
# Already in cache, be silent
set (PNETCDF_FIND_QUIETLY TRUE)
endif (PNETCDF_INCLUDES AND PNETCDF_LIBRARIES)
find_path (PNETCDF_INCLUDES pnetcdf.h
HINTS "${PNETCDF_ROOT}/include" "$ENV{PNETCDF_ROOT}/include")
string(REGEX REPLACE "/include/?$" ""
PNETCDF_LIB_HINT ${PNETCDF_INCLUDES})
find_library (PNETCDF_LIBRARIES
NAMES pnetcdf
HINTS ${PNETCDF_LIB_HINT} PATH_SUFFIXES lib lib64)
if ((NOT PNETCDF_LIBRARIES) OR (NOT PNETCDF_INCLUDES))
message(STATUS "Trying to find PNetCDF using LD_LIBRARY_PATH (we're desperate)...")
file(TO_CMAKE_PATH "$ENV{LD_LIBRARY_PATH}" LD_LIBRARY_PATH)
find_library(PNETCDF_LIBRARIES
NAMES pnetcdf
HINTS ${LD_LIBRARY_PATH})
if (PNETCDF_LIBRARIES)
get_filename_component(PNETCDF_LIB_DIR ${PNETCDF_LIBRARIES} PATH)
string(REGEX REPLACE "/(lib|lib64)/?$" "/include"
PNETCDF_H_HINT ${PNETCDF_LIB_DIR})
find_path (PNETCDF_INCLUDES pnetcdf.h
HINTS ${PNETCDF_H_HINT}
DOC "Path to pnetcdf.h")
endif()
endif()
# handle the QUIETLY and REQUIRED arguments and set PNETCDF_FOUND to TRUE if
# all listed variables are TRUE
include (FindPackageHandleStandardArgs)
find_package_handle_standard_args (PNetCDF DEFAULT_MSG PNETCDF_LIBRARIES PNETCDF_INCLUDES)
mark_as_advanced (PNETCDF_LIBRARIES PNETCDF_INCLUDES)

26
cmake/Modules/Packages/USER-NETCDF.cmake
View File

@ -1,6 +1,24 @@
if(PKG_USER-NETCDF)
find_package(NetCDF REQUIRED)
include_directories(${NETCDF_INCLUDE_DIRS})
list(APPEND LAMMPS_LINK_LIBS ${NETCDF_LIBRARIES})
add_definitions(-DLMP_HAS_NETCDF -DNC_64BIT_DATA=0x0020)
# USER-NETCDF can use NetCDF, Parallel NetCDF (PNetCDF), or both. At least one necessary.
# NetCDF library enables dump sytle "netcdf", while PNetCDF enables dump style "netcdf/mpiio"
find_package(NetCDF)
if(NETCDF_FOUND)
find_package(PNetCDF)
else(NETCDF_FOUND)
find_package(PNetCDF REQUIRED)
endif(NETCDF_FOUND)
if(NETCDF_FOUND)
include_directories(${NETCDF_INCLUDE_DIRS})
list(APPEND LAMMPS_LINK_LIBS ${NETCDF_LIBRARIES})
add_definitions(-DLMP_HAS_NETCDF)
endif(NETCDF_FOUND)
if(PNETCDF_FOUND)
include_directories(${PNETCDF_INCLUDES})
list(APPEND LAMMPS_LINK_LIBS ${PNETCDF_LIBRARIES})
add_definitions(-DLMP_HAS_PNETCDF)
endif(PNETCDF_FOUND)
add_definitions(-DNC_64BIT_DATA=0x0020)
endif()

46
doc/Makefile
View File

@ -31,7 +31,7 @@ SPHINXEXTRA = -j $(shell $(PYTHON) -c 'import multiprocessing;print(multiprocess
SOURCES=$(filter-out $(wildcard $(TXTDIR)/lammps_commands*.txt) $(TXTDIR)/lammps_support.txt $(TXTDIR)/lammps_tutorials.txt,$(wildcard $(TXTDIR)/*.txt))
OBJECTS=$(SOURCES:$(TXTDIR)/%.txt=$(RSTDIR)/%.rst)
.PHONY: help clean-all clean epub mobi rst html pdf venv spelling anchor_check
.PHONY: help clean-all clean epub mobi rst html pdf venv spelling anchor_check style_check
# ------------------------------------------
@ -46,6 +46,7 @@ help:
@echo " clean remove all intermediate RST files"
@echo " clean-all reset the entire build environment"
@echo " anchor_check scan for duplicate anchor labels"
@echo " style_check check for complete and consistent style lists"
@echo " spelling spell-check the manual"
# ------------------------------------------
@ -69,6 +70,7 @@ html: $(OBJECTS) $(ANCHORCHECK)
echo "############################################" ;\
rst_anchor_check src/*.rst ;\
env LC_ALL=C grep -n '[^ -~]' $(RSTDIR)/*.rst ;\
python utils/check-styles.py -s ../src -d src ;\
echo "############################################" ;\
deactivate ;\
)
@ -122,24 +124,27 @@ pdf: $(OBJECTS) $(ANCHORCHECK)
cd ../../; \
)
@(\
. $(VENV)/bin/activate ;\
sphinx-build $(SPHINXEXTRA) -b latex -c utils/sphinx-config -d $(BUILDDIR)/doctrees $(RSTDIR) latex ;\
echo "############################################" ;\
rst_anchor_check src/*.rst ;\
echo "############################################" ;\
deactivate ;\
. $(VENV)/bin/activate ;\
sphinx-build $(SPHINXEXTRA) -b latex -c utils/sphinx-config -d $(BUILDDIR)/doctrees $(RSTDIR) latex ;\
echo "############################################" ;\
rst_anchor_check src/*.rst ;\
env LC_ALL=C grep -n '[^ -~]' $(RSTDIR)/*.rst ;\
python utils/check-styles.py -s ../src -d src ;\
echo "############################################" ;\
deactivate ;\
)
@cd latex && \
sed 's/latexmk -pdf -dvi- -ps-/pdflatex/g' Makefile > temp && \
mv temp Makefile && \
sed 's/\\begin{equation}//g' LAMMPS.tex > tmp.tex && \
mv tmp.tex LAMMPS.tex && \
sed 's/\\end{equation}//g' LAMMPS.tex > tmp.tex && \
mv tmp.tex LAMMPS.tex && \
make && \
make && \
mv LAMMPS.pdf ../Manual.pdf && \
cd ../;
sed 's/latexmk -pdf -dvi- -ps-/pdflatex/g' Makefile > temp && \
mv temp Makefile && \
sed 's/\\begin{equation}//g' LAMMPS.tex > tmp.tex && \
mv tmp.tex LAMMPS.tex && \
sed 's/\\end{equation}//g' LAMMPS.tex > tmp.tex && \
mv tmp.tex LAMMPS.tex && \
make && \
make && \
make && \
mv LAMMPS.pdf ../Manual.pdf && \
cd ../;
@rm -rf latex/_sources
@rm -rf latex/PDF
@rm -rf latex/USER
@ -166,6 +171,13 @@ anchor_check : $(ANCHORCHECK)
deactivate ;\
)
style_check :
@(\
. $(VENV)/bin/activate ;\
python utils/check-styles.py -s ../src -d src ;\
deactivate ;\
)
# ------------------------------------------
$(RSTDIR)/%.rst : $(TXTDIR)/%.txt $(TXT2RST)

11
doc/github-development-workflow.md
View File

@ -104,14 +104,17 @@ Here are some items to check:
* every new command or style should have documentation. The names of
source files (c++ and manual) should follow the name of the style.
(example: `src/fix_nve.cpp`, `src/fix_nve.h` for `fix nve` command,
implementing the class `FixNVE`, documented in `doc/src/fix_nve.txt`)
implementing the class `FixNVE`, documented in `doc/src/fix_nve.rst`)
* all new style names should be lower case, the must be no dashes,
blanks, or underscores separating words, only forward slashes.
* new style docs should be added to the "overview" files in
`doc/src/Commands_*.txt`, `doc/src/{fixes,computes,pairs,bonds,...}.txt`
and `doc/src/lammps.book`
`doc/src/Commands_*.rst`, `doc/src/{fixes,computes,pairs,bonds,...}.rst`
* check whether manual cleanly translates with `make html` and `make pdf`
* if documentation is (still) provided as a .txt file, convert to .rst
and remove the .txt file. For files in doc/txt the conversion is automatic.
* remove all .txt files in `doc/txt` that are out of sync with their .rst counterparts in `doc/src`
* check spelling of manual with `make spelling` in doc folder
* check style tables and command lists with `make style_check`
* new source files in packages should be added to `src/.gitignore`
* removed or renamed files in packages should be added to `src/Purge.list`
* C++ source files should use C++ style include files for accessing
@ -136,7 +139,7 @@ Here are some items to check:
* Code should follow the C++-98 standard. C++-11 is only accepted
in individual special purpose packages
* indentation is 2 spaces per level
* there should be NO tabs and no trailing whitespace
* there should be NO tabs and no trailing whitespace (review the "checkstyle" test on pull requests)
* header files, especially of new styles, should not include any
other headers, except the header with the base class or cstdio.
Forward declarations should be used instead when possible.

2
doc/lammps.1
View File

@ -1,4 +1,4 @@
.TH LAMMPS "20 November 2019" "2019-11-20"
.TH LAMMPS "9 January 2020" "2020-01-09"
.SH NAME
.B LAMMPS
\- Molecular Dynamics Simulator.

2
doc/src/Build_extras.rst
View File

@ -203,7 +203,7 @@ inside the CMake build directory. If the KIM library is already on
your system (in a location CMake cannot find it), set the PKG\_CONFIG\_PATH
environment variable so that libkim-api can be found.
For using KIM web queries.
For using OpenKIM web queries in LAMMPS.
If LMP\_DEBUG\_CURL is set, the libcurl verbose mode will be on, and any
libcurl calls within the KIM web query display a lot of information about

96
doc/src/Commands_all.rst
View File

@ -25,102 +25,105 @@ An alphabetic list of all general LAMMPS commands.
* :doc:`atom_style <atom_style>`
* :doc:`balance <balance>`
* :doc:`bond_coeff <bond_coeff>`
* :doc:`bond\_style <bond_style>`
* :doc:`bond\_write <bond_write>`
* :doc:`bond_style <bond_style>`
* :doc:`bond_write <bond_write>`
* :doc:`boundary <boundary>`
* :doc:`box <box>`
* :doc:`change\_box <change_box>`
* :doc:`change_box <change_box>`
* :doc:`clear <clear>`
* :doc:`comm\_modify <comm_modify>`
* :doc:`comm\_style <comm_style>`
* :doc:`comm_modify <comm_modify>`
* :doc:`comm_style <comm_style>`
* :doc:`compute <compute>`
* :doc:`compute\_modify <compute_modify>`
* :doc:`create\_atoms <create_atoms>`
* :doc:`create\_bonds <create_bonds>`
* :doc:`create\_box <create_box>`
* :doc:`delete\_atoms <delete_atoms>`
* :doc:`delete\_bonds <delete_bonds>`
* :doc:`compute_modify <compute_modify>`
* :doc:`create_atoms <create_atoms>`
* :doc:`create_bonds <create_bonds>`
* :doc:`create_box <create_box>`
* :doc:`delete_atoms <delete_atoms>`
* :doc:`delete_bonds <delete_bonds>`
* :doc:`dielectric <dielectric>`
* :doc:`dihedral\_coeff <dihedral_coeff>`
* :doc:`dihedral\_style <dihedral_style>`
* :doc:`dihedral_coeff <dihedral_coeff>`
* :doc:`dihedral_style <dihedral_style>`
* :doc:`dimension <dimension>`
* :doc:`displace\_atoms <displace_atoms>`
* :doc:`displace_atoms <displace_atoms>`
* :doc:`dump <dump>`
* :doc:`dump adios <dump_adios>`
* :doc:`dump atom/adios <dump_adios>`
* :doc:`dump custom/adios <dump_adios>`
* :doc:`dump image <dump_image>`
* :doc:`dump movie <dump_image>`
* :doc:`dump netcdf <dump_netcdf>`
* :doc:`dump netcdf/mpiio <dump_netcdf>`
* :doc:`dump vtk <dump_vtk>`
* :doc:`dump\_modify <dump_modify>`
* :doc:`dynamical\_matrix <dynamical_matrix>`
* :doc:`dump_modify <dump_modify>`
* :doc:`dynamical_matrix <dynamical_matrix>`
* :doc:`echo <echo>`
* :doc:`fix <fix>`
* :doc:`fix\_modify <fix_modify>`
* :doc:`fix_modify <fix_modify>`
* :doc:`group <group>`
* :doc:`group2ndx <group2ndx>`
* :doc:`hyper <hyper>`
* :doc:`if <if>`
* :doc:`improper\_coeff <improper_coeff>`
* :doc:`improper\_style <improper_style>`
* :doc:`improper_coeff <improper_coeff>`
* :doc:`improper_style <improper_style>`
* :doc:`include <include>`
* :doc:`info <info>`
* :doc:`jump <jump>`
* :doc:`kim\_init <kim_commands>`
* :doc:`kim\_interactions <kim_commands>`
* :doc:`kim\_query <kim_commands>`
* :doc:`kspace\_modify <kspace_modify>`
* :doc:`kspace\_style <kspace_style>`
* :doc:`kim_init <kim_commands>`
* :doc:`kim_interactions <kim_commands>`
* :doc:`kim_param <kim_commands>`
* :doc:`kim_query <kim_commands>`
* :doc:`kspace_modify <kspace_modify>`
* :doc:`kspace_style <kspace_style>`
* :doc:`label <label>`
* :doc:`lattice <lattice>`
* :doc:`log <log>`
* :doc:`mass <mass>`
* :doc:`message <message>`
* :doc:`minimize <minimize>`
* :doc:`min\_modify <min_modify>`
* :doc:`min\_style <min_style>`
* :doc:`min\_style spin <min_spin>`
* :doc:`min_modify <min_modify>`
* :doc:`min_style <min_style>`
* :doc:`min_style spin <min_spin>`
* :doc:`molecule <molecule>`
* :doc:`ndx2group <group2ndx>`
* :doc:`neb <neb>`
* :doc:`neb/spin <neb_spin>`
* :doc:`neigh\_modify <neigh_modify>`
* :doc:`neigh_modify <neigh_modify>`
* :doc:`neighbor <neighbor>`
* :doc:`newton <newton>`
* :doc:`next <next>`
* :doc:`package <package>`
* :doc:`pair\_coeff <pair_coeff>`
* :doc:`pair\_modify <pair_modify>`
* :doc:`pair\_write <pair_write>`
* :doc:`pair_coeff <pair_coeff>`
* :doc:`pair_modify <pair_modify>`
* :doc:`pair_write <pair_write>`
* :doc:`partition <partition>`
* :doc:`prd <prd>`
* :doc:`print <print>`
* :doc:`processors <processors>`
* :doc:`python <python>`
* :doc:`quit <quit>`
* :doc:`read\_data <read_data>`
* :doc:`read\_dump <read_dump>`
* :doc:`read\_restart <read_restart>`
* :doc:`read_data <read_data>`
* :doc:`read_dump <read_dump>`
* :doc:`read_restart <read_restart>`
* :doc:`region <region>`
* :doc:`replicate <replicate>`
* :doc:`rerun <rerun>`
* :doc:`reset\_ids <reset_ids>`
* :doc:`reset\_timestep <reset_timestep>`
* :doc:`reset_ids <reset_ids>`
* :doc:`reset_timestep <reset_timestep>`
* :doc:`restart <restart>`
* :doc:`run <run>`
* :doc:`run\_style <run_style>`
* :doc:`run_style <run_style>`
* :doc:`server <server>`
* :doc:`set <set>`
* :doc:`shell <shell>`
* :doc:`special\_bonds <special_bonds>`
* :doc:`special_bonds <special_bonds>`
* :doc:`suffix <suffix>`
* :doc:`tad <tad>`
* :doc:`temper <temper>`
* :doc:`temper/grem <temper_grem>`
* :doc:`temper/npt <temper_npt>`
* :doc:`thermo <thermo>`
* :doc:`thermo\_modify <thermo_modify>`
* :doc:`thermo\_style <thermo_style>`
* :doc:`third\_order <third_order>`
* :doc:`thermo_modify <thermo_modify>`
* :doc:`thermo_style <thermo_style>`
* :doc:`third_order <third_order>`
* :doc:`timer <timer>`
* :doc:`timestep <timestep>`
* :doc:`uncompute <uncompute>`
@ -129,7 +132,8 @@ An alphabetic list of all general LAMMPS commands.
* :doc:`units <units>`
* :doc:`variable <variable>`
* :doc:`velocity <velocity>`
* :doc:`write\_coeff <write_coeff>`
* :doc:`write\_data <write_data>`
* :doc:`write\_dump <write_dump>`
* :doc:`write\_restart <write_restart>`
* :doc:`write_coeff <write_coeff>`
* :doc:`write_data <write_data>`
* :doc:`write_dump <write_dump>`
* :doc:`write_restart <write_restart>`

19
doc/src/Commands_bond.rst
View File

@ -13,7 +13,7 @@
.. _bond:
bond_style potentials
Bond_style potentials
=====================
All LAMMPS :doc:`bond_style <bond_style>` commands. Some styles have
@ -44,16 +44,13 @@ OPT.
* :doc:`nonlinear (o) <bond_nonlinear>`
* :doc:`oxdna/fene <bond_oxdna>`
* :doc:`oxdna2/fene <bond_oxdna>`
* :doc:`oxrna2/fene <bond_oxdna>`
* :doc:`quartic (o) <bond_quartic>`
* :doc:`table (o) <bond_table>`
*
*
---
.. _angle:
angle_style potentials
Angle_style potentials
======================
All LAMMPS :doc:`angle_style <angle_style>` commands. Some styles have
@ -91,13 +88,10 @@ OPT.
* :doc:`quartic (o) <angle_quartic>`
* :doc:`sdk (o) <angle_sdk>`
* :doc:`table (o) <angle_table>`
*
---
.. _dihedral:
dihedral_style potentials
Dihedral_style potentials
=========================
All LAMMPS :doc:`dihedral_style <dihedral_style>` commands. Some styles
@ -131,12 +125,10 @@ OPT.
* :doc:`spherical <dihedral_spherical>`
* :doc:`table (o) <dihedral_table>`
* :doc:`table/cut <dihedral_table_cut>`
*
*
.. _improper:
improper_style potentials
Improper_style potentials
=========================
All LAMMPS :doc:`improper\_style <improper_style>` commands. Some styles
@ -166,4 +158,3 @@ OPT.
* :doc:`ring (o) <improper_ring>`
* :doc:`sqdistharm <improper_sqdistharm>`
* :doc:`umbrella (o) <improper_umbrella>`
*

4
doc/src/Commands_compute.rst
View File

@ -163,6 +163,4 @@ KOKKOS, o = USER-OMP, t = OPT.
* :doc:`vcm/chunk <compute_vcm_chunk>`
* :doc:`voronoi/atom <compute_voronoi_atom>`
* :doc:`xrd <compute_xrd>`
*
*
*

20
doc/src/Commands_fix.rst
View File

@ -105,16 +105,17 @@ OPT.
* :doc:`mvv/edpd <fix_mvv_dpd>`
* :doc:`mvv/tdpd <fix_mvv_dpd>`
* :doc:`neb <fix_neb>`
* :doc:`neb\_spin <fix_neb_spin>`
* :doc:`neb/spin <fix_neb_spin>`
* :doc:`nph (ko) <fix_nh>`
* :doc:`nph/asphere (o) <fix_nph_asphere>`
* :doc:`nph/body <fix_nph_body>`
* :doc:`nph/eff <fix_nh_eff>`
* :doc:`nph/sphere (o) <fix_nph_sphere>`
* :doc:`nphug (o) <fix_nphug>`
* :doc:`nphug <fix_nphug>`
* :doc:`npt (iko) <fix_nh>`
* :doc:`npt/asphere (o) <fix_npt_asphere>`
* :doc:`npt/body <fix_npt_body>`
* :doc:`npt/cauchy <fix_npt_cauchy>`
* :doc:`npt/eff <fix_nh_eff>`
* :doc:`npt/sphere (o) <fix_npt_sphere>`
* :doc:`npt/uef <fix_nh_uef>`
@ -155,6 +156,7 @@ OPT.
* :doc:`precession/spin <fix_precession_spin>`
* :doc:`press/berendsen <fix_press_berendsen>`
* :doc:`print <fix_print>`
* :doc:`propel/self <fix_propel_self>`
* :doc:`property/atom (k) <fix_property_atom>`
* :doc:`python/invoke <fix_python_invoke>`
* :doc:`python/move <fix_python_move>`
@ -188,15 +190,16 @@ OPT.
* :doc:`rx (k) <fix_rx>`
* :doc:`saed/vtk <fix_saed_vtk>`
* :doc:`setforce (k) <fix_setforce>`
* :doc:`setforce/spin <fix_setforce>`
* :doc:`shake <fix_shake>`
* :doc:`shardlow (k) <fix_shardlow>`
* :doc:`smd <fix_smd>`
* :doc:`smd/adjust\_dt <fix_smd_adjust_dt>`
* :doc:`smd/integrate\_tlsph <fix_smd_integrate_tlsph>`
* :doc:`smd/integrate\_ulsph <fix_smd_integrate_ulsph>`
* :doc:`smd/move\_tri\_surf <fix_smd_move_triangulated_surface>`
* :doc:`smd/adjust_dt <fix_smd_adjust_dt>`
* :doc:`smd/integrate_tlsph <fix_smd_integrate_tlsph>`
* :doc:`smd/integrate_ulsph <fix_smd_integrate_ulsph>`
* :doc:`smd/move_tri_surf <fix_smd_move_triangulated_surface>`
* :doc:`smd/setvel <fix_smd_setvel>`
* :doc:`smd/wall\_surface <fix_smd_wall_surface>`
* :doc:`smd/wall_surface <fix_smd_wall_surface>`
* :doc:`spring <fix_spring>`
* :doc:`spring/chunk <fix_spring_chunk>`
* :doc:`spring/rg <fix_spring_rg>`
@ -233,8 +236,7 @@ OPT.
* :doc:`wall/morse <fix_wall>`
* :doc:`wall/piston <fix_wall_piston>`
* :doc:`wall/reflect (k) <fix_wall_reflect>`
* :doc:`wall/reflect/stochastic <fix_wall_reflect_stochastic>`
* :doc:`wall/region <fix_wall_region>`
* :doc:`wall/region/ees <fix_wall_ees>`
* :doc:`wall/srd <fix_wall_srd>`
*
*

11
doc/src/Commands_kspace.rst
View File

@ -24,13 +24,16 @@ OPT.
* :doc:`ewald (o) <kspace_style>`
* :doc:`ewald/disp <kspace_style>`
* :doc:`ewald/dipole <kspace_style>`
* :doc:`ewald/dipole/spin <kspace_style>`
* :doc:`msm (o) <kspace_style>`
* :doc:`msm/cg (o) <kspace_style>`
* :doc:`pppm (gok) <kspace_style>`
* :doc:`pppm (giko) <kspace_style>`
* :doc:`pppm/cg (o) <kspace_style>`
* :doc:`pppm/disp (i) <kspace_style>`
* :doc:`pppm/disp/tip4p <kspace_style>`
* :doc:`pppm/dipole <kspace_style>`
* :doc:`pppm/dipole/spin <kspace_style>`
* :doc:`pppm/disp (io) <kspace_style>`
* :doc:`pppm/disp/tip4p (o) <kspace_style>`
* :doc:`pppm/stagger <kspace_style>`
* :doc:`pppm/tip4p (o) <kspace_style>`
* :doc:`scafacos <kspace_style>`
*

21
doc/src/Commands_pair.rst
View File

@ -11,10 +11,10 @@
* :ref:`Improper styles <improper>`
* :doc:`KSpace styles <Commands_kspace>`
Pair\_style potentials
Pair_style potentials
======================
All LAMMPS :doc:`pair\_style <pair_style>` commands. Some styles have
All LAMMPS :doc:`pair_style <pair_style>` 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.
@ -146,7 +146,7 @@ OPT.
* :doc:`lj/cut/soft (o) <pair_fep_soft>`
* :doc:`lj/cut/thole/long (o) <pair_thole>`
* :doc:`lj/cut/tip4p/cut (o) <pair_lj>`
* :doc:`lj/cut/tip4p/long (ot) <pair_lj>`
* :doc:`lj/cut/tip4p/long (got) <pair_lj>`
* :doc:`lj/cut/tip4p/long/soft (o) <pair_fep_soft>`
* :doc:`lj/expand (gko) <pair_lj_expand>`
* :doc:`lj/expand/coul/long (g) <pair_lj_expand>`
@ -162,7 +162,7 @@ OPT.
* :doc:`lj/sf/dipole/sf (go) <pair_dipole>`
* :doc:`lj/smooth (o) <pair_lj_smooth>`
* :doc:`lj/smooth/linear (o) <pair_lj_smooth_linear>`
* :doc:`lj/switch3/coulgauss/long <pair_lj_switch3_coulgauss>`
* :doc:`lj/switch3/coulgauss/long <pair_lj_switch3_coulgauss_long>`
* :doc:`lj96/cut (go) <pair_lj96>`
* :doc:`local/density <pair_local_density>`
* :doc:`lubricate (o) <pair_lubricate>`
@ -174,8 +174,10 @@ OPT.
* :doc:`meam/c <pair_meamc>`
* :doc:`meam/spline (o) <pair_meam_spline>`
* :doc:`meam/sw/spline <pair_meam_sw_spline>`
* :doc:`mesocnt <pair_mesocnt>`
* :doc:`mgpt <pair_mgpt>`
* :doc:`mie/cut (g) <pair_mie>`
* :doc:`mm3/switch3/coulgauss/long <pair_mm3_switch3_coulgauss_long>`
* :doc:`momb <pair_momb>`
* :doc:`morse (gkot) <pair_morse>`
* :doc:`morse/smooth/linear (o) <pair_morse>`
@ -197,10 +199,17 @@ OPT.
* :doc:`oxdna2/hbond <pair_oxdna2>`
* :doc:`oxdna2/stk <pair_oxdna2>`
* :doc:`oxdna2/xstk <pair_oxdna2>`
* :doc:`oxrna2/excv <pair_oxrna2>`
* :doc:`oxrna2/hbond <pair_oxrna2>`
* :doc:`oxrna2/dh <pair_oxrna2>`
* :doc:`oxrna2/stk <pair_oxrna2>`
* :doc:`oxrna2/xstk <pair_oxrna2>`
* :doc:`oxrna2/coaxstk <pair_oxrna2>`
* :doc:`peri/eps <pair_peri>`
* :doc:`peri/lps (o) <pair_peri>`
* :doc:`peri/pmb (o) <pair_peri>`
* :doc:`peri/ves <pair_peri>`
* :doc:`polymorphic <pair_polymorphic>`
* :doc:`python <pair_python>`
* :doc:`quip <pair_quip>`
* :doc:`reax/c (ko) <pair_reaxc>`
@ -209,7 +218,7 @@ OPT.
* :doc:`sdpd/taitwater/isothermal <pair_sdpd_taitwater_isothermal>`
* :doc:`smd/hertz <pair_smd_hertz>`
* :doc:`smd/tlsph <pair_smd_tlsph>`
* :doc:`smd/tri\_surface <pair_smd_triangulated_surface>`
* :doc:`smd/tri_surface <pair_smd_triangulated_surface>`
* :doc:`smd/ulsph <pair_smd_ulsph>`
* :doc:`smtbq <pair_smtbq>`
* :doc:`snap (k) <pair_snap>`
@ -248,5 +257,3 @@ OPT.
* :doc:`yukawa (gko) <pair_yukawa>`
* :doc:`yukawa/colloid (go) <pair_yukawa_colloid>`
* :doc:`zbl (gko) <pair_zbl>`
*
*

16
doc/src/Errors_messages.rst
View File

@ -286,6 +286,9 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
*Attempting to rescale a 0.0 temperature*
Cannot rescale a temperature that is already 0.0.
*Attempting to insert more particles than available lattice points*
Self-explanatory.
*Bad FENE bond*
Two atoms in a FENE bond have become so far apart that the bond cannot
be computed.
@ -486,6 +489,9 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
Only systems with bonds that can be changed can be used. Atom\_style
template does not qualify.
*Bond/react: Invalid template atom ID in map file*
Atom IDs in molecule templates range from 1 to the number of atoms in the template.
*Bond/react: Rmax cutoff is longer than pairwise cutoff*
This is not allowed because bond creation is done using the pairwise
neighbor list.
@ -518,6 +524,16 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
*Bond/react: A deleted atom cannot remain bonded to an atom that is not deleted*
Self-explanatory.
*Bond/react: First neighbors of chiral atoms must be of mutually different types*
Self-explanatory.
*Bond/react: Chiral atoms must have exactly four first neighbors*
Self-explanatory.
*Bond/react: Molecule template 'Coords' section required for chiralIDs keyword*
The coordinates of atoms in the pre-reacted template are used to determine
chirality.
*Bond/react special bond generation overflow*
The number of special bonds per-atom created by a reaction exceeds the
system setting. See the read\_data or create\_box command for how to

9
doc/src/Errors_warnings.rst
View File

@ -195,6 +195,12 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
*Fix SRD walls overlap but fix srd overlap not set*
You likely want to set this in your input script.
* Fix bond/create is used multiple times or with fix bond/break - may not work as expected*
When using fix bond/create multiple times or in combination with
fix bond/break, the individual fix instances do not share information
about changes they made at the same time step and thus it may result
in unexpected behavior.
*Fix bond/swap will ignore defined angles*
See the doc page for fix bond/swap for more info on this
restriction.
@ -677,6 +683,9 @@ This will most likely cause errors in kinetic fluctuations.
*Slab correction not needed for MSM*
Slab correction is intended to be used with Ewald or PPPM and is not needed by MSM.
*Specifying an 'subset' value of '0' is equivalent to no 'subset' keyword*
Self-explanatory.
*System is not charge neutral, net charge = %g*
The total charge on all atoms on the system is not 0.0.
For some KSpace solvers this is only a warning.

2
doc/src/Examples.rst
View File

@ -133,6 +133,8 @@ Lowercase directories
+-------------+------------------------------------------------------------------+
| reax | RDX and TATB models using the ReaxFF |
+-------------+------------------------------------------------------------------+
| rerun | use of rerun and read\_dump commands |
+-------------+------------------------------------------------------------------+
| rigid | rigid bodies modeled as independent or coupled |
+-------------+------------------------------------------------------------------+
| shear | sideways shear applied to 2d solid, with and without a void |

4
doc/src/Howto_bash.rst
View File

@ -115,8 +115,8 @@ Files in Ubuntu on Windows
^^^^^^^^^^^^^^^^^^^^^^^^^^
When you launch "Bash on Ubuntu on Windows" you will start out in your Linux
user home directory /home/\ **username**\ . You can access your Windows user directory
using the /mnt/c/Users/\ **username** folder.
user home directory /home/[username]\ . You can access your Windows user directory
using the /mnt/c/Users/[username] folder.
Download LAMMPS
^^^^^^^^^^^^^^^

33
doc/src/Howto_client_server.rst
View File

@ -24,9 +24,38 @@ atoms. The quantum code computes energy and forces based on the
coords. It returns them as a message to LAMMPS, which completes the
timestep.
A more complex example is where LAMMPS is the client code and
processes a series of data files, sending each configuration to a
quantum code to compute energy and forces. Or LAMMPS runs dynamics
with an atomistic force field, but pauses every N steps to ask the
quantum code to compute energy and forces.
Alternate methods for code coupling with LAMMPS are described on
the :doc:`Howto couple <Howto_couple>` doc page.
The protocol for using LAMMPS as a client is to use these 3 commands
in this order (other commands may come in between):
* :doc:`message client <message>` # initiate client/server interaction
* :doc:`fix client/md <fix_client_md>` # any client fix which makes specific requests to the server
* :doc:`message quit <message>` # terminate client/server interaction
In between the two message commands, a client fix command and
:doc:`unfix <unfix>` command can be used multiple times. Similarly,
this sequence of 3 commands can be repeated multiple times, assuming
the server program operates in a similar fashion, to initiate and
terminate client/server communication.
The protocol for using LAMMPS as a server is to use these 2 commands
in this order (other commands may come in between):
* :doc:`message server <message>` # initiate client/server interaction
* :doc:`server md <server_md>` # any server command which responds to specific requests from the client
This sequence of 2 commands can be repeated multiple times, assuming
the client program operates in a similar fashion, to initiate and
terminate client/server communication.
LAMMPS support for client/server coupling is in its :ref:`MESSAGE package <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
@ -39,8 +68,8 @@ 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
code, the other code also has to use the CSlib. This can often be
done without any modification 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

25
doc/src/Howto_library.rst
View File

@ -20,6 +20,31 @@ and C and Python codes which show how a driver code can link to LAMMPS
as a library, run LAMMPS on a subset of processors, grab data from
LAMMPS, change it, and put it back into LAMMPS.
Thread-safety
-------------
LAMMPS has not initially been conceived as a thread-safe program, but
over the years changes have been applied to replace operations that
collide with creating multiple LAMMPS instances from multiple-threads
of the same process with thread-safe alternatives. This primarily
applies to the core LAMMPS code and less so on add-on packages, especially
when those packages require additional code in the *lib* folder,
interface LAMMPS to Fortran libraries, or the code uses static variables
(like the USER-COLVARS package.
Another major issue to deal with is to correctly handle MPI. Creating
a LAMMPS instance requires passing an MPI communicator, or it assumes
the MPI\_COMM\_WORLD communicator, which spans all MPI processor ranks.
When creating multiple LAMMPS object instances from different threads,
this communicator has to be different for each thread or else collisions
can happen, or it has to be guaranteed, that only one thread at a time
is active. MPI communicators, however, are not a problem, if LAMMPS is
compiled with the MPI STUBS library, which implies that there is no MPI
communication and only 1 MPI rank.
Provided APIs
-------------
The file src/library.cpp contains the following functions for creating
and destroying an instance of LAMMPS and sending it commands to
execute. See the documentation in the src/library.cpp file for

6
doc/src/Manual_build.rst
View File

@ -55,9 +55,9 @@ the doc dir.
make mobi # generate LAMMPS.mobi in MOBI format using ebook-convert
make clean # remove intermediate RST files created by HTML build
make clean-all # remove entire build folder and any cached data
make anchor\_check # check for duplicate anchor labels
make spelling # spell-check the manual
make anchor_check # check for duplicate anchor labels
style_check # check for complete and consistent style lists
make spelling # spell-check the manual
----------

13
doc/src/Packages_details.rst
View File

@ -1096,8 +1096,9 @@ USER-ADIOS package
**Contents:**
ADIOS is a high-performance I/O library. This package implements the
dump "atom/adios" and dump "custom/adios" commands to write data using
the ADIOS library.
:doc:`dump atom/adios <dump_adios>`, :doc:`dump custom/adios <dump_adios>` and
:doc:`read_dump ... format adios <read_dump>`
commands to write and read data using the ADIOS library.
**Authors:** Norbert Podhorszki (ORNL) from the ADIOS developer team.
@ -1111,6 +1112,10 @@ This package has :ref:`specific installation instructions <user-adios>` on the :
* src/USER-ADIOS/README
* examples/USER/adios
* https://github.com/ornladios/ADIOS2
* :doc:`dump atom/adios <dump_adios>`
* :doc:`dump custom/adios <dump_adios>`
* :doc:`read_dump <read_dump>`
----------
@ -2438,8 +2443,8 @@ which discuss the `QuickFF <quickff_>`_ methodology.
* :doc:`bond\_style mm3 <bond_mm3>`
* :doc:`improper\_style distharm <improper_distharm>`
* :doc:`improper\_style sqdistharm <improper_sqdistharm>`
* :doc:`pair\_style mm3/switch3/coulgauss/long <pair_mm3_switch3_coulgauss>`
* :doc:`pair\_style lj/switch3/coulgauss/long <pair_lj_switch3_coulgauss>`
* :doc:`pair\_style mm3/switch3/coulgauss/long <pair_mm3_switch3_coulgauss_long>`
* :doc:`pair\_style lj/switch3/coulgauss/long <pair_lj_switch3_coulgauss_long>`
* examples/USER/yaff

8
doc/src/_ext/table_from_list.py
View File

@ -1,6 +1,6 @@
from docutils import nodes
from sphinx.util.docutils import SphinxDirective
from docutils.nodes import Element, Node
from docutils.nodes import Element, Node, list_item
from typing import Any, Dict, List
from sphinx import addnodes
from sphinx.util import logging
@ -26,8 +26,12 @@ class TableFromList(SphinxDirective):
raise SphinxError('table_from_list content is not a list')
fulllist = node.children[0]
# fill list with empty items to have a number of entries
# that is divisible by ncolumns
if (len(fulllist) % ncolumns) != 0:
raise SphinxError('number of list elements not a multiple of column number')
missing = int(ncolumns - (len(fulllist) % ncolumns))
for i in range(0,missing):
fulllist += list_item()
table = nodes.table()
tgroup = nodes.tgroup(cols=ncolumns)

1
doc/src/bond_style.rst
View File

@ -100,6 +100,7 @@ accelerated styles exist.
* :doc:`nonlinear <bond_nonlinear>` - nonlinear bond
* :doc:`oxdna/fene <bond_oxdna>` - modified FENE bond suitable for DNA modeling
* :doc:`oxdna2/fene <bond_oxdna>` - same as oxdna but used with different pair styles
* :doc:`oxrna2/fene <bond_oxdna>` - modified FENE bond suitable for RNA modeling
* :doc:`quartic <bond_quartic>` - breakable quartic bond
* :doc:`table <bond_table>` - tabulated by bond length

8
doc/src/compute_angle_local.rst
View File

@ -81,12 +81,12 @@ and output the statistics in various ways:
compute 1 all property/local aatom1 aatom2 aatom3 atype
compute 2 all angle/local eng theta v_cos v_cossq set theta t
dump 1 all local 100 tmp.dump c_1**\*** c_2**\***
dump 1 all local 100 tmp.dump c_1[*] c_2[*]
compute 3 all reduce ave c_2**\***
thermo_style custom step temp press c_3**\***
compute 3 all reduce ave c_2[*]
thermo_style custom step temp press c_3[*]
fix 10 all ave/histo 10 10 100 -1 1 20 c_2\ **3** mode vector file tmp.histo
fix 10 all ave/histo 10 10 100 -1 1 20 c_2[3] mode vector file tmp.histo
The :doc:`dump local <dump>` command will output the energy, angle,
cosine(angle), cosine\^2(angle) for every angle in the system. The

8
doc/src/compute_bond_local.rst
View File

@ -134,12 +134,12 @@ output the statistics in various ways:
compute 1 all property/local batom1 batom2 btype
compute 2 all bond/local engpot dist v_dsq set dist d
dump 1 all local 100 tmp.dump c_1**\*** c_2**\***
dump 1 all local 100 tmp.dump c_1[*] c_2[*]
compute 3 all reduce ave c_2**\***
thermo_style custom step temp press c_3**\***
compute 3 all reduce ave c_2[*]
thermo_style custom step temp press c_3[*]
fix 10 all ave/histo 10 10 100 0 6 20 c_2\ **3** mode vector file tmp.histo
fix 10 all ave/histo 10 10 100 0 6 20 c_2[3] mode vector file tmp.histo
The :doc:`dump local <dump>` command will output the energy, distance,
distance\^2 for every bond in the system. The

8
doc/src/compute_chunk_spread_atom.rst
View File

@ -32,7 +32,7 @@ Examples
.. parsed-literal::
compute 1 all chunk/spread/atom mychunk c_com**\*** c_gyration
compute 1 all chunk/spread/atom mychunk c_com[*] c_gyration
Description
"""""""""""
@ -109,7 +109,7 @@ with 3 columns:
.. parsed-literal::
compute com all com/chunk mychunk
compute 10 all chunk/spread/atom mychunk c_com[\*]
compute 10 all chunk/spread/atom mychunk c_com[*]
compute 10 all chunk/spread/atom mychunk c_com[1] c_com[2] c_com[3]
@ -125,8 +125,8 @@ to the bench/in.chain script.
compute cmol all chunk/atom molecule
compute com all com/chunk cmol
compute comchunk all chunk/spread/atom cmol c_com**\***
dump 1 all custom 50 tmp.dump id mol type x y z c_comchunk**\***
compute comchunk all chunk/spread/atom cmol c_com[*]
dump 1 all custom 50 tmp.dump id mol type x y z c_comchunk[*]
dump_modify 1 sort id
The same per-chunk data for each atom could be used to define per-atom

8
doc/src/compute_dihedral_local.rst
View File

@ -79,12 +79,12 @@ the system and output the statistics in various ways:
compute 1 all property/local datom1 datom2 datom3 datom4 dtype
compute 2 all dihedral/local phi v_cos v_cossq set phi p
dump 1 all local 100 tmp.dump c_1**\*** c_2**\***
dump 1 all local 100 tmp.dump c_1[*] c_2[*]
compute 3 all reduce ave c_2**\***
thermo_style custom step temp press c_3**\***
compute 3 all reduce ave c_2[*]
thermo_style custom step temp press c_3[*]
fix 10 all ave/histo 10 10 100 -1 1 20 c_2\ **2** mode vector file tmp.histo
fix 10 all ave/histo 10 10 100 -1 1 20 c_2[2] mode vector file tmp.histo
The :doc:`dump local <dump>` command will output the angle,
cosine(angle), cosine\^2(angle) for every dihedral in the system. The

4
doc/src/compute_displace_atom.rst
View File

@ -94,10 +94,10 @@ something like the following commands:
write_dump all custom tmp.dump id type x y z # see comment below
variable Dhop equal 0.6
variable check atom "c_dsp\ **4** > v_Dhop"
variable check atom "c_dsp[4] > v_Dhop"
compute dsp all displace/atom refresh check
dump 1 all custom 100 tmp.dump id type x y z
dump_modify 1 append yes thresh c_dsp\ **4** > $\ *Dhop* &
dump_modify 1 append yes thresh c_dsp[4] > ${Dhop} &
refresh c_dsp delay 100
The :doc:`dump\_modify thresh <dump_modify>` command will only output

22
doc/src/create_atoms.rst
View File

@ -27,7 +27,7 @@ Syntax
region-ID = create atoms within this region, use NULL for entire simulation box
* zero or more keyword/value pairs may be appended
* keyword = *mol* or *basis* or *remap* or *var* or *set* or *units*
* keyword = *mol* or *basis* or *ratio* or *subset* or *remap* or *var* or *set* or *rotate* or *units*
.. parsed-literal::
@ -37,6 +37,12 @@ Syntax
*basis* values = M itype
M = which basis atom
itype = atom type (1-N) to assign to this basis atom
*ratio* values = frac seed
frac = fraction of lattice sites (0 to 1) to populate randomly
seed = random # seed (positive integer)
*subset* values = Nsubset seed
Nsubset = # of lattice sites to populate randomly
seed = random # seed (positive integer)
*remap* value = *yes* or *no*
*var* value = name = variable name to evaluate for test of atom creation
*set* values = dim name
@ -59,6 +65,7 @@ Examples
create_atoms 1 box
create_atoms 3 region regsphere basis 2 3
create_atoms 3 region regsphere basis 2 3 ratio 0.5 74637
create_atoms 3 single 0 0 5
create_atoms 1 box var v set x xpos set y ypos
@ -214,6 +221,19 @@ command for specifics on how basis atoms are defined for the unit cell
of the lattice. By default, all created atoms are assigned the
argument *type* as their atom type.
The *ratio* and *subset* keywords can be used in conjunction with the
*box* or *region* styles to limit the total number of particles
inserted. The lattice defines a set of *Nlatt* eligible sites for
inserting particles, which may be limited by the *region* style or the
*var* and *set* keywords. For the *ratio* keyword only the specified
fraction of them (0 <= *frac* <= 1) will be assigned particles. For
the *subset* keyword only the specified *Nsubset* of them will be
assigned particles. In both cases the assigned lattice sites are
chosen randomly. An iterative algorithm is used which insures the
correct number of particles are inserted, in a perfectly random
fashion. Which lattice sites are selected will change with the number
of processors used.
The *remap* keyword only applies to the *single* style. If it is set
to *yes*\ , then if the specified position is outside the simulation
box, it will mapped back into the box, assuming the relevant

14
doc/src/dump.rst
View File

@ -21,8 +21,11 @@ dump command
:doc:`dump movie <dump_image>` command
======================================
:doc:`dump adios <dump_adios>` command
======================================
:doc:`dump atom/adios <dump_adios>` command
===========================================
:doc:`dump custom/adios <dump_adios>` command
=============================================
Syntax
""""""
@ -45,12 +48,12 @@ Syntax
*atom* args = none
*atom/gz* args = none
*atom/mpiio* args = none
*atom/adios* args = none, discussed on :doc:`dump adios <dump_adios>` doc page
*atom/adios* args = none, discussed on :doc:`dump atom/adios <dump_adios>` doc page
*cfg* args = same as *custom* args, see below
*cfg/gz* args = same as *custom* args, see below
*cfg/mpiio* args = same as *custom* args, see below
*custom*\ , *custom/gz*\ , *custom/mpiio* args = see below
*custom/adios* args = same as *custom* args, discussed on :doc:`dump adios <dump_adios>` doc page
*custom/adios* args = same as *custom* args, discussed on :doc:`dump custom/adios <dump_adios>` doc page
*dcd* args = none
*h5md* args = discussed on :doc:`dump h5md <dump_h5md>` doc page
*image* args = discussed on :doc:`dump image <dump_image>` doc page
@ -713,7 +716,8 @@ LAMMPS was built with that package. See the :doc:`Build package <Build_package>
Related commands
""""""""""""""""
:doc:`dump adios <dump_adios>` :doc:`dump h5md <dump_h5md>`, :doc:`dump image <dump_image>`,
:doc:`dump atom/adios <dump_adios>`, :doc:`dump custom/adios <dump_adios>`,
:doc:`dump h5md <dump_h5md>`, :doc:`dump image <dump_image>`,
:doc:`dump molfile <dump_molfile>`, :doc:`dump\_modify <dump_modify>`,
:doc:`undump <undump>`

7
doc/src/dump_adios.rst
View File

@ -1,6 +1,7 @@
.. index:: dump atoms/adios
.. index:: dump atom/adios
.. index:: dump custom/adios
dump atoms/adios command
dump atom/adios command
=========================
dump custom/adios command
@ -12,7 +13,7 @@ Syntax
.. parsed-literal::
dump ID group-ID atoms/adios N file.bp
dump ID group-ID atom/adios N file.bp
dump ID group-ID custom/adios N file.bp args

25
doc/src/fix.rst
View File

@ -64,16 +64,16 @@ with new settings). This is the same as if an "unfix" command were
first performed on the old fix, except that the new fix is kept in the
same order relative to the existing fixes as the old one originally
was. Note that this operation also wipes out any additional changes
made to the old fix via the :doc:`fix\_modify <fix_modify>` command.
made to the old fix via the :doc:`fix_modify <fix_modify>` command.
The :doc:`fix modify <fix_modify>` command allows settings for some
fixes to be reset. See the doc page for individual fixes for details.
Some fixes store an internal "state" which is written to binary
restart files via the :doc:`restart <restart>` or
:doc:`write\_restart <write_restart>` commands. This allows the fix to
:doc:`write_restart <write_restart>` commands. This allows the fix to
continue on with its calculations in a restarted simulation. See the
:doc:`read\_restart <read_restart>` command for info on how to re-specify
:doc:`read_restart <read_restart>` command for info on how to re-specify
a fix in an input script that reads a restart file. See the doc pages
for individual fixes for info on which ones can be restarted.
@ -133,7 +133,7 @@ various commands explain the details.
In LAMMPS, the values generated by a fix can be used in several ways:
* Global values can be output via the :doc:`thermo\_style custom <thermo_style>` or :doc:`fix ave/time <fix_ave_time>` command.
* Global values can be output via the :doc:`thermo_style custom <thermo_style>` or :doc:`fix ave/time <fix_ave_time>` command.
Or the values can be referenced in a :doc:`variable equal <variable>` or
:doc:`variable atom <variable>` command.
* Per-atom values can be output via the :doc:`dump custom <dump>` command.
@ -257,6 +257,7 @@ accelerated styles exist.
* :doc:`mvv/edpd <fix_mvv_dpd>` - constant energy DPD using the modified velocity-Verlet algorithm
* :doc:`mvv/tdpd <fix_mvv_dpd>` - constant temperature DPD using the modified velocity-Verlet algorithm
* :doc:`neb <fix_neb>` - nudged elastic band (NEB) spring forces
* :doc:`neb/spin <fix_neb_spin>` - nudged elastic band (NEB) spring forces for spins
* :doc:`nph <fix_nh>` - constant NPH time integration via Nose/Hoover
* :doc:`nph/asphere <fix_nph_asphere>` - NPH for aspherical particles
* :doc:`nph/body <fix_nph_body>` - NPH for body particles
@ -266,6 +267,7 @@ accelerated styles exist.
* :doc:`npt <fix_nh>` - constant NPT time integration via Nose/Hoover
* :doc:`npt/asphere <fix_npt_asphere>` - NPT for aspherical particles
* :doc:`npt/body <fix_npt_body>` - NPT for body particles
* :doc:`npt/cauchy <fix_npt_cauchy>` - NPT with Cauchy stress
* :doc:`npt/eff <fix_nh_eff>` - NPT for nuclei and electrons in the electron force field model
* :doc:`npt/sphere <fix_npt_sphere>` - NPT for spherical particles
* :doc:`npt/uef <fix_nh_uef>` - NPT style time integration with diagonal flow
@ -306,6 +308,7 @@ accelerated styles exist.
* :doc:`precession/spin <fix_precession_spin>` -
* :doc:`press/berendsen <fix_press_berendsen>` - pressure control by Berendsen barostat
* :doc:`print <fix_print>` - print text and variables during a simulation
* :doc:`propel/self <fix_propel_self>` - model self-propelled particles
* :doc:`property/atom <fix_property_atom>` - add customized per-atom values
* :doc:`python/invoke <fix_python_invoke>` - call a Python function during a simulation
* :doc:`python/move <fix_python_move>` - call a Python function during a simulation run
@ -339,15 +342,16 @@ accelerated styles exist.
* :doc:`rx <fix_rx>` -
* :doc:`saed/vtk <fix_saed_vtk>` -
* :doc:`setforce <fix_setforce>` - set the force on each atom
* :doc:`setforce/spin <fix_setforce>` - set magnetic precession vectors on each atom
* :doc:`shake <fix_shake>` - SHAKE constraints on bonds and/or angles
* :doc:`shardlow <fix_shardlow>` - integration of DPD equations of motion using the Shardlow splitting
* :doc:`smd <fix_smd>` - applied a steered MD force to a group
* :doc:`smd/adjust\_dt <fix_smd_adjust_dt>` -
* :doc:`smd/integrate\_tlsph <fix_smd_integrate_tlsph>` -
* :doc:`smd/integrate\_ulsph <fix_smd_integrate_ulsph>` -
* :doc:`smd/move\_tri\_surf <fix_smd_move_triangulated_surface>` -
* :doc:`smd/adjust_dt <fix_smd_adjust_dt>` -
* :doc:`smd/integrate_tlsph <fix_smd_integrate_tlsph>` -
* :doc:`smd/integrate_ulsph <fix_smd_integrate_ulsph>` -
* :doc:`smd/move_tri_surf <fix_smd_move_triangulated_surface>` -
* :doc:`smd/setvel <fix_smd_setvel>` -
* :doc:`smd/wall\_surface <fix_smd_wall_surface>` -
* :doc:`smd/wall_surface <fix_smd_wall_surface>` -
* :doc:`spring <fix_spring>` - apply harmonic spring force to group of atoms
* :doc:`spring/chunk <fix_spring_chunk>` - apply harmonic spring force to each chunk of atoms
* :doc:`spring/rg <fix_spring_rg>` - spring on radius of gyration of group of atoms
@ -384,6 +388,7 @@ accelerated styles exist.
* :doc:`wall/morse <fix_wall>` - Morse potential wall
* :doc:`wall/piston <fix_wall_piston>` - moving reflective piston wall
* :doc:`wall/reflect <fix_wall_reflect>` - reflecting wall(s)
* :doc:`wall/reflect/stochastic <fix_wall_reflect_stochastic>` - reflecting wall(s) with finite temperature
* :doc:`wall/region <fix_wall_region>` - use region surface as wall
* :doc:`wall/region/ees <fix_wall_ees>` - use region surface as wall for ellipsoidal particles
* :doc:`wall/srd <fix_wall_srd>` - slip/no-slip wall for SRD particles
@ -399,7 +404,7 @@ individual fixes tell if it is part of a package.
Related commands
""""""""""""""""
:doc:`unfix <unfix>`, :doc:`fix\_modify <fix_modify>`
:doc:`unfix <unfix>`, :doc:`fix_modify <fix_modify>`
**Default:** none

2
doc/src/fix_ave_atom.rst
View File

@ -88,7 +88,7 @@ command creates a per-atom array with 6 columns:
compute my_stress all stress/atom NULL
fix 1 all ave/atom 10 20 1000 c_my_stress[\*]
fix 1 all ave/atom 10 20 1000 c_my_stress[1] c_my_stress[1] &
fix 1 all ave/atom 10 20 1000 c_my_stress[1] c_my_stress[2] &
c_my_stress[3] c_my_stress[4] &
c_my_stress[5] c_my_stress[6]

2
doc/src/fix_ave_chunk.rst
View File

@ -440,7 +440,7 @@ By default, these header lines are as follows:
In the first line, ID and name are replaced with the fix-ID and group
name. The second line describes the two values that are printed at
the first of each section of output. In the third line the values are
replaced with the appropriate value names, e.g. fx or c\_myCompute\ **2**\ .
replaced with the appropriate value names, e.g. fx or c\_myCompute[2].
The words in parenthesis only appear with corresponding columns if the
chunk style specified for the :doc:`compute chunk/atom <compute_chunk_atom>` command supports them. The OrigID

28
doc/src/fix_bond_react.rst
View File

@ -20,9 +20,9 @@ Syntax
* the common keyword/values may be appended directly after 'bond/react'
* this applies to all reaction specifications (below)
* common\_keyword = *stabilization*
.. parsed-literal::
*stabilization* values = *no* or *yes* *group-ID* *xmax*
*no* = no reaction site stabilization
*yes* = perform reaction site stabilization
@ -40,9 +40,9 @@ Syntax
* map\_file = name of file specifying corresponding atom-IDs in the pre- and post-reacted templates
* zero or more individual keyword/value pairs may be appended to each react argument
* individual\_keyword = *prob* or *max\_rxn* or *stabilize\_steps* or *update\_edges*
.. parsed-literal::
*prob* values = fraction seed
fraction = initiate reaction with this probability if otherwise eligible
seed = random number seed (positive integer)
@ -253,7 +253,7 @@ A discussion of correctly handling this is also provided on the
The map file is a text document with the following format:
A map file has a header and a body. The header of map file the
contains one mandatory keyword and four optional keywords. The
contains one mandatory keyword and five optional keywords. The
mandatory keyword is 'equivalences':
@ -269,10 +269,11 @@ The optional keywords are 'edgeIDs', 'deleteIDs', 'customIDs' and
N *edgeIDs* = # of edge atoms N in the pre-reacted molecule template
N *deleteIDs* = # of atoms N that are specified for deletion
N *chiralIDs* = # of specified chiral centers N
N *customIDs* = # of atoms N that are specified for a custom update
N *constraints* = # of specified reaction constraints N
The body of the map file contains two mandatory sections and four
The body of the map file contains two mandatory sections and five
optional sections. The first mandatory section begins with the keyword
'BondingIDs' and lists the atom IDs of the bonding atom pair in the
pre-reacted molecule template. The second mandatory section begins
@ -284,12 +285,14 @@ molecule template. The first optional section begins with the keyword
'EdgeIDs' and lists the atom IDs of edge atoms in the pre-reacted
molecule template. The second optional section begins with the keyword
'DeleteIDs' and lists the atom IDs of pre-reaction template atoms to
delete. The third optional section begins with the keyword 'Custom
delete. The third optional section begins with the keyword 'ChiralIDs'
lists the atom IDs of chiral atoms whose handedness should be
enforced. The fourth optional section begins with the keyword 'Custom
Edges' and allows for forcing the update of a specific atom's atomic
charge. The first column is the ID of an atom near the edge of the
pre-reacted molecule template, and the value of the second column is
either 'none' or 'charges.' Further details are provided in the
discussion of the 'update\_edges' keyword. The fourth optional section
discussion of the 'update\_edges' keyword. The fifth optional section
begins with the keyword 'Constraints' and lists additional criteria
that must be satisfied in order for the reaction to occur. Currently,
there are three types of constraints available, as discussed below.
@ -332,6 +335,15 @@ A sample map file is given below:
----------
The handedness of atoms that are chiral centers can be enforced by
listing their IDs in the ChiralIDs section. A chiral atom must be
bonded to four atoms with mutually different atom types. This feature
uses the coordinates and types of the involved atoms in the
pre-reaction template to determine handedness. Three atoms bonded to
the chiral center are arbitrarily chosen, to define an oriented plane,
and the relative position of the fourth bonded atom determines the
chiral center's handedness.
Any number of additional constraints may be specified in the
Constraints section of the map file. The constraint of type 'distance'
has syntax as follows:

12
doc/src/fix_client_md.rst
View File

@ -41,10 +41,10 @@ computes their interaction, and returns the energy, forces, and virial
for the interacting particles to LAMMPS, so it can complete the
timestep.
The server code could be a quantum code, or another classical MD code
which encodes a force field (pair\_style in LAMMPS lingo) which LAMMPS
does not have. In the quantum case, this fix is a mechanism for
running *ab initio* MD with quantum forces.
Note that the server code can be a quantum code, or another classical
MD code which encodes a force field (pair\_style in LAMMPS lingo) which
LAMMPS does not have. In the quantum case, this fix is a mechanism
for running *ab initio* MD with quantum forces.
The group associated with this fix is ignored.
@ -99,8 +99,8 @@ This fix is part of the MESSAGE package. It is only enabled if LAMMPS
was built with that package. See the :doc:`Build package <Build_package>` doc page for more info.
A script that uses this command must also use the
:doc:`message <message>` command to setup the messaging protocol with
the other server code.
:doc:`message <message>` command to setup and shut down the messaging
protocol with the server code.
Related commands
""""""""""""""""

9
doc/src/fix_deposit.rst
View File

@ -57,6 +57,8 @@ Syntax
fix-ID = ID of :doc:`fix rigid/small <fix_rigid>` command
*shake* value = fix-ID
fix-ID = ID of :doc:`fix shake <fix_shake>` command
*orient* values = rx ry rz
rx,ry,rz = vector to randomly rotate an inserted molecule around
*units* value = *lattice* or *box*
lattice = the geometry is defined in lattice units
box = the geometry is defined in simulation box units
@ -236,6 +238,13 @@ sputtering process. E.g. the target point can be far away, so that
all incident particles strike the surface as if they are in an
incident beam of particles at a prescribed angle.
The *orient* keyword is only used when molecules are deposited. By
default, each molecule is inserted at a random orientation. If this
keyword is specified, then (rx,ry,rz) is used as an orientation
vector, and each inserted molecule is rotated around that vector with
a random value from zero to 2*PI. For a 2d simulation, rx = ry = 0.0
is required, since rotations can only be performed around the z axis.
The *id* keyword determines how atom IDs and molecule IDs are assigned
to newly deposited particles. Molecule IDs are only assigned if
molecules are being inserted. For the *max* setting, the atom and

159
doc/src/fix_hyper_local.rst
View File

@ -21,10 +21,14 @@ Syntax
* alpha = boostostat relaxation time (time units)
* Btarget = desired time boost factor (unitless)
* zero or more keyword/value pairs may be appended
* keyword = *check/ghost* or *check/bias*
* keyword = *bound* or *reset* or *check/ghost* or *check/bias*
.. parsed-literal::
*bound* value = Bfrac
Bfrac = -1 or a value >= 0.0
*reset* value = Rfreq
Rfreq = -1 or 0 or timestep value > 0
*check/ghost* values = none
*check/bias* values = Nevery error/warn/ignore
@ -37,6 +41,7 @@ Examples
.. parsed-literal::
fix 1 all hyper/local 1.0 0.3 0.8 300.0
fix 1 all hyper/local 1.0 0.3 0.8 300.0 bound 0.1 reset 0
Description
"""""""""""
@ -214,8 +219,8 @@ guarantee an accelerated time-accurate trajectory of the system.
Cij are initialized to 1.0 and the boostostatting procedure typically
operates slowly enough that there can be a time period of bad dynamics
if *Vmax* is set too large. A better strategy is to set *Vmax* to the
smallest barrier height for an event (the same as for GHD), so that
the Cij remain near unity.
slightly smaller than the lowest barrier height for an event (the same
as for GHD), so that the Cij remain near unity.
The *Tequil* argument is the temperature at which the system is
simulated; see the comment above about the :doc:`fix langevin <fix_langevin>` thermostatting. It is also part of the
@ -310,6 +315,42 @@ time (t\_hyper equation above) will be shorter.
Here is additional information on the optional keywords for this fix.
The *bound* keyword turns on min/max bounds for bias coefficients Cij
for all bonds. Cij is a prefactor for each bond on the bias potential
of maximum strength Vmax. Depending on the choice of *alpha* and
*Btarget* and *Vmax*\ , the boostostatting can cause individual Cij
values to fluctuate. If the fluctuations are too large Cij\*Vmax can
exceed low barrier heights and induce bad event dynamics. Bounding
the Cij values is a way to prevent this. If *Bfrac* is set to -1 or
any negative value (the default) then no bounds are enforced on Cij
values (except they must always be >= 0.0). A *Bfrac* setting >= 0.0
sets a lower bound of 1.0 - Bfrac and upper bound of 1.0 + Bfrac on
each Cij value. Note that all Cij values are initialized to 1.0 when
a bond is created for the first time. Thus *Bfrac* limits the bias
potential height to *Vmax* +/- *Bfrac*\ \*\ *Vmax*\ .
The *reset* keyword allow *Vmax* to be adjusted dynamically depending
on the average value of all Cij prefactors. This can be useful if you
are unsure what value of *Vmax* will match the *Btarget* boost for the
system. The Cij values will then adjust in aggregate (up or down) so
that Cij\*Vmax produces a boost of *Btarget*\ , but this may conflict
with the *bound* keyword settings. By using *bound* and *reset*
together, *Vmax* itself can be reset, and desired bounds still applied
to the Cij values.
A setting for *Rfreq* of -1 (the default) means *Vmax* never changes.
A setting of 0 means *Vmax* is adjusted every time an event occurs and
bond pairs are recalculated. A setting of N > 0 timesteps means
*Vmax* is adjusted on the first time an event occurs on a timestep >=
N steps after the previous adjustment. The adjustment to *Vmax* is
computed as follows. The current average of all Cij\*Vmax values is
computed and the *Vmax* is reset to that value. All Cij values are
changed to new prefactors such the new Cij\*Vmax is the same as it was
previously. If the *bound* keyword was used, those bounds are
enforced on the new Cij values. Henceforth, new bonds are assigned a
Cij = 1.0, which means their bias potential magnitude is the new
*Vmax*\ .
The *check/ghost* keyword turns on extra computation each timestep to
compute statistics about ghost atoms used to determine which bonds to
bias. The output of these stats are the vector values 14 and 15,
@ -338,83 +379,96 @@ enabled by these keywords.
No information about this fix is written to :doc:`binary restart files <restart>`.
The :doc:`fix\_modify <fix_modify>` *energy* option is supported by this
fix to add the energy of the bias potential to the system's
potential energy as part of :doc:`thermodynamic output <thermo_style>`.
fix to add the energy of the bias potential to the system's potential
energy as part of :doc:`thermodynamic output <thermo_style>`.
This fix computes a global scalar and global vector of length 21,
This fix computes a global scalar and global vector of length 28,
which can be accessed by various :doc:`output commands <Howto_output>`.
The scalar is the magnitude of the bias potential (energy units)
applied on the current timestep, summed over all biased bonds. The
vector stores the following quantities:
* 1 = # of biased bonds on this step
* 2 = max strain Eij of any bond on this step (absolute value, unitless)
* 3 = average bias coeff for all bonds on this step (unitless)
* 4 = average # of bonds/atom on this step
* 5 = average neighbor bonds/bond on this step within *Dcut*
* 1 = average boost for all bonds on this step (unitless)
* 2 = # of biased bonds on this step
* 3 = max strain Eij of any bond on this step (absolute value, unitless)
* 4 = value of Vmax on this step (energy units)
* 5 = average bias coeff for all bonds on this step (unitless)
* 6 = min bias coeff for all bonds on this step (unitless)
* 7 = max bias coeff for all bonds on this step (unitless)
* 8 = average # of bonds/atom on this step
* 9 = average neighbor bonds/bond on this step within *Dcut*
* 6 = max bond length during this run (distance units)
* 7 = average # of biased bonds/step during this run
* 8 = fraction of biased bonds with no bias during this run
* 9 = fraction of biased bonds with negative strain during this run
* 10 = average bias coeff for all bonds during this run (unitless)
* 11 = min bias coeff for any bond during this run (unitless)
* 12 = max bias coeff for any bond during this run (unitless)
* 10 = average boost for all bonds during this run (unitless)
* 11 = average # of biased bonds/step during this run
* 12 = fraction of biased bonds with no bias during this run
* 13 = fraction of biased bonds with negative strain during this run
* 14 = max bond length during this run (distance units)
* 15 = average bias coeff for all bonds during this run (unitless)
* 16 = min bias coeff for any bond during this run (unitless)
* 17 = max bias coeff for any bond during this run (unitless)
* 13 = max drift distance of any bond atom during this run (distance units)
* 14 = max distance from proc subbox of any ghost atom with maxstrain < qfactor during this run (distance units)
* 15 = max distance outside my box of any ghost atom with any maxstrain during this run (distance units)
* 16 = count of ghost atoms that could not be found on reneighbor steps during this run
* 17 = count of bias overlaps (< Dcut) found during this run
* 18 = max drift distance of any bond atom during this run (distance units)
* 19 = max distance from proc subbox of any ghost atom with maxstrain < qfactor during this run (distance units)
* 20 = max distance outside my box of any ghost atom with any maxstrain during this run (distance units)
* 21 = count of ghost atoms that could not be found on reneighbor steps during this run
* 22 = count of bias overlaps (< Dcut) found during this run
* 18 = cumulative hyper time since fix created (time units)
* 19 = cumulative count of event timesteps since fix created
* 20 = cumulative count of atoms in events since fix created
* 21 = cumulative # of new bonds formed since fix created
* 23 = cumulative hyper time since fix created (time units)
* 24 = cumulative count of event timesteps since fix created
* 25 = cumulative count of atoms in events since fix created
* 26 = cumulative # of new bonds formed since fix created
The first quantities (1-5) are for the current timestep. Quantities
6-17 are for the current hyper run. They are reset each time a new
hyper run is performed. Quantities 18-21 are cumulative across
27 = average boost for biased bonds on this step (unitless)
28 = # of bonds with absolute strain >= q on this step
The first quantities 1-9 are for the current timestep. Quantities
10-22 are for the current hyper run. They are reset each time a new
hyper run is performed. Quantities 23-26 are cumulative across
multiple runs (since the point in the input script the fix was
defined).
For value 8, the numerator is a count of all biased bonds on each
For value 10, each bond instantaneous boost factor is given by the
equation for Bij above. The total system boost (average across all
bonds) fluctuates, but should average to a value close to the
specified Btarget.
For value 12, the numerator is a count of all biased bonds on each
timestep whose bias energy = 0.0 due to Eij >= *qfactor*\ . The
denominator is the count of all biased bonds on all timesteps.
For value 9, the numerator is a count of all biased bonds on each
For value 13, the numerator is a count of all biased bonds on each
timestep with negative strain. The denominator is the count of all
biased bonds on all timesteps.
Values 13-17 are mostly useful for debugging and diagnostic purposes.
Values 18-22 are mostly useful for debugging and diagnostic purposes.
For value 13, drift is the distance an atom moves between two quenched
For value 18, drift is the distance an atom moves between two quenched
states when the second quench determines an event has occurred. Atoms
involved in an event will typically move the greatest distance since
others typically remain near their original quenched position.
For values 14-16, neighbor atoms in the full neighbor list with cutoff
For values 19-21, neighbor atoms in the full neighbor list with cutoff
*Dcut* may be ghost atoms outside a processor's sub-box. Before the
next event occurs they may move further than *Dcut* away from the
sub-box boundary. Value 14 is the furthest (from the sub-box) any
sub-box boundary. Value 19 is the furthest (from the sub-box) any
ghost atom in the neighbor list with maxstrain < *qfactor* was
accessed during the run. Value 15 is the same except that the ghost
accessed during the run. Value 20 is the same except that the ghost
atom's maxstrain may be >= *qfactor*\ , which may mean it is about to
participate in an event. Value 16 is a count of how many ghost atoms
participate in an event. Value 21 is a count of how many ghost atoms
could not be found on reneighbor steps, presumably because they moved
too far away due to their participation in an event (which will likely
be detected at the next quench).
Typical values for 14 and 15 should be slightly larger than *Dcut*\ ,
Typical values for 19 and 20 should be slightly larger than *Dcut*\ ,
which accounts for ghost atoms initially at a *Dcut* distance moving
thermally before the next event takes place.
Note that for values 14 and 15 to be computed, the optional keyword
Note that for values 19 and 20 to be computed, the optional keyword
*check/ghost* must be specified. Otherwise these values will be zero.
This is because computing them incurs overhead, so the values are only
computed if requested.
Value 16 should be zero or small. As explained above a small count
Value 21 should be zero or small. As explained above a small count
likely means some ghost atoms were participating in their own events
and moved a longer distance. If the value is large, it likely means
the communication cutoff for ghosts is too close to *Dcut* leading to
@ -424,11 +478,11 @@ assumes those atoms are part of highly strained bonds. As explained
above, the :doc:`comm\_modify cutoff <comm_modify>` command can be used
to set a longer cutoff.
For value 17, no two bonds should be biased if they are within a
For value 22, no two bonds should be biased if they are within a
*Dcut* distance of each other. This value should be zero, indicating
that no pair of biased bonds are closer than *Dcut* from each other.
Note that for values 17 to be computed, the optional keyword
Note that for value 22 to be computed, the optional keyword
*check/bias* must be specified and it determines how often this check
is performed. This is because performing the check incurs overhead,
so if only computed as often as requested.
@ -438,27 +492,32 @@ timestep the check was made. Note that the value is a count of atoms
in bonds which found other atoms in bonds too close, so it is almost
always an over-count of the number of too-close bonds.
Value 18 is simply the specified *boost* factor times the number of
Value 23 is simply the specified *boost* factor times the number of
timesteps times the timestep size.
For value 19, events are checked for by the :doc:`hyper <hyper>` command
For value 24, events are checked for by the :doc:`hyper <hyper>` command
once every *Nevent* timesteps. This value is the count of those
timesteps on which one (or more) events was detected. It is NOT the
number of distinct events, since more than one event may occur in the
same *Nevent* time window.
For value 20, each time the :doc:`hyper <hyper>` command checks for an
For value 25, each time the :doc:`hyper <hyper>` command checks for an
event, it invokes a compute to flag zero or more atoms as
participating in one or more events. E.g. atoms that have displaced
more than some distance from the previous quench state. Value 20 is
more than some distance from the previous quench state. Value 25 is
the cumulative count of the number of atoms participating in any of
the events that were found.
Value 21 tallies the number of new bonds created by the bond reset
Value 26 tallies the number of new bonds created by the bond reset
operation. Bonds between a specific I,J pair of atoms may persist for
the entire hyperdynamics simulation if neither I or J are involved in
an event.
Value 27 computes the average boost for biased bonds only on this step.
Value 28 is the count of bonds with an absolute value of strain >= q
on this step.
The scalar and vector values calculated by this fix are all
"intensive".
@ -491,7 +550,9 @@ Related commands
Default
"""""""
The check/ghost and check/bias keywords are not enabled by default.
The default settings for optimal keywords are bounds = -1 and reset =
-1. The check/ghost and check/bias keywords are not enabled by
default.
----------

2
doc/src/fix_nh.rst
View File

@ -132,7 +132,7 @@ integrators derived by Tuckerman et al in :ref:`(Tuckerman) <nh-Tuckerman>`.
----------
The thermostat parameters for fix styles *nvt* and *npt* is specified
The thermostat parameters for fix styles *nvt* and *npt* are specified
using the *temp* keyword. Other thermostat-related keywords are
*tchain*\ , *tloop* and *drag*\ , which are discussed below.

679
doc/src/fix_npt_cauchy.rst Normal file
View File

@ -0,0 +1,679 @@
.. index:: fix npt/cauchy
fix npt/cauchy command
======================
Syntax
""""""
.. parsed-literal::
fix ID group-ID style_name keyword value ...
* ID, group-ID are documented in :doc:`fix <fix>` command
* style\_name = *npt/cauchy*
* one or more keyword/value pairs may be appended
* keyword = *temp* or *iso* or *aniso* or *tri* or *x* or *y* or *z* or *xy* or *yz* or *xz* or *couple* or *tchain* or *pchain* or *mtk* or *tloop* or *ploop* or *nreset* or *drag* or *dilate* or *scalexy* or *scaleyz* or *scalexz* or *flip* or *fixedpoint* or *update*
.. parsed-literal::
*temp* values = Tstart Tstop Tdamp
Tstart,Tstop = external temperature at start/end of run
Tdamp = temperature damping parameter (time units)
*iso* or *aniso* or *tri* values = Pstart Pstop Pdamp
Pstart,Pstop = scalar external pressure at start/end of run (pressure units)
Pdamp = pressure damping parameter (time units)
*x* or *y* or *z* or *xy* or *yz* or *xz* values = Pstart Pstop Pdamp
Pstart,Pstop = external stress tensor component at start/end of run (pressure units)
Pdamp = stress damping parameter (time units)
*couple* = *none* or *xyz* or *xy* or *yz* or *xz*
*tchain* value = N
N = length of thermostat chain (1 = single thermostat)
*pchain* values = N
N length of thermostat chain on barostat (0 = no thermostat)
*mtk* value = *yes* or *no* = add in MTK adjustment term or not
*tloop* value = M
M = number of sub-cycles to perform on thermostat
*ploop* value = M
M = number of sub-cycles to perform on barostat thermostat
*nreset* value = reset reference cell every this many timesteps
*drag* value = Df
Df = drag factor added to barostat/thermostat (0.0 = no drag)
*dilate* value = dilate-group-ID
dilate-group-ID = only dilate atoms in this group due to barostat volume changes
*scalexy* value = *yes* or *no* = scale xy with ly
*scaleyz* value = *yes* or *no* = scale yz with lz
*scalexz* value = *yes* or *no* = scale xz with lz
*flip* value = *yes* or *no* = allow or disallow box flips when it becomes highly skewed
*cauchystat* cauchystat values = alpha continue
alpha = strength of Cauchy stress control parameter
continue = *yes* or *no* = whether of not to continue from a previous run
*fixedpoint* values = x y z
x,y,z = perform barostat dilation/contraction around this point (distance units)
Examples
""""""""
fix 1 water npt/cauchy temp 300.0 300.0 100.0 iso 0.0 0.0 1000.0
Description
"""""""""""
This command performs time integration on Nose-Hoover style
non-Hamiltonian equations of motion which are designed to generate
positions and velocities sampled from the isothermal-isobaric (npt)
ensembles. This updates the position and velocity for atoms in the
group each timestep and the box dimensions.
The thermostatting and barostatting is achieved by adding some dynamic
variables which are coupled to the particle velocities
(thermostatting) and simulation domain dimensions (barostatting). In
addition to basic thermostatting and barostatting, this fix can
also create a chain of thermostats coupled to the particle thermostat,
and another chain of thermostats coupled to the barostat
variables. The barostat can be coupled to the overall box volume, or
to individual dimensions, including the *xy*\ , *xz* and *yz* tilt
dimensions. The external pressure of the barostat can be specified as
either a scalar pressure (isobaric ensemble) or as components of a
symmetric stress tensor (constant stress ensemble). When used
correctly, the time-averaged temperature and stress tensor of the
particles will match the target values specified by Tstart/Tstop and
Pstart/Pstop.
The equations of motion used are those of Shinoda et al in
:ref:`(Shinoda) <nc-Shinoda>`, which combine the hydrostatic equations of
Martyna, Tobias and Klein in :ref:`(Martyna) <nc-Martyna>` with the strain
energy proposed by Parrinello and Rahman in
:ref:`(Parrinello) <nc-Parrinello>`. The time integration schemes closely
follow the time-reversible measure-preserving Verlet and rRESPA
integrators derived by Tuckerman et al in :ref:`(Tuckerman) <nc-Tuckerman>`.
----------
The thermostat parameters are specified using the *temp* keyword.
Other thermostat-related keywords are *tchain*\ , *tloop* and *drag*\ ,
which are discussed below.
The thermostat is applied to only the translational degrees of freedom
for the particles. The translational degrees of freedom can also have
a bias velocity removed before thermostatting takes place; see the
description below. The desired temperature at each timestep is a
ramped value during the run from *Tstart* to *Tstop*\ . The *Tdamp*
parameter is specified in time units and determines how rapidly the
temperature is relaxed. For example, a value of 10.0 means to relax
the temperature in a timespan of (roughly) 10 time units (e.g. tau or
fmsec or psec - see the :doc:`units <units>` command). The atoms in the
fix group are the only ones whose velocities and positions are updated
by the velocity/position update portion of the integration.
.. note::
A Nose-Hoover thermostat will not work well for arbitrary values
of *Tdamp*\ . If *Tdamp* is too small, the temperature can fluctuate
wildly; if it is too large, the temperature will take a very long time
to equilibrate. A good choice for many models is a *Tdamp* of around
100 timesteps. Note that this is NOT the same as 100 time units for
most :doc:`units <units>` settings.
----------
The barostat parameters are specified using one or more of the *iso*\ ,
*aniso*\ , *tri*\ , *x*\ , *y*\ , *z*\ , *xy*\ , *xz*\ , *yz*\ , and *couple* keywords.
These keywords give you the ability to specify all 6 components of an
external stress tensor, and to couple various of these components
together so that the dimensions they represent are varied together
during a constant-pressure simulation.
Other barostat-related keywords are *pchain*\ , *mtk*\ , *ploop*\ ,
*nreset*\ , *drag*\ , and *dilate*\ , which are discussed below.
Orthogonal simulation boxes have 3 adjustable dimensions (x,y,z).
Triclinic (non-orthogonal) simulation boxes have 6 adjustable
dimensions (x,y,z,xy,xz,yz). The :doc:`create\_box <create_box>`, :doc:`read data <read_data>`, and :doc:`read\_restart <read_restart>` commands
specify whether the simulation box is orthogonal or non-orthogonal
(triclinic) and explain the meaning of the xy,xz,yz tilt factors.
The target pressures for each of the 6 components of the stress tensor
can be specified independently via the *x*\ , *y*\ , *z*\ , *xy*\ , *xz*\ , *yz*
keywords, which correspond to the 6 simulation box dimensions. For
each component, the external pressure or tensor component at each
timestep is a ramped value during the run from *Pstart* to *Pstop*\ .
If a target pressure is specified for a component, then the
corresponding box dimension will change during a simulation. For
example, if the *y* keyword is used, the y-box length will change. If
the *xy* keyword is used, the xy tilt factor will change. A box
dimension will not change if that component is not specified, although
you have the option to change that dimension via the :doc:`fix deform <fix_deform>` command.
Note that in order to use the *xy*\ , *xz*\ , or *yz* keywords, the
simulation box must be triclinic, even if its initial tilt factors are
0.0.
For all barostat keywords, the *Pdamp* parameter operates like the
*Tdamp* parameter, determining the time scale on which pressure is
relaxed. For example, a value of 10.0 means to relax the pressure in
a timespan of (roughly) 10 time units (e.g. tau or fmsec or psec - see
the :doc:`units <units>` command).
.. note::
A Nose-Hoover barostat will not work well for arbitrary values
of *Pdamp*\ . If *Pdamp* is too small, the pressure and volume can
fluctuate wildly; if it is too large, the pressure will take a very
long time to equilibrate. A good choice for many models is a *Pdamp*
of around 1000 timesteps. However, note that *Pdamp* is specified in
time units, and that timesteps are NOT the same as time units for most
:doc:`units <units>` settings.
Regardless of what atoms are in the fix group (the only atoms which
are time integrated), a global pressure or stress tensor is computed
for all atoms. Similarly, when the size of the simulation box is
changed, all atoms are re-scaled to new positions, unless the keyword
*dilate* is specified with a *dilate-group-ID* for a group that
represents a subset of the atoms. This can be useful, for example, to
leave the coordinates of atoms in a solid substrate unchanged and
controlling the pressure of a surrounding fluid. This option should
be used with care, since it can be unphysical to dilate some atoms and
not others, because it can introduce large, instantaneous
displacements between a pair of atoms (one dilated, one not) that are
far from the dilation origin. Also note that for atoms not in the fix
group, a separate time integration fix like :doc:`fix nve <fix_nve>` or
:doc:`fix nvt <fix_nh>` can be used on them, independent of whether they
are dilated or not.
----------
The *couple* keyword allows two or three of the diagonal components of
the pressure tensor to be "coupled" together. The value specified
with the keyword determines which are coupled. For example, *xz*
means the *Pxx* and *Pzz* components of the stress tensor are coupled.
*Xyz* means all 3 diagonal components are coupled. Coupling means two
things: the instantaneous stress will be computed as an average of the
corresponding diagonal components, and the coupled box dimensions will
be changed together in lockstep, meaning coupled dimensions will be
dilated or contracted by the same percentage every timestep. The
*Pstart*\ , *Pstop*\ , *Pdamp* parameters for any coupled dimensions must
be identical. *Couple xyz* can be used for a 2d simulation; the *z*
dimension is simply ignored.
----------
The *iso*\ , *aniso*\ , and *tri* keywords are simply shortcuts that are
equivalent to specifying several other keywords together.
The keyword *iso* means couple all 3 diagonal components together when
pressure is computed (hydrostatic pressure), and dilate/contract the
dimensions together. Using "iso Pstart Pstop Pdamp" is the same as
specifying these 4 keywords:
.. parsed-literal::
x Pstart Pstop Pdamp
y Pstart Pstop Pdamp
z Pstart Pstop Pdamp
couple xyz
The keyword *aniso* means *x*\ , *y*\ , and *z* dimensions are controlled
independently using the *Pxx*\ , *Pyy*\ , and *Pzz* components of the
stress tensor as the driving forces, and the specified scalar external
pressure. Using "aniso Pstart Pstop Pdamp" is the same as specifying
these 4 keywords:
.. parsed-literal::
x Pstart Pstop Pdamp
y Pstart Pstop Pdamp
z Pstart Pstop Pdamp
couple none
The keyword *tri* means *x*\ , *y*\ , *z*\ , *xy*\ , *xz*\ , and *yz* dimensions
are controlled independently using their individual stress components
as the driving forces, and the specified scalar pressure as the
external normal stress. Using "tri Pstart Pstop Pdamp" is the same as
specifying these 7 keywords:
.. parsed-literal::
x Pstart Pstop Pdamp
y Pstart Pstop Pdamp
z Pstart Pstop Pdamp
xy 0.0 0.0 Pdamp
yz 0.0 0.0 Pdamp
xz 0.0 0.0 Pdamp
couple none
----------
In some cases (e.g. for solids) the pressure (volume) and/or
temperature of the system can oscillate undesirably when a Nose/Hoover
barostat and thermostat is applied. The optional *drag* keyword will
damp these oscillations, although it alters the Nose/Hoover equations.
A value of 0.0 (no drag) leaves the Nose/Hoover formalism unchanged.
A non-zero value adds a drag term; the larger the value specified, the
greater the damping effect. Performing a short run and monitoring the
pressure and temperature is the best way to determine if the drag term
is working. Typically a value between 0.2 to 2.0 is sufficient to
damp oscillations after a few periods. Note that use of the drag
keyword will interfere with energy conservation and will also change
the distribution of positions and velocities so that they do not
correspond to the nominal NVT, NPT, or NPH ensembles.
An alternative way to control initial oscillations is to use chain
thermostats. The keyword *tchain* determines the number of thermostats
in the particle thermostat. A value of 1 corresponds to the original
Nose-Hoover thermostat. The keyword *pchain* specifies the number of
thermostats in the chain thermostatting the barostat degrees of
freedom. A value of 0 corresponds to no thermostatting of the
barostat variables.
The *mtk* keyword controls whether or not the correction terms due to
Martyna, Tuckerman, and Klein are included in the equations of motion
:ref:`(Martyna) <nc-Martyna>`. Specifying *no* reproduces the original
Hoover barostat, whose volume probability distribution function
differs from the true NPT and NPH ensembles by a factor of 1/V. Hence
using *yes* is more correct, but in many cases the difference is
negligible.
The keyword *tloop* can be used to improve the accuracy of integration
scheme at little extra cost. The initial and final updates of the
thermostat variables are broken up into *tloop* sub-steps, each of
length *dt*\ /\ *tloop*\ . This corresponds to using a first-order
Suzuki-Yoshida scheme :ref:`(Tuckerman) <nc-Tuckerman>`. The keyword *ploop*
does the same thing for the barostat thermostat.
The keyword *nreset* controls how often the reference dimensions used
to define the strain energy are reset. If this keyword is not used,
or is given a value of zero, then the reference dimensions are set to
those of the initial simulation domain and are never changed. If the
simulation domain changes significantly during the simulation, then
the final average pressure tensor will differ significantly from the
specified values of the external stress tensor. A value of *nstep*
means that every *nstep* timesteps, the reference dimensions are set
to those of the current simulation domain.
The *scaleyz*\ , *scalexz*\ , and *scalexy* keywords control whether or
not the corresponding tilt factors are scaled with the associated box
dimensions when barostatting triclinic periodic cells. The default
values *yes* will turn on scaling, which corresponds to adjusting the
linear dimensions of the cell while preserving its shape. Choosing
*no* ensures that the tilt factors are not scaled with the box
dimensions. See below for restrictions and default values in different
situations. In older versions of LAMMPS, scaling of tilt factors was
not performed. The old behavior can be recovered by setting all three
scale keywords to *no*\ .
The *flip* keyword allows the tilt factors for a triclinic box to
exceed half the distance of the parallel box length, as discussed
below. If the *flip* value is set to *yes*\ , the bound is enforced by
flipping the box when it is exceeded. If the *flip* value is set to
*no*\ , the tilt will continue to change without flipping. Note that if
applied stress induces large deformations (e.g. in a liquid), this
means the box shape can tilt dramatically and LAMMPS will run less
efficiently, due to the large volume of communication needed to
acquire ghost atoms around a processor's irregular-shaped sub-domain.
For extreme values of tilt, LAMMPS may also lose atoms and generate an
error.
The *fixedpoint* keyword specifies the fixed point for barostat volume
changes. By default, it is the center of the box. Whatever point is
chosen will not move during the simulation. For example, if the lower
periodic boundaries pass through (0,0,0), and this point is provided
to *fixedpoint*\ , then the lower periodic boundaries will remain at
(0,0,0), while the upper periodic boundaries will move twice as
far. In all cases, the particle trajectories are unaffected by the
chosen value, except for a time-dependent constant translation of
positions.
----------
.. note::
Using a barostat coupled to tilt dimensions *xy*\ , *xz*\ , *yz* can
sometimes result in arbitrarily large values of the tilt dimensions,
i.e. a dramatically deformed simulation box. LAMMPS allows the tilt
factors to grow a small amount beyond the normal limit of half the box
length (0.6 times the box length), and then performs a box "flip" to
an equivalent periodic cell. See the discussion of the *flip* keyword
above, to allow this bound to be exceeded, if desired.
The flip operation is described in more detail in the doc page for
:doc:`fix deform <fix_deform>`. Both the barostat dynamics and the atom
trajectories are unaffected by this operation. However, if a tilt
factor is incremented by a large amount (1.5 times the box length) on
a single timestep, LAMMPS can not accommodate this event and will
terminate the simulation with an error. This error typically indicates
that there is something badly wrong with how the simulation was
constructed, such as specifying values of *Pstart* that are too far
from the current stress value, or specifying a timestep that is too
large. Triclinic barostatting should be used with care. This also is
true for other barostat styles, although they tend to be more
forgiving of insults. In particular, it is important to recognize that
equilibrium liquids can not support a shear stress and that
equilibrium solids can not support shear stresses that exceed the
yield stress.
One exception to this rule is if the 1st dimension in the tilt factor
(x for xy) is non-periodic. In that case, the limits on the tilt
factor are not enforced, since flipping the box in that dimension does
not change the atom positions due to non-periodicity. In this mode,
if you tilt the system to extreme angles, the simulation will simply
become inefficient due to the highly skewed simulation box.
.. note::
Unlike the :doc:`fix temp/berendsen <fix_temp_berendsen>` command
which performs thermostatting but NO time integration, this fix
performs thermostatting/barostatting AND time integration. Thus you
should not use any other time integration fix, such as :doc:`fix nve <fix_nve>` on atoms to which this fix is applied. Likewise,
fix npt/cauchy should not normally be used on atoms that also
have their temperature controlled by another fix - e.g. by :doc:`fix langevin <fix_nh>` or :doc:`fix temp/rescale <fix_temp_rescale>`
commands.
See the :doc:`Howto thermostat <Howto_thermostat>` and :doc:`Howto barostat <Howto_barostat>` doc pages for a discussion of different
ways to compute temperature and perform thermostatting and
barostatting.
----------
This fix compute a temperature and pressure each timestep. To do
this, the fix creates its own computes of style "temp" and "pressure",
as if one of these sets of commands had been issued:
.. parsed-literal::
compute fix-ID_temp all temp
compute fix-ID_press all pressure fix-ID_temp
The group for both the new temperature and pressure compute is "all"
since pressure is computed for the entire system. See the :doc:`compute temp <compute_temp>` and :doc:`compute pressure <compute_pressure>`
commands for details. Note that the IDs of the new computes are the
fix-ID + underscore + "temp" or fix\_ID + underscore + "press".
Note that these are NOT the computes used by thermodynamic output (see
the :doc:`thermo\_style <thermo_style>` command) with ID = *thermo\_temp*
and *thermo\_press*. This means you can change the attributes of these
fix's temperature or pressure via the
:doc:`compute\_modify <compute_modify>` command. Or you can print this
temperature or pressure during thermodynamic output via the
:doc:`thermo\_style custom <thermo_style>` command using the appropriate
compute-ID. It also means that changing attributes of *thermo\_temp*
or *thermo\_press* will have no effect on this fix.
Like other fixes that perform thermostatting, fix npt/cauchy can
be used with :doc:`compute commands <compute>` that calculate a
temperature after removing a "bias" from the atom velocities.
E.g. removing the center-of-mass velocity from a group of atoms or
only calculating temperature on the x-component of velocity or only
calculating temperature for atoms in a geometric region. This is not
done by default, but only if the :doc:`fix\_modify <fix_modify>` command
is used to assign a temperature compute to this fix that includes such
a bias term. See the doc pages for individual :doc:`compute commands <compute>` to determine which ones include a bias. In
this case, the thermostat works in the following manner: the current
temperature is calculated taking the bias into account, bias is
removed from each atom, thermostatting is performed on the remaining
thermal degrees of freedom, and the bias is added back in.
----------
This fix can be used with either the *verlet* or *respa*
:doc:`integrators <run_style>`. When using this fix
with *respa*\ , LAMMPS uses an integrator constructed
according to the following factorization of the Liouville propagator
(for two rRESPA levels):
.. image:: Eqs/fix_nh1.jpg
:align: center
This factorization differs somewhat from that of Tuckerman et al, in
that the barostat is only updated at the outermost rRESPA level,
whereas Tuckerman's factorization requires splitting the pressure into
pieces corresponding to the forces computed at each rRESPA level. In
theory, the latter method will exhibit better numerical stability. In
practice, because Pdamp is normally chosen to be a large multiple of
the outermost rRESPA timestep, the barostat dynamics are not the
limiting factor for numerical stability. Both factorizations are
time-reversible and can be shown to preserve the phase space measure
of the underlying non-Hamiltonian equations of motion.
.. note::
Under NPT dynamics, for a system with zero initial total linear
momentum, the total momentum fluctuates close to zero. It may occasionally
undergo brief excursions to non-negligible values, before returning close
to zero. Over long simulations, this has the effect of causing the
center-of-mass to undergo a slow random walk. This can be mitigated by
resetting the momentum at infrequent intervals using the
:doc:`fix momentum <fix_momentum>` command.
----------
**Restart, fix\_modify, output, run start/stop, minimize info:**
This fix writes the state of all the thermostat and barostat
variables to :doc:`binary restart files <restart>`. See the
:doc:`read\_restart <read_restart>` command for info on how to re-specify
a fix in an input script that reads a restart file, so that the
operation of the fix continues in an uninterrupted fashion.
The :doc:`fix\_modify <fix_modify>` *temp* and *press* options are
supported by this fix. You can use them to assign a
:doc:`compute <compute>` you have defined to this fix which will be used
in its thermostatting or barostatting procedure, as described above.
If you do this, note that the kinetic energy derived from the compute
temperature should be consistent with the virial term computed using
all atoms for the pressure. LAMMPS will warn you if you choose to
compute temperature on a subset of atoms.
.. note::
If both the *temp* and *press* keywords are used in a single
thermo\_modify command (or in two separate commands), then the order in
which the keywords are specified is important. Note that a :doc:`pressure compute <compute_pressure>` defines its own temperature compute as
an argument when it is specified. The *temp* keyword will override
this (for the pressure compute being used by fix npt), but only if the
*temp* keyword comes after the *press* keyword. If the *temp* keyword
comes before the *press* keyword, then the new pressure compute
specified by the *press* keyword will be unaffected by the *temp*
setting.
The :doc:`fix\_modify <fix_modify>` *energy* option is supported by this
fix to add the energy change induced by Nose/Hoover thermostatting
and barostatting to the system's potential energy as part of
:doc:`thermodynamic output <thermo_style>`.
This fix computes a global scalar and a global vector of quantities,
which can be accessed by various :doc:`output commands <Howto_output>`.
The scalar value calculated by this fix is "extensive"; the vector
values are "intensive".
The scalar is the cumulative energy change due to the fix.
The vector stores internal Nose/Hoover thermostat and barostat
variables. The number and meaning of the vector values depends on
which fix is used and the settings for keywords *tchain* and *pchain*\ ,
which specify the number of Nose/Hoover chains for the thermostat and
barostat. If no thermostatting is done, then *tchain* is 0. If no
barostatting is done, then *pchain* is 0. In the following list,
"ndof" is 0, 1, 3, or 6, and is the number of degrees of freedom in
the barostat. Its value is 0 if no barostat is used, else its value
is 6 if any off-diagonal stress tensor component is barostatted, else
its value is 1 if *couple xyz* is used or *couple xy* for a 2d
simulation, otherwise its value is 3.
The order of values in the global vector and their meaning is as
follows. The notation means there are tchain values for eta, followed
by tchain for eta\_dot, followed by ndof for omega, etc:
* eta[tchain] = particle thermostat displacements (unitless)
* eta\_dot[tchain] = particle thermostat velocities (1/time units)
* omega[ndof] = barostat displacements (unitless)
* omega\_dot[ndof] = barostat velocities (1/time units)
* etap[pchain] = barostat thermostat displacements (unitless)
* etap\_dot[pchain] = barostat thermostat velocities (1/time units)
* PE\_eta[tchain] = potential energy of each particle thermostat displacement (energy units)
* KE\_eta\_dot[tchain] = kinetic energy of each particle thermostat velocity (energy units)
* PE\_omega[ndof] = potential energy of each barostat displacement (energy units)
* KE\_omega\_dot[ndof] = kinetic energy of each barostat velocity (energy units)
* PE\_etap[pchain] = potential energy of each barostat thermostat displacement (energy units)
* KE\_etap\_dot[pchain] = kinetic energy of each barostat thermostat velocity (energy units)
* PE\_strain[1] = scalar strain energy (energy units)
This fix can ramp its external temperature and pressure over
multiple runs, using the *start* and *stop* keywords of the
:doc:`run <run>` command. See the :doc:`run <run>` command for details of
how to do this.
This fix is not invoked during :doc:`energy minimization <minimize>`.
----------
Restrictions
""""""""""""
This fix is part of the USER-MISC package. It is only enabled if
LAMMPS was built with that package. See the :doc:`Build package <Build_package>` doc page for more info.
*X*\ , *y*\ , *z* cannot be barostatted if the associated dimension is not
periodic. *Xy*\ , *xz*\ , and *yz* can only be barostatted if the
simulation domain is triclinic and the 2nd dimension in the keyword
(\ *y* dimension in *xy*\ ) is periodic. *Z*\ , *xz*\ , and *yz*\ , cannot be
barostatted for 2D simulations. The :doc:`create\_box <create_box>`,
:doc:`read data <read_data>`, and :doc:`read\_restart <read_restart>`
commands specify whether the simulation box is orthogonal or
non-orthogonal (triclinic) and explain the meaning of the xy,xz,yz
tilt factors.
For the *temp* keyword, the final Tstop cannot be 0.0 since it would
make the external T = 0.0 at some timestep during the simulation which
is not allowed in the Nose/Hoover formulation.
The *scaleyz yes* and *scalexz yes* keyword/value pairs can not be used
for 2D simulations. *scaleyz yes*\ , *scalexz yes*\ , and *scalexy yes* options
can only be used if the 2nd dimension in the keyword is periodic,
and if the tilt factor is not coupled to the barostat via keywords
*tri*\ , *yz*\ , *xz*\ , and *xy*\ .
Without the *cauchystat* keyword, the barostat algorithm
controls the Second-Piola Kirchhoff stress, which is a stress measure
referred to the unmodified (initial) simulation box. If the box
deforms substantially during the equilibration, the difference between
the set values and the final true (Cauchy) stresses can be
considerable.
The *cauchystat* keyword modifies the barostat as per Miller et
al. (Miller)\_"#nc-Miller" so that the Cauchy stress is controlled.
*alpha* is the non-dimensional parameter, typically set to 0.001 or
0.01 that determines how aggressively the algorithm drives the system
towards the set Cauchy stresses. Larger values of *alpha* will modify
the system more quickly, but can lead to instabilities. Smaller
values will lead to longer convergence time. Since *alpha* also
influences how much the stress fluctuations deviate from the
equilibrium fluctuations, it should be set as small as possible.
A *continue* value of *yes* indicates that the fix is subsequent to a
previous run with the npt/cauchy fix, and the intention is to continue
from the converged stress state at the end of the previous run. This
may be required, for example, when implementing a multi-step loading/unloading
sequence over several fixes.
Setting *alpha* to zero is not permitted. To "turn off" the
cauchystat control and thus restore the equilibrium stress
fluctuations, two subsequent fixes should be used. In the first, the
cauchystat flag is used and the simulation box equilibrates to the
correct shape for the desired stresses. In the second, the *fix*
statement is identical except that the *cauchystat* keyword is removed
(along with related *alpha* and *continue* values). This restores the
original Parrinello-Rahman algorithm, but now with the correct simulation
box shape from the first fix.
This fix can be used with dynamic groups as defined by the
:doc:`group <group>` command. Likewise it can be used with groups to
which atoms are added or deleted over time, e.g. a deposition
simulation. However, the conservation properties of the thermostat
and barostat are defined for systems with a static set of atoms. You
may observe odd behavior if the atoms in a group vary dramatically
over time or the atom count becomes very small.
Related commands
""""""""""""""""
:doc:`fix nve <fix_nve>`, :doc:`fix\_modify <fix_modify>`,
:doc:`run\_style <run_style>`
Default
"""""""
The keyword defaults are tchain = 3, pchain = 3, mtk = yes, tloop =
ploop = 1, nreset = 0, drag = 0.0, dilate = all, couple = none,
cauchystat = no,
scaleyz = scalexz = scalexy = yes if periodic in 2nd dimension and
not coupled to barostat, otherwise no.
----------
.. _nc-Martyna:
**(Martyna)** Martyna, Tobias and Klein, J Chem Phys, 101, 4177 (1994).
.. _nc-Parrinello:
**(Parrinello)** Parrinello and Rahman, J Appl Phys, 52, 7182 (1981).
.. _nc-Tuckerman:
**(Tuckerman)** Tuckerman, Alejandre, Lopez-Rendon, Jochim, and
Martyna, J Phys A: Math Gen, 39, 5629 (2006).
.. _nc-Shinoda:
**(Shinoda)** Shinoda, Shiga, and Mikami, Phys Rev B, 69, 134103 (2004).
.. _nc-Miller:
**(Miller)** Miller, Tadmor, Gibson, Bernstein and Pavia, J Chem Phys,
144, 184107 (2016).
.. _lws: http://lammps.sandia.gov
.. _ld: Manual.html
.. _lc: Commands_all.html

113
doc/src/fix_propel_self.rst Normal file
View File

@ -0,0 +1,113 @@
.. index:: fix propel/self
fix propel/self command
=======================
Syntax
""""""
fix ID group-ID propel/self mode magnitude keyword values ...
* ID, group-ID are documented in :doc:`fix <fix>` command
* propel/self = style name of this fix command
* mode = velocity or quat
* magnitude = magnitude of the active force
* one or more keyword/value pairs may be appended to args
* keyword = *types*
*types* values = one or more atom types
Examples
""""""""
.. parsed-literal::
fix active_group all propel/self velocity 1.0
fix constant_velocity all viscous 1.0
fix active_group all propel/self quat 1.0
fix active all propel/self quat 1.0 types 1 2 4
Description
"""""""""""
Adds a force of a constant magnitude to each atom in the group. The nature in
which the force is added depends on the mode.
For *mode* = *velocity*, the active force acts along the velocity vector of
each atom. This can be interpreted as a velocity-dependent friction,
such as proposed by :ref:`(Erdmann) <Erdmann>`.
For *mode* = *quat* the force is applied along the axis obtained
by rotating the x-axis along the atom's quaternion. In other words, the
force is along the x-axis in the atom's body frame. This mode requires
all atoms in the group to have a quaternion, so atom\_style should
either be ellipsoid or body. In combination with Langevin thermostat
for translation and rotation in the overdamped regime, the quaternion
mode corresponds to the active Brownian particle model introduced by
:ref:`(Henkes) <Henkes>`, :ref:`(Bialke) <Bialke>` and :ref:`(Fily)
<Fily>`.
By default, this fix is applied to all atoms in the group. You can
override this behavior by specifying the atom types the fix should work
on through the *types* keyword.
----------
**Restart, fix\_modify, output, run start/stop, minimize info:**
No information about this fix is written to :doc:`binary restart files <restart>`.
This fix is not imposed during minimization.
Restrictions
""""""""""""
In quat mode, this fix makes use of per-atom quaternions to take
into account the fact that the orientation can rotate and hence the
direction of the active force can change. The quat mode
of this fix only works with atom\_style ellipsoid.
Related commands
""""""""""""""""
:doc:`fix setforce <fix_setforce>`, :doc:`fix addforce <fix_addforce>`
.. _Erdmann:
**(Erdmann)** U. Erdmann , W. Ebeling, L. Schimansky-Geier, and F. Schweitzer,
Eur. Phys. J. B 15, 105-113, 2000.
.. _Henkes:
**(Henkes)** Henkes, S, Fily, Y., and Marchetti, M. C. Phys. Rev. E, 84, 040301(R), 2011.
.. _Bialke:
**(Bialke)** J. Bialke, T. Speck, and H Loewen, Phys. Rev. Lett. 108, 168301, 2012.
.. _Fily:
**(Fily)** Y. Fily and M.C. Marchetti, Phys. Rev. Lett. 108, 235702, 2012.
**Default:** types
.. _lws: http://lammps.sandia.gov
.. _ld: Manual.html
.. _lc: Commands_all.html

50
doc/src/fix_wall_reflect.rst
View File

@ -21,13 +21,9 @@ Syntax
.. parsed-literal::
*xlo*\ ,\ *ylo*\ ,\ *zlo* arg = EDGE or constant or variable
arg = EDGE or constant or variable
EDGE = current lo edge of simulation box
constant = number like 0.0 or -30.0 (distance units)
variable = :doc:`equal-style variable <variable>` like v_x or v_wiggle
*xhi*\ ,\ *yhi*\ ,\ *zhi* arg = EDGE or constant or variable
EDGE = current hi edge of simulation box
constant = number like 50.0 or 100.3 (distance units)
constant = number like 0.0 or 30.0 (distance units)
variable = :doc:`equal-style variable <variable>` like v_x or v_wiggle
* zero or more keyword/value pairs may be appended
@ -62,11 +58,12 @@ by a distance delta (e.g. due to :doc:`fix nve <fix_nve>`), then it is
put back inside the face by the same delta, and the sign of the
corresponding component of its velocity is flipped.
When used in conjunction with :doc:`fix nve <fix_nve>` and :doc:`run\_style verlet <run_style>`, the resultant time-integration algorithm is
equivalent to the primitive splitting algorithm (PSA) described by
:ref:`Bond <Bond1>`. Because each reflection event divides
the corresponding timestep asymmetrically, energy conservation is only
satisfied to O(dt), rather than to O(dt\^2) as it would be for
When used in conjunction with :doc:`fix nve <fix_nve>` and
:doc:`run\_style verlet <run_style>`, the resultant time-integration
algorithm is equivalent to the primitive splitting algorithm (PSA)
described by :ref:`Bond <Bond1>`. Because each reflection event
divides the corresponding timestep asymmetrically, energy conservation
is only satisfied to O(dt), rather than to O(dt\^2) as it would be for
velocity-Verlet integration without reflective walls.
Up to 6 walls or faces can be specified in a single command: *xlo*\ ,
@ -156,17 +153,19 @@ perturbation on the particles:
Styles with a *gpu*\ , *intel*\ , *kk*\ , *omp*\ , or *opt* suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed on the :doc:`Speed packages <Speed_packages>` doc
page. The accelerated styles take the same arguments and should
hardware, as discussed on the :doc:`Speed packages <Speed_packages>`
doc page. The accelerated styles take the same arguments and should
produce the same results, except for round-off and precision issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the :doc:`Build package <Build_package>` doc page for more info.
LAMMPS was built with those packages. See the :doc:`Build package
<Build_package>` doc page for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the :doc:`-suffix command-line switch <Run_options>` when you invoke LAMMPS, or you can use the
:doc:`suffix <suffix>` command in your input script.
by including their suffix, or you can use the :doc:`-suffix
command-line switch <Run_options>` when you invoke LAMMPS, or you can
use the :doc:`suffix <suffix>` command in your input script.
See the :doc:`Speed packages <Speed_packages>` doc page for more
instructions on how to use the accelerated styles effectively.
@ -177,11 +176,13 @@ instructions on how to use the accelerated styles effectively.
**Restart, fix\_modify, output, run start/stop, minimize info:**
No information about this fix is written to :doc:`binary restart files <restart>`. None of the :doc:`fix\_modify <fix_modify>` options
are relevant to this fix. No global or per-atom quantities are stored
by this fix for access by various :doc:`output commands <Howto_output>`.
No information about this fix is written to :doc:`binary restart files
<restart>`. None of the :doc:`fix\_modify <fix_modify>` options are
relevant to this fix. No global or per-atom quantities are stored by
this fix for access by various :doc:`output commands <Howto_output>`.
No parameter of this fix can be used with the *start/stop* keywords of
the :doc:`run <run>` command. This fix is not invoked during :doc:`energy minimization <minimize>`.
the :doc:`run <run>` command. This fix is not invoked during
:doc:`energy minimization <minimize>`.
Restrictions
""""""""""""
@ -192,17 +193,18 @@ Any dimension (xyz) that has a reflecting wall must be non-periodic.
A reflecting wall should not be used with rigid bodies such as those
defined by a "fix rigid" command. This is because the wall/reflect
displaces atoms directly rather than exerts a force on them. For
rigid bodies, use a soft wall instead, such as :doc:`fix wall/lj93 <fix_wall>`. LAMMPS will flag the use of a rigid
fix with fix wall/reflect with a warning, but will not generate an
error.
rigid bodies, use a soft wall instead, such as :doc:`fix wall/lj93
<fix_wall>`. LAMMPS will flag the use of a rigid fix with fix
wall/reflect with a warning, but will not generate an error.
Related commands
""""""""""""""""
:doc:`fix wall/lj93 <fix_wall>`, :doc:`fix oneway <fix_oneway>`
**Default:** none
**Default:**
The default for the units keyword is lattice.
----------

157
doc/src/fix_wall_reflect_stochastic.rst Normal file
View File

@ -0,0 +1,157 @@
.. index:: fix wall/reflect/stochastic
fix wall/reflect/stochastic command
===================================
Syntax
""""""
.. parsed-literal::
fix ID group-ID wall/reflect/stochastic rstyle seed face args ... keyword value ...
* ID, group-ID are documented in :doc:`fix <fix>` command
* wall/reflect/stochastic = style name of this fix command
* rstyle = diffusive or maxwell or ccl
* seed = random seed for stochasticity (positive integer)
* one or more face/args pairs may be appended
* face = *xlo* or *xhi* or *ylo* or *yhi* or *zlo* or *zhi*
.. parsed-literal::
args = pos temp velx vely velz accomx accomy accomz
pos = EDGE or constant
EDGE = current lo or hi edge of simulation box
constant = number like 0.0 or 30.0 (distance units)
temp = wall temperature (temperature units)
velx,vely,velz = wall velocity in x,y,z directions (velocity units)
accomx,accomy,accomz = accommodation coeffs in x,y,z directions (unitless)
not specified for rstyle = diffusive
single accom coeff specified for rstyle maxwell
all 3 coeffs specified for rstyle cll
* zero or more keyword/value pairs may be appended
* keyword = *units*
.. parsed-literal::
*units* value = *lattice* or *box*
*lattice* = the wall position is defined in lattice units
*box* = the wall position is defined in simulation box units
Examples
""""""""
.. parsed-literal::
fix zwalls all wall/reflect/stochastic diffusive 23424 zlo EDGE 300 0.1 0.1 0 zhi EDGE 200 0.1 0.1 0
fix ywalls all wall/reflect/stochastic maxwell 345533 ylo 5.0 300 0.1 0.0 0.0 0.8 yhi 10.0 300 0.1 0.0 0.0 0.8
fix xwalls all wall/reflect/stochastic cercignanilampis 2308 xlo 0.0 300 0.0 0.1 0.9 0.8 0.7 xhi EDGE 300 0.0 0.1 0 0.9 0.8 0.7 units box
Description
"""""""""""
Bound the simulation with one or more walls which reflect particles
in the specified group when they attempt to move through them.
Reflection means that if an atom moves outside the wall on a timestep
(e.g. due to the :doc:`fix nve <fix_nve>` command), then it is put back
inside the wall with a changed velocity.
This fix models treats the wall as a moving solid boundary with a
finite temperature, which can exchange energy with particles that
collide with it. This is different than the simpler :doc:`fix wall/reflect <fix_wall_reflect>` command which models mirror
reflection. For this fix, the post collision velocity of each
particle is treated stochastically. The randomness can come from many
sources: thermal motion of the wall atoms, surface roughness, etc.
Three stochastic reflection models are currently implemented.
For rstyle *diffusive*\ , particles are reflected diffusively. Their
velocity distribution corresponds to an equilibrium distribution of
particles at the wall temperature. No accommodation coefficients
are specified.
For rstyle *maxwell*\ , particle reflection is Maxwellian which means
partially diffusive and partially specular (:ref:`Maxwell <Maxwell>`). A
single accommodation coeff is specified which must be between 0.0 and
1.0 inclusive. It determines the fraction of the collision which is
diffusive versus specular. An accommodation coefficient of 1.0 is fully
diffusive; a coefficient of 0.0 is fully specular.
For rstyle *cll*\ , particle collisions are computed by the
Cercignani/Lampis model. See :ref:`CL <CL>` and :ref:`To <To>` for details.
Three accommodations coefficient are specified. Each must be between
0.0 and 1.0 inclusive. Two are velocity accommodation coefficients;
one is a normal kinetic energy accommodation. The normal coeff is the
one corresponding to the normal of the wall itself. For example if
the wall is *ylo* or *yhi*\ , *accomx* and *accomz* are the tangential
velocity accommodation coefficients, and *accomy* is the normal
kinetic energy accommodation coefficient.
The optional *units* keyword determines the distance units used to
define a wall position. A *box* value selects standard distance units
as defined by the :doc:`units <units>` command, e.g. Angstroms for units
= real or metal. A *lattice* value means the distance units are in
lattice spacings. The :doc:`lattice <lattice>` command must have been
previously used to define the lattice spacings.
----------
Restrictions
""""""""""""
This fix has the same limitations as the :doc:`fix wall/reflect <fix_wall_reflect>` command. Any dimension (xyz) that
has a wall must be non-periodic. It should not be used with rigid
bodies such as those defined by the :doc:`fix rigid <fix_rigid>`
command. The wall velocity must lie on the same plane as the wall
itself.
This fix is part of the USER-MISC package. It is only enabled if
LAMMPS was built with that package. See the :doc:`Build package <Build_package>` doc page for more info.
Related commands
""""""""""""""""
:doc:`fix wall/reflect <fix_wall_reflect>`
Default
"""""""
The default for the units keyword is lattice.
----------
.. _Maxwell:
**(Maxwell)** J.C. Maxwell, Philos. Tans. Royal Soc. London, 157: 49-88
(1867).
.. _CL:
**(Cercignani)** C. Cercignani and M. Lampis. Trans. Theory
Stat. Phys. 1, 2, 101 (1971).
.. _To:
**(To)** Q.D. To, V.H. Vu, G. Lauriat, and
C. Leonard. J. Math. Phys. 56, 103101 (2015).
.. _lws: http://lammps.sandia.gov
.. _ld: Manual.html
.. _lc: Commands_all.html

31
doc/src/kspace_style.rst
View File

@ -11,26 +11,30 @@ Syntax
kspace_style style value
* style = *none* or *ewald* or *ewald/disp* or *ewald/omp* or *pppm* or *pppm/cg* or *pppm/disp* or *pppm/tip4p* or *pppm/stagger* or *pppm/disp/tip4p* or *pppm/gpu* or *pppm/kk* or *pppm/omp* or *pppm/cg/omp* or *pppm/tip4p/omp* or *msm* or *msm/cg* or *msm/omp* or *msm/cg/omp* or *scafacos*
* style = *none* or *ewald* or *ewald/dipole* or *ewald/dipole/spin* or *ewald/disp* or *ewald/omp* or *pppm* or *pppm/cg* or *pppm/disp* or *pppm/tip4p* or *pppm/stagger* or *pppm/disp/tip4p* or *pppm/gpu* or *pppm/intel* or *pppm/disp/intel* or *pppm/kk* or *pppm/omp* or *pppm/cg/omp* or *pppm/disp/tip4p/omp* or *pppm/tip4p/omp* or *msm* or *msm/cg* or *msm/omp* or *msm/cg/omp* or *scafacos*
.. parsed-literal::
*none* value = none
*ewald* value = accuracy
accuracy = desired relative error in forces
*ewald/disp* value = accuracy
accuracy = desired relative error in forces
*ewald/omp* value = accuracy
accuracy = desired relative error in forces
*ewald/dipole* value = accuracy
accuracy = desired relative error in forces
*ewald/dipole/spin* value = accuracy
accuracy = desired relative error in forces
*ewald/disp* value = accuracy
accuracy = desired relative error in forces
*ewald/omp* value = accuracy
accuracy = desired relative error in forces
*pppm* value = accuracy
accuracy = desired relative error in forces
*pppm/cg* values = accuracy (smallq)
accuracy = desired relative error in forces
smallq = cutoff for charges to be considered (optional) (charge units)
*pppm/dipole* value = accuracy
accuracy = desired relative error in forces
*pppm/dipole/spin* value = accuracy
accuracy = desired relative error in forces
*pppm/disp* value = accuracy
accuracy = desired relative error in forces
*pppm/tip4p* value = accuracy
@ -41,22 +45,23 @@ Syntax
accuracy = desired relative error in forces
*pppm/intel* value = accuracy
accuracy = desired relative error in forces
*pppm/disp/intel* value = accuracy
accuracy = desired relative error in forces
*pppm/kk* value = accuracy
accuracy = desired relative error in forces
*pppm/omp* value = accuracy
accuracy = desired relative error in forces
*pppm/cg/omp* value = accuracy
*pppm/cg/omp* values = accuracy (smallq)
accuracy = desired relative error in forces
*pppm/disp/intel* value = accuracy
smallq = cutoff for charges to be considered (optional) (charge units)
*pppm/disp/omp* value = accuracy
accuracy = desired relative error in forces
*pppm/tip4p/omp* value = accuracy
accuracy = desired relative error in forces
*pppm/disp/tip4p/omp* value = accuracy
accuracy = desired relative error in forces
*pppm/stagger* value = accuracy
accuracy = desired relative error in forces
*pppm/dipole* value = accuracy
accuracy = desired relative error in forces
*pppm/dipole/spin* value = accuracy
accuracy = desired relative error in forces
*msm* value = accuracy
accuracy = desired relative error in forces
*msm/cg* value = accuracy (smallq)

47
doc/src/message.rst
View File

@ -11,7 +11,7 @@ Syntax
message which protocol mode arg
* which = *client* or *server*
* which = *client* or *server* or *quit*
* protocol = *md* or *mc*
* mode = *file* or *zmq* or *mpi/one* or *mpi/two*
@ -46,6 +46,8 @@ Examples
message client md mpi/two tmp.couple
message server md mpi/two tmp.couple
message quit
Description
"""""""""""
@ -64,6 +66,10 @@ enables the two codes to work in tandem to perform a simulation.
The *which* argument defines LAMMPS to be the client or the server.
As explained below the *quit* option should be used when LAMMPS is
finished as a client. It sends a message to the server to tell it to
shut down.
----------
@ -146,12 +152,12 @@ path/file in a common filesystem.
----------
Normally, the message command should be used at the top of a LAMMPS
input script. It performs an initial handshake with the other code to
setup messaging and to verify that both codes are using the same
message protocol and mode. Assuming both codes are launched at
(nearly) the same time, the other code should perform the same kind of
initialization.
Normally, the message client or message server command should be used
at the top of a LAMMPS input script. It performs an initial handshake
with the other code to setup messaging and to verify that both codes
are using the same message protocol and mode. Assuming both codes are
launched at (nearly) the same time, the other code should perform the
same kind of initialization.
If LAMMPS is the client code, it will begin sending messages when a
LAMMPS client command begins its operation. E.g. for the :doc:`fix client/md <fix_client_md>` command, it is when a :doc:`run <run>`
@ -160,16 +166,25 @@ command is executed.
If LAMMPS is the server code, it will begin receiving messages when
the :doc:`server <server>` command is invoked.
A fix client command will terminate its messaging with the server when
LAMMPS ends, or the fix is deleted via the :doc:`unfix <unfix>` command.
The server command will terminate its messaging with the client when the
client signals it. Then the remainder of the LAMMPS input script will
be processed.
If LAMMPS is being used as a client, the message quit command will
terminate its messaging with the server. If you do not use this
command and just allow LAMMPS to exit, then the server will continue
to wait for further messages. This may not be a problem, but if both
the client and server programs were launched in the same batch script,
then if the server runs indefinitely, it may consume the full allocation
of computer time, even if the calculation finishes sooner.
If both codes do something similar, this means a new round of
client/server messaging can be initiated after termination by re-using
a 2nd message command in your LAMMPS input script, followed by a new
fix client or server command.
Note that if LAMMPS is the client or server, it will continue
processing the rest of its input script after client/server
communication terminates.
If both codes cooperate in this manner, a new round of client/server
messaging can be initiated after termination by re-using a 2nd message
command in your LAMMPS input script, followed by a new fix client or
server command, followed by another message quit command (if LAMMPS is
the client). As an example, this can be performed in a loop to use a
quantum code as a server to compute quantum forces for multiple LAMMPS
data files or periodic snapshots while running dynamics.
----------

2
doc/src/pair_granular.rst
View File

@ -432,7 +432,7 @@ option by an additional factor of *a*\ , the radius of the contact region. The t
Here, *a* is the radius of the contact region, given by :math:`a =\sqrt{R\delta}`
for all normal contact models, except for *jkr*\ , where it is given
implicitly by :math:`\delta = a^2/R - 2\sqrt{\pi \gamma a/E}`, see
discussion above. To match the Mindlin solution, one should set :math:`k_t = 8G`, where :math:`G` is the shear modulus, related to Young's modulus
discussion above. To match the Mindlin solution, one should set :math:`k_t = 4G/(2-\nu)`, where :math:`G` is the shear modulus, related to Young's modulus
:math:`E` by :math:`G = E/(2(1+\nu))`, where :math:`\nu` is Poisson's ratio. This
can also be achieved by specifying *NULL* for :math:`k_t`, in which case a
normal contact model that specifies material parameters :math:`E` and

20
doc/src/pair_ilp_graphene_hbn.rst
View File

@ -82,15 +82,15 @@ list for calculating the normals for each atom pair.
.. note::
Two new sets of parameters of ILP for two-dimensional hexagonal
Materials are presented in :ref:`(Ouyang) <Ouyang>`. These parameters provide
a good description in both short- and long-range interaction regimes.
Four new sets of parameters of ILP for 2D layered Materials with bilayer and
bulk configurations are presented in :ref:`(Ouyang1) <Ouyang1>` and :ref:`(Ouyang2) <Ouyang2>`, respectively.
These parameters provide a good description in both short- and long-range interaction regimes.
While the old ILP parameters published in :ref:`(Leven2) <Leven2>` and
:ref:`(Maaravi) <Maaravi2>` are only suitable for long-range interaction
regime. This feature is essential for simulations in high pressure
regime (i.e., the interlayer distance is smaller than the equilibrium
distance). The benchmark tests and comparison of these parameters can
be found in :ref:`(Ouyang) <Ouyang>`.
distance). The benchmark tests and comparison of these parameters can
be found in :ref:`(Ouyang1) <Ouyang1>` and :ref:`(Ouyang2) <Ouyang2>`.
This potential must be used in combination with hybrid/overlay.
Other interactions can be set to zero using pair\_style *none*\ .
@ -185,11 +185,17 @@ Related commands
**(Kolmogorov)** A. N. Kolmogorov, V. H. Crespi, Phys. Rev. B 71, 235415 (2005).
.. _Ouyang:
.. _Ouyang1:
**(Ouyang)** W. Ouyang, D. Mandelli, M. Urbakh and O. Hod, Nano Lett. 18, 6009-6016 (2018).
**(Ouyang1)** W. Ouyang, D. Mandelli, M. Urbakh and O. Hod, Nano Lett. 18, 6009-6016 (2018).
.. _Ouyang2:
**(Ouyang2)** W. Ouyang et al., J. Chem. Theory Comput. 16(1), 666-676 (2020).
.. _lws: http://lammps.sandia.gov

14
doc/src/pair_kolmogorov_crespi_full.rst
View File

@ -70,7 +70,7 @@ list for calculating the normals for each atom pair.
Two new sets of parameters of KC potential for hydrocarbons, CH.KC
(without the taper function) and CH\_taper.KC (with the taper function)
are presented in :ref:`(Ouyang) <Ouyang1>`. The energy for the KC potential
are presented in :ref:`(Ouyang1) <Ouyang3>`. The energy for the KC potential
with the taper function goes continuously to zero at the cutoff. The
parameters in both CH.KC and CH\_taper.KC provide a good description in
both short- and long-range interaction regimes. While the original
@ -78,7 +78,7 @@ list for calculating the normals for each atom pair.
suitable for long-range interaction regime. This feature is essential
for simulations in high pressure regime (i.e., the interlayer distance
is smaller than the equilibrium distance). The benchmark tests and
comparison of these parameters can be found in :ref:`(Ouyang) <Ouyang1>`.
comparison of these parameters can be found in :ref:`(Ouyang1) <Ouyang3>` and :ref:`(Ouyang2) <Ouyang4>`.
This potential must be used in combination with hybrid/overlay.
Other interactions can be set to zero using pair\_style *none*\ .
@ -154,11 +154,17 @@ Related commands
**(Kolmogorov)** A. N. Kolmogorov, V. H. Crespi, Phys. Rev. B 71, 235415 (2005)
.. _Ouyang1:
.. _Ouyang3:
**(Ouyang)** W. Ouyang, D. Mandelli, M. Urbakh and O. Hod, Nano Lett. 18, 6009-6016 (2018).
**(Ouyang1)** W. Ouyang, D. Mandelli, M. Urbakh and O. Hod, Nano Lett. 18, 6009-6016 (2018).
.. _Ouyang4:
**(Ouyang2)** W. Ouyang et al., J. Chem. Theory Comput. 16(1), 666-676 (2020).
.. _lws: http://lammps.sandia.gov

3
doc/src/pair_lj.rst
View File

@ -96,6 +96,9 @@ pair\_style lj/cut/tip4p/cut/omp command
pair\_style lj/cut/tip4p/long command
=====================================
pair\_style lj/cut/tip4p/long/gpu command
=========================================
pair\_style lj/cut/tip4p/long/omp command
=========================================

0
doc/src/pair_lj_switch3_coulgauss.rst → doc/src/pair_lj_switch3_coulgauss_long.rst
View File

13
doc/src/pair_meamc.rst
View File

@ -233,15 +233,20 @@ where
Cmin(I,J,K) = Cmin screening parameter when I-J pair is screened
by K (I<=J); default = 2.0
lattce(I,J) = lattice structure of I-J reference structure:
dia = diamond (interlaced fcc for alloy)
fcc = face centered cubic
bcc = body centered cubic
dim = dimer
b1 = rock salt (NaCl structure)
hcp = hexagonal close-packed
dim = dimer
dia = diamond (interlaced fcc for alloy)
dia3= diamond structure with primary 1NN and secondary 3NN interation
b1 = rock salt (NaCl structure)
c11 = MoSi2 structure
l12 = Cu3Au structure (lower case L, followed by 12)
b2 = CsCl structure (interpenetrating simple cubic)
ch4 = methane-like structure, only for binary system
lin = linear structure (180 degree angle)
zig = zigzag structure with a uniform angle
tri = H2O-like structure that has an angle
nn2(I,J) = turn on second-nearest neighbor MEAM formulation for
I-J pair (see for example :ref:`(Lee) <Lee>`).
0 = second-nearest neighbor formulation off
@ -254,6 +259,8 @@ where
zbl(I,J) = blend the MEAM I-J pair potential with the ZBL potential for small
atom separations :ref:`(ZBL) <ZBL>`
default = 1
theta(I,J) = angle between three atoms in line, zigzag, and trimer reference structures in degrees
default = 180
gsmooth_factor = factor determining the length of the G-function smoothing
region; only significant for ibar=0 or ibar=4.
99.0 = short smoothing region, sharp step

161
doc/src/pair_mesocnt.rst Normal file
View File

@ -0,0 +1,161 @@
.. index:: pair\_style mesocnt
pair\_style mesocnt command
===========================
Syntax
""""""
.. parsed-literal::
pair_style mesocnt
Examples
""""""""
.. parsed-literal::
pair_style mesocnt
pair_coeff \* \* 10_10.cnt
Description
"""""""""""
Style *mesocnt* implements a mesoscopic potential
for the interaction of carbon nanotubes (CNTs). In this potential,
CNTs are modelled as chains of cylindrical segments in which
each infinitesimal surface element interacts with all other
CNT surface elements with the Lennard-Jones (LJ) term adopted from
the :doc:`airebo <pair_airebo>` style. The interaction energy
is then computed by integrating over the surfaces of all interacting
CNTs.
The potential is based on interactions between one cylindrical
segment and infinitely or semi-infinitely long CNTs as described
in :ref:`(Volkov1) <Volkov1>`. Chains of segments are
converted to these (semi-)infinite CNTs bases on an approximate
chain approach outlined in :ref:`(Volkov2) <Volkov2>`.
This allows to simplify the computation of the interactions
significantly and reduces the computational times to the
same order of magnitude as for regular bead spring models
where beads interact with the standard :doc:`pair_lj/cut <pair_lj>`
potential.
In LAMMPS, cylindrical segments are represented by bonds. Each
segment is defined by its two end points ("nodes") which correspond
to atoms in LAMMPS. For the exact functional form of the potential
and implementation details, the reader is referred to the
original papers :ref:`(Volkov1) <Volkov1>` and
:ref:`(Volkov2) <Volkov2>`.
The potential requires tabulated data provided in a single ASCII
text file specified in the :doc:`pair\_coeff <pair_coeff>` command.
The first line of the file provides a time stamp and
general information. The second line lists four integers giving
the number of data points provided in the subsequent four
data tables. The third line lists four floating point numbers:
the CNT radius R, the LJ parameter sigma and two numerical
parameters delta1 and delta2. These four parameters are given
in Angstroms. This is followed by four data tables each separated
by a single empty line. The first two tables have two columns
and list the parameters uInfParallel and Gamma respectively.
The last two tables have three columns giving data on a quadratic
array and list the parameters Phi and uSemiParallel respectively.
uInfParallel and uSemiParallel are given in eV/Angstrom, Phi is
given in eV and Gamma is unitless.
Potential files for CNTs can be readily generated using the freely
available code provided on
.. parsed-literal::
https://github.com/phankl/cntpot
Using the same approach, it should also be possible to
generate potential files for other 1D systems such as
boron nitride nanotubes.
.. note::
LAMMPS comes with one *mesocnt* style potential file
where the default number of data points per table is 1001.
This is sufficient for NVT simulations. For proper energy
conservation, we recommend using a potential file where
the resolution for Phi is at least 2001 data points.
.. note::
The *mesocnt* style requires CNTs to be represented
as a chain of atoms connected by bonds. Atoms need
to be numbered consecutively within one chain.
Atoms belonging to different CNTs need to be assigned
different molecule IDs.
A full summary of the method and LAMMPS implementation details
is expected to soon become available in Computer Physics
Communications.
----------
**Mixing, shift, table, tail correction, restart, rRESPA info**\ :
This pair style does not support mixing.
This pair style does not support the :doc:`pair\_modify <pair_modify>`
shift, table, and tail options.
The *mesocnt* pair style do not write their information to :doc:`binary restart files <restart>`,
since it is stored in tabulated potential files.
Thus, you need to re-specify the pair\_style and pair\_coeff commands in
an input script that reads a restart file.
This pair style can only be used via the *pair* keyword of the
:doc:`run\_style respa <run_style>` command. They do not support the
*inner*\ , *middle*\ , *outer* keywords.
----------
Restrictions
""""""""""""
This style is part of the USER-MISC package. It is only
enabled if LAMMPS was built with that package. See the :doc:`Build package <Build_package>` doc page for more info.
This pair potential requires the :doc:`newton <newton>` setting to be
"on" for pair interactions.
Related commands
""""""""""""""""
:doc:`pair\_coeff <pair_coeff>`
**Default:** none
----------
.. _Volkov1:
**(Volkov1)** Volkov and Zhigilei, J Phys Chem C, 114, 5513 (2010).
.. _Volkov2:
**(Volkov2)** Volkov, Simov and Zhigilei, APS Meeting Abstracts,
Q31.013 (2008).
.. _lws: http://lammps.sandia.gov
.. _ld: Manual.html
.. _lc: Commands_all.html

2
doc/src/pair_mm3_switch3_coulgauss.rst → doc/src/pair_mm3_switch3_coulgauss_long.rst
View File

@ -37,7 +37,7 @@ Examples
Description
"""""""""""
The *mm3/switch3/coulgauss* style evaluates the MM3
The *mm3/switch3/coulgauss/long* style evaluates the MM3
vdW potential :ref:`(Allinger) <mm3-allinger1989>`
.. image:: Eqs/pair_mm3_switch3.jpg

7
doc/src/pair_modify.rst
View File

@ -247,7 +247,9 @@ or *lj/coul* to change both to the same set of 3 values. The wt1,wt2,wt3
values are numeric weights from 0.0 to 1.0 inclusive, for the 1-2,
1-3, and 1-4 bond topology neighbors, respectively. The *special*
keyword can only be used in conjunction with the *pair* keyword
and has to directly follow it.
and has to directly follow it. This option is not compatible with
pair styles from the GPU or the USER-INTEL package and attempting
it will cause an error.
.. note::
@ -278,10 +280,11 @@ and allows to selectively disable or enable processing of the various
Restrictions
""""""""""""
none
You cannot use *shift* yes with *tail* yes, since those are
conflicting options. You cannot use *tail* yes with 2d simulations.
You cannot use *special* with pair styles from the GPU or
USER-INTEL package.
Related commands
""""""""""""""""

38
doc/src/pair_style.rst
View File

@ -32,7 +32,7 @@ Description
Set the formula(s) LAMMPS uses to compute pairwise interactions. In
LAMMPS, pair potentials are defined between pairs of atoms that are
within a cutoff distance and the set of active interactions typically
changes over time. See the :doc:`bond\_style <bond_style>` command to
changes over time. See the :doc:`bond_style <bond_style>` command to
define potentials between pairs of bonded atoms, which typically
remain in place for the duration of a simulation.
@ -48,11 +48,11 @@ different pair potentials can be setup using the *hybrid* pair style.
The coefficients associated with a pair style are typically set for
each pair of atom types, and are specified by the
:doc:`pair\_coeff <pair_coeff>` command or read from a file by the
:doc:`read\_data <read_data>` or :doc:`read\_restart <read_restart>`
:doc:`pair_coeff <pair_coeff>` command or read from a file by the
:doc:`read_data <read_data>` or :doc:`read_restart <read_restart>`
commands.
The :doc:`pair\_modify <pair_modify>` command sets options for mixing of
The :doc:`pair_modify <pair_modify>` command sets options for mixing of
type I-J interaction coefficients and adding energy offsets or tail
corrections to Lennard-Jones potentials. Details on these options as
they pertain to individual potentials are described on the doc page
@ -70,11 +70,11 @@ cutoffs for all pairs of atom types. The distance(s) can be smaller
or larger than the dimensions of the simulation box.
Typically, the global cutoff value can be overridden for a specific
pair of atom types by the :doc:`pair\_coeff <pair_coeff>` command. The
pair of atom types by the :doc:`pair_coeff <pair_coeff>` command. The
pair style settings (including global cutoffs) can be changed by a
subsequent pair\_style command using the same style. This will reset
the cutoffs for all atom type pairs, including those previously set
explicitly by a :doc:`pair\_coeff <pair_coeff>` command. The exceptions
explicitly by a :doc:`pair_coeff <pair_coeff>` command. The exceptions
to this are that pair\_style *table* and *hybrid* settings cannot be
reset. A new pair\_style command for these styles will wipe out all
previously specified pair\_coeff values.
@ -88,7 +88,7 @@ also listed in more compact form on the :doc:`Commands pair <Commands_pair>` doc
Click on the style to display the formula it computes, any additional
arguments specified in the pair\_style command, and coefficients
specified by the associated :doc:`pair\_coeff <pair_coeff>` command.
specified by the associated :doc:`pair_coeff <pair_coeff>` command.
There are also additional accelerated pair styles included in the
LAMMPS distribution for faster performance on CPUs, GPUs, and KNLs.
@ -170,6 +170,7 @@ accelerated styles exist.
* :doc:`gauss <pair_gauss>` - Gaussian potential
* :doc:`gauss/cut <pair_gauss>` - generalized Gaussian potential
* :doc:`gayberne <pair_gayberne>` - Gay-Berne ellipsoidal potential
* :doc:`granular <pair_granular>` - Generalized granular potential
* :doc:`gran/hertz/history <pair_gran>` - granular potential with Hertzian interactions
* :doc:`gran/hooke <pair_gran>` - granular potential with history effects
* :doc:`gran/hooke/history <pair_gran>` - granular potential without history effects
@ -231,7 +232,7 @@ accelerated styles exist.
* :doc:`lj/sf/dipole/sf <pair_dipole>` - LJ with dipole interaction with shifted forces
* :doc:`lj/smooth <pair_lj_smooth>` - smoothed Lennard-Jones potential
* :doc:`lj/smooth/linear <pair_lj_smooth_linear>` - linear smoothed LJ potential
* `lj/switch3/coulgauss <pair_lj_switch3_coulgauss>`_ - smoothed LJ vdW potential with Gaussian electrostatics
* :doc:`lj/switch3/coulgauss/long <pair_lj_switch3_coulgauss_long>` - smoothed LJ vdW potential with Gaussian electrostatics
* :doc:`lj96/cut <pair_lj96>` - Lennard-Jones 9/6 potential
* :doc:`local/density <pair_local_density>` - generalized basic local density potential
* :doc:`lubricate <pair_lubricate>` - hydrodynamic lubrication forces
@ -243,9 +244,10 @@ accelerated styles exist.
* :doc:`meam/c <pair_meamc>` - modified embedded atom method (MEAM) in C
* :doc:`meam/spline <pair_meam_spline>` - splined version of MEAM
* :doc:`meam/sw/spline <pair_meam_sw_spline>` - splined version of MEAM with a Stillinger-Weber term
* :doc:`mesocnt <pair_mesocnt>` - mesoscale model for (carbon) nanotubes
* :doc:`mgpt <pair_mgpt>` - simplified model generalized pseudopotential theory (MGPT) potential
* :doc:`mie/cut <pair_mie>` - Mie potential
* `mm3/switch3/coulgauss <pair_mm3_switch3_coulgauss>`_ - smoothed MM3 vdW potential with Gaussian electrostatics
* :doc:`mm3/switch3/coulgauss/long <pair_mm3_switch3_coulgauss_long>` - smoothed MM3 vdW potential with Gaussian electrostatics
* :doc:`momb <pair_momb>` - Many-Body Metal-Organic (MOMB) force field
* :doc:`morse <pair_morse>` - Morse potential
* :doc:`morse/smooth/linear <pair_morse>` - linear smoothed Morse potential
@ -267,6 +269,12 @@ accelerated styles exist.
* :doc:`oxdna2/hbond <pair_oxdna2>` -
* :doc:`oxdna2/stk <pair_oxdna2>` -
* :doc:`oxdna2/xstk <pair_oxdna2>` -
* :doc:`oxrna2/coaxstk <pair_oxrna2>` -
* :doc:`oxrna2/dh <pair_oxrna2>` -
* :doc:`oxrna2/excv <pair_oxrna2>` -
* :doc:`oxrna2/hbond <pair_oxrna2>` -
* :doc:`oxrna2/stk <pair_oxrna2>` -
* :doc:`oxrna2/xstk <pair_oxrna2>` -
* :doc:`peri/eps <pair_peri>` - peridynamic EPS potential
* :doc:`peri/lps <pair_peri>` - peridynamic LPS potential
* :doc:`peri/pmb <pair_peri>` - peridynamic PMB potential
@ -280,7 +288,7 @@ accelerated styles exist.
* :doc:`sdpd/taitwater/isothermal <pair_sdpd_taitwater_isothermal>` - smoothed dissipative particle dynamics for water at isothermal conditions
* :doc:`smd/hertz <pair_smd_hertz>` -
* :doc:`smd/tlsph <pair_smd_tlsph>` -
* :doc:`smd/tri\_surface <pair_smd_triangulated_surface>` -
* :doc:`smd/tri_surface <pair_smd_triangulated_surface>` -
* :doc:`smd/ulsph <pair_smd_ulsph>` -
* :doc:`smtbq <pair_smtbq>` -
* :doc:`snap <pair_snap>` - SNAP quantum-accurate potential
@ -328,8 +336,8 @@ Restrictions
This command must be used before any coefficients are set by the
:doc:`pair\_coeff <pair_coeff>`, :doc:`read\_data <read_data>`, or
:doc:`read\_restart <read_restart>` commands.
:doc:`pair_coeff <pair_coeff>`, :doc:`read_data <read_data>`, or
:doc:`read_restart <read_restart>` commands.
Some pair styles are part of specific packages. They are only enabled
if LAMMPS was built with that package. See the :doc:`Build package <Build_package>` doc page for more info. The doc pages for
@ -338,9 +346,9 @@ individual pair potentials tell if it is part of a package.
Related commands
""""""""""""""""
:doc:`pair\_coeff <pair_coeff>`, :doc:`read\_data <read_data>`,
:doc:`pair\_modify <pair_modify>`, :doc:`kspace\_style <kspace_style>`,
:doc:`dielectric <dielectric>`, :doc:`pair\_write <pair_write>`
:doc:`pair_coeff <pair_coeff>`, :doc:`read_data <read_data>`,
:doc:`pair_modify <pair_modify>`, :doc:`kspace_style <kspace_style>`,
:doc:`dielectric <dielectric>`, :doc:`pair_write <pair_write>`
Default
"""""""

2
doc/src/python.rst
View File

@ -356,7 +356,7 @@ to the screen and log file. Note that since the LAMMPS print command
itself takes a string in quotes as its argument, the Python string
must be delimited with a different style of quotes.
The :doc:`Pytnon library <Python_library>` doc page describes the syntax
The :doc:`Python library <Python_library>` doc page describes the syntax
for how Python wraps the various functions included in the LAMMPS
library interface.

49
doc/src/read_dump.rst
View File

@ -43,6 +43,9 @@ Syntax
*format* values = format of dump file, must be last keyword if used
*native* = native LAMMPS dump file
*xyz* = XYZ file
*adios* [*timeout* value] = dump file written by the :doc:`dump adios <dump_adios>` command
*timeout* = specify waiting time for the arrival of the timestep when running concurrently.
The value is a float number and is interpreted in seconds.
*molfile* style path = VMD molfile plugin interface
style = *dcd* or *xyz* or others supported by molfile plugins
path = optional path for location of molfile plugins
@ -65,6 +68,8 @@ Examples
read_dump dump.xyz 10 x y z box no format molfile xyz ../plugins
read_dump dump.dcd 0 x y z format molfile dcd
read_dump dump.file 1000 x y z vx vy vz format molfile lammpstrj /usr/local/lib/vmd/plugins/LINUXAMD64/plugins/molfile
read_dump dump.bp 5000 x y z vx vy vz format adios
read_dump dump.bp 5000 x y z vx vy vz format adios timeout 60.0
Description
"""""""""""
@ -136,6 +141,17 @@ contain multiple directories separated by a colon (or semi-colon on
windows). The *path* keyword is optional and defaults to ".",
i.e. the current directory.
The *adios* format supports reading data that was written by the
:doc:`dump adios <dump_adios>` command. The
entire dump is read in parallel across all the processes, dividing
the atoms evenly among the processes. The number of writers that
has written the dump file does not matter. Using the adios style for
dump and read_dump is a convenient way to dump all atoms from *N*
writers and read it back by *M* readers. If one is running two
LAMMPS instances concurrently where one dumps data and the other is
reading it with the rerun command, the timeout option can be specified
to wait on the reader side for the arrival of the requested step.
Support for other dump format readers may be added in the future.
@ -147,7 +163,19 @@ and box information.
The dump file is scanned for a snapshot with a timestamp that matches
the specified *Nstep*\ . This means the LAMMPS timestep the dump file
snapshot was written on for the *native* format. Note that the *xyz*
snapshot was written on for the *native* or *adios* formats.
The list of timestamps available in an adios .bp file is stored in the
variable *ntimestep*:
.. parsed-literal::
$ bpls dump.bp -d ntimestep
uint64_t ntimestep 5*scalar
(0) 0 50 100 150 200
Note that the *xyz*
and *molfile* formats do not store the timestep. For these formats,
timesteps are numbered logically, in a sequential manner, starting
from 0. Thus to access the 10th snapshot in an *xyz* or *mofile*
@ -160,7 +188,8 @@ and the current simulation box is orthogonal or vice versa. A warning
will be generated if the snapshot box boundary conditions (periodic,
shrink-wrapped, etc) do not match the current simulation boundary
conditions, but the boundary condition information in the snapshot is
otherwise ignored. See the "boundary" command for more details.
otherwise ignored. See the "boundary" command for more details. The
*adios* reader does the same as the *native* format reader.
For the *xyz* format, no information about the box is available, so
you must set the *box* flag to *no*\ . See details below.
@ -231,6 +260,18 @@ consistent from snapshot to snapshot in the molfile dump file.
See the :doc:`dump\_modify sort <dump_modify>` command if the dump file
was written by LAMMPS.
The *adios* format supports all fields that the *native* format supports
except for the *q* charge field.
The list of fields stored in an adios .bp file is recorded in the attributes
*columns* (array of short strings) and *columnstr* (space-separated single string).
.. parsed-literal::
$ bpls -la dump.bp column*
string columns attr = {"id", "type", "x", "y", "z", "vx", "vy", "vz"}
string columnstr attr = "id type x y z vx vy vz "
----------
@ -357,10 +398,14 @@ The *molfile* dump file formats are part of the USER-MOLFILE package.
They are only enabled if LAMMPS was built with that packages. See the
:doc:`Build package <Build_package>` doc page for more info.
To write and read adios .bp files, you must compile LAMMPS with the
:ref:`USER-ADIOS <PKG-USER-ADIOS>` package.
Related commands
""""""""""""""""
:doc:`dump <dump>`, :doc:`dump molfile <dump_molfile>`,
:doc:`dump adios <dump_adios>`,
:doc:`read\_data <read_data>`, :doc:`read\_restart <read_restart>`,
:doc:`rerun <rerun>`

2
doc/src/rerun.rst
View File

@ -44,6 +44,8 @@ Examples
rerun dump.vels dump x y z vx vy vz box yes format molfile lammpstrj
rerun dump.dcd dump x y z box no format molfile dcd
rerun ../run7/dump.file.gz skip 2 dump x y z box yes
rerun dump.bp dump x y z box no format adios
rerun dump.bp dump x y z vx vy vz format adios timeout 10.0
Description
"""""""""""

2
doc/src/server.rst
View File

@ -39,7 +39,7 @@ enables the two codes to work in tandem to perform a simulation.
When this command is invoked, LAMMPS will run in server mode in an
endless loop, waiting for messages from the client code. The client
signals when it is done sending messages to LAMMPS, at which point the
loop will exit, and the remainder of the LAMMPS script will be
loop will exit, and the remainder of the LAMMPS input script will be
processed.
The *protocol* argument defines the format and content of messages

68
doc/src/set.rst
View File

@ -14,7 +14,7 @@ Syntax
* style = *atom* or *type* or *mol* or *group* or *region*
* ID = atom ID range or type range or mol ID range or group ID or region ID
* one or more keyword/value pairs may be appended
* keyword = *type* or *type/fraction* or *mol* or *x* or *y* or *z* or *charge* or *dipole* or *dipole/random* or *quat* or *spin* or *spin/random* or *quat* or *quat/random* or *diameter* or *shape* or *length* or *tri* or *theta* or *theta/random* or *angmom* or *omega* or *mass* or *density* or *density/disc* or *volume* or *image* or *bond* or *angle* or *dihedral* or *improper* or *meso/e* or *meso/cv* or *meso/rho* or *smd/contact/radius* or *smd/mass/density* or *dpd/theta* or *edpd/temp* or *edpd/cv* or *cc* or *i\_name* or *d\_name*
* keyword = *type* or *type/fraction* or *type/ratio* or *type/subset* or *mol* or *x* or *y* or *z* or *charge* or *dipole* or *dipole/random* or *quat* or *spin* or *spin/random* or *quat* or *quat/random* or *diameter* or *shape* or *length* or *tri* or *theta* or *theta/random* or *angmom* or *omega* or *mass* or *density* or *density/disc* or *volume* or *image* or *bond* or *angle* or *dihedral* or *improper* or *meso/e* or *meso/cv* or *meso/rho* or *smd/contact/radius* or *smd/mass/density* or *dpd/theta* or *edpd/temp* or *edpd/cv* or *cc* or *i\_name* or *d\_name*
.. parsed-literal::
@ -22,7 +22,15 @@ Syntax
value can be an atom-style variable (see below)
*type/fraction* values = type fraction seed
type = new atom type
fraction = fraction of selected atoms to set to new atom type
fraction = approximate fraction of selected atoms to set to new atom type
seed = random # seed (positive integer)
*type/ratio* values = type fraction seed
type = new atom type
fraction = exact fraction of selected atoms to set to new atom type
seed = random # seed (positive integer)
*type/subset* values = type Nsubset seed
type = new atom type
Nsubset = exact number of selected atoms to set to new atom type
seed = random # seed (positive integer)
*mol* value = molecule ID
value can be an atom-style variable (see below)
@ -184,15 +192,16 @@ This section describes the keyword options for which properties to
change, for the selected atoms.
Note that except where explicitly prohibited below, all of the
keywords allow an :doc:`atom-style or atomfile-style variable <variable>` to be used as the specified value(s). If the
value is a variable, it should be specified as v\_name, where name is
the variable name. In this case, the variable will be evaluated, and
its resulting per-atom value used to determine the value assigned to
each selected atom. Note that the per-atom value from the variable
will be ignored for atoms that are not selected via the *style* and
*ID* settings explained above. A simple way to use per-atom values
from the variable to reset a property for all atoms is to use style
*atom* with *ID* = "\*"; this selects all atom IDs.
keywords allow an :doc:`atom-style or atomfile-style variable
<variable>` to be used as the specified value(s). If the value is a
variable, it should be specified as v\_name, where name is the
variable name. In this case, the variable will be evaluated, and its
resulting per-atom value used to determine the value assigned to each
selected atom. Note that the per-atom value from the variable will be
ignored for atoms that are not selected via the *style* and *ID*
settings explained above. A simple way to use per-atom values from
the variable to reset a property for all atoms is to use style *atom*
with *ID* = "\*"; this selects all atom IDs.
Atom-style variables can specify formulas with various mathematical
functions, and include :doc:`thermo\_style <thermo_style>` command
@ -220,23 +229,36 @@ command.
Keyword *type/fraction* sets the atom type for a fraction of the
selected atoms. The actual number of atoms changed is not guaranteed
to be exactly the requested fraction, but should be statistically
close. Random numbers are used in such a way that a particular atom
is changed or not changed, regardless of how many processors are being
used. This keyword does not allow use of an atom-style variable.
to be exactly the specified fraction (0 <= *fraction* <= 1), but
should be statistically close. Random numbers are used in such a way
that a particular atom is changed or not changed, regardless of how
many processors are being used. This keyword does not allow use of an
atom-style variable.
Keyword *mol* sets the molecule ID for all selected atoms. The :doc:`atom style <atom_style>` being used must support the use of molecule
IDs.
Keywords *type/ratio* and *type/subset" also set the atom type for a
fraction of the selected atoms. The actual number of atoms changed
will be exactly the requested number. For *type/ratio* the specified
fraction (0 <= *fraction* <= 1) determines the number. For
*type/subset*, the specified *Nsubset* is the number. An iterative
algorithm is used which insures the correct number of atoms are
selected, in a perfectly random fashion. Which atoms are selected
will change with the number of processors used. These keywords do not
allow use of an atom-style variable.
Keywords *x*\ , *y*\ , *z*\ , and *charge* set the coordinates or charge of
all selected atoms. For *charge*\ , the :doc:`atom style <atom_style>`
being used must support the use of atomic charge. Keywords *vx*\ , *vy*\ ,
and *vz* set the velocities of all selected atoms.
Keyword *mol* sets the molecule ID for all selected atoms. The
:doc:`atom style <atom_style>` being used must support the use of
molecule IDs.
Keywords *x*\ , *y*\ , *z*\ , and *charge* set the coordinates or
charge of all selected atoms. For *charge*\ , the :doc:`atom style
<atom_style>` being used must support the use of atomic
charge. Keywords *vx*\ , *vy*\ , and *vz* set the velocities of all
selected atoms.
Keyword *dipole* uses the specified x,y,z values as components of a
vector to set as the orientation of the dipole moment vectors of the
selected atoms. The magnitude of the dipole moment is set
by the length of this orientation vector.
selected atoms. The magnitude of the dipole moment is set by the
length of this orientation vector.
Keyword *dipole/random* randomizes the orientation of the dipole
moment vectors for the selected atoms and sets the magnitude of each

10894
doc/txt/Errors_messages.txt
View File

File diff suppressed because it is too large Load Diff

982
doc/txt/Errors_warnings.txt
View File

@ -1,982 +0,0 @@
"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
{Angles are defined but no angle style is set} :dt
The topology contains angles, but there are no angle forces computed
since there was no angle_style command. :dd
{Atom style in data file differs from currently defined atom style} :dt
Self-explanatory. :dd
{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
{Bonds are defined but no bond style is set} :dt
The topology contains bonds, but there are no bond forces computed
since there was no bond_style command. :dd
{Bond/angle/dihedral extent > half of periodic box length} :dt
This is a restriction because LAMMPS can be confused about which image
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
{Bond/react: Atom affected by reaction too close to template edge} :dt
This means an atom which changes type or connectivity during the
reaction is too close to an 'edge' atom defined in the superimpose
file. This could cause incorrect assignment of bonds, angle, etc.
Generally, this means you must include more atoms in your templates,
such that there are at least two atoms between each atom involved in
the reaction and an edge atom. :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 0.0. No ghost atoms will be generated. Atoms may get lost} :dt
The communication cutoff defaults to the maximum of what is inferred from
pair and bond styles (will be zero, if none are defined) and what is specified
via "comm_modify cutoff"_comm_modify.html (defaults to 0.0). If this results
to 0.0, no ghost atoms will be generated and LAMMPS may lose atoms or use
incorrect periodic images of atoms in interaction lists. To avoid, either use
"pair style zero"_pair_zero.html with a suitable cutoff or use "comm_modify
cutoff"_comm_modify.html. :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
{Dihedrals are defined but no dihedral style is set} :dt
The topology contains dihedrals, but there are no dihedral forces computed
since there was no dihedral_style command. :dd
{Dump dcd/xtc timestamp may be wrong with fix dt/reset} :dt
If the fix changes the timestep, the dump dcd file will not
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
{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 langevin gjf using random gaussians is not implemented with kokkos} :dt
This will most likely cause errors in kinetic fluctuations.
{Fix property/atom mol or charge w/out ghost communication} :dt
A model typically needs these properties defined for ghost atoms. :dd
{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
{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
{Impropers are defined but no improper style is set} :dt
The topology contains impropers, but there are no improper forces computed
since there was no improper_style command. :dd
{Inconsistent image flags} :dt
The image flags for a pair on bonded atoms appear to be inconsistent.
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
{Increasing communication cutoff for GPU style} :dt
The pair style has increased the communication cutoff to be consistent with
the communication cutoff requirements for this pair style when run on the GPU. :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
{Likewise 1-2 special neighbor interactions != 1.0} :dt
The topology contains bonds, but there is no bond style defined
and a 1-2 special neighbor scaling factor was not 1.0. This
means that pair style interactions may have scaled or missing
pairs in the neighbor list in expectation of interactions for
those pairs being computed from the bond style. :dd
{Likewise 1-3 special neighbor interactions != 1.0} :dt
The topology contains angles, but there is no angle style defined
and a 1-3 special neighbor scaling factor was not 1.0. This
means that pair style interactions may have scaled or missing
pairs in the neighbor list in expectation of interactions for
those pairs being computed from the angle style. :dd
{Likewise 1-4 special neighbor interactions != 1.0} :dt
The topology contains dihedrals, but there is no dihedral style defined
and a 1-4 special neighbor scaling factor was not 1.0. This
means that pair style interactions may have scaled or missing
pairs in the neighbor list in expectation of interactions for
those pairs being computed from the dihedral style. :dd
{Lost atoms via change_box: original %ld current %ld} :dt
The command options you have used caused atoms to be lost. :dd
{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 reflecting 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 many-body 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 many-body 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

1
doc/txt/Examples.txt
View File

@ -94,6 +94,7 @@ python: using embedded Python in a LAMMPS input script
qeq: use of the QEQ package for charge equilibration
rdf-adf: computing radial and angle distribution functions for water
reax: RDX and TATB models using the ReaxFF
rerun: use of rerun and read_dump commands
rigid: rigid bodies modeled as independent or coupled
shear: sideways shear applied to 2d solid, with and without a void
snap: NVE dynamics for BCC tantalum crystal using SNAP potential

204
doc/txt/Howto_bash.txt
View File

@ -1,204 +0,0 @@
"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 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
via apt-get and all files are accessible in both the Windows Explorer and your
Linux shell (bash). This avoids switching to a different operating system or
installing a virtual machine. Everything runs on Windows.
Installing Bash on Windows :h4
Prerequisites :h5
Windows 10 (64bit only)
Latest updates installed :ul
Enable developer mode :h5
You enable this feature by first opening Windows Settings and enabling
Developer mode. Go to the Windows settings and search for "developer". This
will allow you to install software which comes from outside of the Windows
Store. You might be prompted to reboot your compute. Please do so.
:image(JPG/bow_tutorial_01_small.png,JPG/bow_tutorial_01.png)
:image(JPG/bow_tutorial_02_small.png,JPG/bow_tutorial_02.png)
:image(JPG/bow_tutorial_03_small.png,JPG/bow_tutorial_03.png)
Install Windows Subsystem for Linux :h5
Next you must ensure that the Window Subsystem for Linux is installed. Again,
search for "enable windows features" in the Settings dialog. This opens a
dialog with a list of features you can install. Add a checkmark to Windows
Subsystem for Linux (Beta) and press OK.
:image(JPG/bow_tutorial_04_small.png,JPG/bow_tutorial_04.png)
:image(JPG/bow_tutorial_05.png,JPG/bow_tutorial_05.png)
Install Bash for Windows :h5
After installation completes, type "bash" in the Windows Start menu search.
Select the first found option. This will launch a command-line window which
will prompt you about installing Ubuntu on Windows. Confirm with "y" and press
enter. This will then download Ubuntu for Windows.
:image(JPG/bow_tutorial_06.png)
:image(JPG/bow_tutorial_07.png)
During installation, you will be asked for a new password. This will be used
for installing new software and running commands with sudo.
:image(JPG/bow_tutorial_08.png)
Type exit to close the command-line window.
Go to the Start menu and type "bash" again. This time you will see a "Bash on
Ubuntu on Windows" Icon. Start this program.
:image(JPG/bow_tutorial_09.png)
Congratulations, you have installed [Bash on Ubuntu on Windows].
:image(JPG/bow_tutorial_10.png)
:line
Compiling LAMMPS in Bash on Windows :h4
The installation of LAMMPS in this environment is identical to working inside
of a real Ubuntu Linux installation. At the time writing, it uses Ubuntu 16.04.
Installing prerequisite packages :h5
First upgrade all existing packages using
sudo apt update
sudo apt upgrade -y :pre
Next install the following packages, which include compilers and libraries
needed for various LAMMPS features:
sudo apt install -y build-essential ccache gfortran openmpi-bin libopenmpi-dev libfftw3-dev libjpeg-dev libpng12-dev python-dev python-virtualenv libblas-dev liblapack-dev libhdf5-serial-dev hdf5-tools :pre
Files in Ubuntu on Windows :h5
When you launch "Bash on Ubuntu on Windows" you will start out in your Linux
user home directory /home/[username]. You can access your Windows user directory
using the /mnt/c/Users/[username] folder.
Download LAMMPS :h5
Obtain a copy of the LAMMPS code and go into it using "cd"
Option 1: Downloading LAMMPS tarball using wget :h6
wget http://lammps.sandia.gov/tars/lammps-stable.tar.gz
tar xvzf lammps-stable.tar.gz
cd lammps-31Mar17 :pre
Option 2: Obtaining LAMMPS code from GitHub :h6
git clone https://github.com/lammps/lammps.git
cd lammps :pre
Compiling LAMMPS :h5
At this point you can compile LAMMPS like on Ubuntu Linux.
Compiling serial version :h6
cd src/
make -j 4 serial :pre
This will create an executable called lmp_serial in the src/ directory
Compiling MPI version :h6
cd src/
make -j 4 mpi :pre
This will create an executable called lmp_mpi in the src/ directory
:line
Finally, please note the absolute path of your src folder. You can get this using
pwd :pre
or
echo $PWD :pre
To run any examples you need the location of the executable. For now, let us
save this location in a temporary variable
LAMMPS_DIR=$PWD :pre
:line
Running an example script :h5
Once compiled you can execute some of the LAMMPS examples. Switch into the
examples/melt folder
cd ../examples/melt :pre
The full path of the serial executable is $LAMMPS_DIR/lmp_serial, while the mpi
version is $LAMMPS_DIR/lmp_mpi. You can run the melt example with either
version as follows:
$LAMMPS_DIR/lmp_serial -in in.melt :pre
or
mpirun -np 4 $LAMMPS_DIR/lmp_mpi -in in.melt :pre
Note the use of our variable $LAMMPS_DIR, which expands into the full path of
the LAMMPS src folder we saved earlier.
Adding your executable directory to your PATH :h6
You can avoid having to type the full path of your LAMMPS binary by adding its
parent folder to the PATH environment variable as follows:
export PATH=$LAMMPS_DIR:$PATH :pre
Input scripts can then be run like this:
lmp_serial -in in.melt :pre
or
mpirun -np 4 lmp_mpi -in in.melt :pre
However, this PATH variable will not persist if you close your bash window.
To persist this setting edit the $HOME/.bashrc file using your favorite editor
and add this line
export PATH=/full/path/to/your/lammps/src:$PATH :pre
[Example:]
For an executable lmp_serial with a full path
/home/richard/lammps/src/lmp_serial :pre
the PATH variable should be
export PATH=/home/richard/lammps/src:$PATH :pre
NOTE: This should give you a jump start when trying to run LAMMPS on Windows.
To become effective in this environment I encourage you to look into Linux
tutorials explaining Bash and Basic Unix commands (e.g., "Linux
Journey"_https://linuxjourney.com)

131
doc/txt/Howto_client_server.txt
View File

@ -1,131 +0,0 @@
"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 between 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, through 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 substituted 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.

23
doc/txt/Howto_library.txt
View File

@ -28,6 +28,29 @@ and C and Python codes which show how a driver code can link to LAMMPS
as a library, run LAMMPS on a subset of processors, grab data from
LAMMPS, change it, and put it back into LAMMPS.
Thread-safety :h4
LAMMPS has not initially been conceived as a thread-safe program, but
over the years changes have been applied to replace operations that
collide with creating multiple LAMMPS instances from multiple-threads
of the same process with thread-safe alternatives. This primarily
applies to the core LAMMPS code and less so on add-on packages, especially
when those packages require additional code in the {lib} folder,
interface LAMMPS to Fortran libraries, or the code uses static variables
(like the USER-COLVARS package.
Another major issue to deal with is to correctly handle MPI. Creating
a LAMMPS instance requires passing an MPI communicator, or it assumes
the MPI_COMM_WORLD communicator, which spans all MPI processor ranks.
When creating multiple LAMMPS object instances from different threads,
this communicator has to be different for each thread or else collisions
can happen, or it has to be guaranteed, that only one thread at a time
is active. MPI communicators, however, are not a problem, if LAMMPS is
compiled with the MPI STUBS library, which implies that there is no MPI
communication and only 1 MPI rank.
Provided APIs :h4
The file src/library.cpp contains the following functions for creating
and destroying an instance of LAMMPS and sending it commands to
execute. See the documentation in the src/library.cpp file for

2157
doc/txt/Packages_details.txt
View File

File diff suppressed because it is too large Load Diff

135
doc/txt/compute_angle_local.txt
View File

@ -1,135 +0,0 @@
"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
compute angle/local command :h3
[Syntax:]
compute ID group-ID angle/local value1 value2 ... keyword args ... :pre
ID, group-ID are documented in "compute"_compute.html command :ulb,l
angle/local = style name of this compute command :l
one or more values may be appended :l
value = {theta} or {eng} or {v_name} :l
{theta} = tabulate angles
{eng} = tabulate angle energies
{v_name} = equal-style variable with name (see below) :pre
zero or more keyword/args pairs may be appended :l
keyword = {set} :l
{set} args = theta name
theta = only currently allowed arg
name = name of variable to set with theta :pre
:ule
[Examples:]
compute 1 all angle/local theta
compute 1 all angle/local eng theta
compute 1 all angle/local theta v_cos set theta t :pre
[Description:]
Define a computation that calculates properties of individual angle
interactions. The number of datums generated, aggregated across all
processors, equals the number of angles in the system, modified by the
group parameter as explained below.
The value {theta} is the angle for the 3 atoms in the interaction.
The value {eng} is the interaction energy for the angle.
The value {v_name} can be used together with the {set} keyword to
compute a user-specified function of the angle theta. The {name}
specified for the {v_name} value is the name of an "equal-style
variable"_variable.html which should evaluate a formula based on a
variable which will store the angle theta. This other variable must
be an "internal-style variable"_variable.html defined in the input
script; its initial numeric value can be anything. It must be an
internal-style variable, because this command resets its value
directly. The {set} keyword is used to identify the name of this
other variable associated with theta.
Note that the value of theta for each angle which stored in the
internal variable is in radians, not degrees.
As an example, these commands can be added to the bench/in.rhodo
script to compute the cosine and cosine^2 of every angle in the system
and output the statistics in various ways:
variable t internal 0.0
variable cos equal cos(v_t)
variable cossq equal cos(v_t)*cos(v_t) :pre
compute 1 all property/local aatom1 aatom2 aatom3 atype
compute 2 all angle/local eng theta v_cos v_cossq set theta t
dump 1 all local 100 tmp.dump c_1[*] c_2[*] :pre
compute 3 all reduce ave c_2[*]
thermo_style custom step temp press c_3[*] :pre
fix 10 all ave/histo 10 10 100 -1 1 20 c_2[3] mode vector file tmp.histo :pre
The "dump local"_dump.html command will output the energy, angle,
cosine(angle), cosine^2(angle) for every angle in the system. The
"thermo_style"_thermo_style.html command will print the average of
those quantities via the "compute reduce"_compute_reduce.html command
with thermo output. And the "fix ave/histo"_fix_ave_histo.html
command will histogram the cosine(angle) values and write them to a
file.
:line
The local data stored by this command is generated by looping over all
the atoms owned on a processor and their angles. An angle will only
be included if all 3 atoms in the angle are in the specified compute
group. Any angles that have been broken (see the
"angle_style"_angle_style.html command) by setting their angle type to
0 are not included. Angles that have been turned off (see the "fix
shake"_fix_shake.html or "delete_bonds"_delete_bonds.html commands) by
setting their angle type negative are written into the file, but their
energy will be 0.0.
Note that as atoms migrate from processor to processor, there will be
no consistent ordering of the entries within the local vector or array
from one timestep to the next. The only consistency that is
guaranteed is that the ordering on a particular timestep will be the
same for local vectors or arrays generated by other compute commands.
For example, angle output from the "compute
property/local"_compute_property_local.html command can be combined
with data from this command and output by the "dump local"_dump.html
command in a consistent way.
Here is an example of how to do this:
compute 1 all property/local atype aatom1 aatom2 aatom3
compute 2 all angle/local theta eng
dump 1 all local 1000 tmp.dump index c_1\[1\] c_1\[2\] c_1\[3\] c_1\[4\] c_2\[1\] c_2\[2\] :pre
[Output info:]
This compute calculates a local vector or local array depending on the
number of values. The length of the vector or number of rows in the
array is the number of angles. If a single value is specified, a
local vector is produced. If two or more values are specified, a
local array is produced where the number of columns = the number of
values. The vector or array can be accessed by any command that uses
local values from a compute as input. See the "Howto
output"_Howto_output.html doc page for an overview of LAMMPS output
options.
The output for {theta} will be in degrees. The output for {eng} will
be in energy "units"_units.html.
[Restrictions:] none
[Related commands:]
"dump local"_dump.html, "compute
property/local"_compute_property_local.html
[Default:] none

187
doc/txt/compute_bond_local.txt
View File

@ -1,187 +0,0 @@
"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
compute bond/local command :h3
[Syntax:]
compute ID group-ID bond/local value1 value2 ... keyword args ... :pre
ID, group-ID are documented in "compute"_compute.html command :ulb,l
bond/local = style name of this compute command :l
one or more values may be appended :l
value = {dist} or {engpot} or {force} or {fx} or {fy} or {fz} or {engvib} or {engrot} or {engtrans} or {omega} or {velvib} or {v_name} :l
{dist} = bond distance
{engpot} = bond potential energy
{force} = bond force :pre
{fx},{fy},{fz} = components of bond force
{engvib} = bond kinetic energy of vibration
{engrot} = bond kinetic energy of rotation
{engtrans} = bond kinetic energy of translation
{omega} = magnitude of bond angular velocity
{velvib} = vibrational velocity along the bond length
{v_name} = equal-style variable with name (see below) :pre
zero or more keyword/args pairs may be appended :l
keyword = {set} :l
{set} args = dist name
dist = only currently allowed arg
name = name of variable to set with distance (dist) :pre
:ule
:ule
[Examples:]
compute 1 all bond/local engpot
compute 1 all bond/local dist engpot force :pre
compute 1 all bond/local dist fx fy fz :pre
compute 1 all angle/local dist v_distsq set dist d :pre
[Description:]
Define a computation that calculates properties of individual bond
interactions. The number of datums generated, aggregated across all
processors, equals the number of bonds in the system, modified by the
group parameter as explained below.
All these properties are computed for the pair of atoms in a bond,
whether the 2 atoms represent a simple diatomic molecule, or are part
of some larger molecule.
The value {dist} is the current length of the bond.
The value {engpot} is the potential energy for the bond,
based on the current separation of the pair of atoms in the bond.
The value {force} is the magnitude of the force acting between the
pair of atoms in the bond.
The values {fx}, {fy}, and {fz} are the xyz components of
{force} between the pair of atoms in the bond.
The remaining properties are all computed for motion of the two atoms
relative to the center of mass (COM) velocity of the 2 atoms in the
bond.
The value {engvib} is the vibrational kinetic energy of the two atoms
in the bond, which is simply 1/2 m1 v1^2 + 1/2 m2 v2^2, where v1 and
v2 are the magnitude of the velocity of the 2 atoms along the bond
direction, after the COM velocity has been subtracted from each.
The value {engrot} is the rotational kinetic energy of the two atoms
in the bond, which is simply 1/2 m1 v1^2 + 1/2 m2 v2^2, where v1 and
v2 are the magnitude of the velocity of the 2 atoms perpendicular to
the bond direction, after the COM velocity has been subtracted from
each.
The value {engtrans} is the translational kinetic energy associated
with the motion of the COM of the system itself, namely 1/2 (m1+m2)
Vcm^2 where Vcm = magnitude of the velocity of the COM.
Note that these 3 kinetic energy terms are simply a partitioning of
the summed kinetic energy of the 2 atoms themselves. I.e. total KE =
1/2 m1 v1^2 + 1/2 m2 v2^2 = engvib + engrot + engtrans, where v1,v2
are the magnitude of the velocities of the 2 atoms, without any
adjustment for the COM velocity.
The value {omega} is the magnitude of the angular velocity of the
two atoms around their COM position.
The value {velvib} is the magnitude of the relative velocity of the
two atoms in the bond towards each other. A negative value means the
2 atoms are moving toward each other; a positive value means they are
moving apart.
The value {v_name} can be used together with the {set} keyword to
compute a user-specified function of the bond distance. The {name}
specified for the {v_name} value is the name of an "equal-style
variable"_variable.html which should evaluate a formula based on a
variable which will store the bond distance. This other variable must
be an "internal-style variable"_variable.html defined in the input
script; its initial numeric value can be anything. It must be an
internal-style variable, because this command resets its value
directly. The {set} keyword is used to identify the name of this
other variable associated with theta.
As an example, these commands can be added to the bench/in.rhodo
script to compute the distance^2 of every bond in the system and
output the statistics in various ways:
variable d internal 0.0
variable dsq equal v_d*v_d :pre
compute 1 all property/local batom1 batom2 btype
compute 2 all bond/local engpot dist v_dsq set dist d
dump 1 all local 100 tmp.dump c_1[*] c_2[*] :pre
compute 3 all reduce ave c_2[*]
thermo_style custom step temp press c_3[*] :pre
fix 10 all ave/histo 10 10 100 0 6 20 c_2[3] mode vector file tmp.histo :pre
The "dump local"_dump.html command will output the energy, distance,
distance^2 for every bond in the system. The
"thermo_style"_thermo_style.html command will print the average of
those quantities via the "compute reduce"_compute_reduce.html command
with thermo output. And the "fix ave/histo"_fix_ave_histo.html
command will histogram the distance^2 values and write them to a file.
:line
The local data stored by this command is generated by looping over all
the atoms owned on a processor and their bonds. A bond will only be
included if both atoms in the bond are in the specified compute group.
Any bonds that have been broken (see the "bond_style"_bond_style.html
command) by setting their bond type to 0 are not included. Bonds that
have been turned off (see the "fix shake"_fix_shake.html or
"delete_bonds"_delete_bonds.html commands) by setting their bond type
negative are written into the file, but their energy will be 0.0.
Note that as atoms migrate from processor to processor, there will be
no consistent ordering of the entries within the local vector or array
from one timestep to the next. The only consistency that is
guaranteed is that the ordering on a particular timestep will be the
same for local vectors or arrays generated by other compute commands.
For example, bond output from the "compute
property/local"_compute_property_local.html command can be combined
with data from this command and output by the "dump local"_dump.html
command in a consistent way.
Here is an example of how to do this:
compute 1 all property/local btype batom1 batom2
compute 2 all bond/local dist engpot
dump 1 all local 1000 tmp.dump index c_1\[*\] c_2\[*\] :pre
[Output info:]
This compute calculates a local vector or local array depending on the
number of values. The length of the vector or number of rows in the
array is the number of bonds. If a single value is specified, a local
vector is produced. If two or more values are specified, a local
array is produced where the number of columns = the number of values.
The vector or array can be accessed by any command that uses local
values from a compute as input. See the "Howto
output"_Howto_output.html doc page for an overview of LAMMPS output
options.
The output for {dist} will be in distance "units"_units.html. The
output for {velvib} will be in velocity "units"_units.html. The output
for {omega} will be in velocity/distance "units"_units.html. The
output for {engtrans}, {engvib}, {engrot}, and {engpot} will be in
energy "units"_units.html. The output for {force} will be in force
"units"_units.html.
[Restrictions:] none
[Related commands:]
"dump local"_dump.html, "compute
property/local"_compute_property_local.html
[Default:] none

203
doc/txt/compute_chunk_spread_atom.txt
View File

@ -1,203 +0,0 @@
"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
compute chunk/spread/atom command :h3
[Syntax:]
compute ID group-ID chunk/spread/atom chunkID input1 input2 ... :pre
ID, group-ID are documented in "compute"_compute.html command :ulb,l
chunk/spread/atom = style name of this compute command :l
chunkID = ID of "compute chunk/atom"_compute_chunk_atom.html command :l
one or more inputs can be listed :l
input = c_ID, c_ID\[N\], f_ID, f_ID\[N\] :l
c_ID = global vector calculated by a compute with ID
c_ID\[I\] = Ith column of global array calculated by a compute with ID, I can include wildcard (see below)
f_ID = global vector calculated by a fix with ID
f_ID\[I\] = Ith column of global array calculated by a fix with ID, I can include wildcard (see below) :pre
:ule
[Examples:]
compute 1 all chunk/spread/atom mychunk c_com[*] c_gyration :pre
[Description:]
Define a calculation that "spreads" one or more per-chunk values to
each atom in the chunk. This can be useful in several scenarios:
For creating a "dump file"_dump.html where each atom lists info about
the chunk it is in, e.g. for post-processing purposes. :ulb,l
To access chunk value in "atom-style variables"_variable.html that
need info about the chunk each atom is in. :l
To use the "fix ave/chunk"_fix_ave_chunk.html command to spatially
average per-chunk values calculated by a per-chunk compute. :l,ule
Examples are given below.
In LAMMPS, chunks are collections of atoms defined by a "compute
chunk/atom"_compute_chunk_atom.html command, which assigns each atom
to a single chunk (or no chunk). The ID for this command is specified
as chunkID. For example, a single chunk could be the atoms in a
molecule or atoms in a spatial bin. See the "compute
chunk/atom"_compute_chunk_atom.html and "Howto chunk"_Howto_chunk.html
doc pages for details of how chunks can be defined and examples of how
they can be used to measure properties of a system.
For inputs that are computes, they must be a compute that calculates
per-chunk values. These are computes whose style names end in
"/chunk".
For inputs that are fixes, they should be a fix that calculates
per-chunk values. For example, "fix ave/chunk"_fix_ave_chunk.html or
"fix ave/time"_fix_ave_time.html (assuming it is time-averaging
per-chunk data).
For each atom, this compute accesses its chunk ID from the specified
{chunkID} compute, then accesses the per-chunk value in each input.
Those values are copied to this compute to become the output for that
atom.
The values generated by this compute will be 0.0 for atoms not in the
specified compute group {group-ID}. They will also be 0.0 if the atom
is not in a chunk, as assigned by the {chunkID} compute. They will
also be 0.0 if the current chunk ID for the atom is out-of-bounds with
respect to the number of chunks stored by a particular input compute
or fix.
NOTE: LAMMPS does not check that a compute or fix which calculates
per-chunk values uses the same definition of chunks as this compute.
It's up to you to be consistent. Likewise, for a fix input, LAMMPS
does not check that it is per-chunk data. It only checks that the fix
produces a global vector or array.
:line
Each listed input is operated on independently.
If a bracketed index I is used, it can be specified using a wildcard
asterisk with the index to effectively specify multiple values. This
takes the form "*" or "*n" or "n*" or "m*n". If N = the number of
columns in the array, then an asterisk with no numeric values means
all indices from 1 to N. A leading asterisk means all indices from 1
to n (inclusive). A trailing asterisk means all indices from n to N
(inclusive). A middle asterisk means all indices from m to n
(inclusive).
Using a wildcard is the same as if the individual columns of the array
had been listed one by one. E.g. these 2 compute chunk/spread/atom
commands are equivalent, since the "compute
com/chunk"_compute_com_chunk.html command creates a per-atom array
with 3 columns:
compute com all com/chunk mychunk
compute 10 all chunk/spread/atom mychunk c_com\[*\]
compute 10 all chunk/spread/atom mychunk c_com\[1\] c_com\[2\] c_com\[3\] :pre
:line
Here is an example of writing a dump file the with the center-of-mass
(COM) for the chunk each atom is in. The commands below can be added
to the bench/in.chain script.
compute cmol all chunk/atom molecule
compute com all com/chunk cmol
compute comchunk all chunk/spread/atom cmol c_com[*]
dump 1 all custom 50 tmp.dump id mol type x y z c_comchunk[*]
dump_modify 1 sort id :pre
The same per-chunk data for each atom could be used to define per-atom
forces for the "fix addforce"_fix_addforce.html command. In this
example the forces act to pull atoms of an extended polymer chain
towards its COM in an attractive manner.
compute prop all property/atom xu yu zu
variable k equal 0.1
variable fx atom v_k*(c_comchunk\[1\]-c_prop\[1\])
variable fy atom v_k*(c_comchunk\[2\]-c_prop\[2\])
variable fz atom v_k*(c_comchunk\[3\]-c_prop\[3\])
fix 3 all addforce v_fx v_fy v_fz :pre
Note that "compute property/atom"_compute_property_atom.html is used
to generate unwrapped coordinates for use in the per-atom force
calculation, so that the effect of periodic boundaries is accounted
for properly.
Over time this applied force could shrink each polymer chain's radius
of gyration in a polymer mixture simulation. Here is output from the
bench/in.chain script. Thermo output is shown for 1000 steps, where
the last column is the average radius of gyration over all 320 chains
in the 32000 atom system:
compute gyr all gyration/chunk cmol
variable ave equal ave(c_gyr)
thermo_style custom step etotal press v_ave :pre
0 22.394765 4.6721833 5.128278
100 22.445002 4.8166709 5.0348372
200 22.500128 4.8790392 4.9364875
300 22.534686 4.9183766 4.8590693
400 22.557196 4.9492211 4.7937849
500 22.571017 4.9161853 4.7412008
600 22.573944 5.0229708 4.6931243
700 22.581804 5.0541301 4.6440647
800 22.584683 4.9691734 4.6000016
900 22.59128 5.0247538 4.5611513
1000 22.586832 4.94697 4.5238362 :pre
:line
Here is an example for using one set of chunks, defined for molecules,
to compute the dipole moment vector for each chunk. E.g. for water
molecules. Then spreading those values to each atom in each chunk.
Then defining a second set of chunks based on spatial bins. And
finally, using the "fix ave/chunk"_fix_ave_chunk.html command to
calculate an average dipole moment vector per spatial bin.
compute cmol all chunk/atom molecule
compute dipole all dipole/chunk cmol
compute spread all chunk/spread/atom cmol c_dipole\[1\] c_dipole\[2\] c_dipole\[3\]
compute cspatial all chunk/atom bin/1d z lower 0.1 units reduced
fix ave all ave/chunk 100 10 1000 cspatial c_spread\[*\] :pre
Note that the "fix ave/chunk"_fix_ave_chunk.html command requires
per-atom values as input. That is why the compute chunk/spread/atom
command is used to assign per-chunk values to each atom in the chunk.
If a molecule straddles bin boundaries, each of its atoms contributes
in a weighted manner to the average dipole moment of the spatial bin
it is in.
:line
[Output info:]
This compute calculates a per-atom vector or array, which can be
accessed by any command that uses per-atom values from a compute as
input. See the "Howto output"_Howto_output.html doc page for an
overview of LAMMPS output options.
The output is a per-atom vector if a single input value is specified,
otherwise a per-atom array is output. The number of columns in the
array is the number of inputs provided. The per-atom values for the
vector or each column of the array will be in whatever
"units"_units.html the corresponding input value is in.
The vector or array values are "intensive".
[Restrictions:] none
[Related commands:]
"compute chunk/atom"_compute_chunk_atom.html, "fix
ave/chunk"_fix_ave_chunk.html, "compute
reduce/chunk"_compute_reduce_chunk.html
[Default:] none

126
doc/txt/compute_dihedral_local.txt
View File

@ -1,126 +0,0 @@
"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
compute dihedral/local command :h3
[Syntax:]
compute ID group-ID dihedral/local value1 value2 ... keyword args ... :pre
ID, group-ID are documented in "compute"_compute.html command :ulb,l
dihedral/local = style name of this compute command :l
one or more values may be appended :l
value = {phi} or {v_name} :l
{phi} = tabulate dihedral angles
{v_name} = equal-style variable with name (see below) :pre
zero or more keyword/args pairs may be appended :l
keyword = {set} :l
{set} args = phi name
phi = only currently allowed arg
name = name of variable to set with phi :pre
:ule
[Examples:]
compute 1 all dihedral/local phi :pre
compute 1 all dihedral/local phi v_cos set phi p :pre
[Description:]
Define a computation that calculates properties of individual dihedral
interactions. The number of datums generated, aggregated across all
processors, equals the number of dihedral angles in the system, modified
by the group parameter as explained below.
The value {phi} is the dihedral angle, as defined in the diagram on
the "dihedral_style"_dihedral_style.html doc page.
The value {v_name} can be used together with the {set} keyword to
compute a user-specified function of the dihedral angle phi. The
{name} specified for the {v_name} value is the name of an "equal-style
variable"_variable.html which should evaluate a formula based on a
variable which will store the angle phi. This other variable must
be an "internal-style variable"_variable.html defined in the input
script; its initial numeric value can be anything. It must be an
internal-style variable, because this command resets its value
directly. The {set} keyword is used to identify the name of this
other variable associated with phi.
Note that the value of phi for each angle which stored in the internal
variable is in radians, not degrees.
As an example, these commands can be added to the bench/in.rhodo
script to compute the cosine and cosine^2 of every dihedral angle in
the system and output the statistics in various ways:
variable p internal 0.0
variable cos equal cos(v_p)
variable cossq equal cos(v_p)*cos(v_p) :pre
compute 1 all property/local datom1 datom2 datom3 datom4 dtype
compute 2 all dihedral/local phi v_cos v_cossq set phi p
dump 1 all local 100 tmp.dump c_1[*] c_2[*] :pre
compute 3 all reduce ave c_2[*]
thermo_style custom step temp press c_3[*] :pre
fix 10 all ave/histo 10 10 100 -1 1 20 c_2[2] mode vector file tmp.histo :pre
The "dump local"_dump.html command will output the angle,
cosine(angle), cosine^2(angle) for every dihedral in the system. The
"thermo_style"_thermo_style.html command will print the average of
those quantities via the "compute reduce"_compute_reduce.html command
with thermo output. And the "fix ave/histo"_fix_ave_histo.html
command will histogram the cosine(angle) values and write them to a
file.
:line
The local data stored by this command is generated by looping over all
the atoms owned on a processor and their dihedrals. A dihedral will
only be included if all 4 atoms in the dihedral are in the specified
compute group.
Note that as atoms migrate from processor to processor, there will be
no consistent ordering of the entries within the local vector or array
from one timestep to the next. The only consistency that is
guaranteed is that the ordering on a particular timestep will be the
same for local vectors or arrays generated by other compute commands.
For example, dihedral output from the "compute
property/local"_compute_property_local.html command can be combined
with data from this command and output by the "dump local"_dump.html
command in a consistent way.
Here is an example of how to do this:
compute 1 all property/local dtype datom1 datom2 datom3 datom4
compute 2 all dihedral/local phi
dump 1 all local 1000 tmp.dump index c_1\[1\] c_1\[2\] c_1\[3\] c_1\[4\] c_1\[5\] c_2\[1\] :pre
[Output info:]
This compute calculates a local vector or local array depending on the
number of values. The length of the vector or number of rows in the
array is the number of dihedrals. If a single value is specified, a
local vector is produced. If two or more values are specified, a
local array is produced where the number of columns = the number of
values. The vector or array can be accessed by any command that uses
local values from a compute as input. See the "Howto
output"_Howto_output.html doc page for an overview of LAMMPS output
options.
The output for {phi} will be in degrees.
[Restrictions:] none
[Related commands:]
"dump local"_dump.html, "compute
property/local"_compute_property_local.html
[Default:] none

137
doc/txt/compute_displace_atom.txt
View File

@ -1,137 +0,0 @@
"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
compute displace/atom command :h3
[Syntax:]
compute ID group-ID displace/atom :pre
ID, group-ID are documented in "compute"_compute.html command :ulb,l
displace/atom = style name of this compute command :l
zero or more keyword/arg pairs may be appended :l
keyword = {refresh} :l
{replace} arg = name of per-atom variable :pre
:ule
[Examples:]
compute 1 all displace/atom
compute 1 all displace/atom refresh myVar :pre
[Description:]
Define a computation that calculates the current displacement of each
atom in the group from its original (reference) coordinates, including
all effects due to atoms passing through periodic boundaries.
A vector of four quantities per atom is calculated by this compute.
The first 3 elements of the vector are the dx,dy,dz displacements.
The 4th component is the total displacement, i.e. sqrt(dx*dx + dy*dy +
dz*dz).
The displacement of an atom is from its original position at the time
the compute command was issued. The value of the displacement will be
0.0 for atoms not in the specified compute group.
NOTE: Initial coordinates are stored in "unwrapped" form, by using the
image flags associated with each atom. See the "dump
custom"_dump.html command for a discussion of "unwrapped" coordinates.
See the Atoms section of the "read_data"_read_data.html command for a
discussion of image flags and how they are set for each atom. You can
reset the image flags (e.g. to 0) before invoking this compute by
using the "set image"_set.html command.
NOTE: If you want the quantities calculated by this compute to be
continuous when running from a "restart file"_read_restart.html, then
you should use the same ID for this compute, as in the original run.
This is so that the fix this compute creates to store per-atom
quantities will also have the same ID, and thus be initialized
correctly with time=0 atom coordinates from the restart file.
:line
The {refresh} option can be used in conjunction with the "dump_modify
refresh" command to generate incremental dump files.
The definition and motivation of an incremental dump file is as
follows. Instead of outputting all atoms at each snapshot (with some
associated values), you may only wish to output the subset of atoms
with a value that has changed in some way compared to the value the
last time that atom was output. In some scenarios this can result in
a dramatically smaller dump file. If desired, by post-processing the
sequence of snapshots, the values for all atoms at all timesteps can
be inferred.
A concrete example using this compute, is a simulation of atom
diffusion in a solid, represented as atoms on a lattice. Diffusive
hops are rare. Imagine that when a hop occurs an atom moves more than
a distance {Dhop}. For any snapshot we only want to output atoms that
have hopped since the last snapshot. This can be accomplished with
something like the following commands:
write_dump all custom tmp.dump id type x y z # see comment below :pre
variable Dhop equal 0.6
variable check atom "c_dsp[4] > v_Dhop"
compute dsp all displace/atom refresh check
dump 1 all custom 100 tmp.dump id type x y z
dump_modify 1 append yes thresh c_dsp[4] > ${Dhop} &
refresh c_dsp delay 100 :pre
The "dump_modify thresh"_dump_modify.html command will only output
atoms that have displaced more than 0.6 Angstroms on each snapshot
(assuming metal units). The dump_modify {refresh} option triggers a
call to this compute at the end of every dump.
The {refresh} argument for this compute is the ID of an "atom-style
variable"_variable.html which calculates a Boolean value (0 or 1)
based on the same criterion used by dump_modify thresh. This compute
evaluates the atom-style variable. For each atom that returns 1
(true), the original (reference) coordinates of the atom (stored by
this compute) are updated.
The effect of these commands is that a particular atom will only be
output in the dump file on the snapshot after it makes a diffusive
hop. It will not be output again until it makes another hop.
Note that in the first snapshot of a subsequent run, no atoms will be
typically be output. That is because the initial displacement for all
atoms is 0.0. If an initial dump snapshot is desired, containing the
initial reference positions of all atoms, one way to do this is
illustrated above. An initial write_dump command can be used before
the first run. It will contain the positions of all the atoms,
Options in the "dump_modify"_dump_modify.html command above will
append new output to that same file and delay the output until a later
timestep. The {delay} setting avoids a second time = 0 snapshot which
would be empty.
:line
[Output info:]
This compute calculates a per-atom array with 4 columns, which can be
accessed by indices 1-4 by any command that uses per-atom values from
a compute as input. See the "Howto output"_Howto_output.html doc page
for an overview of LAMMPS output options.
The per-atom array values will be in distance "units"_units.html.
This compute supports the {refresh} option as explained above, for use
in conjunction with "dump_modify refresh"_dump_modify.html to generate
incremental dump files.
[Restrictions:] none
[Related commands:]
"compute msd"_compute_msd.html, "dump custom"_dump.html, "fix
store/state"_fix_store_state.html
[Default:] none

334
doc/txt/create_atoms.txt
View File

@ -1,334 +0,0 @@
"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
create_atoms command :h3
[Syntax:]
create_atoms type style args keyword values ... :pre
type = atom type (1-Ntypes) of atoms to create (offset for molecule creation) :ulb,l
style = {box} or {region} or {single} or {random} :l
{box} args = none
{region} args = region-ID
region-ID = particles will only be created if contained in the region
{single} args = x y z
x,y,z = coordinates of a single particle (distance units)
{random} args = N seed region-ID
N = number of particles to create
seed = random # seed (positive integer)
region-ID = create atoms within this region, use NULL for entire simulation box :pre
zero or more keyword/value pairs may be appended :l
keyword = {mol} or {basis} or {remap} or {var} or {set} or {units} :l
{mol} value = template-ID seed
template-ID = ID of molecule template specified in a separate "molecule"_molecule.html command
seed = random # seed (positive integer)
{basis} values = M itype
M = which basis atom
itype = atom type (1-N) to assign to this basis atom
{remap} value = {yes} or {no}
{var} value = name = variable name to evaluate for test of atom creation
{set} values = dim name
dim = {x} or {y} or {z}
name = name of variable to set with x, y, or z atom position
{rotate} values = theta Rx Ry Rz
theta = rotation angle for single molecule (degrees)
Rx,Ry,Rz = rotation vector for single molecule
{units} value = {lattice} or {box}
{lattice} = the geometry is defined in lattice units
{box} = the geometry is defined in simulation box units :pre
:ule
[Examples:]
create_atoms 1 box
create_atoms 3 region regsphere basis 2 3
create_atoms 3 single 0 0 5
create_atoms 1 box var v set x xpos set y ypos :pre
[Description:]
This command creates atoms (or molecules) on a lattice, or a single
atom (or molecule), or a random collection of atoms (or molecules), as
an alternative to reading in their coordinates explicitly via a
"read_data"_read_data.html or "read_restart"_read_restart.html
command. A simulation box must already exist, which is typically
created via the "create_box"_create_box.html command. Before using
this command, a lattice must also be defined using the
"lattice"_lattice.html command, unless you specify the {single} style
with units = box or the {random} style. For the remainder of this doc
page, a created atom or molecule is referred to as a "particle".
If created particles are individual atoms, they are assigned the
specified atom {type}, though this can be altered via the {basis}
keyword as discussed below. If molecules are being created, the type
of each atom in the created molecule is specified in the file read by
the "molecule"_molecule.html command, and those values are added to
the specified atom {type}. E.g. if {type} = 2, and the file specifies
atom types 1,2,3, then each created molecule will have atom types
3,4,5.
For the {box} style, the create_atoms command fills the entire
simulation box with particles on the lattice. If your simulation box
is periodic, you should insure its size is a multiple of the lattice
spacings, to avoid unwanted atom overlaps at the box boundaries. If
your box is periodic and a multiple of the lattice spacing in a
particular dimension, LAMMPS is careful to put exactly one particle at
the boundary (on either side of the box), not zero or two.
For the {region} style, a geometric volume is filled with particles on
the lattice. This volume what is inside the simulation box and is
also consistent with the region volume. See the "region"_region.html
command for details. Note that a region can be specified so that its
"volume" is either inside or outside a geometric boundary. Also note
that if your region is the same size as a periodic simulation box (in
some dimension), LAMMPS does not implement the same logic described
above as for the {box} style, to insure exactly one particle at
periodic boundaries. if this is what you desire, you should either
use the {box} style, or tweak the region size to get precisely the
particles you want.
For the {single} style, a single particle is added to the system at
the specified coordinates. This can be useful for debugging purposes
or to create a tiny system with a handful of particles at specified
positions.
For the {random} style, N particles are added to the system at
randomly generated coordinates, which can be useful for generating an
amorphous system. The particles are created one by one using the
specified random number {seed}, resulting in the same set of particles
coordinates, independent of how many processors are being used in the
simulation. If the {region-ID} argument is specified as NULL, then
the created particles will be anywhere in the simulation box. If a
{region-ID} is specified, a geometric volume is filled which is both
inside the simulation box and is also consistent with the region
volume. See the "region"_region.html command for details. Note that
a region can be specified so that its "volume" is either inside or
outside a geometric boundary.
NOTE: Particles generated by the {random} style will typically be
highly overlapped which will cause many interatomic potentials to
compute large energies and forces. Thus you should either perform an
"energy minimization"_minimize.html or run dynamics with "fix
nve/limit"_fix_nve_limit.html to equilibrate such a system, before
running normal dynamics.
Note that this command adds particles to those that already exist.
This means it can be used to add particles to a system previously read
in from a data or restart file. Or the create_atoms command can be
used multiple times, to add multiple sets of particles to the
simulation. For example, grain boundaries can be created, by
interleaving create_atoms with "lattice"_lattice.html commands
specifying different orientations. By using the create_atoms command
in conjunction with the "delete_atoms"_delete_atoms.html command,
reasonably complex geometries can be created, or a protein can be
solvated with a surrounding box of water molecules.
In all these cases, care should be taken to insure that new atoms do
not overlap existing atoms inappropriately, especially if molecules
are being added. The "delete_atoms"_delete_atoms.html command can be
used to remove overlapping atoms or molecules.
NOTE: You cannot use any of the styles explained above to create atoms
that are outside the simulation box; they will just be ignored by
LAMMPS. This is true even if you are using shrink-wrapped box
boundaries, as specified by the "boundary"_boundary.html command.
However, you can first use the "change_box"_change_box.html command to
temporarily expand the box, then add atoms via create_atoms, then
finally use change_box command again if needed to re-shrink-wrap the
new atoms. See the "change_box"_change_box.html doc page for an
example of how to do this, using the create_atoms {single} style to
insert a new atom outside the current simulation box.
:line
Individual atoms are inserted by this command, unless the {mol}
keyword is used. It specifies a {template-ID} previously defined
using the "molecule"_molecule.html command, which reads a file that
defines the molecule. The coordinates, atom types, charges, etc, as
well as any bond/angle/etc and special neighbor information for the
molecule can be specified in the molecule file. See the
"molecule"_molecule.html command for details. The only settings
required to be in this file are the coordinates and types of atoms in
the molecule.
Using a lattice to add molecules, e.g. via the {box} or {region} or
{single} styles, is exactly the same as adding atoms on lattice
points, except that entire molecules are added at each point, i.e. on
the point defined by each basis atom in the unit cell as it tiles the
simulation box or region. This is done by placing the geometric
center of the molecule at the lattice point, and giving the molecule a
random orientation about the point. The random {seed} specified with
the {mol} keyword is used for this operation, and the random numbers
generated by each processor are different. This means the coordinates
of individual atoms (in the molecules) will be different when running
on different numbers of processors, unlike when atoms are being
created in parallel.
Also note that because of the random rotations, it may be important to
use a lattice with a large enough spacing that adjacent molecules will
not overlap, regardless of their relative orientations.
NOTE: If the "create_box"_create_box.html command is used to create
the simulation box, followed by the create_atoms command with its
{mol} option for adding molecules, then you typically need to use the
optional keywords allowed by the "create_box"_create_box.html command
for extra bonds (angles,etc) or extra special neighbors. This is
because by default, the "create_box"_create_box.html command sets up a
non-molecular system which doesn't allow molecules to be added.
:line
This is the meaning of the other allowed keywords.
The {basis} keyword is only used when atoms (not molecules) are being
created. It specifies an atom type that will be assigned to specific
basis atoms as they are created. See the "lattice"_lattice.html
command for specifics on how basis atoms are defined for the unit cell
of the lattice. By default, all created atoms are assigned the
argument {type} as their atom type.
The {remap} keyword only applies to the {single} style. If it is set
to {yes}, then if the specified position is outside the simulation
box, it will mapped back into the box, assuming the relevant
dimensions are periodic. If it is set to {no}, no remapping is done
and no particle is created if its position is outside the box.
The {var} and {set} keywords can be used together to provide a
criterion for accepting or rejecting the addition of an individual
atom, based on its coordinates. The {name} specified for the {var}
keyword is the name of an "equal-style variable"_variable.html which
should evaluate to a zero or non-zero value based on one or two or
three variables which will store the x, y, or z coordinates of an atom
(one variable per coordinate). If used, these other variables must be
"internal-style variables"_variable.html defined in the input script;
their initial numeric value can be anything. They must be
internal-style variables, because this command resets their values
directly. The {set} keyword is used to identify the names of these
other variables, one variable for the x-coordinate of a created atom,
one for y, and one for z.
When an atom is created, its x,y,z coordinates become the values for
any {set} variable that is defined. The {var} variable is then
evaluated. If the returned value is 0.0, the atom is not created. If
it is non-zero, the atom is created.
As an example, these commands can be used in a 2d simulation, to
create a sinusoidal surface. Note that the surface is "rough" due to
individual lattice points being "above" or "below" the mathematical
expression for the sinusoidal curve. If a finer lattice were used,
the sinusoid would appear to be "smoother". Also note the use of the
"xlat" and "ylat" "thermo_style"_thermo_style.html keywords which
converts lattice spacings to distance. Click on the image for a
larger version.
dimension 2
variable x equal 100
variable y equal 25
lattice hex 0.8442
region box block 0 $x 0 $y -0.5 0.5
create_box 1 box :pre
variable xx internal 0.0
variable yy internal 0.0
variable v equal "(0.2*v_y*ylat * cos(v_xx/xlat * 2.0*PI*4.0/v_x) + 0.5*v_y*ylat - v_yy) > 0.0"
create_atoms 1 box var v set x xx set y yy
write_dump all atom sinusoid.lammpstrj :pre
:c,image(JPG/sinusoid_small.jpg,JPG/sinusoid.jpg)
The {rotate} keyword allows specification of the orientation
at which molecules are inserted. The axis of rotation is
determined by the rotation vector (Rx,Ry,Rz) that goes through the
insertion point. The specified {theta} determines the angle of
rotation around that axis. Note that the direction of rotation for
the atoms around the rotation axis is consistent with the right-hand
rule: if your right-hand's thumb points along {R}, then your fingers
wrap around the axis in the direction of rotation.
The {units} keyword determines the meaning of the distance units used
to specify the coordinates of the one particle created by the {single}
style. A {box} value selects standard distance units as defined by
the "units"_units.html command, e.g. Angstroms for units = real or
metal. A {lattice} value means the distance units are in lattice
spacings.
:line
Atom IDs are assigned to created atoms in the following way. The
collection of created atoms are assigned consecutive IDs that start
immediately following the largest atom ID existing before the
create_atoms command was invoked. This is done by the processor's
communicating the number of atoms they each own, the first processor
numbering its atoms from 1 to N1, the second processor from N1+1 to
N2, etc. Where N1 = number of atoms owned by the first processor, N2
= number owned by the second processor, etc. Thus when the same
simulation is performed on different numbers of processors, there is
no guarantee a particular created atom will be assigned the same ID in
both simulations. If molecules are being created, molecule IDs are
assigned to created molecules in a similar fashion.
Aside from their ID, atom type, and xyz position, other properties of
created atoms are set to default values, depending on which quantities
are defined by the chosen "atom style"_atom_style.html. See the "atom
style"_atom_style.html command for more details. See the
"set"_set.html and "velocity"_velocity.html commands for info on how
to change these values.
charge = 0.0
dipole moment magnitude = 0.0
diameter = 1.0
shape = 0.0 0.0 0.0
density = 1.0
volume = 1.0
velocity = 0.0 0.0 0.0
angular velocity = 0.0 0.0 0.0
angular momentum = 0.0 0.0 0.0
quaternion = (1,0,0,0)
bonds, angles, dihedrals, impropers = none :ul
If molecules are being created, these defaults can be overridden by
values specified in the file read by the "molecule"_molecule.html
command. E.g. the file typically defines bonds (angles,etc) between
atoms in the molecule, and can optionally define charges on each atom.
Note that the {sphere} atom style sets the default particle diameter
to 1.0 as well as the density. This means the mass for the particle
is not 1.0, but is PI/6 * diameter^3 = 0.5236.
Note that the {ellipsoid} atom style sets the default particle shape
to (0.0 0.0 0.0) and the density to 1.0 which means it is a point
particle, not an ellipsoid, and has a mass of 1.0.
Note that the {peri} style sets the default volume and density to 1.0
and thus also set the mass for the particle to 1.0.
The "set"_set.html command can be used to override many of these
default settings.
:line
[Restrictions:]
An "atom_style"_atom_style.html must be previously defined to use this
command.
A rotation vector specified for a single molecule must be in
the z-direction for a 2d model.
[Related commands:]
"lattice"_lattice.html, "region"_region.html, "create_box"_create_box.html,
"read_data"_read_data.html, "read_restart"_read_restart.html
[Default:]
The default for the {basis} keyword is that all created atoms are
assigned the argument {type} as their atom type (when single atoms are
being created). The other defaults are {remap} = no, {rotate} =
random, and {units} = lattice.

392
doc/txt/fix.txt
View File

@ -1,392 +0,0 @@
"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
fix command :h3
[Syntax:]
fix ID group-ID style args :pre
ID = user-assigned name for the fix
group-ID = ID of the group of atoms to apply the fix to
style = one of a long list of possible style names (see below)
args = arguments used by a particular style :ul
[Examples:]
fix 1 all nve
fix 3 all nvt temp 300.0 300.0 0.01
fix mine top setforce 0.0 NULL 0.0 :pre
[Description:]
Set a fix that will be applied to a group of atoms. In LAMMPS, a
"fix" is any operation that is applied to the system during
timestepping or minimization. Examples include updating of atom
positions and velocities due to time integration, controlling
temperature, applying constraint forces to atoms, enforcing boundary
conditions, computing diagnostics, etc. There are hundreds of fixes
defined in LAMMPS and new ones can be added; see the
"Modify"_Modify.html doc page for details.
Fixes perform their operations at different stages of the timestep.
If 2 or more fixes operate at the same stage of the timestep, they are
invoked in the order they were specified in the input script.
The ID of a fix can only contain alphanumeric characters and
underscores.
Fixes can be deleted with the "unfix"_unfix.html command.
NOTE: The "unfix"_unfix.html command is the only way to turn off a
fix; simply specifying a new fix with a similar style will not turn
off the first one. This is especially important to realize for
integration fixes. For example, using a "fix nve"_fix_nve.html
command for a second run after using a "fix nvt"_fix_nh.html command
for the first run, will not cancel out the NVT time integration
invoked by the "fix nvt" command. Thus two time integrators would be
in place!
If you specify a new fix with the same ID and style as an existing
fix, the old fix is deleted and the new one is created (presumably
with new settings). This is the same as if an "unfix" command were
first performed on the old fix, except that the new fix is kept in the
same order relative to the existing fixes as the old one originally
was. Note that this operation also wipes out any additional changes
made to the old fix via the "fix_modify"_fix_modify.html command.
The "fix modify"_fix_modify.html command allows settings for some
fixes to be reset. See the doc page for individual fixes for details.
Some fixes store an internal "state" which is written to binary
restart files via the "restart"_restart.html or
"write_restart"_write_restart.html commands. This allows the fix to
continue on with its calculations in a restarted simulation. See the
"read_restart"_read_restart.html command for info on how to re-specify
a fix in an input script that reads a restart file. See the doc pages
for individual fixes for info on which ones can be restarted.
:line
Some fixes calculate one of three styles of quantities: global,
per-atom, or local, which can be used by other commands or output as
described below. A global quantity is one or more system-wide values,
e.g. the energy of a wall interacting with particles. A per-atom
quantity is one or more values per atom, e.g. the displacement vector
for each atom since time 0. Per-atom values are set to 0.0 for atoms
not in the specified fix group. Local quantities are calculated by
each processor based on the atoms it owns, but there may be zero or
more per atoms.
Note that a single fix can produce either global or per-atom or local
quantities (or none at all), but not both global and per-atom. It can
produce local quantities in tandem with global or per-atom quantities.
The fix doc page will explain.
Global, per-atom, and local quantities each come in three kinds: a
single scalar value, a vector of values, or a 2d array of values. The
doc page for each fix describes the style and kind of values it
produces, e.g. a per-atom vector. Some fixes produce more than one
kind of a single style, e.g. a global scalar and a global vector.
When a fix quantity is accessed, as in many of the output commands
discussed below, it can be referenced via the following bracket
notation, where ID is the ID of the fix:
f_ID | entire scalar, vector, or array
f_ID\[I\] | one element of vector, one column of array
f_ID\[I\]\[J\] | one element of array :tb(s=|)
In other words, using one bracket reduces the dimension of the
quantity once (vector -> scalar, array -> vector). Using two brackets
reduces the dimension twice (array -> scalar). Thus a command that
uses scalar fix values as input can also process elements of a vector
or array.
Note that commands and "variables"_variable.html which use fix
quantities typically do not allow for all kinds, e.g. a command may
require a vector of values, not a scalar. This means there is no
ambiguity about referring to a fix quantity as f_ID even if it
produces, for example, both a scalar and vector. The doc pages for
various commands explain the details.
:line
In LAMMPS, the values generated by a fix can be used in several ways:
Global values can be output via the "thermo_style
custom"_thermo_style.html or "fix ave/time"_fix_ave_time.html command.
Or the values can be referenced in a "variable equal"_variable.html or
"variable atom"_variable.html command. :ulb,l
Per-atom values can be output via the "dump custom"_dump.html command.
Or they can be time-averaged via the "fix ave/atom"_fix_ave_atom.html
command or reduced by the "compute reduce"_compute_reduce.html
command. Or the per-atom values can be referenced in an "atom-style
variable"_variable.html. :l
Local values can be reduced by the "compute
reduce"_compute_reduce.html command, or histogrammed by the "fix
ave/histo"_fix_ave_histo.html command. :l
:ule
See the "Howto output"_Howto_output.html doc page for a summary of
various LAMMPS output options, many of which involve fixes.
The results of fixes that calculate global quantities can be either
"intensive" or "extensive" values. Intensive means the value is
independent of the number of atoms in the simulation,
e.g. temperature. Extensive means the value scales with the number of
atoms in the simulation, e.g. total rotational kinetic energy.
"Thermodynamic output"_thermo_style.html will normalize extensive
values by the number of atoms in the system, depending on the
"thermo_modify norm" setting. It will not normalize intensive values.
If a fix value is accessed in another way, e.g. by a
"variable"_variable.html, you may want to know whether it is an
intensive or extensive value. See the doc page for individual fixes
for further info.
:line
Each fix style has its own doc page which describes its arguments and
what it does, as listed below. Here is an alphabetic list of fix
styles available in LAMMPS. They are also listed in more compact form
on the "Commands fix"_Commands_fix.html doc page.
There are also additional accelerated fix styles included in the
LAMMPS distribution for faster performance on CPUs, GPUs, and KNLs.
The individual style names on the "Commands fix"_Commands_fix.html doc
page are followed by one or more of (g,i,k,o,t) to indicate which
accelerated styles exist.
"adapt"_fix_adapt.html - change a simulation parameter over time
"adapt/fep"_fix_adapt_fep.html - enhanced version of fix adapt
"addforce"_fix_addforce.html - add a force to each atom
"addtorque"_fix_addtorque.html - add a torque to a group of atoms
"append/atoms"_fix_append_atoms.html - append atoms to a running simulation
"atc"_fix_atc.html - initiates a coupled MD/FE simulation
"atom/swap"_fix_atom_swap.html - Monte Carlo atom type swapping
"ave/atom"_fix_ave_atom.html - compute per-atom time-averaged quantities
"ave/chunk"_fix_ave_chunk.html - compute per-chunk time-averaged quantities
"ave/correlate"_fix_ave_correlate.html - compute/output time correlations
"ave/correlate/long"_fix_ave_correlate_long.html -
"ave/histo"_fix_ave_histo.html - compute/output time-averaged histograms
"ave/histo/weight"_fix_ave_histo.html - weighted version of fix ave/histo
"ave/time"_fix_ave_time.html - compute/output global time-averaged quantities
"aveforce"_fix_aveforce.html - add an averaged force to each atom
"balance"_fix_balance.html - perform dynamic load-balancing
"bocs"_fix_bocs.html - NPT style time integration with pressure correction
"bond/break"_fix_bond_break.html - break bonds on the fly
"bond/create"_fix_bond_create.html - create bonds on the fly
"bond/react"_fix_bond_react.html - apply topology changes to model reactions
"bond/swap"_fix_bond_swap.html - Monte Carlo bond swapping
"box/relax"_fix_box_relax.html - relax box size during energy minimization
"client/md"_fix_client_md.html - MD client for client/server simulations
"cmap"_fix_cmap.html - enables CMAP cross-terms of the CHARMM force field
"colvars"_fix_colvars.html - interface to the collective variables "Colvars" library
"controller"_fix_controller.html - apply control loop feedback mechanism
"deform"_fix_deform.html - change the simulation box size/shape
"deposit"_fix_deposit.html - add new atoms above a surface
"dpd/energy"_fix_dpd_energy.html - constant energy dissipative particle dynamics
"drag"_fix_drag.html - drag atoms towards a defined coordinate
"drude"_fix_drude.html - part of Drude oscillator polarization model
"drude/transform/direct"_fix_drude_transform.html - part of Drude oscillator polarization model
"drude/transform/inverse"_fix_drude_transform.html - part of Drude oscillator polarization model
"dt/reset"_fix_dt_reset.html - reset the timestep based on velocity, forces
"edpd/source"_fix_dpd_source.html - add heat source to eDPD simulations
"efield"_fix_efield.html - impose electric field on system
"ehex"_fix_ehex.html - enhanced heat exchange algorithm
"electron/stopping"_fix_electron_stopping.html - electronic stopping power as a friction force
"enforce2d"_fix_enforce2d.html - zero out z-dimension velocity and force
"eos/cv"_fix_eos_cv.html -
"eos/table"_fix_eos_table.html -
"eos/table/rx"_fix_eos_table_rx.html -
"evaporate"_fix_evaporate.html - remove atoms from simulation periodically
"external"_fix_external.html - callback to an external driver program
"ffl"_fix_ffl.html - apply a Fast-Forward Langevin equation thermostat
"filter/corotate"_fix_filter_corotate.html - implement corotation filter to allow larger timesteps with r-RESPA
"flow/gauss"_fix_flow_gauss.html - Gaussian dynamics for constant mass flux
"freeze"_fix_freeze.html - freeze atoms in a granular simulation
"gcmc"_fix_gcmc.html - grand canonical insertions/deletions
"gld"_fix_gld.html - generalized Langevin dynamics integrator
"gle"_fix_gle.html - generalized Langevin equation thermostat
"gravity"_fix_gravity.html - add gravity to atoms in a granular simulation
"grem"_fix_grem.html - implements the generalized replica exchange method
"halt"_fix_halt.html - terminate a dynamics run or minimization
"heat"_fix_heat.html - add/subtract momentum-conserving heat
"hyper/global"_fix_hyper_global.html - global hyperdynamics
"hyper/local"_fix_hyper_local.html - local hyperdynamics
"imd"_fix_imd.html - implements the "Interactive MD" (IMD) protocol
"indent"_fix_indent.html - impose force due to an indenter
"ipi"_fix_ipi.html - enable LAMMPS to run as a client for i-PI path-integral simulations
"langevin"_fix_langevin.html - Langevin temperature control
"langevin/drude"_fix_langevin_drude.html - Langevin temperature control of Drude oscillators
"langevin/eff"_fix_langevin_eff.html - Langevin temperature control for the electron force field model
"langevin/spin"_fix_langevin_spin.html - Langevin temperature control for a spin or spin-lattice system
"latte"_fix_latte.html - wrapper on LATTE density-functional tight-binding code
"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 - constrain atoms to move in a line
"manifoldforce"_fix_manifoldforce.html - restrain atoms to a manifold during minimization
"meso"_fix_meso.html - time integration for SPH/DPDE particles
"meso/move"_fix_meso_move.html - move mesoscopic SPH/SDPD particles in a prescribed fashion
"meso/stationary"_fix_meso_stationary.html -
"momentum"_fix_momentum.html - zero the linear and/or angular momentum of a group of atoms
"move"_fix_move.html - move atoms in a prescribed fashion
"mscg"_fix_mscg.html - apply MSCG method for force-matching to generate coarse grain models
"msst"_fix_msst.html - multi-scale shock technique (MSST) integration
"mvv/dpd"_fix_mvv_dpd.html - DPD using the modified velocity-Verlet integration algorithm
"mvv/edpd"_fix_mvv_dpd.html - constant energy DPD using the modified velocity-Verlet algorithm
"mvv/tdpd"_fix_mvv_dpd.html - constant temperature DPD using the modified velocity-Verlet algorithm
"neb"_fix_neb.html - nudged elastic band (NEB) spring forces
"nph"_fix_nh.html - constant NPH time integration via Nose/Hoover
"nph/asphere"_fix_nph_asphere.html - NPH for aspherical particles
"nph/body"_fix_nph_body.html - NPH for body particles
"nph/eff"_fix_nh_eff.html - NPH for nuclei and electrons in the electron force field model
"nph/sphere"_fix_nph_sphere.html - NPH for spherical particles
"nphug"_fix_nphug.html - constant-stress Hugoniostat integration
"npt"_fix_nh.html - constant NPT time integration via Nose/Hoover
"npt/asphere"_fix_npt_asphere.html - NPT for aspherical particles
"npt/body"_fix_npt_body.html - NPT for body particles
"npt/eff"_fix_nh_eff.html - NPT for nuclei and electrons in the electron force field model
"npt/sphere"_fix_npt_sphere.html - NPT for spherical particles
"npt/uef"_fix_nh_uef.html - NPT style time integration with diagonal flow
"nve"_fix_nve.html - constant NVE time integration
"nve/asphere"_fix_nve_asphere.html - NVE for aspherical particles
"nve/asphere/noforce"_fix_nve_asphere_noforce.html - NVE for aspherical particles without forces
"nve/awpmd"_fix_nve_awpmd.html - NVE for the Antisymmetrized Wave Packet Molecular Dynamics model
"nve/body"_fix_nve_body.html - NVE for body particles
"nve/dot"_fix_nve_dot.html - rigid body constant energy time integrator for coarse grain models
"nve/dotc/langevin"_fix_nve_dotc_langevin.html - Langevin style rigid body time integrator for coarse grain models
"nve/eff"_fix_nve_eff.html - NVE for nuclei and electrons in the electron force field model
"nve/limit"_fix_nve_limit.html - NVE with limited step length
"nve/line"_fix_nve_line.html - NVE for line segments
"nve/manifold/rattle"_fix_nve_manifold_rattle.html -
"nve/noforce"_fix_nve_noforce.html - NVE without forces (v only)
"nve/sphere"_fix_nve_sphere.html - NVE for spherical particles
"nve/spin"_fix_nve_spin.html - NVE for a spin or spin-lattice system
"nve/tri"_fix_nve_tri.html - NVE for triangles
"nvk"_fix_nvk.html - constant kinetic energy time integration
"nvt"_fix_nh.html - NVT time integration via Nose/Hoover
"nvt/asphere"_fix_nvt_asphere.html - NVT for aspherical particles
"nvt/body"_fix_nvt_body.html - NVT for body particles
"nvt/eff"_fix_nh_eff.html - NVE for nuclei and electrons in the electron force field model
"nvt/manifold/rattle"_fix_nvt_manifold_rattle.html -
"nvt/sllod"_fix_nvt_sllod.html - NVT for NEMD with SLLOD equations
"nvt/sllod/eff"_fix_nvt_sllod_eff.html - NVT for NEMD with SLLOD equations for the electron force field model
"nvt/sphere"_fix_nvt_sphere.html - NVT for spherical particles
"nvt/uef"_fix_nh_uef.html - NVT style time integration with diagonal flow
"oneway"_fix_oneway.html - constrain particles on move in one direction
"orient/bcc"_fix_orient.html - add grain boundary migration force for BCC
"orient/fcc"_fix_orient.html - add grain boundary migration force for FCC
"phonon"_fix_phonon.html - calculate dynamical matrix from MD simulations
"pimd"_fix_pimd.html - Feynman path integral molecular dynamics
"planeforce"_fix_planeforce.html - constrain atoms to move in a plane
"plumed"_fix_plumed.html - wrapper on PLUMED free energy library
"poems"_fix_poems.html - constrain clusters of atoms to move as coupled rigid bodies
"pour"_fix_pour.html - pour new atoms/molecules into a granular simulation domain
"precession/spin"_fix_precession_spin.html -
"press/berendsen"_fix_press_berendsen.html - pressure control by Berendsen barostat
"print"_fix_print.html - print text and variables during a simulation
"property/atom"_fix_property_atom.html - add customized per-atom values
"python/invoke"_fix_python_invoke.html - call a Python function during a simulation
"python/move"_fix_python_move.html - call a Python function during a simulation run
"qbmsst"_fix_qbmsst.html - quantum bath multi-scale shock technique time integrator
"qeq/comb"_fix_qeq_comb.html - charge equilibration for COMB potential
"qeq/dynamic"_fix_qeq.html - charge equilibration via dynamic method
"qeq/fire"_fix_qeq.html - charge equilibration via FIRE minimizer
"qeq/point"_fix_qeq.html - charge equilibration via point method
"qeq/reax"_fix_qeq_reax.html - charge equilibration for ReaxFF potential
"qeq/shielded"_fix_qeq.html - charge equilibration via shielded method
"qeq/slater"_fix_qeq.html - charge equilibration via Slater method
"qmmm"_fix_qmmm.html - functionality to enable a quantum mechanics/molecular mechanics coupling
"qtb"_fix_qtb.html - implement quantum thermal bath scheme
"rattle"_fix_shake.html - RATTLE constraints on bonds and/or angles
"reax/c/bonds"_fix_reaxc_bonds.html - write out ReaxFF bond information
"reax/c/species"_fix_reaxc_species.html - write out ReaxFF molecule information
"recenter"_fix_recenter.html - constrain the center-of-mass position of a group of atoms
"restrain"_fix_restrain.html - constrain a bond, angle, dihedral
"rhok"_fix_rhok.html - add bias potential for long-range ordered systems
"rigid"_fix_rigid.html - constrain one or more clusters of atoms to move as a rigid body with NVE integration
"rigid/meso"_fix_rigid_meso.html - constrain clusters of mesoscopic SPH/SDPD particles to move as a rigid body
"rigid/nph"_fix_rigid.html - constrain one or more clusters of atoms to move as a rigid body with NPH integration
"rigid/nph/small"_fix_rigid.html - constrain many small clusters of atoms to move as a rigid body with NPH integration
"rigid/npt"_fix_rigid.html - constrain one or more clusters of atoms to move as a rigid body with NPT integration
"rigid/npt/small"_fix_rigid.html - constrain many small clusters of atoms to move as a rigid body with NPT integration
"rigid/nve"_fix_rigid.html - constrain one or more clusters of atoms to move as a rigid body with alternate NVE integration
"rigid/nve/small"_fix_rigid.html - constrain many small clusters of atoms to move as a rigid body with alternate NVE integration
"rigid/nvt"_fix_rigid.html - constrain one or more clusters of atoms to move as a rigid body with NVT integration
"rigid/nvt/small"_fix_rigid.html - constrain many small clusters of atoms to move as a rigid body with NVT integration
"rigid/small"_fix_rigid.html - constrain many small clusters of atoms to move as a rigid body with NVE integration
"rx"_fix_rx.html -
"saed/vtk"_fix_saed_vtk.html -
"setforce"_fix_setforce.html - set the force on each atom
"shake"_fix_shake.html - SHAKE constraints on bonds and/or angles
"shardlow"_fix_shardlow.html - integration of DPD equations of motion using the Shardlow splitting
"smd"_fix_smd.html - applied a steered MD force to a group
"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_tri_surf"_fix_smd_move_triangulated_surface.html -
"smd/setvel"_fix_smd_setvel.html -
"smd/wall_surface"_fix_smd_wall_surface.html -
"spring"_fix_spring.html - apply harmonic spring force to group of atoms
"spring/chunk"_fix_spring_chunk.html - apply harmonic spring force to each chunk of atoms
"spring/rg"_fix_spring_rg.html - spring on radius of gyration of group of atoms
"spring/self"_fix_spring_self.html - spring from each atom to its origin
"srd"_fix_srd.html - stochastic rotation dynamics (SRD)
"store/force"_fix_store_force.html - store force on each atom
"store/state"_fix_store_state.html - store attributes for each atom
"tdpd/source"_fix_dpd_source.html -
"temp/berendsen"_fix_temp_berendsen.html - temperature control by Berendsen thermostat
"temp/csld"_fix_temp_csvr.html - canonical sampling thermostat with Langevin dynamics
"temp/csvr"_fix_temp_csvr.html - canonical sampling thermostat with Hamiltonian dynamics
"temp/rescale"_fix_temp_rescale.html - temperature control by velocity rescaling
"temp/rescale/eff"_fix_temp_rescale_eff.html - temperature control by velocity rescaling in the electron force field model
"tfmc"_fix_tfmc.html - perform force-bias Monte Carlo with time-stamped method
"thermal/conductivity"_fix_thermal_conductivity.html - Muller-Plathe kinetic energy exchange for thermal conductivity calculation
"ti/spring"_fix_ti_spring.html -
"tmd"_fix_tmd.html - guide a group of atoms to a new configuration
"ttm"_fix_ttm.html - two-temperature model for electronic/atomic coupling
"ttm/mod"_fix_ttm.html - enhanced two-temperature model with additional options
"tune/kspace"_fix_tune_kspace.html - auto-tune KSpace parameters
"vector"_fix_vector.html - accumulate a global vector every N timesteps
"viscosity"_fix_viscosity.html - Muller-Plathe momentum exchange for viscosity calculation
"viscous"_fix_viscous.html - viscous damping for granular simulations
"wall/body/polygon"_fix_wall_body_polygon.html -
"wall/body/polyhedron"_fix_wall_body_polyhedron.html -
"wall/colloid"_fix_wall.html - Lennard-Jones wall interacting with finite-size particles
"wall/ees"_fix_wall_ees.html - wall for ellipsoidal particles
"wall/gran"_fix_wall_gran.html - frictional wall(s) for granular simulations
"wall/gran/region"_fix_wall_gran_region.html -
"wall/harmonic"_fix_wall.html - harmonic spring wall
"wall/lj1043"_fix_wall.html - Lennard-Jones 10-4-3 wall
"wall/lj126"_fix_wall.html - Lennard-Jones 12-6 wall
"wall/lj93"_fix_wall.html - Lennard-Jones 9-3 wall
"wall/morse"_fix_wall.html - Morse potential wall
"wall/piston"_fix_wall_piston.html - moving reflective piston wall
"wall/reflect"_fix_wall_reflect.html - reflecting wall(s)
"wall/region"_fix_wall_region.html - use region surface as wall
"wall/region/ees"_fix_wall_ees.html - use region surface as wall for ellipsoidal particles
"wall/srd"_fix_wall_srd.html - slip/no-slip wall for SRD particles :ul
[Restrictions:]
Some fix styles are part of specific packages. They are only enabled
if LAMMPS was built with that package. See the "Build
package"_Build_package.html doc page for more info. The doc pages for
individual fixes tell if it is part of a package.
[Related commands:]
"unfix"_unfix.html, "fix_modify"_fix_modify.html
[Default:] none

2
doc/txt/fix_ave_atom.txt
View File

@ -80,7 +80,7 @@ command creates a per-atom array with 6 columns:
compute my_stress all stress/atom NULL
fix 1 all ave/atom 10 20 1000 c_my_stress\[*\]
fix 1 all ave/atom 10 20 1000 c_my_stress\[1\] c_my_stress\[1\] &
fix 1 all ave/atom 10 20 1000 c_my_stress\[1\] c_my_stress\[2\] &
c_my_stress\[3\] c_my_stress\[4\] &
c_my_stress\[5\] c_my_stress\[6\] :pre

492
doc/txt/fix_ave_chunk.txt
View File

@ -1,492 +0,0 @@
"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
fix ave/chunk command :h3
[Syntax:]
fix ID group-ID ave/chunk Nevery Nrepeat Nfreq chunkID value1 value2 ... keyword args ... :pre
ID, group-ID are documented in "fix"_fix.html command :ulb,l
ave/chunk = style name of this fix command :l
Nevery = use input values every this many timesteps :l
Nrepeat = # of times to use input values for calculating averages :l
Nfreq = calculate averages every this many timesteps :l
chunkID = ID of "compute chunk/atom"_compute_chunk_atom.html command :l
one or more input values can be listed :l
value = vx, vy, vz, fx, fy, fz, density/mass, density/number, temp, c_ID, c_ID\[I\], f_ID, f_ID\[I\], v_name :l
vx,vy,vz,fx,fy,fz = atom attribute (velocity, force component)
density/number, density/mass = number or mass density
temp = temperature
c_ID = per-atom vector calculated by a compute with ID
c_ID\[I\] = Ith column of per-atom array calculated by a compute with ID, I can include wildcard (see below)
f_ID = per-atom vector calculated by a fix with ID
f_ID\[I\] = Ith column of per-atom array calculated by a fix with ID, I can include wildcard (see below)
v_name = per-atom vector calculated by an atom-style variable with name :pre
zero or more keyword/arg pairs may be appended :l
keyword = {norm} or {ave} or {bias} or {adof} or {cdof} or {file} or {overwrite} or {title1} or {title2} or {title3} :l
{norm} arg = {all} or {sample} or {none} = how output on {Nfreq} steps is normalized
all = output is sum of atoms across all {Nrepeat} samples, divided by atom count
sample = output is sum of {Nrepeat} sample averages, divided by {Nrepeat}
none = output is sum of {Nrepeat} sample sums, divided by {Nrepeat}
{ave} args = {one} or {running} or {window M}
one = output new average value every Nfreq steps
running = output cumulative average of all previous Nfreq steps
window M = output average of M most recent Nfreq steps
{bias} arg = bias-ID
bias-ID = ID of a temperature compute that removes a velocity bias for temperature calculation
{adof} value = dof_per_atom
dof_per_atom = define this many degrees-of-freedom per atom for temperature calculation
{cdof} value = dof_per_chunk
dof_per_chunk = define this many degrees-of-freedom per chunk for temperature calculation
{file} arg = filename
filename = file to write results to
{overwrite} arg = none = overwrite output file with only latest output
{format} arg = string
string = C-style format string
{title1} arg = string
string = text to print as 1st line of output file
{title2} arg = string
string = text to print as 2nd line of output file
{title3} arg = string
string = text to print as 3rd line of output file :pre
:ule
[Examples:]
fix 1 all ave/chunk 10000 1 10000 binchunk c_myCentro title1 "My output values"
fix 1 flow ave/chunk 100 10 1000 molchunk vx vz norm sample file vel.profile
fix 1 flow ave/chunk 100 5 1000 binchunk density/mass ave running
fix 1 flow ave/chunk 100 5 1000 binchunk density/mass ave running :pre
[NOTE:]
If you are trying to replace a deprecated fix ave/spatial command
with the newer, more flexible fix ave/chunk and "compute
chunk/atom"_compute_chunk_atom.html commands, you simply need to split
the fix ave/spatial arguments across the two new commands. For
example, this command:
fix 1 flow ave/spatial 100 10 1000 y 0.0 1.0 vx vz norm sample file vel.profile :pre
could be replaced by:
compute cc1 flow chunk/atom bin/1d y 0.0 1.0
fix 1 flow ave/chunk 100 10 1000 cc1 vx vz norm sample file vel.profile :pre
[Description:]
Use one or more per-atom vectors as inputs every few timesteps, sum
the values over the atoms in each chunk at each timestep, then average
the per-chunk values over longer timescales. The resulting chunk
averages can be used by other "output commands"_Howto_output.html such
as "thermo_style custom"_thermo_style.html, and can also be written to
a file.
In LAMMPS, chunks are collections of atoms defined by a "compute
chunk/atom"_compute_chunk_atom.html command, which assigns each atom
to a single chunk (or no chunk). The ID for this command is specified
as chunkID. For example, a single chunk could be the atoms in a
molecule or atoms in a spatial bin. See the "compute
chunk/atom"_compute_chunk_atom.html doc page and the "Howto
chunk"_Howto_chunk.html doc page for details of how chunks can be
defined and examples of how they can be used to measure properties of
a system.
Note that only atoms in the specified group contribute to the summing
and averaging calculations. The "compute
chunk/atom"_compute_chunk_atom.html command defines its own group as
well as an optional region. Atoms will have a chunk ID = 0, meaning
they belong to no chunk, if they are not in that group or region.
Thus you can specify the "all" group for this command if you simply
want to use the chunk definitions provided by chunkID.
Each specified per-atom value can be an atom attribute (position,
velocity, force component), a mass or number density, or the result of
a "compute"_compute.html or "fix"_fix.html or the evaluation of an
atom-style "variable"_variable.html. In the latter cases, the
compute, fix, or variable must produce a per-atom quantity, not a
global quantity. Note that the "compute
property/atom"_compute_property_atom.html command provides access to
any attribute defined and stored by atoms. If you wish to
time-average global quantities from a compute, fix, or variable, then
see the "fix ave/time"_fix_ave_time.html command.
The per-atom values of each input vector are summed and averaged
independently of the per-atom values in other input vectors.
"Computes"_compute.html that produce per-atom quantities are those
which have the word {atom} in their style name. See the doc pages for
individual "fixes"_fix.html to determine which ones produce per-atom
quantities. "Variables"_variable.html of style {atom} are the only
ones that can be used with this fix since all other styles of variable
produce global quantities.
Note that for values from a compute or fix, the bracketed index I can
be specified using a wildcard asterisk with the index to effectively
specify multiple values. This takes the form "*" or "*n" or "n*" or
"m*n". If N = the size of the vector (for {mode} = scalar) or the
number of columns in the array (for {mode} = vector), then an asterisk
with no numeric values means all indices from 1 to N. A leading
asterisk means all indices from 1 to n (inclusive). A trailing
asterisk means all indices from n to N (inclusive). A middle asterisk
means all indices from m to n (inclusive).
Using a wildcard is the same as if the individual columns of the array
had been listed one by one. E.g. these 2 fix ave/chunk commands are
equivalent, since the "compute
property/atom"_compute_property_atom.html command creates, in this
case, a per-atom array with 3 columns:
compute myAng all property/atom angmomx angmomy angmomz
fix 1 all ave/chunk 100 1 100 cc1 c_myAng\[*\] file tmp.angmom
fix 2 all ave/chunk 100 1 100 cc1 c_myAng\[1\] c_myAng\[2\] c_myAng\[3\] file tmp.angmom :pre
NOTE: This fix works by creating an array of size {Nchunk} by Nvalues
on each processor. {Nchunk} is the number of chunks which is defined
by the "compute chunk/atom"_compute_chunk_atom.html command.
Nvalues is the number of input values specified. Each processor loops
over its atoms, tallying its values to the appropriate chunk. Then
the entire array is summed across all processors. This means that
using a large number of chunks will incur an overhead in memory and
computational cost (summing across processors), so be careful to
define a reasonable number of chunks.
:line
The {Nevery}, {Nrepeat}, and {Nfreq} arguments specify on what
timesteps the input values will be accessed and contribute to the
average. The final averaged quantities are generated on timesteps
that are a multiples of {Nfreq}. The average is over {Nrepeat}
quantities, computed in the preceding portion of the simulation every
{Nevery} timesteps. {Nfreq} must be a multiple of {Nevery} and
{Nevery} must be non-zero even if {Nrepeat} is 1. Also, the timesteps
contributing to the average value cannot overlap, i.e. Nrepeat*Nevery
can not exceed Nfreq.
For example, if Nevery=2, Nrepeat=6, and Nfreq=100, then values on
timesteps 90,92,94,96,98,100 will be used to compute the final average
on timestep 100. Similarly for timesteps 190,192,194,196,198,200 on
timestep 200, etc. If Nrepeat=1 and Nfreq = 100, then no time
averaging is done; values are simply generated on timesteps
100,200,etc.
Each input value can also be averaged over the atoms in each chunk.
The way the averaging is done across the {Nrepeat} timesteps to
produce output on the {Nfreq} timesteps, and across multiple {Nfreq}
outputs, is determined by the {norm} and {ave} keyword settings, as
discussed below.
NOTE: To perform per-chunk averaging within a {Nfreq} time window, the
number of chunks {Nchunk} defined by the "compute
chunk/atom"_compute_chunk_atom.html command must remain constant. If
the {ave} keyword is set to {running} or {window} then {Nchunk} must
remain constant for the duration of the simulation. This fix forces
the chunk/atom compute specified by chunkID to hold {Nchunk} constant
for the appropriate time windows, by not allowing it to re-calculate
{Nchunk}, which can also affect how it assigns chunk IDs to atoms.
This is particularly important to understand if the chunks defined by
the "compute chunk/atom"_compute_chunk_atom.html command are spatial
bins. If its {units} keyword is set to {box} or {lattice}, then the
number of bins {Nchunk} and size of each bin will be fixed over the
{Nfreq} time window, which can affect which atoms are discarded if the
simulation box size changes. If its {units} keyword is set to
{reduced}, then the number of bins {Nchunk} will still be fixed, but
the size of each bin can vary at each timestep if the simulation box
size changes, e.g. for an NPT simulation.
:line
The atom attribute values (vx,vy,vz,fx,fy,fz) are self-explanatory.
As noted above, any other atom attributes can be used as input values
to this fix by using the "compute
property/atom"_compute_property_atom.html command and then specifying
an input value from that compute.
The {density/number} value means the number density is computed for
each chunk, i.e. number/volume. The {density/mass} value means the
mass density is computed for each chunk, i.e. total-mass/volume. The
output values are in units of 1/volume or density (mass/volume). See
the "units"_units.html command doc page for the definition of density
for each choice of units, e.g. gram/cm^3. If the chunks defined by
the "compute chunk/atom"_compute_chunk_atom.html command are spatial
bins, the volume is the bin volume. Otherwise it is the volume of the
entire simulation box.
The {temp} value means the temperature is computed for each chunk, by
the formula KE = DOF/2 k T, where KE = total kinetic energy of the
chunk of atoms (sum of 1/2 m v^2), DOF = the total number of degrees
of freedom for all atoms in the chunk, k = Boltzmann constant, and T =
temperature.
The DOF is calculated as N*adof + cdof, where N = number of atoms in
the chunk, adof = degrees of freedom per atom, and cdof = degrees of
freedom per chunk. By default adof = 2 or 3 = dimensionality of
system, as set via the "dimension"_dimension.html command, and cdof =
0.0. This gives the usual formula for temperature.
Note that currently this temperature only includes translational
degrees of freedom for each atom. No rotational degrees of freedom
are included for finite-size particles. Also no degrees of freedom
are subtracted for any velocity bias or constraints that are applied,
such as "compute temp/partial"_compute_temp_partial.html, or "fix
shake"_fix_shake.html or "fix rigid"_fix_rigid.html. This is because
those degrees of freedom (e.g. a constrained bond) could apply to sets
of atoms that are both included and excluded from a specific chunk,
and hence the concept is somewhat ill-defined. In some cases, you can
use the {adof} and {cdof} keywords to adjust the calculated degrees of
freedom appropriately, as explained below.
Also note that a bias can be subtracted from atom velocities before
they are used in the above formula for KE, by using the {bias}
keyword. This allows, for example, a thermal temperature to be
computed after removal of a flow velocity profile.
Note that the per-chunk temperature calculated by this fix and the
"compute temp/chunk"_compute_temp_chunk.html command can be different.
The compute calculates the temperature for each chunk for a single
snapshot. This fix can do that but can also time average those values
over many snapshots, or it can compute a temperature as if the atoms
in the chunk on different timesteps were collected together as one set
of atoms to calculate their temperature. The compute allows the
center-of-mass velocity of each chunk to be subtracted before
calculating the temperature; this fix does not.
If a value begins with "c_", a compute ID must follow which has been
previously defined in the input script. If no bracketed integer is
appended, the per-atom vector calculated by the compute is used. If a
bracketed integer is appended, the Ith column of the per-atom array
calculated by the compute is used. Users can also write code for
their own compute styles and "add them to LAMMPS"_Modify.html.
See the discussion above for how I can be specified with a wildcard
asterisk to effectively specify multiple values.
If a value begins with "f_", a fix ID must follow which has been
previously defined in the input script. If no bracketed integer is
appended, the per-atom vector calculated by the fix is used. If a
bracketed integer is appended, the Ith column of the per-atom array
calculated by the fix is used. Note that some fixes only produce
their values on certain timesteps, which must be compatible with
{Nevery}, else an error results. Users can also write code for their
own fix styles and "add them to LAMMPS"_Modify.html. See the
discussion above for how I can be specified with a wildcard asterisk
to effectively specify multiple values.
If a value begins with "v_", a variable name must follow which has
been previously defined in the input script. Variables of style
{atom} can reference thermodynamic keywords and various per-atom
attributes, or invoke other computes, fixes, or variables when they
are evaluated, so this is a very general means of generating per-atom
quantities to average within chunks.
:line
Additional optional keywords also affect the operation of this fix
and its outputs.
The {norm} keyword affects how averaging is done for the per-chunk
values that are output every {Nfreq} timesteps.
It the {norm} setting is {all}, which is the default, a chunk value is
summed over all atoms in all {Nrepeat} samples, as is the count of
atoms in the chunk. The averaged output value for the chunk on the
{Nfreq} timesteps is Total-sum / Total-count. In other words it is an
average over atoms across the entire {Nfreq} timescale. For the
{density/number} and {density/mass} values, the volume (bin volume or
system volume) used in the final normalization will be the volume at
the final {Nfreq} timestep.
If the {norm} setting is {sample}, the chunk value is summed over
atoms for each sample, as is the count, and an "average sample value"
is computed for each sample, i.e. Sample-sum / Sample-count. The
output value for the chunk on the {Nfreq} timesteps is the average of
the {Nrepeat} "average sample values", i.e. the sum of {Nrepeat}
"average sample values" divided by {Nrepeat}. In other words it is an
average of an average. For the {density/number} and {density/mass}
values, the volume (bin volume or system volume) used in the
per-sample normalization will be the current volume at each sampling
step.
If the {norm} setting is {none}, a similar computation as for the
{sample} setting is done, except the individual "average sample
values" are "summed sample values". A summed sample value is simply
the chunk value summed over atoms in the sample, without dividing by
the number of atoms in the sample. The output value for the chunk on
the {Nfreq} timesteps is the average of the {Nrepeat} "summed sample
values", i.e. the sum of {Nrepeat} "summed sample values" divided by
{Nrepeat}. For the {density/number} and {density/mass} values, the
volume (bin volume or system volume) used in the per-sample sum
normalization will be the current volume at each sampling step.
The {ave} keyword determines how the per-chunk values produced every
{Nfreq} steps are averaged with values produced on previous steps that
were multiples of {Nfreq}, before they are accessed by another output
command or written to a file.
If the {ave} setting is {one}, which is the default, then the chunk
values produced on timesteps that are multiples of {Nfreq} are
independent of each other; they are output as-is without further
averaging.
If the {ave} setting is {running}, then the chunk values produced on
timesteps that are multiples of {Nfreq} are summed and averaged in a
cumulative sense before being output. Each output chunk value is thus
the average of the chunk value produced on that timestep with all
preceding values for the same chunk. This running average begins when
the fix is defined; it can only be restarted by deleting the fix via
the "unfix"_unfix.html command, or re-defining the fix by
re-specifying it.
If the {ave} setting is {window}, then the chunk values produced on
timesteps that are multiples of {Nfreq} are summed and averaged within
a moving "window" of time, so that the last M values for the same
chunk are used to produce the output. E.g. if M = 3 and Nfreq = 1000,
then the output on step 10000 will be the average of the individual
chunk values on steps 8000,9000,10000. Outputs on early steps will
average over less than M values if they are not available.
The {bias} keyword specifies the ID of a temperature compute that
removes a "bias" velocity from each atom, specified as {bias-ID}. It
is only used when the {temp} value is calculated, to compute the
thermal temperature of each chunk after the translational kinetic
energy components have been altered in a prescribed way, e.g. to
remove a flow velocity profile. See the doc pages for individual
computes that calculate a temperature to see which ones implement a
bias.
The {adof} and {cdof} keywords define the values used in the degree of
freedom (DOF) formula described above for temperature calculation
for each chunk. They are only used when the {temp} value is
calculated. They can be used to calculate a more appropriate
temperature for some kinds of chunks. Here are 3 examples:
If spatially binned chunks contain some number of water molecules and
"fix shake"_fix_shake.html is used to make each molecule rigid, then
you could calculate a temperature with 6 degrees of freedom (DOF) (3
translational, 3 rotational) per molecule by setting {adof} to 2.0.
If "compute temp/partial"_compute_temp_partial.html is used with the
{bias} keyword to only allow the x component of velocity to contribute
to the temperature, then {adof} = 1.0 would be appropriate.
If each chunk consists of a large molecule, with some number of its
bonds constrained by "fix shake"_fix_shake.html or the entire molecule
by "fix rigid/small"_fix_rigid.html, {adof} = 0.0 and {cdof} could be
set to the remaining degrees of freedom for the entire molecule
(entire chunk in this case), e.g. 6 for 3d, or 3 for 2d, for a rigid
molecule.
The {file} keyword allows a filename to be specified. Every {Nfreq}
timesteps, a section of chunk info will be written to a text file in
the following format. A line with the timestep and number of chunks
is written. Then one line per chunk is written, containing the chunk
ID (1-Nchunk), an optional original ID value, optional coordinate
values for chunks that represent spatial bins, the number of atoms in
the chunk, and one or more calculated values. More explanation of the
optional values is given below. The number of values in each line
corresponds to the number of values specified in the fix ave/chunk
command. The number of atoms and the value(s) are summed or average
quantities, as explained above.
The {overwrite} keyword will continuously overwrite the output file
with the latest output, so that it only contains one timestep worth of
output. This option can only be used with the {ave running} setting.
The {format} keyword sets the numeric format of each value when it is
printed to a file via the {file} keyword. Note that all values are
floating point quantities. The default format is %g. You can specify
a higher precision if desired, e.g. %20.16g.
The {title1} and {title2} and {title3} keywords allow specification of
the strings that will be printed as the first 3 lines of the output
file, assuming the {file} keyword was used. LAMMPS uses default
values for each of these, so they do not need to be specified.
By default, these header lines are as follows:
# Chunk-averaged data for fix ID and group name
# Timestep Number-of-chunks
# Chunk (OrigID) (Coord1) (Coord2) (Coord3) Ncount value1 value2 ... :pre
In the first line, ID and name are replaced with the fix-ID and group
name. The second line describes the two values that are printed at
the first of each section of output. In the third line the values are
replaced with the appropriate value names, e.g. fx or c_myCompute[2].
The words in parenthesis only appear with corresponding columns if the
chunk style specified for the "compute
chunk/atom"_compute_chunk_atom.html command supports them. The OrigID
column is only used if the {compress} keyword was set to {yes} for the
"compute chunk/atom"_compute_chunk_atom.html command. This means that
the original chunk IDs (e.g. molecule IDs) will have been compressed
to remove chunk IDs with no atoms assigned to them. Thus a compressed
chunk ID of 3 may correspond to an original chunk ID or molecule ID of
415. The OrigID column will list 415 for the 3rd chunk.
The CoordN columns only appear if a {binning} style was used in the
"compute chunk/atom"_compute_chunk_atom.html command. For {bin/1d},
{bin/2d}, and {bin/3d} styles the column values are the center point
of the bin in the corresponding dimension. Just Coord1 is used for
{bin/1d}, Coord2 is added for {bin/2d}, Coord3 is added for {bin/3d}.
For {bin/sphere}, just Coord1 is used, and it is the radial
coordinate. For {bin/cylinder}, Coord1 and Coord2 are used. Coord1
is the radial coordinate (away from the cylinder axis), and coord2 is
the coordinate along the cylinder axis.
Note that if the value of the {units} keyword used in the "compute
chunk/atom command"_compute_chunk_atom.html is {box} or {lattice}, the
coordinate values will be in distance "units"_units.html. If the
value of the {units} keyword is {reduced}, the coordinate values will
be in unitless reduced units (0-1). This is not true for the Coord1 value
of style {bin/sphere} or {bin/cylinder} which both represent radial
dimensions. Those values are always in distance "units"_units.html.
:line
[Restart, fix_modify, output, run start/stop, minimize info:]
No information about this fix is written to "binary restart
files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to this fix.
This fix computes a global array of values which can be accessed by
various "output commands"_Howto_output.html. The values can only be
accessed on timesteps that are multiples of {Nfreq} since that is when
averaging is performed. The global array has # of rows = the number
of chunks {Nchunk} as calculated by the specified "compute
chunk/atom"_compute_chunk_atom.html command. The # of columns =
M+1+Nvalues, where M = 1 to 4, depending on whether the optional
columns for OrigID and CoordN are used, as explained above. Following
the optional columns, the next column contains the count of atoms in
the chunk, and the remaining columns are the Nvalue quantities. When
the array is accessed with a row I that exceeds the current number of
chunks, than a 0.0 is returned by the fix instead of an error, since
the number of chunks can vary as a simulation runs depending on how
that value is computed by the compute chunk/atom command.
The array values calculated by this fix are treated as "intensive",
since they are typically already normalized by the count of atoms in
each chunk.
No parameter of this fix can be used with the {start/stop} keywords of
the "run"_run.html command. This fix is not invoked during "energy
minimization"_minimize.html.
[Restrictions:] none
[Related commands:]
"compute"_compute.html, "fix ave/atom"_fix_ave_atom.html, "fix
ave/histo"_fix_ave_histo.html, "fix ave/time"_fix_ave_time.html,
"variable"_variable.html, "fix ave/correlate"_fix_ave_correlate.html
[Default:]
The option defaults are norm = all, ave = one, bias = none, no file output, and
title 1,2,3 = strings as described above.

474
doc/txt/fix_bond_react.txt
View File

@ -1,474 +0,0 @@
"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
fix bond/react command :h3
[Syntax:]
fix ID group-ID bond/react common_keyword values ...
react react-ID react-group-ID Nevery Rmin Rmax template-ID(pre-reacted) template-ID(post-reacted) map_file individual_keyword values ...
react react-ID react-group-ID Nevery Rmin Rmax template-ID(pre-reacted) template-ID(post-reacted) map_file individual_keyword values ...
react react-ID react-group-ID Nevery Rmin Rmax template-ID(pre-reacted) template-ID(post-reacted) map_file individual_keyword values ...
... :pre
ID, group-ID are documented in "fix"_fix.html command. Group-ID is ignored. :ulb,l
bond/react = style name of this fix command :l
the common keyword/values may be appended directly after 'bond/react' :l
this applies to all reaction specifications (below) :l
common_keyword = {stabilization} :l
{stabilization} values = {no} or {yes} {group-ID} {xmax}
{no} = no reaction site stabilization
{yes} = perform reaction site stabilization
{group-ID} = user-assigned prefix for the dynamic group of atoms not currently involved in a reaction
{xmax} = xmax value that is used by an internally-created "nve/limit"_fix_nve_limit.html integrator :pre
react = mandatory argument indicating new reaction specification :l
react-ID = user-assigned name for the reaction :l
react-group-ID = only atoms in this group are considered for the reaction :l
Nevery = attempt reaction every this many steps :l
Rmin = bonding pair atoms must be separated by more than Rmin to initiate reaction (distance units) :l
Rmax = bonding pair atoms must be separated by less than Rmax to initiate reaction (distance units) :l
template-ID(pre-reacted) = ID of a molecule template containing pre-reaction topology :l
template-ID(post-reacted) = ID of a molecule template containing post-reaction topology :l
map_file = name of file specifying corresponding atom-IDs in the pre- and post-reacted templates :l
zero or more individual keyword/value pairs may be appended to each react argument :l
individual_keyword = {prob} or {max_rxn} or {stabilize_steps} or {update_edges} :l
{prob} values = fraction seed
fraction = initiate reaction with this probability if otherwise eligible
seed = random number seed (positive integer)
{max_rxn} value = N
N = maximum number of reactions allowed to occur
{stabilize_steps} value = timesteps
timesteps = number of timesteps to apply the internally-created "nve/limit"_fix_nve_limit.html fix to reacting atoms
{update_edges} value = {none} or {charges} or {custom}
none = do not update topology near the edges of reaction templates
charges = update atomic charges of all atoms in reaction templates
custom = force the update of user-specified atomic charges :pre
:ule
[Examples:]
For unabridged example scripts and files, see examples/USER/misc/bond_react.
molecule mol1 pre_reacted_topology.txt
molecule mol2 post_reacted_topology.txt
fix 5 all bond/react react myrxn1 all 1 0 3.25 mol1 mol2 map_file.txt :pre
molecule mol1 pre_reacted_rxn1.txt
molecule mol2 post_reacted_rxn1.txt
molecule mol3 pre_reacted_rxn2.txt
molecule mol4 post_reacted_rxn2.txt
fix 5 all bond/react stabilization yes nvt_grp .03 &
react myrxn1 all 1 0 3.25 mol1 mol2 map_file_rxn1.txt prob 0.50 12345 &
react myrxn2 all 1 0 2.75 mol3 mol4 map_file_rxn2.txt prob 0.25 12345
fix 6 nvt_grp_REACT nvt temp 300 300 100 # set thermostat after bond/react :pre
[Description:]
Initiate complex covalent bonding (topology) changes. These topology
changes will be referred to as 'reactions' throughout this
documentation. Topology changes are defined in pre- and post-reaction
molecule templates and can include creation and deletion of bonds,
angles, dihedrals, impropers, bond types, angle types, dihedral types,
atom types, or atomic charges. In addition, reaction by-products or
other molecules can be identified and deleted.
Fix bond/react does not use quantum mechanical (eg. fix qmmm) or
pairwise bond-order potential (eg. Tersoff or AIREBO) methods to
determine bonding changes a priori. Rather, it uses a distance-based
probabilistic criteria to effect predetermined topology changes in
simulations using standard force fields.
This fix was created to facilitate the dynamic creation of polymeric,
amorphous or highly cross-linked systems. A suggested workflow for
using this fix is: 1) identify a reaction to be simulated 2) build a
molecule template of the reaction site before the reaction has
occurred 3) build a molecule template of the reaction site after the
reaction has occurred 4) create a map that relates the
template-atom-IDs of each atom between pre- and post-reaction molecule
templates 5) fill a simulation box with molecules and run a simulation
with fix bond/react.
Only one 'fix bond/react' command can be used at a time. Multiple
reactions can be simultaneously applied by specifying multiple {react}
arguments to a single 'fix bond/react' command. This syntax is
necessary because the 'common keywords' are applied to all reactions.
The {stabilization} keyword enables reaction site stabilization.
Reaction site stabilization is performed by including reacting atoms
in an internally-created fix "nve/limit"_fix_nve_limit.html time
integrator for a set number of timesteps given by the
{stabilize_steps} keyword. While reacting atoms are being time
integrated by the internal nve/limit, they are prevented from being
involved in any new reactions. The {xmax} value keyword should
typically be set to the maximum distance that non-reacting atoms move
during the simulation.
Fix bond/react creates and maintains two important dynamic groups of
atoms when using the {stabilization} keyword. The first group contains
all atoms currently involved in a reaction; this group is
automatically thermostatted by an internally-created
"nve/limit"_fix_nve_limit.html integrator. The second group contains
all atoms currently not involved in a reaction. This group should be
used by a thermostat in order to time integrate the system. The name
of this group of non-reacting atoms is created by appending '_REACT'
to the group-ID argument of the {stabilization} keyword, as shown in
the second example above.
NOTE: When using reaction stabilization, you should generally not have
a separate thermostat which acts on the 'all' group.
The group-ID set using the {stabilization} keyword can be an existing
static group or a previously-unused group-ID. It cannot be specified
as 'all'. If the group-ID is previously unused, the fix bond/react
command creates a "dynamic group"_group.html that is initialized to
include all atoms. If the group-ID is that of an existing static
group, the group is used as the parent group of new,
internally-created dynamic group. In both cases, this new dynamic
group is named by appending '_REACT' to the group-ID, e.g.
nvt_grp_REACT. By specifying an existing group, you may thermostat
constant-topology parts of your system separately. The dynamic group
contains only atoms not involved in a reaction at a given timestep,
and therefore should be used by a subsequent system-wide time
integrator such as nvt, npt, or nve, as shown in the second example
above (full examples can be found at examples/USER/misc/bond_react).
The time integration command should be placed after the fix bond/react
command due to the internal dynamic grouping performed by fix
bond/react.
NOTE: If the group-ID is an existing static group, react-group-IDs
should also be specified as this static group, or a subset.
The following comments pertain to each {react} argument (in other
words, can be customized for each reaction, or reaction step):
A check for possible new reaction sites is performed every {Nevery}
timesteps.
Three physical conditions must be met for a reaction to occur. First,
a bonding atom pair must be identified within the reaction distance
cutoffs. Second, the topology surrounding the bonding atom pair must
match the topology of the pre-reaction template. Finally, any reaction
constraints listed in the map file (see below) must be satisfied. If
all of these conditions are met, the reaction site is eligible to be
modified to match the post-reaction template.
A bonding atom pair will be identified if several conditions are met.
First, a pair of atoms I,J within the specified react-group-ID of type
itype and jtype must be separated by a distance between {Rmin} and
{Rmax}. It is possible that multiple bonding atom pairs are
identified: if the bonding atoms in the pre-reacted template are 1-2
neighbors, i.e. directly bonded, the farthest bonding atom partner is
set as its bonding partner; otherwise, the closest potential partner
is chosen. Then, if both an atom I and atom J have each other as their
bonding partners, these two atoms are identified as the bonding atom
pair of the reaction site. Once this unique bonding atom pair is
identified for each reaction, there could two or more reactions that
involve a given atom on the same timestep. If this is the case, only
one such reaction is permitted to occur. This reaction is chosen
randomly from all potential reactions. This capability allows e.g. for
different reaction pathways to proceed from identical reaction sites
with user-specified probabilities.
The pre-reacted molecule template is specified by a molecule command.
This molecule template file contains a sample reaction site and its
surrounding topology. As described below, the bonding atom pairs of
the pre-reacted template are specified by atom ID in the map file. The
pre-reacted molecule template should contain as few atoms as possible
while still completely describing the topology of all atoms affected
by the reaction. For example, if the force field contains dihedrals,
the pre-reacted template should contain any atom within three bonds of
reacting atoms.
Some atoms in the pre-reacted template that are not reacting may have
missing topology with respect to the simulation. For example, the
pre-reacted template may contain an atom that, in the simulation, is
currently connected to the rest of a long polymer chain. These are
referred to as edge atoms, and are also specified in the map file. All
pre-reaction template atoms should be linked to a bonding atom, via at
least one path that does not involve edge atoms. When the pre-reaction
template contains edge atoms, not all atoms, bonds, charges, etc.
specified in the reaction templates will be updated. Specifically,
topology that involves only atoms that are 'too near' to template
edges will not be updated. The definition of 'too near the edge'
depends on which interactions are defined in the simulation. If the
simulation has defined dihedrals, atoms within two bonds of edge atoms
are considered 'too near the edge.' If the simulation defines angles,
but not dihedrals, atoms within one bond of edge atoms are considered
'too near the edge.' If just bonds are defined, only edge atoms are
considered 'too near the edge.'
NOTE: Small molecules, i.e. ones that have all their atoms contained
within the reaction templates, never have edge atoms.
Note that some care must be taken when a building a molecule template
for a given simulation. All atom types in the pre-reacted template
must be the same as those of a potential reaction site in the
simulation. A detailed discussion of matching molecule template atom
types with the simulation is provided on the "molecule"_molecule.html
command page.
The post-reacted molecule template contains a sample of the reaction
site and its surrounding topology after the reaction has occurred. It
must contain the same number of atoms as the pre-reacted template. A
one-to-one correspondence between the atom IDs in the pre- and
post-reacted templates is specified in the map file as described
below. Note that during a reaction, an atom, bond, etc. type may
change to one that was previously not present in the simulation. These
new types must also be defined during the setup of a given simulation.
A discussion of correctly handling this is also provided on the
"molecule"_molecule.html command page.
NOTE: When a reaction occurs, it is possible that the resulting
topology/atom (e.g. special bonds, dihedrals, etc.) exceeds that of
the existing system and reaction templates. As when inserting
molecules, enough space for this increased topology/atom must be
reserved by using the relevant "extra" keywords to the
"read_data"_read_data.html or "create_box"_create_box.html commands.
The map file is a text document with the following format:
A map file has a header and a body. The header of map file the
contains one mandatory keyword and four optional keywords. The
mandatory keyword is 'equivalences':
N {equivalences} = # of atoms N in the reaction molecule templates :pre
The optional keywords are 'edgeIDs', 'deleteIDs', 'customIDs' and
'constraints':
N {edgeIDs} = # of edge atoms N in the pre-reacted molecule template
N {deleteIDs} = # of atoms N that are specified for deletion
N {customIDs} = # of atoms N that are specified for a custom update
N {constraints} = # of specified reaction constraints N :pre
The body of the map file contains two mandatory sections and four
optional sections. The first mandatory section begins with the keyword
'BondingIDs' and lists the atom IDs of the bonding atom pair in the
pre-reacted molecule template. The second mandatory section begins
with the keyword 'Equivalences' and lists a one-to-one correspondence
between atom IDs of the pre- and post-reacted templates. The first
column is an atom ID of the pre-reacted molecule template, and the
second column is the corresponding atom ID of the post-reacted
molecule template. The first optional section begins with the keyword
'EdgeIDs' and lists the atom IDs of edge atoms in the pre-reacted
molecule template. The second optional section begins with the keyword
'DeleteIDs' and lists the atom IDs of pre-reaction template atoms to
delete. The third optional section begins with the keyword 'Custom
Edges' and allows for forcing the update of a specific atom's atomic
charge. The first column is the ID of an atom near the edge of the
pre-reacted molecule template, and the value of the second column is
either 'none' or 'charges.' Further details are provided in the
discussion of the 'update_edges' keyword. The fourth optional section
begins with the keyword 'Constraints' and lists additional criteria
that must be satisfied in order for the reaction to occur. Currently,
there are three types of constraints available, as discussed below.
A sample map file is given below:
:line
# this is a map file :pre
7 equivalences
2 edgeIDs :pre
BondingIDs :pre
3
5 :pre
EdgeIDs :pre
1
7 :pre
Equivalences :pre
1 1
2 2
3 3
4 4
5 5
6 6
7 7 :pre
:line
Any number of additional constraints may be specified in the
Constraints section of the map file. The constraint of type 'distance'
has syntax as follows:
distance {ID1} {ID2} {rmin} {rmax} :pre
where 'distance' is the required keyword, {ID1} and {ID2} are
pre-reaction atom IDs, and these two atoms must be separated by a
distance between {rmin} and {rmax} for the reaction to occur.
The constraint of type 'angle' has the following syntax:
angle {ID1} {ID2} {ID3} {amin} {amax} :pre
where 'angle' is the required keyword, {ID1}, {ID2} and {ID3} are
pre-reaction atom IDs, and these three atoms must form an angle
between {amin} and {amax} for the reaction to occur (where {ID2} is
the central atom). Angles must be specified in degrees. This
constraint can be used to enforce a certain orientation between
reacting molecules.
The constraint of type 'arrhenius' imposes an additional reaction
probability according to the temperature-dependent Arrhenius equation:
:c,image(Eqs/fix_bond_react.jpg)
The Arrhenius constraint has the following syntax:
arrhenius {A} {n} {E_a} {seed} :pre
where 'arrhenius' is the required keyword, {A} is the pre-exponential
factor, {n} is the exponent of the temperature dependence, {E_a} is
the activation energy ("units"_units.html of energy), and {seed} is a
random number seed. The temperature is defined as the instantaneous
temperature averaged over all atoms in the reaction site, and is
calculated in the same manner as for example
"compute_temp_chunk"_compute_temp_chunk.html. Currently, there are no
options for additional temperature averaging or velocity-biased
temperature calculations. A uniform random number between 0 and 1 is
generated using {seed}; if this number is less than the result of the
Arrhenius equation above, the reaction is permitted to occur.
Once a reaction site has been successfully identified, data structures
within LAMMPS that store bond topology are updated to reflect the
post-reacted molecule template. All force fields with fixed bonds,
angles, dihedrals or impropers are supported.
A few capabilities to note: 1) You may specify as many {react}
arguments as desired. For example, you could break down a complicated
reaction mechanism into several reaction steps, each defined by its
own {react} argument. 2) While typically a bond is formed or removed
between the bonding atom pairs specified in the pre-reacted molecule
template, this is not required. 3) By reversing the order of the pre-
and post- reacted molecule templates in another {react} argument, you
can allow for the possibility of one or more reverse reactions.
The optional keywords deal with the probability of a given reaction
occurring as well as the stable equilibration of each reaction site as
it occurs:
The {prob} keyword can affect whether or not an eligible reaction
actually occurs. The fraction setting must be a value between 0.0 and
1.0. A uniform random number between 0.0 and 1.0 is generated and the
eligible reaction only occurs if the random number is less than the
fraction. Up to N reactions are permitted to occur, as optionally
specified by the {max_rxn} keyword.
The {stabilize_steps} keyword allows for the specification of how many
timesteps a reaction site is stabilized before being returned to the
overall system thermostat. In order to produce the most physical
behavior, this 'reaction site equilibration time' should be tuned to
be as small as possible while retaining stability for a given system
or reaction step. After a limited number of case studies, this number
has been set to a default of 60 timesteps. Ideally, it should be
individually tuned for each fix reaction step. Note that in some
situations, decreasing rather than increasing this parameter will
result in an increase in stability.
The {update_edges} keyword can increase the number of atoms whose
atomic charges are updated, when the pre-reaction template contains
edge atoms. When the value is set to 'charges,' all atoms' atomic
charges are updated to those specified by the post-reaction template,
including atoms near the edge of reaction templates. When the value is
set to 'custom,' an additional section must be included in the map
file that specifies whether or not to update charges, on a per-atom
basis. The format of this section is detailed above. Listing a
pre-reaction atom ID with a value of 'charges' will force the update
of the atom's charge, even if it is near a template edge. Atoms not
near a template edge are unaffected by this setting.
A few other considerations:
Many reactions result in one or more atoms that are considered
unwanted by-products. Therefore, bond/react provides the option to
delete a user-specified set of atoms. These pre-reaction atoms are
identified in the map file. A deleted atom must still be included in
the post-reaction molecule template, in which it cannot be bonded to
an atom that is not deleted. In addition to deleting unwanted reaction
by-products, this feature can be used to remove specific topologies,
such as small rings, that may be otherwise indistinguishable.
Optionally, you can enforce additional behaviors on reacting atoms.
For example, it may be beneficial to force reacting atoms to remain at
a certain temperature. For this, you can use the internally-created
dynamic group named "bond_react_MASTER_group", which consists of all
atoms currently involved in a reaction. For example, adding the
following command would add an additional thermostat to the group of
all currently-reacting atoms:
fix 1 bond_react_MASTER_group temp/rescale 1 300 300 10 1 :pre
NOTE: This command must be added after the fix bond/react command, and
will apply to all reactions.
Computationally, each timestep this fix operates, it loops over
neighbor lists (for bond-forming reactions) and computes distances
between pairs of atoms in the list. It also communicates between
neighboring processors to coordinate which bonds are created and/or
removed. All of these operations increase the cost of a timestep. Thus
you should be cautious about invoking this fix too frequently.
You can dump out snapshots of the current bond topology via the dump
local command.
:line
[Restart, fix_modify, output, run start/stop, minimize info:]
Cumulative reaction counts for each reaction are written to "binary
restart files"_restart.html. These values are associated with the
reaction name (react-ID). Additionally, internally-created per-atom
properties are stored to allow for smooth restarts. None of the
"fix_modify"_fix_modify.html options are relevant to this fix.
This fix computes one statistic for each {react} argument that it
stores in a global vector, of length 'number of react arguments', that
can be accessed by various "output commands"_Howto_output.html. The
vector values calculated by this fix are "intensive".
These is 1 quantity for each react argument:
(1) cumulative # of reactions occurred :ul
No parameter of this fix can be used with the {start/stop} keywords
of the "run"_run.html command. This fix is not invoked during "energy
minimization"_minimize.html.
When fix bond/react is 'unfixed,' all internally-created groups are
deleted. Therefore, fix bond/react can only be unfixed after unfixing
all other fixes that use any group created by fix bond/react.
[Restrictions:]
This fix is part of the USER-MISC package. It is only enabled if
LAMMPS was built with that package. See the
"Build package"_Build_package.html doc page for more info.
[Related commands:]
"fix bond/create"_fix_bond_create.html,
"fix bond/break"_fix_bond_break.html,
"fix bond/swap"_fix_bond_swap.html,
"dump local"_dump.html, "special_bonds"_special_bonds.html
[Default:]
The option defaults are stabilization = no, prob = 1.0, stabilize_steps = 60,
update_edges = none
:line
:link(Gissinger)
[(Gissinger)] Gissinger, Jensen and Wise, Polymer, 128, 211 (2017).

106
doc/txt/fix_client_md.txt
View File

@ -1,106 +0,0 @@
"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
fix client/md command :h3
[Syntax:]
fix ID group-ID client/md :pre
ID, group-ID are documented in "fix"_fix.html command
client/md = style name of this fix command :ul
[Examples:]
fix 1 all client/md :pre
[Description:]
This fix style enables LAMMPS to run as a "client" code and
communicate each timestep with a separate "server" code to perform an
MD simulation together.
The "Howto client/server"_Howto_client_server.html doc page gives an
overview of client/server coupling of LAMMPS with another code 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.
When using this fix, LAMMPS (as the client code) passes the current
coordinates of all particles to the server code each timestep, which
computes their interaction, and returns the energy, forces, and virial
for the interacting particles to LAMMPS, so it can complete the
timestep.
The server code could be a quantum code, or another classical MD code
which encodes a force field (pair_style in LAMMPS lingo) which LAMMPS
does not have. In the quantum case, this fix is a mechanism for
running {ab initio} MD with quantum forces.
The group associated with this fix is ignored.
The protocol and "units"_units.html for message format and content
that LAMMPS exchanges with the server code is defined on the "server
md"_server_md.html doc page.
Note that when using LAMMPS as an MD client, your LAMMPS input script
should not normally contain force field commands, like a
"pair_style"_pair_style.html, "bond_style"_bond_style.html, or
"kspace_style"_kspace_style.html command. However it is possible for
a server code to only compute a portion of the full force-field, while
LAMMPS computes the remaining part. Your LAMMPS script can also
specify boundary conditions or force constraints in the usual way,
which will be added to the per-atom forces returned by the server
code.
See the examples/message dir for example scripts where LAMMPS is both
the "client" and/or "server" code for this kind of client/server MD
simulation. The examples/message/README file explains how to launch
LAMMPS and another code in tandem to perform a coupled simulation.
:line
[Restart, fix_modify, output, run start/stop, minimize info:]
No information about this fix is written to "binary restart
files"_restart.html.
The "fix_modify"_fix_modify.html {energy} option is supported by this
fix to add the potential energy computed by the server application to
the system's potential energy as part of "thermodynamic
output"_thermo_style.html.
The "fix_modify"_fix_modify.html {virial} option is supported by this
fix to add the server application's contribution to the system's
virial as part of "thermodynamic output"_thermo_style.html. The
default is {virial yes}
This fix computes a global scalar which can be accessed by various
"output commands"_Howto_output.html. The scalar is the potential
energy discussed above. The scalar value calculated by this fix is
"extensive".
No parameter of this fix can be used with the {start/stop} keywords of
the "run"_run.html command. This fix is not invoked during "energy
minimization"_minimize.html.
[Restrictions:]
This fix is part of the MESSAGE package. It is only enabled if LAMMPS
was built with that package. See the "Build
package"_Build_package.html doc page for more info.
A script that uses this command must also use the
"message"_message.html command to setup the messaging protocol with
the other server code.
[Related commands:]
"message"_message.html, "server"_server.html
[Default:] none

295
doc/txt/fix_deposit.txt
View File

@ -1,295 +0,0 @@
"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
fix deposit command :h3
[Syntax:]
fix ID group-ID deposit N type M seed keyword values ... :pre
ID, group-ID are documented in "fix"_fix.html command :ulb,l
deposit = style name of this fix command :l
N = # of atoms or molecules to insert :l
type = atom type to assign to inserted atoms (offset for molecule insertion) :l
M = insert a single atom or molecule every M steps :l
seed = random # seed (positive integer) :l
one or more keyword/value pairs may be appended to args :l
keyword = {region} or {id} or {global} or {local} or {near} or {gaussian} or {attempt} or {rate} or {vx} or {vy} or {vz} or {mol} or {rigid} or {shake} or {units} :l
{region} value = region-ID
region-ID = ID of region to use as insertion volume
{id} value = {max} or {next}
max = atom ID for new atom(s) is max ID of all current atoms plus one
next = atom ID for new atom(s) increments by one for every deposition
{global} values = lo hi
lo,hi = put new atom/molecule a distance lo-hi above all other atoms (distance units)
{local} values = lo hi delta
lo,hi = put new atom/molecule a distance lo-hi above any nearby atom beneath it (distance units)
delta = lateral distance within which a neighbor is considered "nearby" (distance units)
{near} value = R
R = only insert atom/molecule if further than R from existing particles (distance units)
{gaussian} values = xmid ymid zmid sigma
xmid,ymid,zmid = center of the gaussian distribution (distance units)
sigma = width of gaussian distribution (distance units)
{attempt} value = Q
Q = attempt a single insertion up to Q times
{rate} value = V
V = z velocity (y in 2d) at which insertion volume moves (velocity units)
{vx} values = vxlo vxhi
vxlo,vxhi = range of x velocities for inserted atom/molecule (velocity units)
{vy} values = vylo vyhi
vylo,vyhi = range of y velocities for inserted atom/molecule (velocity units)
{vz} values = vzlo vzhi
vzlo,vzhi = range of z velocities for inserted atom/molecule (velocity units)
{target} values = tx ty tz
tx,ty,tz = location of target point (distance units)
{mol} value = template-ID
template-ID = ID of molecule template specified in a separate "molecule"_molecule.html command
{molfrac} values = f1 f2 ... fN
f1 to fN = relative probability of creating each of N molecules in template-ID
{rigid} value = fix-ID
fix-ID = ID of "fix rigid/small"_fix_rigid.html command
{shake} value = fix-ID
fix-ID = ID of "fix shake"_fix_shake.html command
{units} value = {lattice} or {box}
lattice = the geometry is defined in lattice units
box = the geometry is defined in simulation box units :pre
:ule
[Examples:]
fix 3 all deposit 1000 2 100 29494 region myblock local 1.0 1.0 1.0 units box
fix 2 newatoms deposit 10000 1 500 12345 region disk near 2.0 vz -1.0 -0.8
fix 4 sputter deposit 1000 2 500 12235 region sphere vz -1.0 -1.0 target 5.0 5.0 0.0 units lattice
fix 5 insert deposit 200 2 100 777 region disk gaussian 5.0 5.0 9.0 1.0 units box :pre
[Description:]
Insert a single atom or molecule into the simulation domain every M
timesteps until N atoms or molecules have been inserted. This is
useful for simulating deposition onto a surface. For the remainder of
this doc page, a single inserted atom or molecule is referred to as a
"particle".
If inserted particles are individual atoms, they are assigned the
specified atom type. If they are molecules, the type of each atom in
the inserted molecule is specified in the file read by the
"molecule"_molecule.html command, and those values are added to the
specified atom type. E.g. if the file specifies atom types 1,2,3, and
those are the atom types you want for inserted molecules, then specify
{type} = 0. If you specify {type} = 2, the in the inserted molecule
will have atom types 3,4,5.
All atoms in the inserted particle are assigned to two groups: the
default group "all" and the group specified in the fix deposit command
(which can also be "all").
If you are computing temperature values which include inserted
particles, you will want to use the
"compute_modify"_compute_modify.html dynamic option, which insures the
current number of atoms is used as a normalizing factor each time the
temperature is computed.
Care must be taken that inserted particles are not too near existing
atoms, using the options described below. When inserting particles
above a surface in a non-periodic box (see the
"boundary"_boundary.html command), the possibility of a particle
escaping the surface and flying upward should be considered, since the
particle may be lost or the box size may grow infinitely large. A
"fix wall/reflect"_fix_wall_reflect.html command can be used to
prevent this behavior. Note that if a shrink-wrap boundary is used,
it is OK to insert the new particle outside the box, however the box
will immediately be expanded to include the new particle. When
simulating a sputtering experiment it is probably more realistic to
ignore those atoms using the "thermo_modify"_thermo_modify.html
command with the {lost ignore} option and a fixed
"boundary"_boundary.html.
The fix deposit command must use the {region} keyword to define an
insertion volume. The specified region must have been previously
defined with a "region"_region.html command. It must be defined with
side = {in}.
NOTE: LAMMPS checks that the specified region is wholly inside the
simulation box. It can do this correctly for orthonormal simulation
boxes. However for "triclinic boxes"_Howto_triclinic.html, it only
tests against the larger orthonormal box that bounds the tilted
simulation box. If the specified region includes volume outside the
tilted box, then an insertion will likely fail, leading to a "lost
atoms" error. Thus for triclinic boxes you should insure the
specified region is wholly inside the simulation box.
The locations of inserted particles are taken from uniform distributed
random numbers, unless the {gaussian} keyword is used. Then the
individual coordinates are taken from a gaussian distribution of
width {sigma} centered on {xmid,ymid,zmid}.
Individual atoms are inserted, unless the {mol} keyword is used. It
specifies a {template-ID} previously defined using the
"molecule"_molecule.html command, which reads files that define one or
more molecules. The coordinates, atom types, charges, etc, as well as
any bond/angle/etc and special neighbor information for the molecule
can be specified in the molecule file. See the
"molecule"_molecule.html command for details. The only settings
required to be in each file are the coordinates and types of atoms in
the molecule.
If the molecule template contains more than one molecule, the relative
probability of depositing each molecule can be specified by the
{molfrac} keyword. N relative probabilities, each from 0.0 to 1.0, are
specified, where N is the number of molecules in the template. Each
time a molecule is deposited, a random number is used to sample from
the list of relative probabilities. The N values must sum to 1.0.
If you wish to insert molecules via the {mol} keyword, that will be
treated as rigid bodies, use the {rigid} keyword, specifying as its
value the ID of a separate "fix rigid/small"_fix_rigid.html
command which also appears in your input script.
NOTE: If you wish the new rigid molecules (and other rigid molecules)
to be thermostatted correctly via "fix rigid/small/nvt"_fix_rigid.html
or "fix rigid/small/npt"_fix_rigid.html, then you need to use the
"fix_modify dynamic/dof yes" command for the rigid fix. This is to
inform that fix that the molecule count will vary dynamically.
If you wish to insert molecules via the {mol} keyword, that will have
their bonds or angles constrained via SHAKE, use the {shake} keyword,
specifying as its value the ID of a separate "fix
shake"_fix_shake.html command which also appears in your input script.
Each timestep a particle is inserted, the coordinates for its atoms
are chosen as follows. For insertion of individual atoms, the
"position" referred to in the following description is the coordinate
of the atom. For insertion of molecule, the "position" is the
geometric center of the molecule; see the "molecule"_molecule.html doc
page for details. A random rotation of the molecule around its center
point is performed, which determines the coordinates all the
individual atoms.
A random position within the region insertion volume is generated. If
neither the {global} or {local} keyword is used, the random position
is the trial position. If the {global} keyword is used, the random
x,y values are used, but the z position of the new particle is set
above the highest current atom in the simulation by a distance
randomly chosen between lo/hi. (For a 2d simulation, this is done for
the y position.) If the {local} keyword is used, the z position is
set a distance between lo/hi above the highest current atom in the
simulation that is "nearby" the chosen x,y position. In this context,
"nearby" means the lateral distance (in x,y) between the new and old
particles is less than the {delta} setting.
Once a trial x,y,z position has been selected, the insertion is only
performed if no current atom in the simulation is within a distance R
of any atom in the new particle, including the effect of periodic
boundary conditions if applicable. R is defined by the {near}
keyword. Note that the default value for R is 0.0, which will allow
atoms to strongly overlap if you are inserting where other atoms are
present. This distance test is performed independently for each atom
in an inserted molecule, based on the randomly rotated configuration
of the molecule. If this test fails, a new random position within the
insertion volume is chosen and another trial is made. Up to Q
attempts are made. If the particle is not successfully inserted,
LAMMPS prints a warning message.
NOTE: If you are inserting finite size particles or a molecule or
rigid body consisting of finite-size particles, then you should
typically set R larger than the distance at which any inserted
particle may overlap with either a previously inserted particle or an
existing particle. LAMMPS will issue a warning if R is smaller than
this value, based on the radii of existing and inserted particles.
The {rate} option moves the insertion volume in the z direction (3d)
or y direction (2d). This enables particles to be inserted from a
successively higher height over time. Note that this parameter is
ignored if the {global} or {local} keywords are used, since those
options choose a z-coordinate for insertion independently.
The vx, vy, and vz components of velocity for the inserted particle
are set using the values specified for the {vx}, {vy}, and {vz}
keywords. Note that normally, new particles should be a assigned a
negative vertical velocity so that they move towards the surface. For
molecules, the same velocity is given to every particle (no rotation
or bond vibration).
If the {target} option is used, the velocity vector of the inserted
particle is changed so that it points from the insertion position
towards the specified target point. The magnitude of the velocity is
unchanged. This can be useful, for example, for simulating a
sputtering process. E.g. the target point can be far away, so that
all incident particles strike the surface as if they are in an
incident beam of particles at a prescribed angle.
The {id} keyword determines how atom IDs and molecule IDs are assigned
to newly deposited particles. Molecule IDs are only assigned if
molecules are being inserted. For the {max} setting, the atom and
molecule IDs of all current atoms are checked. Atoms in the new
particle are assigned IDs starting with the current maximum plus one.
If a molecule is inserted it is assigned an ID = current maximum plus
one. This means that if particles leave the system, the new IDs may
replace the lost ones. For the {next} setting, the maximum ID of any
atom and molecule is stored at the time the fix is defined. Each time
a new particle is added, this value is incremented to assign IDs to
the new atom(s) or molecule. Thus atom and molecule IDs for deposited
particles will be consecutive even if particles leave the system over
time.
The {units} keyword determines the meaning of the distance units used
for the other deposition parameters. A {box} value selects standard
distance units as defined by the "units"_units.html command,
e.g. Angstroms for units = real or metal. A {lattice} value means the
distance units are in lattice spacings. The "lattice"_lattice.html
command must have been previously used to define the lattice spacing.
Note that the units choice affects all the keyword values that have
units of distance or velocity.
NOTE: If you are monitoring the temperature of a system where the atom
count is changing due to adding particles, you typically should use
the "compute_modify dynamic yes"_compute_modify.html command for the
temperature compute you are using.
[Restart, fix_modify, output, run start/stop, minimize info:]
This fix writes the state of the deposition to "binary restart
files"_restart.html. This includes information about how many
particles have been deposited, the random number generator seed, the
next timestep for deposition, etc. See the
"read_restart"_read_restart.html command for info on how to re-specify
a fix in an input script that reads a restart file, so that the
operation of the fix continues in an uninterrupted fashion.
NOTE: For this to work correctly, the timestep must [not] be changed
after reading the restart with "reset_timestep"_reset_timestep.html.
The fix will try to detect it and stop with an error.
None of the "fix_modify"_fix_modify.html options are relevant to this
fix. No global or per-atom quantities are stored by this fix for
access by various "output commands"_Howto_output.html. No parameter
of this fix can be used with the {start/stop} keywords of the
"run"_run.html command. This fix is not invoked during "energy
minimization"_minimize.html.
[Restrictions:]
This fix is part of the MISC package. It is only enabled if LAMMPS
was built with that package. See the "Build
package"_Build_package.html doc page for more info.
The specified insertion region cannot be a "dynamic" region, as
defined by the "region"_region.html command.
[Related commands:]
"fix pour"_fix_pour.html, "region"_region.html
[Default:]
Insertions are performed for individual atoms, i.e. no {mol} setting
is defined. If the {mol} keyword is used, the default for {molfrac}
is an equal probabilities for all molecules in the template.
Additional option defaults are id = max, delta = 0.0, near = 0.0,
attempt = 10, rate = 0.0, vx = 0.0 0.0, vy = 0.0 0.0, vz = 0.0 0.0,
and units = lattice.

463
doc/txt/fix_hyper_local.txt
View File

@ -1,463 +0,0 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
fix hyper/local command :h3
[Syntax:]
fix ID group-ID hyper/local cutbond qfactor Vmax Tequil Dcut alpha Btarget :pre
ID, group-ID are documented in "fix"_fix.html command :ulb,l
hyper/local = style name of this fix command :l
cutbond = max distance at which a pair of atoms is considered bonded (distance units) :l
qfactor = max strain at which bias potential goes to 0.0 (unitless) :l
Vmax = estimated height of bias potential (energy units) :l
Tequil = equilibration temperature (temperature units) :l
Dcut = minimum distance between boosted bonds (distance units) :l
alpha = boostostat relaxation time (time units) :l
Btarget = desired time boost factor (unitless) :l
zero or more keyword/value pairs may be appended :l
keyword = {check/ghost} or {check/bias} :l
{check/ghost} values = none
{check/bias} values = Nevery error/warn/ignore :pre
:ule
[Examples:]
fix 1 all hyper/local 1.0 0.3 0.8 300.0 :pre
[Description:]
This fix is meant to be used with the "hyper"_hyper.html command to
perform a bond-boost local hyperdynamics (LHD) simulation. The role
of this fix is to a select multiple pairs of atoms in the system at
each timestep to add a local bias potential to, which will alter the
dynamics of the system in a manner that effectively accelerates time.
This is in contrast to the "fix hyper/global"_fix_hyper_global.html
command, which can be user to perform a global hyperdynamics (GHD)
simulation, by adding a global bias potential to a single pair of
atoms at each timestep. GHD can time accelerate a small simulation
with up to a few 100 atoms. For larger systems, LHD is needed to
achieve good time acceleration.
For a system that undergoes rare transition events, where one or more
atoms move over an energy barrier to a new potential energy basin, the
effect of the bias potential is to induce more rapid transitions.
This can lead to a dramatic speed-up in the rate at which events
occurs, without altering their relative frequencies, thus leading to
an overall increase in the elapsed real time of the simulation as
compared to running for the same number of timesteps with normal MD.
See the "hyper"_hyper.html doc page for a more general discussion of
hyperdynamics and citations that explain both GHD and LHD.
The equations and logic used by this fix and described here to perform
LHD follow the description given in "(Voter2013)"_#Voter2013lhd. The
bond-boost form of a bias potential for HD is due to Miron and
Fichthorn as described in "(Miron)"_#Mironlhd.
To understand this description, you should first read the description
of the GHD algorithm on the "fix hyper/global"_fix_hyper_global.html
doc page. This description of LHD builds on the GHD description.
The definition of bonds and Eij are the same for GHD and LHD. The
formulas for Vij(max) and Fij(max) are also the same except for a
pre-factor Cij, explained below.
The bias energy Vij applied to a bond IJ with maximum strain is
Vij(max) = Cij * Vmax * (1 - (Eij/q)^2) for abs(Eij) < qfactor
= 0 otherwise :pre
The derivative of Vij(max) with respect to the position of each atom
in the IJ bond gives a bias force Fij(max) acting on the bond as
Fij(max) = - dVij(max)/dEij = 2 Cij Vmax Eij / qfactor^2 for abs(Eij) < qfactor
= 0 otherwise :pre
which can be decomposed into an equal and opposite force acting on
only the two I,J atoms in the IJ bond.
The key difference is that in GHD a bias energy and force is added (on
a particular timestep) to only one bond (pair of atoms) in the system,
which is the bond with maximum strain Emax.
In LHD, a bias energy and force can be added to multiple bonds
separated by the specified {Dcut} distance or more. A bond IJ is
biased if it is the maximum strain bond within its local
"neighborhood", which is defined as the bond IJ plus any neighbor
bonds within a distance {Dcut} from IJ. The "distance" between bond
IJ and bond KL is the minimum distance between any of the IK, IL, JK,
JL pairs of atoms.
For a large system, multiple bonds will typically meet this
requirement, and thus a bias potential Vij(max) will be applied to
many bonds on the same timestep.
In LHD, all bonds store a Cij prefactor which appears in the Vij(max)
and Fij(max) equations above. Note that the Cij factor scales the
strength of the bias energy and forces whenever bond IJ is the maximum
strain bond in its neighborhood.
Cij is initialized to 1.0 when a bond between the I,J atoms is first
defined. The specified {Btarget} factor is then used to adjust the
Cij prefactors for each bond every timestep in the following manner.
An instantaneous boost factor Bij is computed each timestep
for each bond, as
Bij = exp(beta * Vkl(max)) :pre
where Vkl(max) is the bias energy of the maxstrain bond KL within bond
IJ's neighborhood, beta = 1/kTequil, and {Tequil} is the temperature
of the system and an argument to this fix.
NOTE: To run an LHD simulation, the input script must also use the
"fix langevin"_fix_langevin.html command to thermostat the atoms at
the same {Tequil} as specified by this fix, so that the system is
running constant-temperature (NVT) dynamics. LAMMPS does not check
that this is done.
Note that if IJ = KL, then bond IJ is a biased bond on that timestep,
otherwise it is not. But regardless, the boost factor Bij can be
thought of an estimate of time boost currently being applied within a
local region centered on bond IJ. For LHD, we want this to be the
specified {Btarget} value everywhere in the simulation domain.
To accomplish this, if Bij < Btarget, the Cij prefactor for bond IJ is
incremented on the current timestep by an amount proportional to the
inverse of the specified {alpha} and the difference (Bij - Btarget).
Conversely if Bij > Btarget, Cij is decremented by the same amount.
This procedure is termed "boostostatting" in
"(Voter2013)"_#Voter2013lhd. It drives all of the individual Cij to
values such that when Vij{max} is applied as a bias to bond IJ, the
resulting boost factor Bij will be close to {Btarget} on average.
Thus the LHD time acceleration factor for the overall system is
effectively {Btarget}.
Note that in LHD, the boost factor {Btarget} is specified by the user.
This is in contrast to global hyperdynamics (GHD) where the boost
factor varies each timestep and is computed as a function of {Vmax},
Emax, and {Tequil}; see the "fix hyper/global"_fix_hyper_global.html
doc page for details.
:line
Here is additional information on the input parameters for LHD.
Note that the {cutbond}, {qfactor}, and {Tequil} arguments have the
same meaning as for GHD. The {Vmax} argument is slightly different.
The {Dcut}, {alpha}, and {Btarget} parameters are unique to LHD.
The {cutbond} argument is the cutoff distance for defining bonds
between pairs of nearby atoms. A pair of I,J atoms in their
equilibrium, minimum-energy configuration, which are separated by a
distance Rij < {cutbond}, are flagged as a bonded pair. Setting
{cubond} to be ~25% larger than the nearest-neighbor distance in a
crystalline lattice is a typical choice for solids, so that bonds
exist only between nearest neighbor pairs.
The {qfactor} argument is the limiting strain at which the bias
potential goes to 0.0. It is dimensionless, so a value of 0.3 means a
bond distance can be up to 30% larger or 30% smaller than the
equilibrium (quenched) R0ij distance and the two atoms in the bond
could still experience a non-zero bias force.
If {qfactor} is set too large, then transitions from one energy basin
to another are affected because the bias potential is non-zero at the
transition state (e.g. saddle point). If {qfactor} is set too small
than little boost can be achieved because the Eij strain of some bond in
the system will (nearly) always exceed {qfactor}. A value of 0.3 for
{qfactor} is typically a reasonable value.
The {Vmax} argument is a fixed prefactor on the bias potential. There
is a also a dynamic prefactor Cij, driven by the choice of {Btarget}
as discussed above. The product of these should be a value less than
the smallest barrier height for an event to occur. Otherwise the
applied bias potential may be large enough (when added to the
interatomic potential) to produce a local energy basin with a maxima
in the center. This can produce artificial energy minima in the same
basin that trap an atom. Or if Cij*{Vmax} is even larger, it may
induce an atom(s) to rapidly transition to another energy basin. Both
cases are "bad dynamics" which violate the assumptions of LHD that
guarantee an accelerated time-accurate trajectory of the system.
NOTE: It may seem that {Vmax} can be set to any value, and Cij will
compensate to reduce the overall prefactor if necessary. However the
Cij are initialized to 1.0 and the boostostatting procedure typically
operates slowly enough that there can be a time period of bad dynamics
if {Vmax} is set too large. A better strategy is to set {Vmax} to the
smallest barrier height for an event (the same as for GHD), so that
the Cij remain near unity.
The {Tequil} argument is the temperature at which the system is
simulated; see the comment above about the "fix
langevin"_fix_langevin.html thermostatting. It is also part of the
beta term in the exponential factor that determines how much boost is
achieved as a function of the bias potential. See the discussion of
the {Btarget} argument below.
As discussed above, the {Dcut} argument is the distance required
between two locally maxstrain bonds for them to both be selected as
biased bonds on the same timestep. Computationally, the larger {Dcut}
is, the more work (computation and communication) must be done each
timestep within the LHD algorithm. And the fewer bonds can be
simultaneously biased, which may mean the specified {Btarget} time
acceleration cannot be achieved.
Physically {Dcut} should be a long enough distance that biasing two
pairs of atoms that close together will not influence the dynamics of
each pair. E.g. something like 2x the cutoff of the interatomic
potential. In practice a {Dcut} value of ~10 Angstroms seems to work
well for many solid-state systems.
NOTE: You should insure that ghost atom communication is performed for
a distance of at least {Dcut} + {cutevent} = the distance one or more
atoms move (between quenched states) to be considered an "event". It
is an argument to the "compute event/displace" command used to detect
events. By default the ghost communication distance is set by the
pair_style cutoff, which will typically be < {Dcut}. The "comm_modify
cutoff"_comm_modify.html command should be used to override the ghost
cutoff explicitly, e.g.
comm_modify cutoff 12.0 :pre
Note that this fix does not know the {cutevent} parameter, but uses
half the {cutbond} parameter as an estimate to warn if the ghost
cutoff is not long enough.
As described above the {alpha} argument is a pre-factor in the
boostostat update equation for each bond's Cij prefactor. {Alpha} is
specified in time units, similar to other thermostat or barostat
damping parameters. It is roughly the physical time it will take the
boostostat to adjust a Cij value from a too high (or too low) value to
a correct one. An {alpha} setting of a few ps is typically good for
solid-state systems. Note that the {alpha} argument here is the
inverse of the alpha parameter discussed in
"(Voter2013)"_#Voter2013lhd.
The {Btarget} argument is the desired time boost factor (a value > 1)
that all the atoms in the system will experience. The elapsed time
t_hyper for an LHD simulation running for {N} timesteps is simply
t_hyper = Btarget * N*dt :pre
where dt is the timestep size defined by the "timestep"_timestep.html
command. The effective time acceleration due to LHD is thus t_hyper /
N*dt = Btarget, where N*dt is elapsed time for a normal MD run
of N timesteps.
You cannot choose an arbitrarily large setting for {Btarget}. The
maximum value you should choose is
Btarget = exp(beta * Vsmall) :pre
where Vsmall is the smallest event barrier height in your system, beta
= 1/kTequil, and {Tequil} is the specified temperature of the system
(both by this fix and the Langevin thermostat).
Note that if {Btarget} is set smaller than this, the LHD simulation
will run correctly. There will just be fewer events because the hyper
time (t_hyper equation above) will be shorter.
NOTE: If you have no physical intuition as to the smallest barrier
height in your system, a reasonable strategy to determine the largest
{Btarget} you can use for an LHD model, is to run a sequence of
simulations with smaller and smaller {Btarget} values, until the event
rate does not change (as a function of hyper time).
:line
Here is additional information on the optional keywords for this fix.
The {check/ghost} keyword turns on extra computation each timestep to
compute statistics about ghost atoms used to determine which bonds to
bias. The output of these stats are the vector values 14 and 15,
described below. If this keyword is not enabled, the output
of the stats will be zero.
The {check/bias} keyword turns on extra computation and communication
to check if any biased bonds are closer than {Dcut} to each other,
which should not be the case if LHD is operating correctly. Thus it
is a debugging check. The {Nevery} setting determines how often the
check is made. The {error}, {warn}, or {ignore} setting determines
what is done if the count of too-close bonds is not zero. Either the
code will exit, or issue a warning, or silently tally the count. The
count can be output as vector value 17, as described below. If this
keyword is not enabled, the output of that statistic will be 0.
Note that both of these computations are costly, hence they are only
enabled by these keywords.
:line
[Restart, fix_modify, output, run start/stop, minimize info:]
No information about this fix is written to "binary restart
files"_restart.html.
The "fix_modify"_fix_modify.html {energy} option is supported by this
fix to add the energy of the bias potential to the system's
potential energy as part of "thermodynamic output"_thermo_style.html.
This fix computes a global scalar and global vector of length 21,
which can be accessed by various "output commands"_Howto_output.html.
The scalar is the magnitude of the bias potential (energy units)
applied on the current timestep, summed over all biased bonds. The
vector stores the following quantities:
1 = # of biased bonds on this step
2 = max strain Eij of any bond on this step (absolute value, unitless)
3 = average bias coeff for all bonds on this step (unitless)
4 = average # of bonds/atom on this step
5 = average neighbor bonds/bond on this step within {Dcut} :ul
6 = max bond length during this run (distance units)
7 = average # of biased bonds/step during this run
8 = fraction of biased bonds with no bias during this run
9 = fraction of biased bonds with negative strain during this run
10 = average bias coeff for all bonds during this run (unitless)
11 = min bias coeff for any bond during this run (unitless)
12 = max bias coeff for any bond during this run (unitless) :ul
13 = max drift distance of any bond atom during this run (distance units)
14 = max distance from proc subbox of any ghost atom with maxstrain < qfactor during this run (distance units)
15 = max distance outside my box of any ghost atom with any maxstrain during this run (distance units)
16 = count of ghost atoms that could not be found on reneighbor steps during this run
17 = count of bias overlaps (< Dcut) found during this run :ul
18 = cumulative hyper time since fix created (time units)
19 = cumulative count of event timesteps since fix created
20 = cumulative count of atoms in events since fix created
21 = cumulative # of new bonds formed since fix created :ul
The first quantities (1-5) are for the current timestep. Quantities
6-17 are for the current hyper run. They are reset each time a new
hyper run is performed. Quantities 18-21 are cumulative across
multiple runs (since the point in the input script the fix was
defined).
For value 8, the numerator is a count of all biased bonds on each
timestep whose bias energy = 0.0 due to Eij >= {qfactor}. The
denominator is the count of all biased bonds on all timesteps.
For value 9, the numerator is a count of all biased bonds on each
timestep with negative strain. The denominator is the count of all
biased bonds on all timesteps.
Values 13-17 are mostly useful for debugging and diagnostic purposes.
For value 13, drift is the distance an atom moves between two quenched
states when the second quench determines an event has occurred. Atoms
involved in an event will typically move the greatest distance since
others typically remain near their original quenched position.
For values 14-16, neighbor atoms in the full neighbor list with cutoff
{Dcut} may be ghost atoms outside a processor's sub-box. Before the
next event occurs they may move further than {Dcut} away from the
sub-box boundary. Value 14 is the furthest (from the sub-box) any
ghost atom in the neighbor list with maxstrain < {qfactor} was
accessed during the run. Value 15 is the same except that the ghost
atom's maxstrain may be >= {qfactor}, which may mean it is about to
participate in an event. Value 16 is a count of how many ghost atoms
could not be found on reneighbor steps, presumably because they moved
too far away due to their participation in an event (which will likely
be detected at the next quench).
Typical values for 14 and 15 should be slightly larger than {Dcut},
which accounts for ghost atoms initially at a {Dcut} distance moving
thermally before the next event takes place.
Note that for values 14 and 15 to be computed, the optional keyword
{check/ghost} must be specified. Otherwise these values will be zero.
This is because computing them incurs overhead, so the values are only
computed if requested.
Value 16 should be zero or small. As explained above a small count
likely means some ghost atoms were participating in their own events
and moved a longer distance. If the value is large, it likely means
the communication cutoff for ghosts is too close to {Dcut} leading to
many not-found ghost atoms before the next event. This may lead to a
reduced number of bonds being selected for biasing, since the code
assumes those atoms are part of highly strained bonds. As explained
above, the "comm_modify cutoff"_comm_modify.html command can be used
to set a longer cutoff.
For value 17, no two bonds should be biased if they are within a
{Dcut} distance of each other. This value should be zero, indicating
that no pair of biased bonds are closer than {Dcut} from each other.
Note that for values 17 to be computed, the optional keyword
{check/bias} must be specified and it determines how often this check
is performed. This is because performing the check incurs overhead,
so if only computed as often as requested.
The result at the end of the run is the cumulative total from every
timestep the check was made. Note that the value is a count of atoms
in bonds which found other atoms in bonds too close, so it is almost
always an over-count of the number of too-close bonds.
Value 18 is simply the specified {boost} factor times the number of
timesteps times the timestep size.
For value 19, events are checked for by the "hyper"_hyper.html command
once every {Nevent} timesteps. This value is the count of those
timesteps on which one (or more) events was detected. It is NOT the
number of distinct events, since more than one event may occur in the
same {Nevent} time window.
For value 20, each time the "hyper"_hyper.html command checks for an
event, it invokes a compute to flag zero or more atoms as
participating in one or more events. E.g. atoms that have displaced
more than some distance from the previous quench state. Value 20 is
the cumulative count of the number of atoms participating in any of
the events that were found.
Value 21 tallies the number of new bonds created by the bond reset
operation. Bonds between a specific I,J pair of atoms may persist for
the entire hyperdynamics simulation if neither I or J are involved in
an event.
The scalar and vector values calculated by this fix are all
"intensive".
This fix also computes a local vector of length the number of bonds
currently in the system. The value for each bond is its Cij prefactor
(bias coefficient). These values can be can be accessed by various
"output commands"_Howto_output.html. A particularly useful one is the
"fix ave/histo"_fix_ave_histo.html command which can be used to
histogram the Cij values to see if they are distributed reasonably
close to 1.0, which indicates a good choice of {Vmax}.
The local values calculated by this fix are unitless.
No parameter of this fix can be used with the {start/stop} keywords of
the "run"_run.html command. This fix is not invoked during "energy
minimization"_minimize.html.
[Restrictions:]
This fix is part of the REPLICA package. It is only enabled if LAMMPS
was built with that package. See the "Build package"_Build_package.html
doc page for more info.
[Related commands:]
"hyper"_hyper.html, "fix hyper/global"_fix_hyper_global.html
[Default:]
The check/ghost and check/bias keywords are not enabled by default.
:line
:link(Voter2013lhd)
[(Voter2013)] S. Y. Kim, D. Perez, A. F. Voter, J Chem Phys, 139,
144110 (2013).
:link(Mironlhd)
[(Miron)] R. A. Miron and K. A. Fichthorn, J Chem Phys, 119, 6210 (2003).

63
doc/txt/fix_nve_dot.txt
View File

@ -1,63 +0,0 @@
"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
fix nve/dot command :h3
[Syntax:]
fix ID group-ID nve/dot :pre
ID, group-ID are documented in "fix"_fix.html command :ulb,l
nve/dot = style name of this fix command :l
:ule
[Examples:]
fix 1 all nve/dot :pre
[Description:]
Apply a rigid-body integrator as described in "(Davidchack)"_#Davidchack1
to a group of atoms, but without Langevin dynamics.
This command performs Molecular dynamics (MD)
via a velocity-Verlet algorithm and an evolution operator that rotates
the quaternion degrees of freedom, similar to the scheme outlined in "(Miller)"_#Miller1.
This command is the equivalent of the "fix nve/dotc/langevin"_fix_nve_dotc_langevin.html
without damping and noise and can be used to determine the stability range
in a NVE ensemble prior to using the Langevin-type DOTC-integrator
(see also "fix nve/dotc/langevin"_fix_nve_dotc_langevin.html).
The command is equivalent to the "fix nve"_fix_nve.html.
The particles are always considered to have a finite size.
An example input file can be found in /examples/USER/cgdna/examples/duplex1/.
Further details of the implementation and stability of the integrator are contained in "(Henrich)"_#Henrich3.
The preprint version of the article can be found "here"_PDF/USER-CGDNA.pdf.
:line
[Restrictions:]
These pair styles can only be used if LAMMPS was built with the
"USER-CGDNA"_Package_details.html#PKG-USER-CGDNA package and the MOLECULE and ASPHERE package.
See the "Build package"_Build_package.html doc page for more info.
[Related commands:]
"fix nve/dotc/langevin"_fix_nve_dotc_langevin.html, "fix nve"_fix_nve.html
[Default:] none
:line
:link(Davidchack1)
[(Davidchack)] R.L Davidchack, T.E. Ouldridge, and M.V. Tretyakov. J. Chem. Phys. 142, 144114 (2015).
:link(Miller1)
[(Miller)] T. F. Miller III, M. Eleftheriou, P. Pattnaik, A. Ndirango, G. J. Martyna, J. Chem. Phys., 116, 8649-8659 (2002).
:link(Henrich3)
[(Henrich)] O. Henrich, Y. A. Gutierrez-Fosado, T. Curk, T. E. Ouldridge, Eur. Phys. J. E 41, 57 (2018).

143
doc/txt/fix_nve_dotc_langevin.txt
View File

@ -1,143 +0,0 @@
"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
fix nve/dotc/langevin command :h3
[Syntax:]
fix ID group-ID nve/dotc/langevin Tstart Tstop damp seed keyword value :pre
ID, group-ID are documented in "fix"_fix.html command :ulb,l
nve/dotc/langevin = style name of this fix command :l
Tstart,Tstop = desired temperature at start/end of run (temperature units) :l
damp = damping parameter (time units) :l
seed = random number seed to use for white noise (positive integer) :l
keyword = {angmom} :l
{angmom} value = factor
factor = do thermostat rotational degrees of freedom via the angular momentum and apply numeric scale factor as discussed below :pre
:ule
[Examples:]
fix 1 all nve/dotc/langevin 1.0 1.0 0.03 457145 angmom 10
fix 1 all nve/dotc/langevin 0.1 0.1 78.9375 457145 angmom 10 :pre
[Description:]
Apply a rigid-body Langevin-type integrator of the kind "Langevin C"
as described in "(Davidchack)"_#Davidchack2
to a group of atoms, which models an interaction with an implicit background
solvent. This command performs Brownian dynamics (BD)
via a technique that splits the integration into a deterministic Hamiltonian
part and the Ornstein-Uhlenbeck process for noise and damping.
The quaternion degrees of freedom are updated though an evolution
operator which performs a rotation in quaternion space, preserves
the quaternion norm and is akin to "(Miller)"_#Miller2.
In terms of syntax this command has been closely modelled on the
"fix langevin"_fix_langevin.html and its {angmom} option. But it combines
the "fix nve"_fix_nve.html and the "fix langevin"_fix_langevin.html in
one single command. The main feature is improved stability
over the standard integrator, permitting slightly larger timestep sizes.
NOTE: Unlike the "fix langevin"_fix_langevin.html this command performs
also time integration of the translational and quaternion degrees of freedom.
The total force on each atom will have the form:
F = Fc + Ff + Fr
Ff = - (m / damp) v
Fr is proportional to sqrt(Kb T m / (dt damp)) :pre
Fc is the conservative force computed via the usual inter-particle
interactions ("pair_style"_pair_style.html,
"bond_style"_bond_style.html, etc).
The Ff and Fr terms are implicitly taken into account by this fix
on a per-particle basis.
Ff is a frictional drag or viscous damping term proportional to the
particle's velocity. The proportionality constant for each atom is
computed as m/damp, where m is the mass of the particle and damp is
the damping factor specified by the user.
Fr is a force due to solvent atoms at a temperature T randomly bumping
into the particle. As derived from the fluctuation/dissipation
theorem, its magnitude as shown above is proportional to sqrt(Kb T m /
dt damp), where Kb is the Boltzmann constant, T is the desired
temperature, m is the mass of the particle, dt is the timestep size,
and damp is the damping factor. Random numbers are used to randomize
the direction and magnitude of this force as described in
"(Dunweg)"_#Dunweg3, where a uniform random number is used (instead of
a Gaussian random number) for speed.
:line
{Tstart} and {Tstop} have to be constant values, i.e. they cannot
be variables. If used together with the oxDNA force field for
coarse-grained simulation of DNA please note that T = 0.1 in oxDNA units
corresponds to T = 300 K.
The {damp} parameter is specified in time units and determines how
rapidly the temperature is relaxed. For example, a value of 0.03
means to relax the temperature in a timespan of (roughly) 0.03 time
units tau (see the "units"_units.html command).
The damp factor can be thought of as inversely related to the
viscosity of the solvent, i.e. a small relaxation time implies a
hi-viscosity solvent and vice versa. See the discussion about gamma
and viscosity in the documentation for the "fix
viscous"_fix_viscous.html command for more details.
Note that the value 78.9375 in the second example above corresponds
to a diffusion constant, which is about an order of magnitude larger
than realistic ones. This has been used to sample configurations faster
in Brownian dynamics simulations.
The random # {seed} must be a positive integer. A Marsaglia random
number generator is used. Each processor uses the input seed to
generate its own unique seed and its own stream of random numbers.
Thus the dynamics of the system will not be identical on two runs on
different numbers of processors.
The keyword/value option has to be used in the following way:
This fix has to be used together with the {angmom} keyword. The
particles are always considered to have a finite size.
The keyword {angmom} enables thermostatting of the rotational degrees of
freedom in addition to the usual translational degrees of freedom.
The scale factor after the {angmom} keyword gives the ratio of the rotational to
the translational friction coefficient.
An example input file can be found in /examples/USER/cgdna/examples/duplex2/.
Further details of the implementation and stability of the integrators are contained in "(Henrich)"_#Henrich4.
The preprint version of the article can be found "here"_PDF/USER-CGDNA.pdf.
:line
[Restrictions:]
These pair styles can only be used if LAMMPS was built with the
"USER-CGDNA"_Package_details.html#PKG-USER-CGDNA package and the MOLECULE and ASPHERE package.
See the "Build package"_Build_package.html doc page for more info.
[Related commands:]
"fix nve"_fix_nve.html, "fix langevin"_fix_langevin.html, "fix nve/dot"_fix_nve_dot.html, "bond_style oxdna/fene"_bond_oxdna.html, "bond_style oxdna2/fene"_bond_oxdna.html, "pair_style oxdna/excv"_pair_oxdna.html, "pair_style oxdna2/excv"_pair_oxdna2.html
[Default:] none
:line
:link(Davidchack2)
[(Davidchack)] R.L Davidchack, T.E. Ouldridge, M.V. Tretyakov. J. Chem. Phys. 142, 144114 (2015).
:link(Miller2)
[(Miller)] T. F. Miller III, M. Eleftheriou, P. Pattnaik, A. Ndirango, G. J. Martyna, J. Chem. Phys., 116, 8649-8659 (2002).
:link(Dunweg3)
[(Dunweg)] B. Dunweg, W. Paul, Int. J. Mod. Phys. C, 2, 817-27 (1991).
:link(Henrich4)
[(Henrich)] O. Henrich, Y. A. Gutierrez-Fosado, T. Curk, T. E. Ouldridge, Eur. Phys. J. E 41, 57 (2018).

183
doc/txt/fix_wall_reflect.txt
View File

@ -1,183 +0,0 @@
"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
fix wall/reflect command :h3
fix wall/reflect/kk command :h3
[Syntax:]
fix ID group-ID wall/reflect face arg ... keyword value ... :pre
ID, group-ID are documented in "fix"_fix.html command :ulb,l
wall/reflect = style name of this fix command :l
one or more face/arg pairs may be appended :l
face = {xlo} or {xhi} or {ylo} or {yhi} or {zlo} or {zhi} :l
{xlo},{ylo},{zlo} arg = EDGE or constant or variable
EDGE = current lo edge of simulation box
constant = number like 0.0 or -30.0 (distance units)
variable = "equal-style variable"_variable.html like v_x or v_wiggle
{xhi},{yhi},{zhi} arg = EDGE or constant or variable
EDGE = current hi edge of simulation box
constant = number like 50.0 or 100.3 (distance units)
variable = "equal-style variable"_variable.html like v_x or v_wiggle :pre
zero or more keyword/value pairs may be appended :l
keyword = {units} :l
{units} value = {lattice} or {box}
{lattice} = the wall position is defined in lattice units
{box} = the wall position is defined in simulation box units :pre
:ule
[Examples:]
fix xwalls all wall/reflect xlo EDGE xhi EDGE
fix walls all wall/reflect xlo 0.0 ylo 10.0 units box
fix top all wall/reflect zhi v_pressdown :pre
[Description:]
Bound the simulation with one or more walls which reflect particles
in the specified group when they attempt to move through them.
Reflection means that if an atom moves outside the wall on a timestep
by a distance delta (e.g. due to "fix nve"_fix_nve.html), then it is
put back inside the face by the same delta, and the sign of the
corresponding component of its velocity is flipped.
When used in conjunction with "fix nve"_fix_nve.html and "run_style
verlet"_run_style.html, the resultant time-integration algorithm is
equivalent to the primitive splitting algorithm (PSA) described by
"Bond"_#Bond1. Because each reflection event divides
the corresponding timestep asymmetrically, energy conservation is only
satisfied to O(dt), rather than to O(dt^2) as it would be for
velocity-Verlet integration without reflective walls.
Up to 6 walls or faces can be specified in a single command: {xlo},
{xhi}, {ylo}, {yhi}, {zlo}, {zhi}. A {lo} face reflects particles
that move to a coordinate less than the wall position, back in the
{hi} direction. A {hi} face reflects particles that move to a
coordinate higher than the wall position, back in the {lo} direction.
The position of each wall can be specified in one of 3 ways: as the
EDGE of the simulation box, as a constant value, or as a variable. If
EDGE is used, then the corresponding boundary of the current
simulation box is used. If a numeric constant is specified then the
wall is placed at that position in the appropriate dimension (x, y, or
z). In both the EDGE and constant cases, the wall will never move.
If the wall position is a variable, it should be specified as v_name,
where name is an "equal-style variable"_variable.html name. In this
case the variable is evaluated each timestep and the result becomes
the current position of the reflecting wall. Equal-style variables
can specify formulas with various mathematical functions, and include
"thermo_style"_thermo_style.html command keywords for the simulation
box parameters and timestep and elapsed time. Thus it is easy to
specify a time-dependent wall position.
The {units} keyword determines the meaning of the distance units used
to define a wall position, but only when a numeric constant or
variable is used. It is not relevant when EDGE is used to specify a
face position. In the variable case, the variable is assumed to
produce a value compatible with the {units} setting you specify.
A {box} value selects standard distance units as defined by the
"units"_units.html command, e.g. Angstroms for units = real or metal.
A {lattice} value means the distance units are in lattice spacings.
The "lattice"_lattice.html command must have been previously used to
define the lattice spacings.
:line
Here are examples of variable definitions that move the wall position
in a time-dependent fashion using equal-style
"variables"_variable.html.
variable ramp equal ramp(0,10)
fix 1 all wall/reflect xlo v_ramp :pre
variable linear equal vdisplace(0,20)
fix 1 all wall/reflect xlo v_linear :pre
variable wiggle equal swiggle(0.0,5.0,3.0)
fix 1 all wall/reflect xlo v_wiggle :pre
variable wiggle equal cwiggle(0.0,5.0,3.0)
fix 1 all wall/reflect xlo v_wiggle :pre
The ramp(lo,hi) function adjusts the wall position linearly from lo to
hi over the course of a run. The vdisplace(c0,velocity) function does
something similar using the equation position = c0 + velocity*delta,
where delta is the elapsed time.
The swiggle(c0,A,period) function causes the wall position to
oscillate sinusoidally according to this equation, where omega = 2 PI
/ period:
position = c0 + A sin(omega*delta) :pre
The cwiggle(c0,A,period) function causes the wall position to
oscillate sinusoidally according to this equation, which will have an
initial wall velocity of 0.0, and thus may impose a gentler
perturbation on the particles:
position = c0 + A (1 - cos(omega*delta)) :pre
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed on the "Speed packages"_Speed_packages.html doc
page. The accelerated styles take the same arguments and should
produce the same results, except for round-off and precision issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Build
package"_Build_package.html doc page for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
switch"_Run_options.html when you invoke LAMMPS, or you can use the
"suffix"_suffix.html command in your input script.
See the "Speed packages"_Speed_packages.html doc page for more
instructions on how to use the accelerated styles effectively.
:line
[Restart, fix_modify, output, run start/stop, minimize info:]
No information about this fix is written to "binary restart
files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to this fix. No global or per-atom quantities are stored
by this fix for access by various "output commands"_Howto_output.html.
No parameter of this fix can be used with the {start/stop} keywords of
the "run"_run.html command. This fix is not invoked during "energy
minimization"_minimize.html.
[Restrictions:]
Any dimension (xyz) that has a reflecting wall must be non-periodic.
A reflecting wall should not be used with rigid bodies such as those
defined by a "fix rigid" command. This is because the wall/reflect
displaces atoms directly rather than exerts a force on them. For
rigid bodies, use a soft wall instead, such as "fix
wall/lj93"_fix_wall.html. LAMMPS will flag the use of a rigid
fix with fix wall/reflect with a warning, but will not generate an
error.
[Related commands:]
"fix wall/lj93"_fix_wall.html, "fix oneway"_fix_oneway.html
[Default:] none
:line
:link(Bond1)
[(Bond)] Bond and Leimkuhler, SIAM J Sci Comput, 30, p 134 (2007).

495
doc/txt/kspace_style.txt
View File

@ -1,495 +0,0 @@
"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
kspace_style command :h3
[Syntax:]
kspace_style style value :pre
style = {none} or {ewald} or {ewald/disp} or {ewald/omp} or {pppm} or {pppm/cg} or {pppm/disp} or {pppm/tip4p} or {pppm/stagger} or {pppm/disp/tip4p} or {pppm/gpu} or {pppm/kk} or {pppm/omp} or {pppm/cg/omp} or {pppm/tip4p/omp} or {msm} or {msm/cg} or {msm/omp} or {msm/cg/omp} or {scafacos} :ulb,l
{none} value = none
{ewald} value = accuracy
accuracy = desired relative error in forces
{ewald/disp} value = accuracy
accuracy = desired relative error in forces
{ewald/omp} value = accuracy
accuracy = desired relative error in forces
{ewald/dipole} value = accuracy
accuracy = desired relative error in forces
{ewald/dipole/spin} value = accuracy
accuracy = desired relative error in forces
{pppm} value = accuracy
accuracy = desired relative error in forces
{pppm/cg} values = accuracy (smallq)
accuracy = desired relative error in forces
smallq = cutoff for charges to be considered (optional) (charge units)
{pppm/disp} value = accuracy
accuracy = desired relative error in forces
{pppm/tip4p} value = accuracy
accuracy = desired relative error in forces
{pppm/disp/tip4p} value = accuracy
accuracy = desired relative error in forces
{pppm/gpu} value = accuracy
accuracy = desired relative error in forces
{pppm/intel} value = accuracy
accuracy = desired relative error in forces
{pppm/kk} value = accuracy
accuracy = desired relative error in forces
{pppm/omp} value = accuracy
accuracy = desired relative error in forces
{pppm/cg/omp} value = accuracy
accuracy = desired relative error in forces
{pppm/disp/intel} value = accuracy
accuracy = desired relative error in forces
{pppm/tip4p/omp} value = accuracy
accuracy = desired relative error in forces
{pppm/stagger} value = accuracy
accuracy = desired relative error in forces
{pppm/dipole} value = accuracy
accuracy = desired relative error in forces
{pppm/dipole/spin} value = accuracy
accuracy = desired relative error in forces
{msm} value = accuracy
accuracy = desired relative error in forces
{msm/cg} value = accuracy (smallq)
accuracy = desired relative error in forces
smallq = cutoff for charges to be considered (optional) (charge units)
{msm/omp} value = accuracy
accuracy = desired relative error in forces
{msm/cg/omp} value = accuracy (smallq)
accuracy = desired relative error in forces
smallq = cutoff for charges to be considered (optional) (charge units)
{scafacos} values = method accuracy
method = fmm or p2nfft or p3m or ewald or direct
accuracy = desired relative error in forces :pre
:ule
[Examples:]
kspace_style pppm 1.0e-4
kspace_style pppm/cg 1.0e-5 1.0e-6
kspace style msm 1.0e-4
kspace style scafacos fmm 1.0e-4
kspace_style none :pre
[Description:]
Define a long-range solver for LAMMPS to use each timestep to compute
long-range Coulombic interactions or long-range 1/r^6 interactions.
Most of the long-range solvers perform their computation in K-space,
hence the name of this command.
When such a solver is used in conjunction with an appropriate pair
style, the cutoff for Coulombic or 1/r^N interactions is effectively
infinite. If the Coulombic case, this means each charge in the system
interacts with charges in an infinite array of periodic images of the
simulation domain.
Note that using a long-range solver requires use of a matching "pair
style"_pair_style.html to perform consistent short-range pairwise
calculations. This means that the name of the pair style contains a
matching keyword to the name of the KSpace style, as in this table:
Pair style : KSpace style
coul/long : ewald or pppm
coul/msm : msm
lj/long or buck/long : disp (for dispersion)
tip4p/long : tip4p :tb(s=:,ea=c)
:line
The {ewald} style performs a standard Ewald summation as described in
any solid-state physics text.
The {ewald/disp} style adds a long-range dispersion sum option for
1/r^6 potentials and is useful for simulation of interfaces
"(Veld)"_#Veld. It also performs standard Coulombic Ewald summations,
but in a more efficient manner than the {ewald} style. The 1/r^6
capability means that Lennard-Jones or Buckingham potentials can be
used without a cutoff, i.e. they become full long-range potentials.
The {ewald/disp} style can also be used with point-dipoles, see
"(Toukmaji)"_#Toukmaji.
The {ewald/dipole} style adds long-range standard Ewald summations
for dipole-dipole interactions, see "(Toukmaji)"_#Toukmaji.
The {ewald/dipole/spin} style adds long-range standard Ewald
summations for magnetic dipole-dipole interactions between
magnetic spins.
:line
The {pppm} style invokes a particle-particle particle-mesh solver
"(Hockney)"_#Hockney which maps atom charge to a 3d mesh, uses 3d FFTs
to solve Poisson's equation on the mesh, then interpolates electric
fields on the mesh points back to the atoms. It is closely related to
the particle-mesh Ewald technique (PME) "(Darden)"_#Darden used in
AMBER and CHARMM. The cost of traditional Ewald summation scales as
N^(3/2) where N is the number of atoms in the system. The PPPM solver
scales as Nlog(N) due to the FFTs, so it is almost always a faster
choice "(Pollock)"_#Pollock.
The {pppm/cg} style is identical to the {pppm} style except that it
has an optimization for systems where most particles are uncharged.
Similarly the {msm/cg} style implements the same optimization for {msm}.
The optional {smallq} argument defines the cutoff for the absolute
charge value which determines whether a particle is considered charged
or not. Its default value is 1.0e-5.
The {pppm/dipole} style invokes a particle-particle particle-mesh solver
for dipole-dipole interactions, following the method of "(Cerda)"_#Cerda2008.
The {pppm/dipole/spin} style invokes a particle-particle particle-mesh solver
for magnetic dipole-dipole interactions between magnetic spins.
The {pppm/tip4p} style is identical to the {pppm} style except that it
adds a charge at the massless 4th site in each TIP4P water molecule.
It should be used with "pair styles"_pair_style.html with a
{tip4p/long} in their style name.
The {pppm/stagger} style performs calculations using two different
meshes, one shifted slightly with respect to the other. This can
reduce force aliasing errors and increase the accuracy of the method
for a given mesh size. Or a coarser mesh can be used for the same
target accuracy, which saves CPU time. However, there is a trade-off
since FFTs on two meshes are now performed which increases the
computation required. See "(Cerutti)"_#Cerutti, "(Neelov)"_#Neelov,
and "(Hockney)"_#Hockney for details of the method.
For high relative accuracy, using staggered PPPM allows the mesh size
to be reduced by a factor of 2 in each dimension as compared to
regular PPPM (for the same target accuracy). This can give up to a 4x
speedup in the KSpace time (8x less mesh points, 2x more expensive).
However, for low relative accuracy, the staggered PPPM mesh size may
be essentially the same as for regular PPPM, which means the method
will be up to 2x slower in the KSpace time (simply 2x more expensive).
For more details and timings, see the "Speed tips"_Speed_tips.html doc
page.
NOTE: Using {pppm/stagger} may not give the same increase in the
accuracy of energy and pressure as it does in forces, so some caution
must be used if energy and/or pressure are quantities of interest,
such as when using a barostat.
:line
The {pppm/disp} and {pppm/disp/tip4p} styles add a mesh-based long-range
dispersion sum option for 1/r^6 potentials "(Isele-Holder)"_#Isele-Holder2012,
similar to the {ewald/disp} style. The 1/r^6 capability means
that Lennard-Jones or Buckingham potentials can be used without a cutoff,
i.e. they become full long-range potentials.
For these styles, you will possibly want to adjust the default choice
of parameters by using the "kspace_modify"_kspace_modify.html command.
This can be done by either choosing the Ewald and grid parameters, or
by specifying separate accuracies for the real and kspace
calculations. When not making any settings, the simulation will stop
with an error message. Further information on the influence of the
parameters and how to choose them is described in
"(Isele-Holder)"_#Isele-Holder2012,
"(Isele-Holder2)"_#Isele-Holder2013 and the "Howto
dispersion"_Howto_dispersion.html doc page.
:line
NOTE: All of the PPPM styles can be used with single-precision FFTs by
using the compiler switch -DFFT_SINGLE for the FFT_INC setting in your
lo-level Makefile. This setting also changes some of the PPPM
operations (e.g. mapping charge to mesh and interpolating electric
fields to particles) to be performed in single precision. This option
can speed-up long-range calculations, particularly in parallel or on
GPUs. The use of the -DFFT_SINGLE flag is discussed on the "Build
settings"_Build_settings.html doc page. MSM does not currently support
the -DFFT_SINGLE compiler switch.
:line
The {msm} style invokes a multi-level summation method MSM solver,
"(Hardy)"_#Hardy2006 or "(Hardy2)"_#Hardy2009, which maps atom charge
to a 3d mesh, and uses a multi-level hierarchy of coarser and coarser
meshes on which direct Coulomb solvers are done. This method does not
use FFTs and scales as N. It may therefore be faster than the other
K-space solvers for relatively large problems when running on large
core counts. MSM can also be used for non-periodic boundary conditions
and for mixed periodic and non-periodic boundaries.
MSM is most competitive versus Ewald and PPPM when only relatively
low accuracy forces, about 1e-4 relative error or less accurate,
are needed. Note that use of a larger Coulombic cutoff (i.e. 15
angstroms instead of 10 angstroms) provides better MSM accuracy for
both the real space and grid computed forces.
Currently calculation of the full pressure tensor in MSM is expensive.
Using the "kspace_modify"_kspace_modify.html {pressure/scalar yes}
command provides a less expensive way to compute the scalar pressure
(Pxx + Pyy + Pzz)/3.0. The scalar pressure can be used, for example,
to run an isotropic barostat. If the full pressure tensor is needed,
then calculating the pressure at every timestep or using a fixed
pressure simulation with MSM will cause the code to run slower.
:line
The {scafacos} style is a wrapper on the "ScaFaCoS Coulomb solver
library"_http://www.scafacos.de which provides a variety of solver
methods which can be used with LAMMPS. The paper by "(Who)"_#Who2012
gives an overview of ScaFaCoS.
ScaFaCoS was developed by a consortium of German research facilities
with a BMBF (German Ministry of Science and Education) funded project
in 2009-2012. Participants of the consortium were the Universities of
Bonn, Chemnitz, Stuttgart, and Wuppertal as well as the
Forschungszentrum Juelich.
The library is available for download at "http://scafacos.de" or can
be cloned from the git-repository
"git://github.com/scafacos/scafacos.git".
In order to use this KSpace style, you must download and build the
ScaFaCoS library, then build LAMMPS with the USER-SCAFACOS package
installed package which links LAMMPS to the ScaFaCoS library.
See details on "this page"_Section_packages.html#USER-SCAFACOS.
NOTE: Unlike other KSpace solvers in LAMMPS, ScaFaCoS computes all
Coulombic interactions, both short- and long-range. Thus you should
NOT use a Coulombic pair style when using kspace_style scafacos. This
also means the total Coulombic energy (short- and long-range) will be
tallied for "thermodynamic output"_thermo_style.html command as part
of the {elong} keyword; the {ecoul} keyword will be zero.
NOTE: See the current restriction below about use of ScaFaCoS in
LAMMPS with molecular charged systems or the TIP4P water model.
The specified {method} determines which ScaFaCoS algorithm is used.
These are the ScaFaCoS methods currently available from LAMMPS:
{fmm} = Fast Multi-Pole method
{p2nfft} = FFT-based Coulomb solver
{ewald} = Ewald summation
{direct} = direct O(N^2) summation
{p3m} = PPPM :ul
We plan to support additional ScaFaCoS solvers from LAMMPS in the
future. For an overview of the included solvers, refer to
"(Sutmann)"_#Sutmann2013
The specified {accuracy} is similar to the accuracy setting for other
LAMMPS KSpace styles, but is passed to ScaFaCoS, which can interpret
it in different ways for different methods it supports. Within the
ScaFaCoS library the {accuracy} is treated as a tolerance level
(either absolute or relative) for the chosen quantity, where the
quantity can be either the Columic field values, the per-atom Columic
energy or the total Columic energy. To select from these options, see
the "kspace_modify scafacos accuracy"_kspace_modify.html doc page.
The "kspace_modify scafacos"_kspace_modify.html command also explains
other ScaFaCoS options currently exposed to LAMMPS.
:line
The specified {accuracy} determines the relative RMS error in per-atom
forces calculated by the long-range solver. It is set as a
dimensionless number, relative to the force that two unit point
charges (e.g. 2 monovalent ions) exert on each other at a distance of
1 Angstrom. This reference value was chosen as representative of the
magnitude of electrostatic forces in atomic systems. Thus an accuracy
value of 1.0e-4 means that the RMS error will be a factor of 10000
smaller than the reference force.
The accuracy setting is used in conjunction with the pairwise cutoff
to determine the number of K-space vectors for style {ewald} or the
grid size for style {pppm} or {msm}.
Note that style {pppm} only computes the grid size at the beginning of
a simulation, so if the length or triclinic tilt of the simulation
cell increases dramatically during the course of the simulation, the
accuracy of the simulation may degrade. Likewise, if the
"kspace_modify slab"_kspace_modify.html option is used with
shrink-wrap boundaries in the z-dimension, and the box size changes
dramatically in z. For example, for a triclinic system with all three
tilt factors set to the maximum limit, the PPPM grid should be
increased roughly by a factor of 1.5 in the y direction and 2.0 in the
z direction as compared to the same system using a cubic orthogonal
simulation cell. One way to handle this issue if you have a long
simulation where the box size changes dramatically, is to break it
into shorter simulations (multiple "run"_run.html commands). This
works because the grid size is re-computed at the beginning of each
run. Another way to ensure the described accuracy requirement is met
is to run a short simulation at the maximum expected tilt or length,
note the required grid size, and then use the
"kspace_modify"_kspace_modify.html {mesh} command to manually set the
PPPM grid size to this value for the long run. The simulation then
will be "too accurate" for some portion of the run.
RMS force errors in real space for {ewald} and {pppm} are estimated
using equation 18 of "(Kolafa)"_#Kolafa, which is also referenced as
equation 9 of "(Petersen)"_#Petersen. RMS force errors in K-space for
{ewald} are estimated using equation 11 of "(Petersen)"_#Petersen,
which is similar to equation 32 of "(Kolafa)"_#Kolafa. RMS force
errors in K-space for {pppm} are estimated using equation 38 of
"(Deserno)"_#Deserno. RMS force errors for {msm} are estimated
using ideas from chapter 3 of "(Hardy)"_#Hardy2006, with equation 3.197
of particular note. When using {msm} with non-periodic boundary
conditions, it is expected that the error estimation will be too
pessimistic. RMS force errors for dipoles when using {ewald/disp}
or {ewald/dipole} are estimated using equations 33 and 46 of
"(Wang)"_#Wang. The RMS force errors for {pppm/dipole} are estimated
using the equations in "(Cerda)"_#Cerda2008.
See the "kspace_modify"_kspace_modify.html command for additional
options of the K-space solvers that can be set, including a {force}
option for setting an absolute RMS error in forces, as opposed to a
relative RMS error.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed on the "Speed packages"_Speed_packages.html doc
page. The accelerated styles take the same arguments and should
produce the same results, except for round-off and precision issues.
More specifically, the {pppm/gpu} style performs charge assignment and
force interpolation calculations on the GPU. These processes are
performed either in single or double precision, depending on whether
the -DFFT_SINGLE setting was specified in your lo-level Makefile, as
discussed above. The FFTs themselves are still calculated on the CPU.
If {pppm/gpu} is used with a GPU-enabled pair style, part of the PPPM
calculation can be performed concurrently on the GPU while other
calculations for non-bonded and bonded force calculation are performed
on the CPU.
The {pppm/kk} style also performs charge assignment and force
interpolation calculations on the GPU while the FFTs themselves are
calculated on the CPU in non-threaded mode.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP, and OPT packages respectively. They are only enabled if
LAMMPS was built with those packages. See the "Build
package"_Build_package.html doc page for more info.
See the "Speed packages"_Speed_packages.html doc page for more
instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
Note that the long-range electrostatic solvers in LAMMPS assume conducting
metal (tinfoil) boundary conditions for both charge and dipole
interactions. Vacuum boundary conditions are not currently supported.
The {ewald/disp}, {ewald}, {pppm}, and {msm} styles support
non-orthogonal (triclinic symmetry) simulation boxes. However,
triclinic simulation cells may not yet be supported by suffix versions
of these styles.
All of the kspace styles are part of the KSPACE package. They are
only enabled if LAMMPS was built with that package. See the "Build
package"_Build_package.html doc page for more info.
For MSM, a simulation must be 3d and one can use any combination of
periodic, non-periodic, or shrink-wrapped boundaries (specified using
the "boundary"_boundary.html command).
For Ewald and PPPM, a simulation must be 3d and periodic in all
dimensions. The only exception is if the slab option is set with
"kspace_modify"_kspace_modify.html, in which case the xy dimensions
must be periodic and the z dimension must be non-periodic.
The scafacos KSpace style will only be enabled if LAMMPS is built with
the USER-SCAFACOS package. See the "Build package"_Build_package.html
doc page for more info.
The use of ScaFaCos in LAMMPS does not yet support molecular charged
systems where the short-range Coulombic interactions between atoms in
the same bond/angle/dihedral are weighted by the
"special_bonds"_special_bonds.html command. Likewise it does not
support the "TIP4P water style" where a fictitious charge site is
introduced in each water molecule.
Finally, the methods {p3m} and {ewald} do not support computing the
virial, so this contribution is not included.
[Related commands:]
"kspace_modify"_kspace_modify.html, "pair_style
lj/cut/coul/long"_pair_lj.html, "pair_style
lj/charmm/coul/long"_pair_charmm.html, "pair_style
lj/long/coul/long"_pair_lj_long.html, "pair_style
buck/coul/long"_pair_buck.html
[Default:]
kspace_style none :pre
:line
:link(Darden)
[(Darden)] Darden, York, Pedersen, J Chem Phys, 98, 10089 (1993).
:link(Deserno)
[(Deserno)] Deserno and Holm, J Chem Phys, 109, 7694 (1998).
:link(Hockney)
[(Hockney)] Hockney and Eastwood, Computer Simulation Using Particles,
Adam Hilger, NY (1989).
:link(Kolafa)
[(Kolafa)] Kolafa and Perram, Molecular Simulation, 9, 351 (1992).
:link(Petersen)
[(Petersen)] Petersen, J Chem Phys, 103, 3668 (1995).
:link(Wang)
[(Wang)] Wang and Holm, J Chem Phys, 115, 6277 (2001).
:link(Pollock)
[(Pollock)] Pollock and Glosli, Comp Phys Comm, 95, 93 (1996).
:link(Cerutti)
[(Cerutti)] Cerutti, Duke, Darden, Lybrand, Journal of Chemical Theory
and Computation 5, 2322 (2009)
:link(Neelov)
[(Neelov)] Neelov, Holm, J Chem Phys 132, 234103 (2010)
:link(Veld)
[(Veld)] In 't Veld, Ismail, Grest, J Chem Phys, 127, 144711 (2007).
:link(Toukmaji)
[(Toukmaji)] Toukmaji, Sagui, Board, and Darden, J Chem Phys, 113,
10913 (2000).
:link(Isele-Holder2012)
[(Isele-Holder)] Isele-Holder, Mitchell, Ismail, J Chem Phys, 137,
174107 (2012).
:link(Isele-Holder2013)
[(Isele-Holder2)] Isele-Holder, Mitchell, Hammond, Kohlmeyer, Ismail,
J Chem Theory Comput 9, 5412 (2013).
:link(Hardy2006)
[(Hardy)] David Hardy thesis: Multilevel Summation for the Fast
Evaluation of Forces for the Simulation of Biomolecules, University of
Illinois at Urbana-Champaign, (2006).
:link(Hardy2009)
[(Hardy2)] Hardy, Stone, Schulten, Parallel Computing, 35, 164-177
(2009).
:link(Sutmann2013)
[(Sutmann)] Sutmann, Arnold, Fahrenberger, et. al., Physical review / E 88(6), 063308 (2013)
:link(Cerda2008)
[(Cerda)] Cerda, Ballenegger, Lenz, Holm, J Chem Phys 129, 234104 (2008)
:link(Who2012)
[(Who)] Who, Author2, Author3, J of Long Range Solvers, 35, 164-177
(2012).

4
doc/txt/lammps.book
View File

@ -26,6 +26,7 @@ Build_settings.html
Build_package.html
Build_extras.html
Build_windows.html
Build_development.html
Run_head.html
Run_basics.html
Run_options.html
@ -412,9 +413,11 @@ fix_wall_gran.html
fix_wall_gran_region.html
fix_wall_piston.html
fix_wall_reflect.html
fix_wall_reflect_stochastic.html
fix_wall_region.html
fix_wall_srd.html
lammps_commands_compute.html
compute.html
compute_modify.html
@ -461,6 +464,7 @@ compute_gyration_shape.html
compute_gyration_shape_chunk.html
compute_heat_flux.html
compute_hexorder_atom.html
compute_hma.html
compute_improper.html
compute_improper_local.html
compute_inertia_chunk.html

162
doc/txt/message.txt
View File

@ -1,162 +0,0 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Command_all.html)
:line
message command :h3
[Syntax:]
message which protocol mode arg :pre
which = {client} or {server} :ulb,l
protocol = {md} or {mc} :l
mode = {file} or {zmq} or {mpi/one} or {mpi/two} :l
{file} arg = filename
filename = file used for message exchanges
{zmq} arg = socket-ID
socket-ID for client = localhost:5555, see description below
socket-ID for server = *:5555, see description below
{mpi/one} arg = none
{mpi/two} arg = filename
filename = file used to establish communication between 2 MPI jobs :pre
:ule
[Examples:]
message client md file tmp.couple
message server md file tmp.couple :pre
message client md zmq localhost:5555
message server md zmq *:5555 :pre
message client md mpi/one
message server md mpi/one :pre
message client md mpi/two tmp.couple
message server md mpi/two tmp.couple :pre
[Description:]
Establish a messaging protocol between LAMMPS and another code for the
purpose of client/server coupling.
The "Howto client/server"_Howto_client_server.html doc page gives an
overview of client/server coupling of LAMMPS with another code 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.
:line
The {which} argument defines LAMMPS to be the client or the server.
:line
The {protocol} argument defines the format and content of messages
that will be exchanged between the two codes. The current options
are:
md = run dynamics with another code
mc = perform Monte Carlo moves with another code :ul
For protocol {md}, LAMMPS can be either a client or server. See the
"server md"_server_md.html doc page for details on the protocol.
For protocol {mc}, LAMMPS can be the server. See the "server
mc"_server_mc.html doc page for details on the protocol.
:line
The {mode} argument specifies how messages are exchanged between the
client and server codes. Both codes must use the same mode and use
consistent parameters.
For mode {file}, the 2 codes communicate via binary files. They must
use the same filename, which is actually a file prefix. Several files
with that prefix will be created and deleted as a simulation runs.
The filename can include a path. Both codes must be able to access
the path/file in a common filesystem.
For mode {zmq}, the 2 codes communicate via a socket on the server
code's machine. Support for socket messaging is provided by the
open-source "ZeroMQ library"_http://zeromq.org, which must be
installed on your system. The client specifies an IP address (IPv4
format) or the DNS name of the machine the server code is running on,
followed by a 4-digit port ID for the socket, separated by a colon.
E.g.
localhost:5555 # client and server running on same machine
192.168.1.1:5555 # server is 192.168.1.1
deptbox.uni.edu:5555 # server is deptbox.uni.edu :pre
The server specifies "*:5555" where "*" represents all available
interfaces on the server's machine, and the port ID must match
what the client specifies.
NOTE: What are allowed port IDs?
NOTE: Additional explanation is needed here about how to use the {zmq}
mode on a parallel machine, e.g. a cluster with many nodes.
For mode {mpi/one}, the 2 codes communicate via MPI and are launched
by the same mpirun command, e.g. with this syntax for OpenMPI:
mpirun -np 2 lmp_mpi -mpicolor 0 -in in.client -log log.client : -np 4 othercode args # LAMMPS is client
mpirun -np 2 othercode args : -np 4 lmp_mpi -mpicolor 1 -in in.server # LAMMPS is server :pre
Note the use of the "-mpicolor color" command-line argument with
LAMMPS. See the "command-line args"_Run_options.html doc page for
further explanation.
For mode {mpi/two}, the 2 codes communicate via MPI, but are launched
be 2 separate mpirun commands. The specified {filename} argument is a
file the 2 MPI processes will use to exchange info so that an MPI
inter-communicator can be established to enable the 2 codes to send
MPI messages to each other. Both codes must be able to access the
path/file in a common filesystem.
:line
Normally, the message command should be used at the top of a LAMMPS
input script. It performs an initial handshake with the other code to
setup messaging and to verify that both codes are using the same
message protocol and mode. Assuming both codes are launched at
(nearly) the same time, the other code should perform the same kind of
initialization.
If LAMMPS is the client code, it will begin sending messages when a
LAMMPS client command begins its operation. E.g. for the "fix
client/md"_fix_client_md.html command, it is when a "run"_run.html
command is executed.
If LAMMPS is the server code, it will begin receiving messages when
the "server"_server.html command is invoked.
A fix client command will terminate its messaging with the server when
LAMMPS ends, or the fix is deleted via the "unfix"_unfix.html command.
The server command will terminate its messaging with the client when the
client signals it. Then the remainder of the LAMMPS input script will
be processed.
If both codes do something similar, this means a new round of
client/server messaging can be initiated after termination by re-using
a 2nd message command in your LAMMPS input script, followed by a new
fix client or server command.
:line
[Restrictions:]
This command is part of the MESSAGE package. It is only enabled if
LAMMPS was built with that package. See the "Build
package"_Build_package.html doc page for more info.
[Related commands:]
"server"_server.html, "fix client/md"_fix_client_md.html
[Default:] none

793
doc/txt/pair_granular.txt
View File

@ -1,793 +0,0 @@
<script type="text/javascript"
src="https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML">
</script>
<script type="text/x-mathjax-config">
MathJax.Hub.Config({ TeX: { equationNumbers: {autoNumber: "AMS"} } });
</script>
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
pair_style granular command :h3
[Syntax:]
pair_style granular cutoff :pre
cutoff = global cutoff (optional). See discussion below. :ul
[Examples:]
pair_style granular
pair_coeff * * hooke 1000.0 50.0 tangential linear_nohistory 1.0 0.4 damping mass_velocity :pre
pair_style granular
pair_coeff * * hooke 1000.0 50.0 tangential linear_history 500.0 1.0 0.4 damping mass_velocity :pre
pair_style granular
pair_coeff * * hertz 1000.0 50.0 tangential mindlin 1000.0 1.0 0.4 :pre
pair_style granular
pair_coeff * * hertz/material 1e8 0.3 0.3 tangential mindlin_rescale NULL 1.0 0.4 damping tsuji :pre
pair_style granular
pair_coeff 1 * jkr 1000.0 500.0 0.3 10 tangential mindlin 800.0 1.0 0.5 rolling sds 500.0 200.0 0.5 twisting marshall
pair_coeff 2 2 hertz 200.0 100.0 tangential linear_history 300.0 1.0 0.1 rolling sds 200.0 100.0 0.1 twisting marshall :pre
pair_style granular
pair_coeff 1 1 dmt 1000.0 50.0 0.3 0.0 tangential mindlin NULL 0.5 0.5 rolling sds 500.0 200.0 0.5 twisting marshall
pair_coeff 2 2 dmt 1000.0 50.0 0.3 10.0 tangential mindlin NULL 0.5 0.1 rolling sds 500.0 200.0 0.1 twisting marshall :pre
[Description:]
The {granular} styles support a variety of options for the normal,
tangential, rolling and twisting forces resulting from contact between
two granular particles. This expands on the options offered by the
"pair gran/*"_pair_gran.html pair styles. The total computed forces
and torques are the sum of various models selected for the normal,
tangential, rolling and twisting modes of motion.
All model choices and parameters are entered in the
"pair_coeff"_pair_coeff.html command, as described below. Unlike
e.g. "pair gran/hooke"_pair_gran.html, coefficient values are not
global, but can be set to different values for different combinations
of particle types, as determined by the "pair_coeff"_pair_coeff.html
command. If the contact model choice is the same for two particle
types, the mixing for the cross-coefficients can be carried out
automatically. This is shown in the last example, where model
choices are the same for type 1 - type 1 as for type 2 - type2
interactions, but coefficients are different. In this case, the
mixed coefficients for type 1 - type 2 interactions can be determined from
mixing rules discussed below. For additional flexibility,
coefficients as well as model forms can vary between particle types,
as shown in the fourth example: type 1 - type 1 interactions are based
on a Johnson-Kendall-Roberts normal contact model and 2-2 interactions
are based on a DMT cohesive model (see below). In that example, 1-1
and 2-2 interactions have different model forms, in which case mixing of
coefficients cannot be determined, so 1-2 interactions must be
explicitly defined via the {pair_coeff 1 *} command, otherwise an
error would result.
:line
The first required keyword for the {pair_coeff} command is the normal
contact model. Currently supported options for normal contact models
and their required arguments are:
{hooke} : \(k_n\), \(\eta_\{n0\}\) (or \(e\))
{hertz} : \(k_n\), \(\eta_\{n0\}\) (or \(e\))
{hertz/material} : E, \(\eta_\{n0\}\) (or \(e\)), \(\nu\)
{dmt} : E, \(\eta_\{n0\}\) (or \(e\)), \(\nu\), \(\gamma\)
{jkr} : E, \(\eta_\{n0\}\) (or \(e\)), \(\nu\), \(\gamma\) :ol
Here, \(k_n\) is spring stiffness (with units that depend on model
choice, see below); \(\eta_\{n0\}\) is a damping prefactor (or, in its
place a coefficient of restitution \(e\), depending on the choice of
damping mode, see below); E is Young's modulus in units of
{force}/{length}^2, i.e. {pressure}; \(\nu\) is Poisson's ratio and
\(\gamma\) is a surface energy density, in units of
{energy}/{length}^2.
For the {hooke} model, the normal, elastic component of force acting
on particle {i} due to contact with particle {j} is given by:
\begin\{equation\}
\mathbf\{F\}_\{ne, Hooke\} = k_N \delta_\{ij\} \mathbf\{n\}
\end\{equation\}
Where \(\delta_\{ij\} = R_i + R_j - \|\mathbf\{r\}_\{ij\}\|\) is the particle
overlap, \(R_i, R_j\) are the particle radii, \(\mathbf\{r\}_\{ij\} =
\mathbf\{r\}_i - \mathbf\{r\}_j\) is the vector separating the two
particle centers (note the i-j ordering so that \(F_\{ne\}\) is
positive for repulsion), and \(\mathbf\{n\} =
\frac\{\mathbf\{r\}_\{ij\}\}\{\|\mathbf\{r\}_\{ij\}\|\}\). Therefore,
for {hooke}, the units of the spring constant \(k_n\) are
{force}/{distance}, or equivalently {mass}/{time^2}.
For the {hertz} model, the normal component of force is given by:
\begin\{equation\}
\mathbf\{F\}_\{ne, Hertz\} = k_N R_\{eff\}^\{1/2\}\delta_\{ij\}^\{3/2\} \mathbf\{n\}
\end\{equation\}
Here, \(R_\{eff\} = \frac\{R_i R_j\}\{R_i + R_j\}\) is the effective
radius, denoted for simplicity as {R} from here on. For {hertz}, the
units of the spring constant \(k_n\) are {force}/{length}^2, or
equivalently {pressure}.
For the {hertz/material} model, the force is given by:
\begin\{equation\}
\mathbf\{F\}_\{ne, Hertz/material\} = \frac\{4\}\{3\} E_\{eff\} R_\{eff\}^\{1/2\}\delta_\{ij\}^\{3/2\} \mathbf\{n\}
\end\{equation\}
Here, \(E_\{eff\} = E = \left(\frac\{1-\nu_i^2\}\{E_i\} +
\frac\{1-\nu_j^2\}\{E_j\}\right)^\{-1\}\) is the effective Young's
modulus, with \(\nu_i, \nu_j \) the Poisson ratios of the particles of
types {i} and {j}. Note that if the elastic modulus and the shear
modulus of the two particles are the same, the {hertz/material} model
is equivalent to the {hertz} model with \(k_N = 4/3 E_\{eff\}\)
The {dmt} model corresponds to the
"(Derjaguin-Muller-Toporov)"_#DMT1975 cohesive model, where the force
is simply Hertz with an additional attractive cohesion term:
\begin\{equation\}
\mathbf\{F\}_\{ne, dmt\} = \left(\frac\{4\}\{3\} E R^\{1/2\}\delta_\{ij\}^\{3/2\} - 4\pi\gamma R\right)\mathbf\{n\}
\end\{equation\}
The {jkr} model is the "(Johnson-Kendall-Roberts)"_#JKR1971 model,
where the force is computed as:
\begin\{equation\}
\label\{eq:force_jkr\}
\mathbf\{F\}_\{ne, jkr\} = \left(\frac\{4Ea^3\}\{3R\} - 2\pi a^2\sqrt\{\frac\{4\gamma E\}\{\pi a\}\}\right)\mathbf\{n\}
\end\{equation\}
Here, {a} is the radius of the contact zone, related to the overlap
\(\delta\) according to:
\begin\{equation\}
\delta = a^2/R - 2\sqrt\{\pi \gamma a/E\}
\end\{equation\}
LAMMPS internally inverts the equation above to solve for {a} in terms
of \(\delta\), then solves for the force in the previous
equation. Additionally, note that the JKR model allows for a tensile
force beyond contact (i.e. for \(\delta < 0\)), up to a maximum of
\(3\pi\gamma R\) (also known as the 'pull-off' force). Note that this
is a hysteretic effect, where particles that are not contacting
initially will not experience force until they come into contact
\(\delta \geq 0\); as they move apart and (\(\delta < 0\)), they
experience a tensile force up to \(3\pi\gamma R\), at which point they
lose contact.
:line
In addition, the normal force is augmented by a damping term of the
following general form:
\begin\{equation\}
\mathbf\{F\}_\{n,damp\} = -\eta_n \mathbf\{v\}_\{n,rel\}
\end\{equation\}
Here, \(\mathbf\{v\}_\{n,rel\} = (\mathbf\{v\}_j - \mathbf\{v\}_i)
\cdot \mathbf\{n\} \mathbf\{n\}\) is the component of relative velocity along
\(\mathbf\{n\}\).
The optional {damping} keyword to the {pair_coeff} command followed by
a keyword determines the model form of the damping factor \(\eta_n\),
and the interpretation of the \(\eta_\{n0\}\) or \(e\) coefficients
specified as part of the normal contact model settings. The {damping}
keyword and corresponding model form selection may be appended
anywhere in the {pair coeff} command. Note that the choice of damping
model affects both the normal and tangential damping (and depending on
other settings, potentially also the twisting damping). The options
for the damping model currently supported are:
{velocity}
{mass_velocity}
{viscoelastic}
{tsuji} :ol
If the {damping} keyword is not specified, the {viscoelastic} model is
used by default.
For {damping velocity}, the normal damping is simply equal to the
user-specified damping coefficient in the {normal} model:
\begin\{equation\}
\eta_n = \eta_\{n0\}
\end\{equation\}
Here, \(\eta_\{n0\}\) is the damping coefficient specified for the normal
contact model, in units of {mass}/{time}.
For {damping mass_velocity}, the normal damping is given by:
\begin\{equation\}
\eta_n = \eta_\{n0\} m_\{eff\}
\end\{equation\}
Here, \(\eta_\{n0\}\) is the damping coefficient specified for the normal
contact model, in units of {mass}/{time} and
\(m_\{eff\} = m_i m_j/(m_i + m_j)\) is the effective mass.
Use {damping mass_velocity} to reproduce the damping behavior of
{pair gran/hooke/*}.
The {damping viscoelastic} model is based on the viscoelastic
treatment of "(Brilliantov et al)"_#Brill1996, where the normal
damping is given by:
\begin\{equation\}
\eta_n = \eta_\{n0\}\ a m_\{eff\}
\end\{equation\}
Here, {a} is the contact radius, given by \(a =\sqrt\{R\delta\}\)
for all models except {jkr}, for which it is given implicitly according
to \(\delta = a^2/R - 2\sqrt\{\pi \gamma a/E\}\). For {damping viscoelastic},
\(\eta_\{n0\}\) is in units of 1/({time}*{distance}).
The {tsuji} model is based on the work of "(Tsuji et
al)"_#Tsuji1992. Here, the damping coefficient specified as part of
the normal model is interpreted as a restitution coefficient
\(e\). The damping constant \(\eta_n\) is given by:
\begin\{equation\}
\eta_n = \alpha (m_\{eff\}k_n)^\{1/2\}
\end\{equation\}
For normal contact models based on material parameters, \(k_n =
4/3Ea\). The parameter \(\alpha\) is related to the restitution
coefficient {e} according to:
\begin\{equation\}
\alpha = 1.2728-4.2783e+11.087e^2-22.348e^3+27.467e^4-18.022e^5+4.8218e^6
\end\{equation\}
The dimensionless coefficient of restitution \(e\) specified as part
of the normal contact model parameters should be between 0 and 1, but
no error check is performed on this.
The total normal force is computed as the sum of the elastic and
damping components:
\begin\{equation\}
\mathbf\{F\}_n = \mathbf\{F\}_\{ne\} + \mathbf\{F\}_\{n,damp\}
\end\{equation\}
:line
The {pair_coeff} command also requires specification of the tangential
contact model. The required keyword {tangential} is expected, followed
by the model choice and associated parameters. Currently supported
tangential model choices and their expected parameters are as follows:
{linear_nohistory} : \(x_\{\gamma,t\}\), \(\mu_s\)
{linear_history} : \(k_t\), \(x_\{\gamma,t\}\), \(\mu_s\)
{mindlin} : \(k_t\) or NULL, \(x_\{\gamma,t\}\), \(\mu_s\)
{mindlin_rescale} : \(k_t\) or NULL, \(x_\{\gamma,t\}\), \(\mu_s\) :ol
Here, \(x_\{\gamma,t\}\) is a dimensionless multiplier for the normal
damping \(\eta_n\) that determines the magnitude of the tangential
damping, \(\mu_t\) is the tangential (or sliding) friction
coefficient, and \(k_t\) is the tangential stiffness coefficient.
For {tangential linear_nohistory}, a simple velocity-dependent Coulomb
friction criterion is used, which mimics the behavior of the {pair
gran/hooke} style. The tangential force (\mathbf\{F\}_t\) is given by:
\begin\{equation\}
\mathbf\{F\}_t = -min(\mu_t F_\{n0\}, \|\mathbf\{F\}_\mathrm\{t,damp\}\|) \mathbf\{t\}
\end\{equation\}
The tangential damping force \(\mathbf\{F\}_\mathrm\{t,damp\}\) is given by:
\begin\{equation\}
\mathbf\{F\}_\mathrm\{t,damp\} = -\eta_t \mathbf\{v\}_\{t,rel\}
\end\{equation\}
The tangential damping prefactor \(\eta_t\) is calculated by scaling
the normal damping \(\eta_n\) (see above):
\begin\{equation\}
\eta_t = -x_\{\gamma,t\} \eta_n
\end\{equation\}
The normal damping prefactor \(\eta_n\) is determined by the choice
of the {damping} keyword, as discussed above. Thus, the {damping}
keyword also affects the tangential damping. The parameter
\(x_\{\gamma,t\}\) is a scaling coefficient. Several works in the
literature use \(x_\{\gamma,t\} = 1\) ("Marshall"_#Marshall2009,
"Tsuji et al"_#Tsuji1992, "Silbert et al"_#Silbert2001). The relative
tangential velocity at the point of contact is given by
\(\mathbf\{v\}_\{t, rel\} = \mathbf\{v\}_\{t\} - (R_i\Omega_i +
R_j\Omega_j) \times \mathbf\{n\}\), where \(\mathbf\{v\}_\{t\} =
\mathbf\{v\}_r - \mathbf\{v\}_r\cdot\mathbf\{n\}\{n\}\),
\(\mathbf\{v\}_r = \mathbf\{v\}_j - \mathbf\{v\}_i\).
The direction of the applied force is \(\mathbf\{t\} =
\mathbf\{v_\{t,rel\}\}/\|\mathbf\{v_\{t,rel\}\}\|\) .
The normal force value \(F_\{n0\}\) used to compute the critical force
depends on the form of the contact model. For non-cohesive models
({hertz}, {hertz/material}, {hooke}), it is given by the magnitude of
the normal force:
\begin\{equation\}
F_\{n0\} = \|\mathbf\{F\}_n\|
\end\{equation\}
For cohesive models such as {jkr} and {dmt}, the critical force is
adjusted so that the critical tangential force approaches \(\mu_t
F_\{pulloff\}\), see "Marshall"_#Marshall2009, equation 43, and
"Thornton"_#Thornton1991. For both models, \(F_\{n0\}\) takes the
form:
\begin\{equation\}
F_\{n0\} = \|\mathbf\{F\}_ne + 2 F_\{pulloff\}\|
\end\{equation\}
Where \(F_\{pulloff\} = 3\pi \gamma R \) for {jkr}, and
\(F_\{pulloff\} = 4\pi \gamma R \) for {dmt}.
The remaining tangential options all use accumulated tangential
displacement (i.e. contact history). This is discussed below in the
context of the {linear_history} option, but the same treatment of the
accumulated displacement applies to the other options as well.
For {tangential linear_history}, the tangential force is given by:
\begin\{equation\}
\mathbf\{F\}_t = -min(\mu_t F_\{n0\}, \|-k_t\mathbf\{\xi\} + \mathbf\{F\}_\mathrm\{t,damp\}\|) \mathbf\{t\}
\end\{equation\}
Here, \(\mathbf\{\xi\}\) is the tangential displacement accumulated
during the entire duration of the contact:
\begin\{equation\}
\mathbf\{\xi\} = \int_\{t0\}^t \mathbf\{v\}_\{t,rel\}(\tau) \mathrm\{d\}\tau
\end\{equation\}
This accumulated tangential displacement must be adjusted to account
for changes in the frame of reference of the contacting pair of
particles during contact. This occurs due to the overall motion of the
contacting particles in a rigid-body-like fashion during the duration
of the contact. There are two modes of motion that are relevant: the
'tumbling' rotation of the contacting pair, which changes the
orientation of the plane in which tangential displacement occurs; and
'spinning' rotation of the contacting pair about the vector connecting
their centers of mass (\(\mathbf\{n\}\)). Corrections due to the
former mode of motion are made by rotating the accumulated
displacement into the plane that is tangential to the contact vector
at each step, or equivalently removing any component of the tangential
displacement that lies along \(\mathbf\{n\}\), and rescaling to
preserve the magnitude. This follows the discussion in
"Luding"_#Luding2008, see equation 17 and relevant discussion in that
work:
\begin\{equation\}
\mathbf\{\xi\} = \left(\mathbf\{\xi'\} - (\mathbf\{n\} \cdot \mathbf\{\xi'\})\mathbf\{n\}\right) \frac\{\|\mathbf\{\xi'\}\|\}\{\|\mathbf\{\xi'\}\| - \mathbf\{n\}\cdot\mathbf\{\xi'\}\}
\label\{eq:rotate_displacements\}
\end\{equation\}
Here, \(\mathbf\{\xi'\}\) is the accumulated displacement prior to the
current time step and \(\mathbf\{\xi\}\) is the corrected
displacement. Corrections to the displacement due to the second mode
of motion described above (rotations about \(\mathbf\{n\}\)) are not
currently implemented, but are expected to be minor for most
simulations.
Furthermore, when the tangential force exceeds the critical force, the
tangential displacement is re-scaled to match the value for the
critical force (see "Luding"_#Luding2008, equation 20 and related
discussion):
\begin\{equation\}
\mathbf\{\xi\} = -\frac\{1\}\{k_t\}\left(\mu_t F_\{n0\}\mathbf\{t\} + \mathbf\{F\}_\{t,damp\}\right)
\end\{equation\}
The tangential force is added to the total normal force (elastic plus
damping) to produce the total force on the particle. The tangential
force also acts at the contact point (defined as the center of the
overlap region) to induce a torque on each particle according to:
\begin\{equation\}
\mathbf\{\tau\}_i = -(R_i - 0.5 \delta) \mathbf\{n\} \times \mathbf\{F\}_t
\end\{equation\}
\begin\{equation\}
\mathbf\{\tau\}_j = -(R_j - 0.5 \delta) \mathbf\{n\} \times \mathbf\{F\}_t
\end\{equation\}
For {tangential mindlin}, the "Mindlin"_#Mindlin1949 no-slip solution is used, which differs from the {linear_history}
option by an additional factor of {a}, the radius of the contact region. The tangential force is given by:
\begin\{equation\}
\mathbf\{F\}_t = -min(\mu_t F_\{n0\}, \|-k_t a \mathbf\{\xi\} + \mathbf\{F\}_\mathrm\{t,damp\}\|) \mathbf\{t\}
\end\{equation\}
Here, {a} is the radius of the contact region, given by \(a =\sqrt\{R\delta\}\)
for all normal contact models, except for {jkr}, where it is given
implicitly by \(\delta = a^2/R - 2\sqrt\{\pi \gamma a/E\}\), see
discussion above. To match the Mindlin solution, one should set \(k_t
= 8G\), where \(G\) is the shear modulus, related to Young's modulus
\(E\) by \(G = E/(2(1+\nu))\), where \(\nu\) is Poisson's ratio. This
can also be achieved by specifying {NULL} for \(k_t\), in which case a
normal contact model that specifies material parameters \(E\) and
\(\nu\) is required (e.g. {hertz/material}, {dmt} or {jkr}). In this
case, mixing of the shear modulus for different particle types {i} and
{j} is done according to:
\begin\{equation\}
1/G = 2(2-\nu_i)(1+\nu_i)/E_i + 2(2-\nu_j)(1+\nu_j)/E_j
\end\{equation\}
The {mindlin_rescale} option uses the same form as {mindlin}, but the
magnitude of the tangential displacement is re-scaled as the contact
unloads, i.e. if \(a < a_\{t_\{n-1\}\}\):
\begin\{equation\}
\mathbf\{\xi\} = \mathbf\{\xi_\{t_\{n-1\}\}\} \frac\{a\}\{a_\{t_\{n-1\}\}\}
\end\{equation\}
Here, \(t_\{n-1\}\) indicates the value at the previous time
step. This rescaling accounts for the fact that a decrease in the
contact area upon unloading leads to the contact being unable to
support the previous tangential loading, and spurious energy is
created without the rescaling above ("Walton"_#WaltonPC ). See also
discussion in "Thornton et al, 2013"_#Thornton2013 , particularly
equation 18(b) of that work and associated discussion.
:line
The optional {rolling} keyword enables rolling friction, which resists
pure rolling motion of particles. The options currently supported are:
{none}
{sds} : \(k_\{roll\}\), \(\gamma_\{roll\}\), \(\mu_\{roll\}\) :ol
If the {rolling} keyword is not specified, the model defaults to {none}.
For {rolling sds}, rolling friction is computed via a
spring-dashpot-slider, using a 'pseudo-force' formulation, as detailed
by "Luding"_#Luding2008. Unlike the formulation in
"Marshall"_#Marshall2009, this allows for the required adjustment of
rolling displacement due to changes in the frame of reference of the
contacting pair. The rolling pseudo-force is computed analogously to
the tangential force:
\begin\{equation\}
\mathbf\{F\}_\{roll,0\} = k_\{roll\} \mathbf\{\xi\}_\{roll\} - \gamma_\{roll\} \mathbf\{v\}_\{roll\}
\end\{equation\}
Here, \(\mathbf\{v\}_\{roll\} = -R(\mathbf\{\Omega\}_i -
\mathbf\{\Omega\}_j) \times \mathbf\{n\}\) is the relative rolling
velocity, as given in "Wang et al"_#Wang2015 and
"Luding"_#Luding2008. This differs from the expressions given by "Kuhn
and Bagi"_#Kuhn2004 and used in "Marshall"_#Marshall2009; see "Wang et
al"_#Wang2015 for details. The rolling displacement is given by:
\begin\{equation\}
\mathbf\{\xi\}_\{roll\} = \int_\{t_0\}^t \mathbf\{v\}_\{roll\} (\tau) \mathrm\{d\} \tau
\end\{equation\}
A Coulomb friction criterion truncates the rolling pseudo-force if it
exceeds a critical value:
\begin\{equation\}
\mathbf\{F\}_\{roll\} = min(\mu_\{roll\} F_\{n,0\}, \|\mathbf\{F\}_\{roll,0\}\|)\mathbf\{k\}
\end\{equation\}
Here, \(\mathbf\{k\} =
\mathbf\{v\}_\{roll\}/\|\mathbf\{v\}_\{roll\}\|\) is the direction of
the pseudo-force. As with tangential displacement, the rolling
displacement is rescaled when the critical force is exceeded, so that
the spring length corresponds the critical force. Additionally, the
displacement is adjusted to account for rotations of the frame of
reference of the two contacting particles in a manner analogous to the
tangential displacement.
The rolling pseudo-force does not contribute to the total force on
either particle (hence 'pseudo'), but acts only to induce an equal and
opposite torque on each particle, according to:
\begin\{equation\}
\tau_\{roll,i\} = R_\{eff\} \mathbf\{n\} \times \mathbf\{F\}_\{roll\}
\end\{equation\}
\begin\{equation\}
\tau_\{roll,j\} = -\tau_\{roll,i\}
\end\{equation\}
:line
The optional {twisting} keyword enables twisting friction, which
resists rotation of two contacting particles about the vector
\(\mathbf\{n\}\) that connects their centers. The options currently
supported are:
{none}
{sds} : \(k_\{twist\}\), \(\gamma_\{twist\}\), \(\mu_\{twist\}\)
{marshall} :ol
If the {twisting} keyword is not specified, the model defaults to {none}.
For both {twisting sds} and {twisting marshall}, a history-dependent
spring-dashpot-slider is used to compute the twisting torque. Because
twisting displacement is a scalar, there is no need to adjust for
changes in the frame of reference due to rotations of the particle
pair. The formulation in "Marshall"_#Marshall2009 therefore provides
the most straightforward treatment:
\begin\{equation\}
\tau_\{twist,0\} = -k_\{twist\}\xi_\{twist\} - \gamma_\{twist\}\Omega_\{twist\}
\end\{equation\}
Here \(\xi_\{twist\} = \int_\{t_0\}^t \Omega_\{twist\} (\tau)
\mathrm\{d\}\tau\) is the twisting angular displacement, and
\(\Omega_\{twist\} = (\mathbf\{\Omega\}_i - \mathbf\{\Omega\}_j) \cdot
\mathbf\{n\}\) is the relative twisting angular velocity. The torque
is then truncated according to:
\begin\{equation\}
\tau_\{twist\} = min(\mu_\{twist\} F_\{n,0\}, \tau_\{twist,0\})
\end\{equation\}
Similar to the sliding and rolling displacement, the angular
displacement is rescaled so that it corresponds to the critical value
if the twisting torque exceeds this critical value:
\begin\{equation\}
\xi_\{twist\} = \frac\{1\}\{k_\{twist\}\} (\mu_\{twist\} F_\{n,0\}sgn(\Omega_\{twist\}) - \gamma_\{twist\}\Omega_\{twist\})
\end\{equation\}
For {twisting sds}, the coefficients \(k_\{twist\}, \gamma_\{twist\}\)
and \(\mu_\{twist\}\) are simply the user input parameters that follow
the {twisting sds} keywords in the {pair_coeff} command.
For {twisting_marshall}, the coefficients are expressed in terms of
sliding friction coefficients, as discussed in
"Marshall"_#Marshall2009 (see equations 32 and 33 of that work):
\begin\{equation\}
k_\{twist\} = 0.5k_ta^2
\end\{equation\}
\begin\{equation\}
\eta_\{twist\} = 0.5\eta_ta^2
\end\{equation\}
\begin\{equation\}
\mu_\{twist\} = \frac\{2\}\{3\}a\mu_t
\end\{equation\}
Finally, the twisting torque on each particle is given by:
\begin\{equation\}
\mathbf\{\tau\}_\{twist,i\} = \tau_\{twist\}\mathbf\{n\}
\end\{equation\}
\begin\{equation\}
\mathbf\{\tau\}_\{twist,j\} = -\mathbf\{\tau\}_\{twist,i\}
\end\{equation\}
:line
The {granular} pair style can reproduce the behavior of the
{pair gran/*} styles with the appropriate settings (some very
minor differences can be expected due to corrections in
displacement history frame-of-reference, and the application
of the torque at the center of the contact rather than
at each particle). The first example above
is equivalent to {pair gran/hooke 1000.0 NULL 50.0 50.0 0.4 1}.
The second example is equivalent to
{pair gran/hooke/history 1000.0 500.0 50.0 50.0 0.4 1}.
The third example is equivalent to
{pair gran/hertz/history 1000.0 500.0 50.0 50.0 0.4 1}.
:line
LAMMPS automatically sets pairwise cutoff values for {pair_style
granular} based on particle radii (and in the case of {jkr} pull-off
distances). In the vast majority of situations, this is adequate.
However, a cutoff value can optionally be appended to the {pair_style
granular} command to specify a global cutoff (i.e. a cutoff for all
atom types). Additionally, the optional {cutoff} keyword can be passed
to the {pair_coeff} command, followed by a cutoff value. This will
set a pairwise cutoff for the atom types in the {pair_coeff} command.
These options may be useful in some rare cases where the automatic
cutoff determination is not sufficient, e.g. if particle diameters
are being modified via the {fix adapt} command. In that case, the
global cutoff specified as part of the {pair_style granular} command
is applied to all atom types, unless it is overridden for a given atom
type combination by the {cutoff} value specified in the {pair coeff}
command. If {cutoff} is only specified in the {pair coeff} command
and no global cutoff is appended to the {pair_style granular} command,
then LAMMPS will use that cutoff for the specified atom type
combination, and automatically set pairwise cutoffs for the remaining
atom types.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed on the "Speed packages"_Speed_packages.html doc
page. The accelerated styles take the same arguments and should
produce the same results, except for round-off and precision issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Build
package"_Build_package.html doc page for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
switch"_Run_options.html when you invoke LAMMPS, or you can use the
"suffix"_suffix.html command in your input script.
See the "Speed packages"_Speed_packages.html doc page for more
instructions on how to use the accelerated styles effectively.
:line
[Mixing, shift, table, tail correction, restart, rRESPA info]:
The "pair_modify"_pair_modify.html mix, shift, table, and tail options
are not relevant for granular pair styles.
Mixing of coefficients is carried out using geometric averaging for
most quantities, e.g. if friction coefficient for type 1-type 1
interactions is set to \(\mu_1\), and friction coefficient for type
2-type 2 interactions is set to \(\mu_2\), the friction coefficient
for type1-type2 interactions is computed as \(\sqrt\{\mu_1\mu_2\}\)
(unless explicitly specified to a different value by a {pair_coeff 1 2
...} command). The exception to this is elastic modulus, only
applicable to {hertz/material}, {dmt} and {jkr} normal contact
models. In that case, the effective elastic modulus is computed as:
\begin\{equation\}
E_\{eff,ij\} = \left(\frac\{1-\nu_i^2\}\{E_i\} + \frac\{1-\nu_j^2\}\{E_j\}\right)^\{-1\}
\end\{equation\}
If the {i-j} coefficients \(E_\{ij\}\) and \(\nu_\{ij\}\) are
explicitly specified, the effective modulus is computed as:
\begin\{equation\}
E_\{eff,ij\} = \left(\frac\{1-\nu_\{ij\}^2\}\{E_\{ij\}\} + \frac\{1-\nu_\{ij\}^2\}\{E_\{ij\}\}\right)^\{-1\}
\end\{equation\}
or
\begin\{equation\}
E_\{eff,ij\} = \frac\{E_\{ij\}\}\{2(1-\nu_\{ij\})\}
\end\{equation\}
These pair styles write their information to "binary restart
files"_restart.html, so a pair_style command does not need to be
specified in an input script that reads a restart file.
These pair styles can only be used via the {pair} keyword of the
"run_style respa"_run_style.html command. They do not support the
{inner}, {middle}, {outer} keywords.
The single() function of these pair styles returns 0.0 for the energy
of a pairwise interaction, since energy is not conserved in these
dissipative potentials. It also returns only the normal component of
the pairwise interaction force. However, the single() function also
calculates 12 extra pairwise quantities. The first 3 are the
components of the tangential force between particles I and J, acting
on particle I. The 4th is the magnitude of this tangential force.
The next 3 (5-7) are the components of the rolling torque acting on
particle I. The next entry (8) is the magnitude of the rolling torque.
The next entry (9) is the magnitude of the twisting torque acting
about the vector connecting the two particle centers.
The last 3 (10-12) are the components of the vector connecting
the centers of the two particles (x_I - x_J).
These extra quantities can be accessed by the "compute
pair/local"_compute_pair_local.html command, as {p1}, {p2}, ...,
{p12}.
:line
[Restrictions:]
All the granular pair styles are part of the GRANULAR package. It is
only enabled if LAMMPS was built with that package. See the "Build
package"_Build_package.html doc page for more info.
These pair styles require that atoms store torque and angular velocity
(omega) as defined by the "atom_style"_atom_style.html. They also
require a per-particle radius is stored. The {sphere} atom style does
all of this.
This pair style requires you to use the "comm_modify vel
yes"_comm_modify.html command so that velocities are stored by ghost
atoms.
These pair styles will not restart exactly when using the
"read_restart"_read_restart.html command, though they should provide
statistically similar results. This is because the forces they
compute depend on atom velocities. See the
"read_restart"_read_restart.html command for more details.
[Related commands:]
"pair_coeff"_pair_coeff.html
"pair gran/*"_pair_gran.html
[Default:]
For the {pair_coeff} settings: {damping viscoelastic}, {rolling none},
{twisting none}.
[References:]
:link(Brill1996)
[(Brilliantov et al, 1996)] Brilliantov, N. V., Spahn, F., Hertzsch,
J. M., & Poschel, T. (1996). Model for collisions in granular
gases. Physical review E, 53(5), 5382.
:link(Tsuji1992)
[(Tsuji et al, 1992)] Tsuji, Y., Tanaka, T., & Ishida,
T. (1992). Lagrangian numerical simulation of plug flow of
cohesionless particles in a horizontal pipe. Powder technology, 71(3),
239-250.
:link(JKR1971)
[(Johnson et al, 1971)] Johnson, K. L., Kendall, K., & Roberts,
A. D. (1971). Surface energy and the contact of elastic
solids. Proc. R. Soc. Lond. A, 324(1558), 301-313.
:link(DMT1975)
[Derjaguin et al, 1975)] Derjaguin, B. V., Muller, V. M., & Toporov,
Y. P. (1975). Effect of contact deformations on the adhesion of
particles. Journal of Colloid and interface science, 53(2), 314-326.
:link(Luding2008)
[(Luding, 2008)] Luding, S. (2008). Cohesive, frictional powders:
contact models for tension. Granular matter, 10(4), 235.
:link(Marshall2009)
[(Marshall, 2009)] Marshall, J. S. (2009). Discrete-element modeling
of particulate aerosol flows. Journal of Computational Physics,
228(5), 1541-1561.
:link(Silbert2001)
[(Silbert, 2001)] Silbert, L. E., Ertas, D., Grest, G. S., Halsey,
T. C., Levine, D., & Plimpton, S. J. (2001). Granular flow down an
inclined plane: Bagnold scaling and rheology. Physical Review E,
64(5), 051302.
:link(Kuhn2004)
[(Kuhn and Bagi, 2005)] Kuhn, M. R., & Bagi, K. (2004). Contact
rolling and deformation in granular media. International journal of
solids and structures, 41(21), 5793-5820.
:link(Wang2015)
[(Wang et al, 2015)] Wang, Y., Alonso-Marroquin, F., & Guo,
W. W. (2015). Rolling and sliding in 3-D discrete element
models. Particuology, 23, 49-55.
:link(Thornton1991)
[(Thornton, 1991)] Thornton, C. (1991). Interparticle sliding in the
presence of adhesion. J. Phys. D: Appl. Phys. 24 1942
:link(Mindlin1949)
[(Mindlin, 1949)] Mindlin, R. D. (1949). Compliance of elastic bodies
in contact. J. Appl. Mech., ASME 16, 259-268.
:link(Thornton2013)
[(Thornton et al, 2013)] Thornton, C., Cummins, S. J., & Cleary,
P. W. (2013). An investigation of the comparative behaviour of
alternative contact force models during inelastic collisions. Powder
Technology, 233, 30-46.
:link(WaltonPC)
[(Otis R. Walton)] Walton, O.R., Personal Communication

159
doc/txt/pair_ilp_graphene_hbn.txt
View File

@ -1,159 +0,0 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
pair_style ilp/graphene/hbn command :h3
[Syntax:]
pair_style \[hybrid/overlay ...\] ilp/graphene/hbn cutoff tap_flag :pre
cutoff = global cutoff (distance units)
tap_flag = 0/1 to turn off/on the taper function :ul
[Examples:]
pair_style hybrid/overlay ilp/graphene/hbn 16.0 1
pair_coeff * * ilp/graphene/hbn BNCH.ILP B N C :pre
pair_style hybrid/overlay rebo tersoff ilp/graphene/hbn 16.0 coul/shield 16.0
pair_coeff * * rebo CH.rebo NULL NULL C
pair_coeff * * tersoff BNC.tersoff B N NULL
pair_coeff * * ilp/graphene/hbn BNCH.ILP B N C
pair_coeff 1 1 coul/shield 0.70
pair_coeff 1 2 coul/shield 0.695
pair_coeff 2 2 coul/shield 0.69 :pre
[Description:]
The {ilp/graphene/hbn} style computes the registry-dependent interlayer
potential (ILP) potential as described in "(Leven1)"_#Leven1,
"(Leven2)"_#Leven2 and "(Maaravi)"_#Maaravi2.
The normals are calculated in the way as described
in "(Kolmogorov)"_#Kolmogorov2.
:c,image(Eqs/pair_ilp_graphene_hbn.jpg)
Where Tap(r_ij) is the taper function which provides a continuous
cutoff (up to third derivative) for interatomic separations larger than
r_c "(Maaravi)"_#Maaravi2. The definitions of each parameter in the above
equation can be found in "(Leven1)"_#Leven1 and "(Maaravi)"_#Maaravi2.
It is important to include all the pairs to build the neighbor list for
calculating the normals.
NOTE: This potential (ILP) is intended for interlayer interactions between two
different layers of graphene, hexagonal boron nitride (h-BN) and their hetero-junction.
To perform a realistic simulation, this potential must be used in combination with
intralayer potential, such as "AIREBO"_pair_airebo.html or "Tersoff"_pair_tersoff.html potential.
To keep the intralayer properties unaffected, the interlayer interaction
within the same layers should be avoided. Hence, each atom has to have a layer
identifier such that atoms residing on the same layer interact via the
appropriate intralayer potential and atoms residing on different layers
interact via the ILP. Here, the molecule id is chosen as the layer identifier,
thus a data file with the "full" atom style is required to use this potential.
The parameter file (e.g. BNCH.ILP), is intended for use with {metal}
"units"_units.html, with energies in meV. Two additional parameters,
{S}, and {rcut} are included in the parameter file. {S} is designed to
facilitate scaling of energies. {rcut} is designed to build the neighbor
list for calculating the normals for each atom pair.
NOTE: The parameters presented in the parameter file (e.g. BNCH.ILP),
are fitted with taper function by setting the cutoff equal to 16.0
Angstrom. Using different cutoff or taper function should be careful.
The parameters for atoms pairs between Boron and Nitrogen are fitted with
a screened Coulomb interaction "coul/shield"_pair_coul_shield.html. Therefore,
to simulated the properties of h-BN correctly, this potential must be used in
combination with the pair style "coul/shield"_pair_coul_shield.html.
NOTE: Two new sets of parameters of ILP for two-dimensional hexagonal
Materials are presented in "(Ouyang)"_#Ouyang. These parameters provide
a good description in both short- and long-range interaction regimes.
While the old ILP parameters published in "(Leven2)"_#Leven2 and
"(Maaravi)"_#Maaravi2 are only suitable for long-range interaction
regime. This feature is essential for simulations in high pressure
regime (i.e., the interlayer distance is smaller than the equilibrium
distance). The benchmark tests and comparison of these parameters can
be found in "(Ouyang)"_#Ouyang.
This potential must be used in combination with hybrid/overlay.
Other interactions can be set to zero using pair_style {none}.
This pair style tallies a breakdown of the total interlayer potential
energy into sub-categories, which can be accessed via the "compute
pair"_compute_pair.html command as a vector of values of length 2.
The 2 values correspond to the following sub-categories:
{E_vdW} = vdW (attractive) energy
{E_Rep} = Repulsive energy :ol
To print these quantities to the log file (with descriptive column
headings) the following commands could be included in an input script:
compute 0 all pair ilp/graphene/hbn
variable Evdw equal c_0\[1\]
variable Erep equal c_0\[2\]
thermo_style custom step temp epair v_Erep v_Evdw :pre
:line
[Mixing, shift, table, tail correction, restart, rRESPA info]:
This pair style does not support the pair_modify mix, shift, table, and
tail options.
This pair style does not write their information to binary restart
files, since it is stored in potential files. Thus, you need to
re-specify the pair_style and pair_coeff commands in an input script
that reads a restart file.
[Restrictions:]
This fix is part of the USER-MISC package. It is only enabled if
LAMMPS was built with that package. See the "Build
package"_Build_package.html doc page for more info.
This pair potential requires the newton setting to be {on} for pair
interactions.
The BNCH.ILP potential file provided with LAMMPS (see the potentials
directory) are parameterized for {metal} units. You can use this
potential with any LAMMPS units, but you would need to create your
BNCH.ILP potential file with coefficients listed in the appropriate
units, if your simulation does not use {metal} units.
[Related commands:]
"pair_coeff"_pair_coeff.html,
"pair_none"_pair_none.html,
"pair_style hybrid/overlay"_pair_hybrid.html,
"pair_style drip"_pair_drip.html,
"pair_style pair_kolmogorov_crespi_z"_pair_kolmogorov_crespi_z.html,
"pair_style pair_kolmogorov_crespi_full"_pair_kolmogorov_crespi_full.html,
"pair_style pair_lebedeva_z"_pair_lebedeva_z.html,
"pair_style pair_coul_shield"_pair_coul_shield.html.
[Default:] tap_flag = 1
:line
:link(Leven1)
[(Leven1)] I. Leven, I. Azuri, L. Kronik and O. Hod, J. Chem. Phys. 140, 104106 (2014).
:link(Leven2)
[(Leven2)] I. Leven et al, J. Chem.Theory Comput. 12, 2896-905 (2016).
:link(Maaravi2)
[(Maaravi)] T. Maaravi et al, J. Phys. Chem. C 121, 22826-22835 (2017).
:link(Kolmogorov2)
[(Kolmogorov)] A. N. Kolmogorov, V. H. Crespi, Phys. Rev. B 71, 235415 (2005).
:link(Ouyang)
[(Ouyang)] W. Ouyang, D. Mandelli, M. Urbakh and O. Hod, Nano Lett. 18, 6009-6016 (2018).

138
doc/txt/pair_kolmogorov_crespi_full.txt
View File

@ -1,138 +0,0 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
pair_style kolmogorov/crespi/full command :h3
[Syntax:]
pair_style hybrid/overlay kolmogorov/crespi/full cutoff tap_flag :pre
cutoff = global cutoff (distance units)
tap_flag = 0/1 to turn off/on the taper function :ul
[Examples:]
pair_style hybrid/overlay kolmogorov/crespi/full 20.0 0
pair_coeff * * none
pair_coeff * * kolmogorov/crespi/full CH.KC C C :pre
pair_style hybrid/overlay rebo kolmogorov/crespi/full 16.0 1
pair_coeff * * rebo CH.rebo C H
pair_coeff * * kolmogorov/crespi/full CH_taper.KC C H :pre
[Description:]
The {kolmogorov/crespi/full} style computes the Kolmogorov-Crespi (KC)
interaction potential as described in "(Kolmogorov)"_#Kolmogorov1.
No simplification is made,
:c,image(Eqs/pair_kolmogorov_crespi_full.jpg)
It is important to have a sufficiently large cutoff to ensure smooth
forces and to include all the pairs to build the neighbor list for
calculating the normals. Energies are shifted so that they go
continuously to zero at the cutoff assuming that the exponential part of
{Vij} (first term) decays sufficiently fast. This shift is achieved by
the last term in the equation for {Vij} above. This is essential only
when the tapper function is turned off. The formula of taper function
can be found in pair style "ilp/graphene/hbn"_pair_ilp_graphene_hbn.html.
NOTE: This potential (ILP) is intended for interlayer interactions between two
different layers of graphene. To perform a realistic simulation, this potential
must be used in combination with intralayer potential, such as
"AIREBO"_pair_airebo.html or "Tersoff"_pair_tersoff.html potential.
To keep the intralayer properties unaffected, the interlayer interaction
within the same layers should be avoided. Hence, each atom has to have a layer
identifier such that atoms residing on the same layer interact via the
appropriate intralayer potential and atoms residing on different layers
interact via the ILP. Here, the molecule id is chosen as the layer identifier,
thus a data file with the "full" atom style is required to use this potential.
The parameter file (e.g. CH.KC), is intended for use with {metal}
"units"_units.html, with energies in meV. Two additional parameters, {S},
and {rcut} are included in the parameter file. {S} is designed to
facilitate scaling of energies. {rcut} is designed to build the neighbor
list for calculating the normals for each atom pair.
NOTE: Two new sets of parameters of KC potential for hydrocarbons, CH.KC
(without the taper function) and CH_taper.KC (with the taper function)
are presented in "(Ouyang)"_#Ouyang1. The energy for the KC potential
with the taper function goes continuously to zero at the cutoff. The
parameters in both CH.KC and CH_taper.KC provide a good description in
both short- and long-range interaction regimes. While the original
parameters (CC.KC) published in "(Kolmogorov)"_#Kolmogorov1 are only
suitable for long-range interaction regime. This feature is essential
for simulations in high pressure regime (i.e., the interlayer distance
is smaller than the equilibrium distance). The benchmark tests and
comparison of these parameters can be found in "(Ouyang)"_#Ouyang1.
This potential must be used in combination with hybrid/overlay.
Other interactions can be set to zero using pair_style {none}.
This pair style tallies a breakdown of the total interlayer potential
energy into sub-categories, which can be accessed via the "compute
pair"_compute_pair.html command as a vector of values of length 2.
The 2 values correspond to the following sub-categories:
{E_vdW} = vdW (attractive) energy
{E_Rep} = Repulsive energy :ol
To print these quantities to the log file (with descriptive column
headings) the following commands could be included in an input script:
compute 0 all pair kolmogorov/crespi/full
variable Evdw equal c_0\[1\]
variable Erep equal c_0\[2\]
thermo_style custom step temp epair v_Erep v_Evdw :pre
:line
[Mixing, shift, table, tail correction, restart, rRESPA info]:
This pair style does not support the pair_modify mix, shift, table,
and tail options.
This pair style does not write their information to binary restart
files, since it is stored in potential files. Thus, you need to
re-specify the pair_style and pair_coeff commands in an input script
that reads a restart file.
[Restrictions:]
This fix is part of the USER-MISC package. It is only enabled if
LAMMPS was built with that package. See the "Build
package"_Build_package.html doc page for more info.
This pair potential requires the newton setting to be {on} for pair
interactions.
The CH.KC potential file provided with LAMMPS (see the potentials
folder) are parameterized for metal units. You can use this potential
with any LAMMPS units, but you would need to create your own custom
CC.KC potential file with all coefficients converted to the appropriate
units.
[Related commands:]
"pair_coeff"_pair_coeff.html,
"pair_none"_pair_none.html,
"pair_style hybrid/overlay"_pair_hybrid.html,
"pair_style drip"_pair_drip.html,
"pair_style pair_lebedeva_z"_pair_lebedeva_z.html,
"pair_style kolmogorov/crespi/z"_pair_kolmogorov_crespi_z.html,
"pair_style ilp/graphene/hbn"_pair_ilp_graphene_hbn.html.
[Default:] tap_flag = 0
:line
:link(Kolmogorov1)
[(Kolmogorov)] A. N. Kolmogorov, V. H. Crespi, Phys. Rev. B 71, 235415 (2005)
:link(Ouyang1)
[(Ouyang)] W. Ouyang, D. Mandelli, M. Urbakh and O. Hod, Nano Lett. 18, 6009-6016 (2018).

348
doc/txt/pair_lj.txt
View File

@ -1,348 +0,0 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
pair_style lj/cut command :h3
pair_style lj/cut/gpu command :h3
pair_style lj/cut/intel command :h3
pair_style lj/cut/kk command :h3
pair_style lj/cut/opt command :h3
pair_style lj/cut/omp command :h3
pair_style lj/cut/coul/cut command :h3
pair_style lj/cut/coul/cut/gpu command :h3
pair_style lj/cut/coul/cut/kk command :h3
pair_style lj/cut/coul/cut/omp command :h3
pair_style lj/cut/coul/debye command :h3
pair_style lj/cut/coul/debye/gpu command :h3
pair_style lj/cut/coul/debye/kk command :h3
pair_style lj/cut/coul/debye/omp command :h3
pair_style lj/cut/coul/dsf command :h3
pair_style lj/cut/coul/dsf/gpu command :h3
pair_style lj/cut/coul/dsf/kk command :h3
pair_style lj/cut/coul/dsf/omp command :h3
pair_style lj/cut/coul/long command :h3
pair_style lj/cut/coul/long/gpu command :h3
pair_style lj/cut/coul/long/kk command :h3
pair_style lj/cut/coul/long/intel command :h3
pair_style lj/cut/coul/long/opt command :h3
pair_style lj/cut/coul/long/omp command :h3
pair_style lj/cut/coul/msm command :h3
pair_style lj/cut/coul/msm/gpu command :h3
pair_style lj/cut/coul/msm/omp command :h3
pair_style lj/cut/coul/wolf command :h3
pair_style lj/cut/coul/wolf/omp command :h3
pair_style lj/cut/tip4p/cut command :h3
pair_style lj/cut/tip4p/cut/omp command :h3
pair_style lj/cut/tip4p/long command :h3
pair_style lj/cut/tip4p/long/omp command :h3
pair_style lj/cut/tip4p/long/opt command :h3
[Syntax:]
pair_style style args :pre
style = {lj/cut} or {lj/cut/coul/cut} or {lj/cut/coul/debye} or {lj/cut/coul/dsf} or {lj/cut/coul/long} {lj/cut/coul/msm} or {lj/cut/tip4p/long}
args = list of arguments for a particular style :ul
{lj/cut} args = cutoff
cutoff = global cutoff for Lennard Jones interactions (distance units)
{lj/cut/coul/cut} args = cutoff (cutoff2)
cutoff = global cutoff for LJ (and Coulombic if only 1 arg) (distance units)
cutoff2 = global cutoff for Coulombic (optional) (distance units)
{lj/cut/coul/debye} args = kappa cutoff (cutoff2)
kappa = inverse of the Debye length (inverse distance units)
cutoff = global cutoff for LJ (and Coulombic if only 1 arg) (distance units)
cutoff2 = global cutoff for Coulombic (optional) (distance units)
{lj/cut/coul/dsf} args = alpha cutoff (cutoff2)
alpha = damping parameter (inverse distance units)
cutoff = global cutoff for LJ (and Coulombic if only 1 arg) (distance units)
cutoff2 = global cutoff for Coulombic (distance units)
{lj/cut/coul/long} args = cutoff (cutoff2)
cutoff = global cutoff for LJ (and Coulombic if only 1 arg) (distance units)
cutoff2 = global cutoff for Coulombic (optional) (distance units)
{lj/cut/coul/msm} args = cutoff (cutoff2)
cutoff = global cutoff for LJ (and Coulombic if only 1 arg) (distance units)
cutoff2 = global cutoff for Coulombic (optional) (distance units)
{lj/cut/coul/wolf} args = alpha cutoff (cutoff2)
alpha = damping parameter (inverse distance units)
cutoff = global cutoff for LJ (and Coulombic if only 2 arg) (distance units)
cutoff2 = global cutoff for Coulombic (optional) (distance units)
{lj/cut/tip4p/cut} args = otype htype btype atype qdist cutoff (cutoff2)
otype,htype = atom types for TIP4P O and H
btype,atype = bond and angle types for TIP4P waters
qdist = distance from O atom to massless charge (distance units)
cutoff = global cutoff for LJ (and Coulombic if only 1 arg) (distance units)
cutoff2 = global cutoff for Coulombic (optional) (distance units)
{lj/cut/tip4p/long} args = otype htype btype atype qdist cutoff (cutoff2)
otype,htype = atom types for TIP4P O and H
btype,atype = bond and angle types for TIP4P waters
qdist = distance from O atom to massless charge (distance units)
cutoff = global cutoff for LJ (and Coulombic if only 1 arg) (distance units)
cutoff2 = global cutoff for Coulombic (optional) (distance units) :pre
[Examples:]
pair_style lj/cut 2.5
pair_coeff * * 1 1
pair_coeff 1 1 1 1.1 2.8 :pre
pair_style lj/cut/coul/cut 10.0
pair_style lj/cut/coul/cut 10.0 8.0
pair_coeff * * 100.0 3.0
pair_coeff 1 1 100.0 3.5 9.0
pair_coeff 1 1 100.0 3.5 9.0 9.0 :pre
pair_style lj/cut/coul/debye 1.5 3.0
pair_style lj/cut/coul/debye 1.5 2.5 5.0
pair_coeff * * 1.0 1.0
pair_coeff 1 1 1.0 1.5 2.5
pair_coeff 1 1 1.0 1.5 2.5 5.0 :pre
pair_style lj/cut/coul/dsf 0.05 2.5 10.0
pair_coeff * * 1.0 1.0
pair_coeff 1 1 1.0 1.0 2.5 :pre
pair_style lj/cut/coul/long 10.0
pair_style lj/cut/coul/long 10.0 8.0
pair_coeff * * 100.0 3.0
pair_coeff 1 1 100.0 3.5 9.0 :pre
pair_style lj/cut/coul/msm 10.0
pair_style lj/cut/coul/msm 10.0 8.0
pair_coeff * * 100.0 3.0
pair_coeff 1 1 100.0 3.5 9.0 :pre
pair_style lj/cut/tip4p/cut 1 2 7 8 0.15 12.0
pair_style lj/cut/tip4p/cut 1 2 7 8 0.15 12.0 10.0
pair_coeff * * 100.0 3.0
pair_coeff 1 1 100.0 3.5 9.0 :pre
pair_style lj/cut/coul/wolf 0.2 5. 10.0
pair_coeff * * 1.0 1.0
pair_coeff 1 1 1.0 1.0 2.5 :pre
pair_style lj/cut/tip4p/long 1 2 7 8 0.15 12.0
pair_style lj/cut/tip4p/long 1 2 7 8 0.15 12.0 10.0
pair_coeff * * 100.0 3.0
pair_coeff 1 1 100.0 3.5 9.0 :pre
[Description:]
The {lj/cut} styles compute the standard 12/6 Lennard-Jones potential,
given by
:c,image(Eqs/pair_lj.jpg)
Rc is the cutoff.
Style {lj/cut/coul/cut} adds a Coulombic pairwise interaction given by
:c,image(Eqs/pair_coulomb.jpg)
where C is an energy-conversion constant, Qi and Qj are the charges on
the 2 atoms, and epsilon is the dielectric constant which can be set
by the "dielectric"_dielectric.html command. If one cutoff is
specified in the pair_style command, it is used for both the LJ and
Coulombic terms. If two cutoffs are specified, they are used as
cutoffs for the LJ and Coulombic terms respectively.
Style {lj/cut/coul/debye} adds an additional exp() damping factor
to the Coulombic term, given by
:c,image(Eqs/pair_debye.jpg)
where kappa is the inverse of the Debye length. This potential is
another way to mimic the screening effect of a polar solvent.
Style {lj/cut/coul/dsf} computes the Coulombic term via the damped
shifted force model described in "Fennell"_#Fennell2, given by:
:c,image(Eqs/pair_coul_dsf.jpg)
where {alpha} is the damping parameter and erfc() is the complementary
error-function. This potential is essentially a short-range,
spherically-truncated, charge-neutralized, shifted, pairwise {1/r}
summation. The potential is based on Wolf summation, proposed as an
alternative to Ewald summation for condensed phase systems where
charge screening causes electrostatic interactions to become
effectively short-ranged. In order for the electrostatic sum to be
absolutely convergent, charge neutralization within the cutoff radius
is enforced by shifting the potential through placement of image
charges on the cutoff sphere. Convergence can often be improved by
setting {alpha} to a small non-zero value.
Styles {lj/cut/coul/long} and {lj/cut/coul/msm} compute the same
Coulombic interactions as style {lj/cut/coul/cut} except that an
additional damping factor is applied to the Coulombic term so it can
be used in conjunction with the "kspace_style"_kspace_style.html
command and its {ewald} or {pppm} option. The Coulombic cutoff
specified for this style means that pairwise interactions within this
distance are computed directly; interactions outside that distance are
computed in reciprocal space.
Style {coul/wolf} adds a Coulombic pairwise interaction via the Wolf
summation method, described in "Wolf"_#Wolf1, given by:
:c,image(Eqs/pair_coul_wolf.jpg)
where {alpha} is the damping parameter, and erfc() is the
complementary error-function terms. This potential
is essentially a short-range, spherically-truncated,
charge-neutralized, shifted, pairwise {1/r} summation. With a
manipulation of adding and subtracting a self term (for i = j) to the
first and second term on the right-hand-side, respectively, and a
small enough {alpha} damping parameter, the second term shrinks and
the potential becomes a rapidly-converging real-space summation. With
a long enough cutoff and small enough alpha parameter, the energy and
forces calculated by the Wolf summation method approach those of the
Ewald sum. So it is a means of getting effective long-range
interactions with a short-range potential.
Styles {lj/cut/tip4p/cut} and {lj/cut/tip4p/long} implement the TIP4P
water model of "(Jorgensen)"_#Jorgensen2, which introduces a massless
site located a short distance away from the oxygen atom along the
bisector of the HOH angle. The atomic types of the oxygen and
hydrogen atoms, the bond and angle types for OH and HOH interactions,
and the distance to the massless charge site are specified as
pair_style arguments. Style {lj/cut/tip4p/cut} uses a cutoff for
Coulomb interactions; style {lj/cut/tip4p/long} is for use with a
long-range Coulombic solver (Ewald or PPPM).
NOTE: For each TIP4P water molecule in your system, the atom IDs for
the O and 2 H atoms must be consecutive, with the O atom first. This
is to enable LAMMPS to "find" the 2 H atoms associated with each O
atom. For example, if the atom ID of an O atom in a TIP4P water
molecule is 500, then its 2 H atoms must have IDs 501 and 502.
See the "Howto tip4p"_Howto_tip4p.html doc page for more information
on how to use the TIP4P pair styles and lists of parameters to set.
Note that the neighbor list cutoff for Coulomb interactions is
effectively extended by a distance 2*qdist when using the TIP4P pair
style, to account for the offset distance of the fictitious charges on
O atoms in water molecules. Thus it is typically best in an
efficiency sense to use a LJ cutoff >= Coulombic cutoff + 2*qdist, to
shrink the size of the neighbor list. This leads to slightly larger
cost for the long-range calculation, so you can test the trade-off for
your model.
For all of the {lj/cut} pair styles, the following coefficients must
be defined for each pair of atoms types via the
"pair_coeff"_pair_coeff.html command as in the examples above, or in
the data file or restart files read by the "read_data"_read_data.html
or "read_restart"_read_restart.html commands, or by mixing as
described below:
epsilon (energy units)
sigma (distance units)
cutoff1 (distance units)
cutoff2 (distance units) :ul
Note that sigma is defined in the LJ formula as the zero-crossing
distance for the potential, not as the energy minimum at 2^(1/6)
sigma.
The latter 2 coefficients are optional. If not specified, the global
LJ and Coulombic cutoffs specified in the pair_style command are used.
If only one cutoff is specified, it is used as the cutoff for both LJ
and Coulombic interactions for this type pair. If both coefficients
are specified, they are used as the LJ and Coulombic cutoffs for this
type pair. You cannot specify 2 cutoffs for style {lj/cut}, since it
has no Coulombic terms.
For {lj/cut/coul/long} and {lj/cut/coul/msm} and {lj/cut/tip4p/cut}
and {lj/cut/tip4p/long} only the LJ cutoff can be specified since a
Coulombic cutoff cannot be specified for an individual I,J type pair.
All type pairs use the same global Coulombic cutoff specified in the
pair_style command.
:line
A version of these styles with a soft core, {lj/cut/soft}, suitable for use in
free energy calculations, is part of the USER-FEP package and is documented with
the "pair_fep_soft"_pair_fep_soft.html styles. The version with soft core is
only available if LAMMPS was built with that package. See the "Build
package"_Build_package.html doc page for more info.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed on the "Speed packages"_Speed_packages.html doc
page. The accelerated styles take the same arguments and should
produce the same results, except for round-off and precision issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Build
package"_Build_package.html doc page for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
switch"_Run_options.html when you invoke LAMMPS, or you can use the
"suffix"_suffix.html command in your input script.
See the "Speed packages"_Speed_packages.html doc page for more
instructions on how to use the accelerated styles effectively.
:line
[Mixing, shift, table, tail correction, restart, rRESPA info]:
For atom type pairs I,J and I != J, the epsilon and sigma coefficients
and cutoff distance for all of the lj/cut pair styles can be mixed.
The default mix value is {geometric}. See the "pair_modify" command
for details.
All of the {lj/cut} pair styles support the
"pair_modify"_pair_modify.html shift option for the energy of the
Lennard-Jones portion of the pair interaction.
The {lj/cut/coul/long} and {lj/cut/tip4p/long} pair styles support the
"pair_modify"_pair_modify.html table option since they can tabulate
the short-range portion of the long-range Coulombic interaction.
All of the {lj/cut} pair styles support the
"pair_modify"_pair_modify.html tail option for adding a long-range
tail correction to the energy and pressure for the Lennard-Jones
portion of the pair interaction.
All of the {lj/cut} pair styles write their information to "binary
restart files"_restart.html, so pair_style and pair_coeff commands do
not need to be specified in an input script that reads a restart file.
The {lj/cut} and {lj/cut/coul/long} pair styles support the use of the
{inner}, {middle}, and {outer} keywords of the "run_style
respa"_run_style.html command, meaning the pairwise forces can be
partitioned by distance at different levels of the rRESPA hierarchy.
The other styles only support the {pair} keyword of run_style respa.
See the "run_style"_run_style.html command for details.
:line
[Restrictions:]
The {lj/cut/coul/long} and {lj/cut/tip4p/long} styles are part of the
KSPACE package. The {lj/cut/tip4p/cut} style is part of the MOLECULE
package. These styles are only enabled if LAMMPS was built with those
packages. See the "Build package"_Build_package.html doc page for
more info.
[Related commands:]
"pair_coeff"_pair_coeff.html
[Default:] none
:line
:link(Jorgensen2)
[(Jorgensen)] Jorgensen, Chandrasekhar, Madura, Impey, Klein, J Chem
Phys, 79, 926 (1983).
:link(Fennell2)
[(Fennell)] C. J. Fennell, J. D. Gezelter, J Chem Phys, 124,
234104 (2006).

86
doc/txt/pair_lj_switch3_coulgauss.txt
View File

@ -1,86 +0,0 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
pair_style lj/switch3/coulgauss/long command :h3
[Syntax:]
pair_style style args :pre
style = {lj/switch3/coulgauss/long}
args = list of arguments for a particular style :ul
{lj/switch3/coulgauss/long} args = cutoff (cutoff2) width
cutoff = global cutoff for LJ (and Coulombic if only 1 arg) (distance units)
cutoff2 = global cutoff for Coulombic (optional) (distance units)
width = width parameter of the smoothing function (distance units) :pre
[Examples:]
pair_style lj/switch3/coulgauss/long 12.0 3.0
pair_coeff 1 0.2 2.5 1.2 :pre
pair_style lj/switch3/coulgauss/long 12.0 10.0 3.0
pair_coeff 1 0.2 2.5 1.2 :pre
[Description:]
The {lj/switch3/coulgauss} style evaluates the LJ
vdW potential
:c,image(Eqs/pair_lj_switch3.jpg)
, which goes smoothly to zero at the cutoff r_c as defined
by the switching function
:c,image(Eqs/pair_switch3.jpg)
where w is the width defined in the arguments. This potential
is combined with Coulomb interaction between Gaussian charge densities:
:c,image(Eqs/pair_coulgauss.jpg)
where qi and qj are the
charges on the 2 atoms, epsilon is the dielectric constant which
can be set by the "dielectric"_dielectric.html command, gamma_i and gamma_j
are the widths of the Gaussian charge distribution and erf() is the error-function.
This style has to be used in conjunction with the "kspace_style"_kspace_style.html command
If one cutoff is specified it is used for both the vdW and Coulomb
terms. If two cutoffs are specified, the first is used as the cutoff
for the vdW terms, and the second is the cutoff for the Coulombic term.
The following coefficients must be defined for each pair of atoms
types via the "pair_coeff"_pair_coeff.html command as in the examples
above, or in the data file or restart files read by the
"read_data"_read_data.html or "read_restart"_read_restart.html
commands:
epsilon (energy)
sigma (distance)
gamma (distance) :ul
:line
[Mixing, shift, table, tail correction, restart, rRESPA info]:
Shifting the potential energy is not necessary because the switching
function ensures that the potential is zero at the cut-off.
[Restrictions:]
These styles are part of the USER-YAFF package. They are only
enabled if LAMMPS was built with that package. See the "Build
package"_Build_package.html doc page for more info.
[Related commands:]
"pair_coeff"_pair_coeff.html
[Default:] none

400
doc/txt/pair_meamc.txt
View File

@ -1,400 +0,0 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
pair_style meam/c command :h3
[Syntax:]
pair_style style :pre
style = {meam/c}
[Examples:]
pair_style meam/c
pair_coeff * * ../potentials/library.meam Si ../potentials/si.meam Si
pair_coeff * * ../potentials/library.meam Ni Al NULL Ni Al Ni Ni :pre
[Description:]
NOTE: The behavior of the MEAM potential for alloy systems has changed
as of November 2010; see description below of the mixture_ref_t
parameter
Style {meam/c} computes pairwise interactions for a variety of materials
using modified embedded-atom method (MEAM) potentials
"(Baskes)"_#Baskes. Conceptually, it is an extension to the original
"EAM potentials"_pair_eam.html which adds angular forces. It is
thus suitable for modeling metals and alloys with fcc, bcc, hcp and
diamond cubic structures, as well as covalently bonded materials like
silicon and carbon. Style {meam/c} is a translation of the (now obsolete)
{meam} code from Fortran to C++. It is functionally equivalent to {meam}
but more efficient, and thus {meam} has been removed from LAMMPS after
the 12 December 2018 release.
In the MEAM formulation, the total energy E of a system of atoms is
given by:
:c,image(Eqs/pair_meam.jpg)
where F is the embedding energy which is a function of the atomic
electron density rho, and phi is a pair potential interaction. The
pair interaction is summed over all neighbors J of atom I within the
cutoff distance. As with EAM, the multi-body nature of the MEAM
potential is a result of the embedding energy term. Details of the
computation of the embedding and pair energies, as implemented in
LAMMPS, are given in "(Gullet)"_#Gullet and references therein.
The various parameters in the MEAM formulas are listed in two files
which are specified by the "pair_coeff"_pair_coeff.html command.
These are ASCII text files in a format consistent with other MD codes
that implement MEAM potentials, such as the serial DYNAMO code and
Warp. Several MEAM potential files with parameters for different
materials are included in the "potentials" directory of the LAMMPS
distribution with a ".meam" suffix. All of these are parameterized in
terms of LAMMPS "metal units"_units.html.
Note that unlike for other potentials, cutoffs for MEAM potentials are
not set in the pair_style or pair_coeff command; they are specified in
the MEAM potential files themselves.
Only a single pair_coeff command is used with the {meam} style which
specifies two MEAM files and the element(s) to extract information
for. The MEAM elements are mapped to LAMMPS atom types by specifying
N additional arguments after the 2nd filename in the pair_coeff
command, where N is the number of LAMMPS atom types:
MEAM library file
Elem1, Elem2, ...
MEAM parameter file
N element names = mapping of MEAM elements to atom types :ul
See the "pair_coeff"_pair_coeff.html doc page for alternate ways
to specify the path for the potential files.
As an example, the potentials/library.meam file has generic MEAM
settings for a variety of elements. The potentials/SiC.meam file has
specific parameter settings for a Si and C alloy system. If your
LAMMPS simulation has 4 atoms types and you want the 1st 3 to be Si,
and the 4th to be C, you would use the following pair_coeff command:
pair_coeff * * library.meam Si C sic.meam Si Si Si C :pre
The 1st 2 arguments must be * * so as to span all LAMMPS atom types.
The two filenames are for the library and parameter file respectively.
The Si and C arguments (between the file names) are the two elements
for which info will be extracted from the library file. The first
three trailing Si arguments map LAMMPS atom types 1,2,3 to the MEAM Si
element. The final C argument maps LAMMPS atom type 4 to the MEAM C
element.
If the 2nd filename is specified as NULL, no parameter file is read,
which simply means the generic parameters in the library file are
used. Use of the NULL specification for the parameter file is
discouraged for systems with more than a single element type
(e.g. alloys), since the parameter file is expected to set element
interaction terms that are not captured by the information in the
library file.
If a mapping value is specified as NULL, the mapping is not performed.
This can be used when a {meam} potential is used as part of the
{hybrid} pair style. The NULL values are placeholders for atom types
that will be used with other potentials.
NOTE: If the 2nd filename is NULL, the element names between the two
filenames can appear in any order, e.g. "Si C" or "C Si" in the
example above. However, if the 2nd filename is not NULL (as in the
example above), it contains settings that are Fortran-indexed for the
elements that preceed it. Thus you need to insure you list the
elements between the filenames in an order consistent with how the
values in the 2nd filename are indexed. See details below on the
syntax for settings in the 2nd file.
The MEAM library file provided with LAMMPS has the name
potentials/library.meam. It is the "meamf" file used by other MD
codes. Aside from blank and comment lines (start with #) which can
appear anywhere, it is formatted as a series of entries, each of which
has 19 parameters and can span multiple lines:
elt, lat, z, ielement, atwt, alpha, b0, b1, b2, b3, alat, esub, asub,
t0, t1, t2, t3, rozero, ibar
The "elt" and "lat" parameters are text strings, such as elt = Si or
Cu and lat = dia or fcc. Because the library file is used by Fortran
MD codes, these strings may be enclosed in single quotes, but this is
not required. The other numeric parameters match values in the
formulas above. The value of the "elt" string is what is used in the
pair_coeff command to identify which settings from the library file
you wish to read in. There can be multiple entries in the library
file with the same "elt" value; LAMMPS reads the 1st matching entry it
finds and ignores the rest.
Other parameters in the MEAM library file correspond to single-element
potential parameters:
lat = lattice structure of reference configuration
z = number of nearest neighbors in the reference structure
ielement = atomic number
atwt = atomic weight
alat = lattice constant of reference structure
esub = energy per atom (eV) in the reference structure at equilibrium
asub = "A" parameter for MEAM (see e.g. "(Baskes)"_#Baskes) :pre
The alpha, b0, b1, b2, b3, t0, t1, t2, t3 parameters correspond to the
standard MEAM parameters in the literature "(Baskes)"_#Baskes (the b
parameters are the standard beta parameters). Note that only parameters
normalized to t0 = 1.0 are supported. The rozero parameter is
an element-dependent density scaling that weights the reference
background density (see e.g. equation 4.5 in "(Gullet)"_#Gullet) and
is typically 1.0 for single-element systems. The ibar parameter
selects the form of the function G(Gamma) used to compute the electron
density; options are
0 => G = sqrt(1+Gamma)
1 => G = exp(Gamma/2)
2 => not implemented
3 => G = 2/(1+exp(-Gamma))
4 => G = sqrt(1+Gamma)
-5 => G = +-sqrt(abs(1+Gamma)) :pre
If used, the MEAM parameter file contains settings that override or
complement the library file settings. Examples of such parameter
files are in the potentials directory with a ".meam" suffix. Their
format is the same as is read by other Fortran MD codes. Aside from
blank and comment lines (start with #) which can appear anywhere, each
line has one of the following forms. Each line can also have a
trailing comment (starting with #) which is ignored.
keyword = value
keyword(I) = value
keyword(I,J) = value
keyword(I,J,K) = value :pre
The indices I, J, K correspond to the elements selected from the
MEAM library file numbered in the order of how those elements were
selected starting from 1. Thus for the example given below
pair_coeff * * library.meam Si C sic.meam Si Si Si C :pre
an index of 1 would refer to Si and an index of 2 to C.
The recognized keywords for the parameter file are as follows:
Ec, alpha, rho0, delta, lattce, attrac, repuls, nn2, Cmin, Cmax, rc, delr,
augt1, gsmooth_factor, re
where
rc = cutoff radius for cutoff function; default = 4.0
delr = length of smoothing distance for cutoff function; default = 0.1
rho0(I) = relative density for element I (overwrites value
read from meamf file)
Ec(I,J) = cohesive energy of reference structure for I-J mixture
delta(I,J) = heat of formation for I-J alloy; if Ec_IJ is input as
zero, then LAMMPS sets Ec_IJ = (Ec_II + Ec_JJ)/2 - delta_IJ
alpha(I,J) = alpha parameter for pair potential between I and J (can
be computed from bulk modulus of reference structure
re(I,J) = equilibrium distance between I and J in the reference
structure
Cmax(I,J,K) = Cmax screening parameter when I-J pair is screened
by K (I<=J); default = 2.8
Cmin(I,J,K) = Cmin screening parameter when I-J pair is screened
by K (I<=J); default = 2.0
lattce(I,J) = lattice structure of I-J reference structure:
dia = diamond (interlaced fcc for alloy)
fcc = face centered cubic
bcc = body centered cubic
dim = dimer
b1 = rock salt (NaCl structure)
hcp = hexagonal close-packed
c11 = MoSi2 structure
l12 = Cu3Au structure (lower case L, followed by 12)
b2 = CsCl structure (interpenetrating simple cubic)
nn2(I,J) = turn on second-nearest neighbor MEAM formulation for
I-J pair (see for example "(Lee)"_#Lee).
0 = second-nearest neighbor formulation off
1 = second-nearest neighbor formulation on
default = 0
attrac(I,J) = additional cubic attraction term in Rose energy I-J pair potential
default = 0
repuls(I,J) = additional cubic repulsive term in Rose energy I-J pair potential
default = 0
zbl(I,J) = blend the MEAM I-J pair potential with the ZBL potential for small
atom separations "(ZBL)"_#ZBL
default = 1
gsmooth_factor = factor determining the length of the G-function smoothing
region; only significant for ibar=0 or ibar=4.
99.0 = short smoothing region, sharp step
0.5 = long smoothing region, smooth step
default = 99.0
augt1 = integer flag for whether to augment t1 parameter by
3/5*t3 to account for old vs. new meam formulations;
0 = don't augment t1
1 = augment t1
default = 1
ialloy = integer flag to use alternative averaging rule for t parameters,
for comparison with the DYNAMO MEAM code
0 = standard averaging (matches ialloy=0 in DYNAMO)
1 = alternative averaging (matches ialloy=1 in DYNAMO)
2 = no averaging of t (use single-element values)
default = 0
mixture_ref_t = integer flag to use mixture average of t to compute the background
reference density for alloys, instead of the single-element values
(see description and warning elsewhere in this doc page)
0 = do not use mixture averaging for t in the reference density
1 = use mixture averaging for t in the reference density
default = 0
erose_form = integer value to select the form of the Rose energy function
(see description below).
default = 0
emb_lin_neg = integer value to select embedding function for negative densities
0 = F(rho)=0
1 = F(rho) = -asub*esub*rho (linear in rho, matches DYNAMO)
default = 0
bkgd_dyn = integer value to select background density formula
0 = rho_bkgd = rho_ref_meam(a) (as in the reference structure)
1 = rho_bkgd = rho0_meam(a)*Z_meam(a) (matches DYNAMO)
default = 0 :pre
Rc, delr, re are in distance units (Angstroms in the case of metal
units). Ec and delta are in energy units (eV in the case of metal
units).
Each keyword represents a quantity which is either a scalar, vector,
2d array, or 3d array and must be specified with the correct
corresponding array syntax. The indices I,J,K each run from 1 to N
where N is the number of MEAM elements being used.
Thus these lines
rho0(2) = 2.25
alpha(1,2) = 4.37 :pre
set rho0 for the 2nd element to the value 2.25 and set alpha for the
alloy interaction between elements 1 and 2 to 4.37.
The augt1 parameter is related to modifications in the MEAM
formulation of the partial electron density function. In recent
literature, an extra term is included in the expression for the
third-order density in order to make the densities orthogonal (see for
example "(Wang)"_#Wang2, equation 3d); this term is included in the
MEAM implementation in lammps. However, in earlier published work
this term was not included when deriving parameters, including most of
those provided in the library.meam file included with lammps, and to
account for this difference the parameter t1 must be augmented by
3/5*t3. If augt1=1, the default, this augmentation is done
automatically. When parameter values are fit using the modified
density function, as in more recent literature, augt1 should be set to
0.
The mixture_ref_t parameter is available to match results with those
of previous versions of lammps (before January 2011). Newer versions
of lammps, by default, use the single-element values of the t
parameters to compute the background reference density. This is the
proper way to compute these parameters. Earlier versions of lammps
used an alloy mixture averaged value of t to compute the background
reference density. Setting mixture_ref_t=1 gives the old behavior.
WARNING: using mixture_ref_t=1 will give results that are demonstrably
incorrect for second-neighbor MEAM, and non-standard for
first-neighbor MEAM; this option is included only for matching with
previous versions of lammps and should be avoided if possible.
The parameters attrac and repuls, along with the integer selection
parameter erose_form, can be used to modify the Rose energy function
used to compute the pair potential. This function gives the energy of
the reference state as a function of interatomic spacing. The form of
this function is:
astar = alpha * (r/re - 1.d0)
if erose_form = 0: erose = -Ec*(1+astar+a3*(astar**3)/(r/re))*exp(-astar)
if erose_form = 1: erose = -Ec*(1+astar+(-attrac+repuls/r)*(astar**3))*exp(-astar)
if erose_form = 2: erose = -Ec*(1 +astar + a3*(astar**3))*exp(-astar)
a3 = repuls, astar < 0
a3 = attrac, astar >= 0 :pre
Most published MEAM parameter sets use the default values attrac=repulse=0.
Setting repuls=attrac=delta corresponds to the form used in several
recent published MEAM parameter sets, such as "(Valone)"_#Valone
NOTE: The default form of the erose expression in LAMMPS was corrected
in March 2009. The current version is correct, but may show different
behavior compared with earlier versions of lammps with the attrac
and/or repuls parameters are non-zero. To obtain the previous default
form, use erose_form = 1 (this form does not seem to appear in the
literature). An alternative form (see e.g. "(Lee2)"_#Lee2) is
available using erose_form = 2.
:line
[Mixing, shift, table, tail correction, restart, rRESPA info]:
For atom type pairs I,J and I != J, where types I and J correspond to
two different element types, mixing is performed by LAMMPS with
user-specifiable parameters as described above. You never need to
specify a pair_coeff command with I != J arguments for this style.
This pair style does not support the "pair_modify"_pair_modify.html
shift, table, and tail options.
This pair style does not write its information to "binary restart
files"_restart.html, since it is stored in potential files. Thus, you
need to re-specify the pair_style and pair_coeff commands in an input
script that reads a restart file.
This pair style can only be used via the {pair} keyword of the
"run_style respa"_run_style.html command. It does not support the
{inner}, {middle}, {outer} keywords.
:line
[Restrictions:]
The {meam/c} style is provided in the USER-MEAMC package. It is
only enabled if LAMMPS was built with that package.
See the "Build package"_Build_package.html doc page for more info.
The maximum number of elements, that can be read from the MEAM
library file, is determined at compile time. The default is 5.
If you need support for more elements, you have to change the
define for the constant 'maxelt' at the beginning of the file
src/USER-MEAMC/meam.h and update/recompile LAMMPS. There is no
limit on the number of atoms types.
[Related commands:]
"pair_coeff"_pair_coeff.html, "pair_style eam"_pair_eam.html,
"pair_style meam/spline"_pair_meam_spline.html
[Default:] none
:line
:link(Baskes)
[(Baskes)] Baskes, Phys Rev B, 46, 2727-2742 (1992).
:link(Gullet)
[(Gullet)] Gullet, Wagner, Slepoy, SANDIA Report 2003-8782 (2003).
This report may be accessed on-line via "this link"_sandreport.
:link(sandreport,http://infoserve.sandia.gov/sand_doc/2003/038782.pdf)
:link(Lee)
[(Lee)] Lee, Baskes, Phys. Rev. B, 62, 8564-8567 (2000).
:link(Lee2)
[(Lee2)] Lee, Baskes, Kim, Cho. Phys. Rev. B, 64, 184102 (2001).
:link(Valone)
[(Valone)] Valone, Baskes, Martin, Phys. Rev. B, 73, 214209 (2006).
:link(Wang2)
[(Wang)] Wang, Van Hove, Ross, Baskes, J. Chem. Phys., 121, 5410 (2004).
:link(ZBL)
[(ZBL)] J.F. Ziegler, J.P. Biersack, U. Littmark, "Stopping and Ranges
of Ions in Matter", Vol 1, 1985, Pergamon Press.

88
doc/txt/pair_mm3_switch3_coulgauss.txt
View File

@ -1,88 +0,0 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
pair_style mm3/switch3/coulgauss/long command :h3
[Syntax:]
pair_style style args :pre
style = {mm3/switch3/coulgauss/long}
args = list of arguments for a particular style :ul
{mm3/switch3/coulgauss/long} args = cutoff (cutoff2) width
cutoff = global cutoff for MM3 (and Coulombic if only 1 arg) (distance units)
cutoff2 = global cutoff for Coulombic (optional) (distance units)
width = width parameter of the smoothing function (distance units) :pre
[Examples:]
pair_style mm3/switch3/coulgauss/long 12.0 3.0
pair_coeff 1 0.2 2.5 1.2 :pre
pair_style mm3/switch3/coulgauss/long 12.0 10.0 3.0
pair_coeff 1 0.2 2.5 1.2 :pre
[Description:]
The {mm3/switch3/coulgauss} style evaluates the MM3
vdW potential "(Allinger)"_#mm3-allinger1989
:c,image(Eqs/pair_mm3_switch3.jpg)
, which goes smoothly to zero at the cutoff r_c as defined
by the switching function
:c,image(Eqs/pair_switch3.jpg)
where w is the width defined in the arguments. This potential
is combined with Coulomb interaction between Gaussian charge densities:
:c,image(Eqs/pair_coulgauss.jpg)
where qi and qj are the
charges on the 2 atoms, epsilon is the dielectric constant which
can be set by the "dielectric"_dielectric.html command, gamma_i and gamma_j
are the widths of the Gaussian charge distribution and erf() is the error-function.
This style has to be used in conjunction with the "kspace_style"_kspace_style.html command
If one cutoff is specified it is used for both the vdW and Coulomb
terms. If two cutoffs are specified, the first is used as the cutoff
for the vdW terms, and the second is the cutoff for the Coulombic term.
The following coefficients must be defined for each pair of atoms
types via the "pair_coeff"_pair_coeff.html command as in the examples
above, or in the data file or restart files read by the
"read_data"_read_data.html or "read_restart"_read_restart.html
commands:
epsilon (energy)
r_v (distance)
gamma (distance) :ul
:line
[Mixing, shift, table, tail correction, restart, rRESPA info]:
Mixing rules are fixed for this style as defined above.
Shifting the potential energy is not necessary because the switching
function ensures that the potential is zero at the cut-off.
[Restrictions:]
These styles are part of the USER-YAFF package. They are only
enabled if LAMMPS was built with that package. See the "Build
package"_Build_package.html doc page for more info.
[Related commands:]
"pair_coeff"_pair_coeff.html
[Default:] none

281
doc/txt/pair_modify.txt
View File

@ -1,281 +0,0 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
pair_modify command :h3
[Syntax:]
pair_modify keyword values ... :pre
one or more keyword/value pairs may be listed :ulb,l
keyword = {pair} or {shift} or {mix} or {table} or {table/disp} or {tabinner}
or {tabinner/disp} or {tail} or {compute} or {nofdotr} :l
{pair} values = sub-style N {special} which wt1 wt2 wt3
or sub-style N {compute/tally} flag
sub-style = sub-style of "pair hybrid"_pair_hybrid.html
N = which instance of sub-style (only if sub-style is used multiple times)
{special} which wt1 wt2 wt3 = override {special_bonds} settings (optional)
which = {lj/coul} or {lj} or {coul}
w1,w2,w3 = 1-2, 1-3, and 1-4 weights from 0.0 to 1.0 inclusive
{compute/tally} flag = {yes} or {no}
{mix} value = {geometric} or {arithmetic} or {sixthpower}
{shift} value = {yes} or {no}
{table} value = N
2^N = # of values in table
{table/disp} value = N
2^N = # of values in table
{tabinner} value = cutoff
cutoff = inner cutoff at which to begin table (distance units)
{tabinner/disp} value = cutoff
cutoff = inner cutoff at which to begin table (distance units)
{tail} value = {yes} or {no}
{compute} value = {yes} or {no}
{nofdotr} :pre
:ule
[Examples:]
pair_modify shift yes mix geometric
pair_modify tail yes
pair_modify table 12
pair_modify pair lj/cut compute no
pair_modify pair tersoff compute/tally no
pair_modify pair lj/cut/coul/long 1 special lj/coul 0.0 0.0 0.0 :pre
[Description:]
Modify the parameters of the currently defined pair style. Not all
parameters are relevant to all pair styles.
If used, the {pair} keyword must appear first in the list of keywords.
It can only be used with the "hybrid and
hybrid/overlay"_pair_hybrid.html pair styles. It means that all the
following parameters will only be modified for the specified
sub-style. If the sub-style is defined multiple times, then an
additional numeric argument {N} must also be specified, which is a
number from 1 to M where M is the number of times the sub-style was
listed in the "pair_style hybrid"_pair_hybrid.html command. The extra
number indicates which instance of the sub-style the remaining
keywords will be applied to. Note that if the {pair} keyword is not
used, and the pair style is {hybrid} or {hybrid/overlay}, then all the
specified keywords will be applied to all sub-styles.
The {special} and {compute/tally} keywords can [only] be used in
conjunction with the {pair} keyword and must directly follow it.
{special} allows to override the
"special_bonds"_special_bonds.html settings for the specified sub-style.
{compute/tally} allows to disable or enable registering
"compute */tally"_compute_tally.html computes for a given sub-style.
More details are given below.
The {mix} keyword affects pair coefficients for interactions between
atoms of type I and J, when I != J and the coefficients are not
explicitly set in the input script. Note that coefficients for I = J
must be set explicitly, either in the input script via the
"pair_coeff" command or in the "Pair Coeffs" section of the "data
file"_read_data.html. For some pair styles it is not necessary to
specify coefficients when I != J, since a "mixing" rule will create
them from the I,I and J,J settings. The pair_modify {mix} value
determines what formulas are used to compute the mixed coefficients.
In each case, the cutoff distance is mixed the same way as sigma.
Note that not all pair styles support mixing. Also, some mix options
are not available for certain pair styles. See the doc page for
individual pair styles for those restrictions. Note also that the
"pair_coeff"_pair_coeff.html command also can be to directly set
coefficients for a specific I != J pairing, in which case no mixing is
performed.
mix {geometric}
epsilon_ij = sqrt(epsilon_i * epsilon_j)
sigma_ij = sqrt(sigma_i * sigma_j) :pre
mix {arithmetic}
epsilon_ij = sqrt(epsilon_i * epsilon_j)
sigma_ij = (sigma_i + sigma_j) / 2 :pre
mix {sixthpower}
epsilon_ij = (2 * sqrt(epsilon_i*epsilon_j) * sigma_i^3 * sigma_j^3) /
(sigma_i^6 + sigma_j^6)
sigma_ij = ((sigma_i**6 + sigma_j**6) / 2) ^ (1/6) :pre
The {shift} keyword determines whether a Lennard-Jones potential is
shifted at its cutoff to 0.0. If so, this adds an energy term to each
pairwise interaction which will be included in the thermodynamic
output, but does not affect pair forces or atom trajectories. See the
doc page for individual pair styles to see which ones support this
option.
The {table} and {table/disp} keywords apply to pair styles with a
long-range Coulombic term or long-range dispersion term respectively;
see the doc page for individual styles to see which potentials support
these options. If N is non-zero, a table of length 2^N is
pre-computed for forces and energies, which can shrink their
computational cost by up to a factor of 2. The table is indexed via a
bit-mapping technique "(Wolff)"_#Wolff1 and a linear interpolation is
performed between adjacent table values. In our experiments with
different table styles (lookup, linear, spline), this method typically
gave the best performance in terms of speed and accuracy.
The choice of table length is a tradeoff in accuracy versus speed. A
larger N yields more accurate force computations, but requires more
memory which can slow down the computation due to cache misses. A
reasonable value of N is between 8 and 16. The default value of 12
(table of length 4096) gives approximately the same accuracy as the
no-table (N = 0) option. For N = 0, forces and energies are computed
directly, using a polynomial fit for the needed erfc() function
evaluation, which is what earlier versions of LAMMPS did. Values
greater than 16 typically slow down the simulation and will not
improve accuracy; values from 1 to 8 give unreliable results.
The {tabinner} and {tabinner/disp} keywords set an inner cutoff above
which the pairwise computation is done by table lookup (if tables are
invoked), for the corresponding Coulombic and dispersion tables
discussed with the {table} and {table/disp} keywords. The smaller the
cutoff is set, the less accurate the table becomes (for a given number
of table values), which can require use of larger tables. The default
cutoff value is sqrt(2.0) distance units which means nearly all
pairwise interactions are computed via table lookup for simulations
with "real" units, but some close pairs may be computed directly
(non-table) for simulations with "lj" units.
When the {tail} keyword is set to {yes}, certain pair styles will add
a long-range VanderWaals tail "correction" to the energy and pressure.
These corrections are bookkeeping terms which do not affect dynamics,
unless a constant-pressure simulation is being performed. See the doc
page for individual styles to see which support this option. These
corrections are included in the calculation and printing of
thermodynamic quantities (see the "thermo_style"_thermo_style.html
command). Their effect will also be included in constant NPT or NPH
simulations where the pressure influences the simulation box
dimensions (e.g. the "fix npt"_fix_nh.html and "fix nph"_fix_nh.html
commands). The formulas used for the long-range corrections come from
equation 5 of "(Sun)"_#Sun.
NOTE: The tail correction terms are computed at the beginning of each
run, using the current atom counts of each atom type. If atoms are
deleted (or lost) or created during a simulation, e.g. via the "fix
gcmc"_fix_gcmc.html command, the correction factors are not
re-computed. If you expect the counts to change dramatically, you can
break a run into a series of shorter runs so that the correction
factors are re-computed more frequently.
Several additional assumptions are inherent in using tail corrections,
including the following:
The simulated system is a 3d bulk homogeneous liquid. This option
should not be used for systems that are non-liquid, 2d, have a slab
geometry (only 2d periodic), or inhomogeneous. :ulb,l
G(r), the radial distribution function (rdf), is unity beyond the
cutoff, so a fairly large cutoff should be used (i.e. 2.5 sigma for an
LJ fluid), and it is probably a good idea to verify this assumption by
checking the rdf. The rdf is not exactly unity beyond the cutoff for
each pair of interaction types, so the tail correction is necessarily
an approximation. :l
The tail corrections are computed at the beginning of each simulation
run. If the number of atoms changes during the run, e.g. due to atoms
leaving the simulation domain, or use of the "fix gcmc"_fix_gcmc.html
command, then the corrections are not updated to reflect the changed
atom count. If this is a large effect in your simulation, you should
break the long run into several short runs, so that the correction
factors are re-computed multiple times.
Thermophysical properties obtained from calculations with this option
enabled will not be thermodynamically consistent with the truncated
force-field that was used. In other words, atoms do not feel any LJ
pair interactions beyond the cutoff, but the energy and pressure
reported by the simulation include an estimated contribution from
those interactions. :l
:ule
The {compute} keyword allows pairwise computations to be turned off,
even though a "pair_style"_pair_style.html is defined. This is not
useful for running a real simulation, but can be useful for debugging
purposes or for performing a "rerun"_rerun.html simulation, when you
only wish to compute partial forces that do not include the pairwise
contribution.
Two examples are as follows. First, this option allows you to perform
a simulation with "pair_style hybrid"_pair_hybrid.html with only a
subset of the hybrid sub-styles enabled. Second, this option allows
you to perform a simulation with only long-range interactions but no
short-range pairwise interactions. Doing this by simply not defining
a pair style will not work, because the
"kspace_style"_kspace_style.html command requires a Kspace-compatible
pair style be defined.
The {nofdotr} keyword allows to disable an optimization that computes
the global stress tensor from the total forces and atom positions rather
than from summing forces between individual pairs of atoms.
:line
The {special} keyword allows to override the 1-2, 1-3, and 1-4
exclusion settings for individual sub-styles of a
"hybrid pair style"_pair_hybrid.html. It requires 4 arguments similar
to the "special_bonds"_special_bonds.html command, {which} and
wt1,wt2,wt3. The {which} argument can be {lj} to change the
Lennard-Jones settings, {coul} to change the Coulombic settings,
or {lj/coul} to change both to the same set of 3 values. The wt1,wt2,wt3
values are numeric weights from 0.0 to 1.0 inclusive, for the 1-2,
1-3, and 1-4 bond topology neighbors, respectively. The {special}
keyword can only be used in conjunction with the {pair} keyword
and has to directly follow it.
NOTE: The global settings specified by the
"special_bonds"_special_bonds.html command affect the construction of
neighbor lists. Weights of 0.0 (for 1-2, 1-3, or 1-4 neighbors)
exclude those pairs from the neighbor list entirely. Weights of 1.0
store the neighbor with no weighting applied. Thus only global values
different from exactly 0.0 or 1.0 can be overridden and an error is
generated if the requested setting is not compatible with the global
setting. Substituting 1.0e-10 for 0.0 and 0.9999999999 for 1.0 is
usually a sufficient workaround in this case without causing a
significant error.
The {compute/tally} keyword takes exactly 1 argument ({no} or {yes}),
and allows to selectively disable or enable processing of the various
"compute */tally"_compute_tally.html styles for a given
"pair hybrid or hybrid/overlay"_pair_hybrid.html sub-style.
NOTE: Any "pair_modify pair compute/tally" command must be issued
[before] the corresponding compute style is defined.
:line
[Restrictions:] none
You cannot use {shift} yes with {tail} yes, since those are
conflicting options. You cannot use {tail} yes with 2d simulations.
[Related commands:]
"pair_style"_pair_style.html, "pair_style hybrid"_pair_hybrid.html,
pair_coeff"_pair_coeff.html, "thermo_style"_thermo_style.html,
"compute */tally"_compute_tally.html
[Default:]
The option defaults are mix = geometric, shift = no, table = 12,
tabinner = sqrt(2.0), tail = no, and compute = yes.
Note that some pair styles perform mixing, but only a certain style of
mixing. See the doc pages for individual pair styles for details.
:line
:link(Wolff1)
[(Wolff)] Wolff and Rudd, Comp Phys Comm, 120, 200-32 (1999).
:link(Sun)
[(Sun)] Sun, J Phys Chem B, 102, 7338-7364 (1998).

112
doc/txt/pair_oxdna.txt
View File

@ -1,112 +0,0 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
pair_style oxdna/excv command :h3
pair_style oxdna/stk command :h3
pair_style oxdna/hbond command :h3
pair_style oxdna/xstk command :h3
pair_style oxdna/coaxstk command :h3
[Syntax:]
pair_style style1 :pre
pair_coeff * * style2 args :pre
style1 = {hybrid/overlay oxdna/excv oxdna/stk oxdna/hbond oxdna/xstk oxdna/coaxstk} :ul
style2 = {oxdna/excv} or {oxdna/stk} or {oxdna/hbond} or {oxdna/xstk} or {oxdna/coaxstk}
args = list of arguments for these particular styles :ul
{oxdna/stk} args = seq T xi kappa 6.0 0.4 0.9 0.32 0.75 1.3 0 0.8 0.9 0 0.95 0.9 0 0.95 2.0 0.65 2.0 0.65
seq = seqav (for average sequence stacking strength) or seqdep (for sequence-dependent stacking strength)
T = temperature (oxDNA units, 0.1 = 300 K)
xi = temperature-independent coefficient in stacking strength
kappa = coefficient of linear temperature dependence in stacking strength
{oxdna/hbond} args = seq eps 8.0 0.4 0.75 0.34 0.7 1.5 0 0.7 1.5 0 0.7 1.5 0 0.7 0.46 3.141592653589793 0.7 4.0 1.5707963267948966 0.45 4.0 1.5707963267948966 0.45
seq = seqav (for average sequence base-pairing strength) or seqdep (for sequence-dependent base-pairing strength)
eps = 1.077 (between base pairs A-T and C-G) or 0 (all other pairs) :pre
[Examples:]
pair_style hybrid/overlay oxdna/excv oxdna/stk oxdna/hbond oxdna/xstk oxdna/coaxstk
pair_coeff * * oxdna/excv 2.0 0.7 0.675 2.0 0.515 0.5 2.0 0.33 0.32
pair_coeff * * oxdna/stk seqdep 0.1 1.3448 2.6568 6.0 0.4 0.9 0.32 0.75 1.3 0 0.8 0.9 0 0.95 0.9 0 0.95 2.0 0.65 2.0 0.65
pair_coeff * * oxdna/hbond seqdep 0.0 8.0 0.4 0.75 0.34 0.7 1.5 0 0.7 1.5 0 0.7 1.5 0 0.7 0.46 3.141592653589793 0.7 4.0 1.5707963267948966 0.45 4.0 1.5707963267948966 0.45
pair_coeff 1 4 oxdna/hbond seqdep 1.077 8.0 0.4 0.75 0.34 0.7 1.5 0 0.7 1.5 0 0.7 1.5 0 0.7 0.46 3.141592653589793 0.7 4.0 1.5707963267948966 0.45 4.0 1.5707963267948966 0.45
pair_coeff 2 3 oxdna/hbond seqdep 1.077 8.0 0.4 0.75 0.34 0.7 1.5 0 0.7 1.5 0 0.7 1.5 0 0.7 0.46 3.141592653589793 0.7 4.0 1.5707963267948966 0.45 4.0 1.5707963267948966 0.45
pair_coeff * * oxdna/xstk 47.5 0.575 0.675 0.495 0.655 2.25 0.791592653589793 0.58 1.7 1.0 0.68 1.7 1.0 0.68 1.5 0 0.65 1.7 0.875 0.68 1.7 0.875 0.68
pair_coeff * * oxdna/coaxstk 46.0 0.4 0.6 0.22 0.58 2.0 2.541592653589793 0.65 1.3 0 0.8 0.9 0 0.95 0.9 0 0.95 2.0 -0.65 2.0 -0.65 :pre
[Description:]
The {oxdna} pair styles compute the pairwise-additive parts of the oxDNA force field
for coarse-grained modelling of DNA. The effective interaction between the nucleotides consists of potentials for the
excluded volume interaction {oxdna/excv}, the stacking {oxdna/stk}, cross-stacking {oxdna/xstk}
and coaxial stacking interaction {oxdna/coaxstk} as well
as the hydrogen-bonding interaction {oxdna/hbond} between complementary pairs of nucleotides on
opposite strands. Average sequence or sequence-dependent stacking and base-pairing strengths
are supported "(Sulc)"_#Sulc1. Quasi-unique base-pairing between nucleotides can be achieved by using
more complementary pairs of atom types like 5-8 and 6-7, 9-12 and 10-11, 13-16 and 14-15, etc.
This prevents the hybridization of in principle complementary bases within Ntypes/4 bases
up and down along the backbone.
The exact functional form of the pair styles is rather complex.
The individual potentials consist of products of modulation factors,
which themselves are constructed from a number of more basic potentials
(Morse, Lennard-Jones, harmonic angle and distance) as well as quadratic smoothing and modulation terms.
We refer to "(Ouldridge-DPhil)"_#Ouldridge-DPhil1 and "(Ouldridge)"_#Ouldridge1
for a detailed description of the oxDNA force field.
NOTE: These pair styles have to be used together with the related oxDNA bond style
{oxdna/fene} for the connectivity of the phosphate backbone (see also documentation of
"bond_style oxdna/fene"_bond_oxdna.html). Most of the coefficients
in the above example have to be kept fixed and cannot be changed without reparameterizing the entire model.
Exceptions are the first four coefficients after {oxdna/stk} (seq=seqdep, T=0.1, xi=1.3448 and kappa=2.6568 in the above example)
and the first coefficient after {oxdna/hbond} (seq=seqdep in the above example).
When using a Langevin thermostat, e.g. through "fix langevin"_fix_langevin.html
or "fix nve/dotc/langevin"_fix_nve_dotc_langevin.html
the temperature coefficients have to be matched to the one used in the fix.
Example input and data files for DNA duplexes can be found in examples/USER/cgdna/examples/oxDNA/ and /oxDNA2/.
A simple python setup tool which creates single straight or helical DNA strands,
DNA duplexes or arrays of DNA duplexes can be found in examples/USER/cgdna/util/.
Please cite "(Henrich)"_#Henrich1 and the relevant oxDNA articles in any publication that uses this implementation.
The article contains more information on the model, the structure of the input file, the setup tool
and the performance of the LAMMPS-implementation of oxDNA.
The preprint version of the article can be found "here"_PDF/USER-CGDNA.pdf.
:line
[Restrictions:]
These pair styles can only be used if LAMMPS was built with the
USER-CGDNA package and the MOLECULE and ASPHERE package. See the
"Build package"_Build_package.html doc page for more info.
[Related commands:]
"bond_style oxdna/fene"_bond_oxdna.html, "fix nve/dotc/langevin"_fix_nve_dotc_langevin.html, "pair_coeff"_pair_coeff.html,
"bond_style oxdna2/fene"_bond_oxdna.html, "pair_style oxdna2/excv"_pair_oxdna2.html
[Default:] none
:line
:link(Henrich1)
[(Henrich)] O. Henrich, Y. A. Gutierrez-Fosado, T. Curk, T. E. Ouldridge, Eur. Phys. J. E 41, 57 (2018).
:link(Sulc1)
[(Sulc)] P. Sulc, F. Romano, T.E. Ouldridge, L. Rovigatti, J.P.K. Doye, A.A. Louis, J. Chem. Phys. 137, 135101 (2012).
:link(Ouldridge-DPhil1)
[(Ouldrigde-DPhil)] T.E. Ouldridge, Coarse-grained modelling of DNA and DNA self-assembly, DPhil. University of Oxford (2011).
:link(Ouldridge1)
[(Ouldridge)] T.E. Ouldridge, A.A. Louis, J.P.K. Doye, J. Chem. Phys. 134, 085101 (2011).

121
doc/txt/pair_oxdna2.txt
View File

@ -1,121 +0,0 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
pair_style oxdna2/excv command :h3
pair_style oxdna2/stk command :h3
pair_style oxdna2/hbond command :h3
pair_style oxdna2/xstk command :h3
pair_style oxdna2/coaxstk command :h3
pair_style oxdna2/dh command :h3
[Syntax:]
pair_style style1 :pre
pair_coeff * * style2 args :pre
style1 = {hybrid/overlay oxdna2/excv oxdna2/stk oxdna2/hbond oxdna2/xstk oxdna2/coaxstk oxdna2/dh} :ul
style2 = {oxdna2/excv} or {oxdna2/stk} or {oxdna2/hbond} or {oxdna2/xstk} or {oxdna2/coaxstk} or {oxdna2/dh}
args = list of arguments for these particular styles :ul
{oxdna2/stk} args = seq T xi kappa 6.0 0.4 0.9 0.32 0.75 1.3 0 0.8 0.9 0 0.95 0.9 0 0.95 2.0 0.65 2.0 0.65
seq = seqav (for average sequence stacking strength) or seqdep (for sequence-dependent stacking strength)
T = temperature (oxDNA units, 0.1 = 300 K)
xi = temperature-independent coefficient in stacking strength
kappa = coefficient of linear temperature dependence in stacking strength
{oxdna2/hbond} args = seq eps 8.0 0.4 0.75 0.34 0.7 1.5 0 0.7 1.5 0 0.7 1.5 0 0.7 0.46 3.141592653589793 0.7 4.0 1.5707963267948966 0.45 4.0 1.5707963267948966 0.45
seq = seqav (for average sequence base-pairing strength) or seqdep (for sequence-dependent base-pairing strength)
eps = 1.0678 (between base pairs A-T and C-G) or 0 (all other pairs)
{oxdna2/dh} args = T rhos qeff
T = temperature (oxDNA units, 0.1 = 300 K)
rhos = salt concentration (mole per litre)
qeff = effective charge (elementary charges) :pre
[Examples:]
pair_style hybrid/overlay oxdna2/excv oxdna2/stk oxdna2/hbond oxdna2/xstk oxdna2/coaxstk oxdna2/dh
pair_coeff * * oxdna2/excv 2.0 0.7 0.675 2.0 0.515 0.5 2.0 0.33 0.32
pair_coeff * * oxdna2/stk seqdep 0.1 1.3523 2.6717 6.0 0.4 0.9 0.32 0.75 1.3 0 0.8 0.9 0 0.95 0.9 0 0.95 2.0 0.65 2.0 0.65
pair_coeff * * oxdna2/hbond seqdep 0.0 8.0 0.4 0.75 0.34 0.7 1.5 0 0.7 1.5 0 0.7 1.5 0 0.7 0.46 3.141592653589793 0.7 4.0 1.5707963267948966 0.45 4.0 1.5707963267948966 0.45
pair_coeff 1 4 oxdna2/hbond seqdep 1.0678 8.0 0.4 0.75 0.34 0.7 1.5 0 0.7 1.5 0 0.7 1.5 0 0.7 0.46 3.141592653589793 0.7 4.0 1.5707963267948966 0.45 4.0 1.5707963267948966 0.45
pair_coeff 2 3 oxdna2/hbond seqdep 1.0678 8.0 0.4 0.75 0.34 0.7 1.5 0 0.7 1.5 0 0.7 1.5 0 0.7 0.46 3.141592653589793 0.7 4.0 1.5707963267948966 0.45 4.0 1.5707963267948966 0.45
pair_coeff * * oxdna2/xstk 47.5 0.575 0.675 0.495 0.655 2.25 0.791592653589793 0.58 1.7 1.0 0.68 1.7 1.0 0.68 1.5 0 0.65 1.7 0.875 0.68 1.7 0.875 0.68
pair_coeff * * oxdna2/coaxstk 58.5 0.4 0.6 0.22 0.58 2.0 2.891592653589793 0.65 1.3 0 0.8 0.9 0 0.95 0.9 0 0.95 40.0 3.116592653589793
pair_coeff * * oxdna2/dh 0.1 1.0 0.815 :pre
[Description:]
The {oxdna2} pair styles compute the pairwise-additive parts of the oxDNA force field
for coarse-grained modelling of DNA. The effective interaction between the nucleotides consists of potentials for the
excluded volume interaction {oxdna2/excv}, the stacking {oxdna2/stk}, cross-stacking {oxdna2/xstk}
and coaxial stacking interaction {oxdna2/coaxstk}, electrostatic Debye-Hueckel interaction {oxdna2/dh}
as well as the hydrogen-bonding interaction {oxdna2/hbond} between complementary pairs of nucleotides on
opposite strands. Average sequence or sequence-dependent stacking and base-pairing strengths
are supported "(Sulc)"_#Sulc2. Quasi-unique base-pairing between nucleotides can be achieved by using
more complementary pairs of atom types like 5-8 and 6-7, 9-12 and 10-11, 13-16 and 14-15, etc.
This prevents the hybridization of in principle complementary bases within Ntypes/4 bases
up and down along the backbone.
The exact functional form of the pair styles is rather complex.
The individual potentials consist of products of modulation factors,
which themselves are constructed from a number of more basic potentials
(Morse, Lennard-Jones, harmonic angle and distance) as well as quadratic smoothing and modulation terms.
We refer to "(Snodin)"_#Snodin and the original oxDNA publications "(Ouldridge-DPhil)"_#Ouldridge-DPhil2
and "(Ouldridge)"_#Ouldridge2 for a detailed description of the oxDNA2 force field.
NOTE: These pair styles have to be used together with the related oxDNA2 bond style
{oxdna2/fene} for the connectivity of the phosphate backbone (see also documentation of
"bond_style oxdna2/fene"_bond_oxdna.html). Most of the coefficients
in the above example have to be kept fixed and cannot be changed without reparameterizing the entire model.
Exceptions are the first four coefficients after {oxdna2/stk} (seq=seqdep, T=0.1, xi=1.3523 and kappa=2.6717 in the above example),
the first coefficient after {oxdna2/hbond} (seq=seqdep in the above example) and the three coefficients
after {oxdna2/dh} (T=0.1, rhos=1.0, qeff=0.815 in the above example). When using a Langevin thermostat
e.g. through "fix langevin"_fix_langevin.html or "fix nve/dotc/langevin"_fix_nve_dotc_langevin.html
the temperature coefficients have to be matched to the one used in the fix.
Example input and data files for DNA duplexes can be found in examples/USER/cgdna/examples/oxDNA/ and /oxDNA2/.
A simple python setup tool which creates single straight or helical DNA strands,
DNA duplexes or arrays of DNA duplexes can be found in examples/USER/cgdna/util/.
Please cite "(Henrich)"_#Henrich and the relevant oxDNA articles in any publication that uses this implementation.
The article contains more information on the model, the structure of the input file, the setup tool
and the performance of the LAMMPS-implementation of oxDNA.
The preprint version of the article can be found "here"_PDF/USER-CGDNA.pdf.
:line
[Restrictions:]
These pair styles can only be used if LAMMPS was built with the
USER-CGDNA package and the MOLECULE and ASPHERE package. See the
"Build package"_Build_package.html doc page for more info.
[Related commands:]
"bond_style oxdna2/fene"_bond_oxdna.html, "fix nve/dotc/langevin"_fix_nve_dotc_langevin.html, "pair_coeff"_pair_coeff.html,
"bond_style oxdna/fene"_bond_oxdna.html, "pair_style oxdna/excv"_pair_oxdna.html
[Default:] none
:line
:link(Henrich)
[(Henrich)] O. Henrich, Y. A. Gutierrez-Fosado, T. Curk, T. E. Ouldridge, Eur. Phys. J. E 41, 57 (2018).
:link(Sulc2)
[(Sulc)] P. Sulc, F. Romano, T.E. Ouldridge, L. Rovigatti, J.P.K. Doye, A.A. Louis, J. Chem. Phys. 137, 135101 (2012).
:link(Snodin)
[(Snodin)] B.E. Snodin, F. Randisi, M. Mosayebi, et al., J. Chem. Phys. 142, 234901 (2015).
:link(Ouldridge-DPhil2)
[(Ouldrigde-DPhil)] T.E. Ouldridge, Coarse-grained modelling of DNA and DNA self-assembly, DPhil. University of Oxford (2011).
:link(Ouldridge2)
[(Ouldridge)] T.E. Ouldridge, A.A. Louis, J.P.K. Doye, J. Chem. Phys. 134, 085101 (2011).

338
doc/txt/pair_style.txt
View File

@ -1,338 +0,0 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
pair_style command :h3
[Syntax:]
pair_style style args :pre
style = one of the styles from the list below
args = arguments used by a particular style :ul
[Examples:]
pair_style lj/cut 2.5
pair_style eam/alloy
pair_style hybrid lj/charmm/coul/long 10.0 eam
pair_style table linear 1000
pair_style none :pre
[Description:]
Set the formula(s) LAMMPS uses to compute pairwise interactions. In
LAMMPS, pair potentials are defined between pairs of atoms that are
within a cutoff distance and the set of active interactions typically
changes over time. See the "bond_style"_bond_style.html command to
define potentials between pairs of bonded atoms, which typically
remain in place for the duration of a simulation.
In LAMMPS, pairwise force fields encompass a variety of interactions,
some of which include many-body effects, e.g. EAM, Stillinger-Weber,
Tersoff, REBO potentials. They are still classified as "pairwise"
potentials because the set of interacting atoms changes with time
(unlike molecular bonds) and thus a neighbor list is used to find
nearby interacting atoms.
Hybrid models where specified pairs of atom types interact via
different pair potentials can be setup using the {hybrid} pair style.
The coefficients associated with a pair style are typically set for
each pair of atom types, and are specified by the
"pair_coeff"_pair_coeff.html command or read from a file by the
"read_data"_read_data.html or "read_restart"_read_restart.html
commands.
The "pair_modify"_pair_modify.html command sets options for mixing of
type I-J interaction coefficients and adding energy offsets or tail
corrections to Lennard-Jones potentials. Details on these options as
they pertain to individual potentials are described on the doc page
for the potential. Likewise, info on whether the potential
information is stored in a "restart file"_write_restart.html is listed
on the potential doc page.
In the formulas listed for each pair style, {E} is the energy of a
pairwise interaction between two atoms separated by a distance {r}.
The force between the atoms is the negative derivative of this
expression.
If the pair_style command has a cutoff argument, it sets global
cutoffs for all pairs of atom types. The distance(s) can be smaller
or larger than the dimensions of the simulation box.
Typically, the global cutoff value can be overridden for a specific
pair of atom types by the "pair_coeff"_pair_coeff.html command. The
pair style settings (including global cutoffs) can be changed by a
subsequent pair_style command using the same style. This will reset
the cutoffs for all atom type pairs, including those previously set
explicitly by a "pair_coeff"_pair_coeff.html command. The exceptions
to this are that pair_style {table} and {hybrid} settings cannot be
reset. A new pair_style command for these styles will wipe out all
previously specified pair_coeff values.
:line
Here is an alphabetic list of pair styles defined in LAMMPS. They are
also listed in more compact form on the "Commands
pair"_Commands_pair.html doc page.
Click on the style to display the formula it computes, any additional
arguments specified in the pair_style command, and coefficients
specified by the associated "pair_coeff"_pair_coeff.html command.
There are also additional accelerated pair styles included in the
LAMMPS distribution for faster performance on CPUs, GPUs, and KNLs.
The individual style names on the "Commands pair"_Commands_pair.html
doc page are followed by one or more of (g,i,k,o,t) to indicate which
accelerated styles exist.
"none"_pair_none.html - turn off pairwise interactions
"hybrid"_pair_hybrid.html - multiple styles of pairwise interactions
"hybrid/overlay"_pair_hybrid.html - multiple styles of superposed pairwise interactions
"zero"_pair_zero.html - neighbor list but no interactions :ul
"adp"_pair_adp.html - angular dependent potential (ADP) of Mishin
"agni"_pair_agni.html - machine learned potential mapping atomic environment to forces
"airebo"_pair_airebo.html - AIREBO potential of Stuart
"airebo/morse"_pair_airebo.html - AIREBO with Morse instead of LJ
"atm"_pair_atm.html - Axilrod-Teller-Muto potential
"awpmd/cut"_pair_awpmd.html - Antisymmetrized Wave Packet MD potential for atoms and electrons
"beck"_pair_beck.html - Beck potential
"body/nparticle"_pair_body_nparticle.html - interactions between body particles
"body/rounded/polygon"_pair_body_rounded_polygon.html - granular-style 2d polygon potential
"body/rounded/polyhedron"_pair_body_rounded_polyhedron.html - granular-style 3d polyhedron potential
"bop"_pair_bop.html - BOP potential of Pettifor
"born"_pair_born.html - Born-Mayer-Huggins potential
"born/coul/dsf"_pair_born.html - Born with damped-shifted-force model
"born/coul/dsf/cs"_pair_cs.html - Born with damped-shifted-force and core/shell model
"born/coul/long"_pair_born.html - Born with long-range Coulombics
"born/coul/long/cs"_pair_cs.html - Born with long-range Coulombics and core/shell
"born/coul/msm"_pair_born.html - Born with long-range MSM Coulombics
"born/coul/wolf"_pair_born.html - Born with Wolf potential for Coulombics
"born/coul/wolf/cs"_pair_cs.html - Born with Wolf potential for Coulombics and core/shell model
"brownian"_pair_brownian.html - Brownian potential for Fast Lubrication Dynamics
"brownian/poly"_pair_brownian.html - Brownian potential for Fast Lubrication Dynamics with polydispersity
"buck"_pair_buck.html - Buckingham potential
"buck/coul/cut"_pair_buck.html - Buckingham with cutoff Coulomb
"buck/coul/long"_pair_buck.html - Buckingham with long-range Coulombics
"buck/coul/long/cs"_pair_cs.html - Buckingham with long-range Coulombics and core/shell
"buck/coul/msm"_pair_buck.html - Buckingham with long-range MSM Coulombics
"buck/long/coul/long"_pair_buck_long.html - long-range Buckingham with long-range Coulombics
"buck/mdf"_pair_mdf.html - Buckingham with a taper function
"buck6d/coul/gauss/dsf"_pair_buck6d_coul_gauss.html - dispersion-damped Buckingham with damped-shift-force model
"buck6d/coul/gauss/long"_pair_buck6d_coul_gauss.html - dispersion-damped Buckingham with long-range Coulombics
"colloid"_pair_colloid.html - integrated colloidal potential
"comb"_pair_comb.html - charge-optimized many-body (COMB) potential
"comb3"_pair_comb.html - charge-optimized many-body (COMB3) potential
"cosine/squared"_pair_cosine_squared.html - Cooke-Kremer-Deserno membrane model potential
"coul/cut"_pair_coul.html - cutoff Coulombic potential
"coul/cut/soft"_pair_fep_soft.html - Coulombic potential with a soft core
"coul/debye"_pair_coul.html - cutoff Coulombic potential with Debye screening
"coul/diel"_pair_coul_diel.html - Coulomb potential with dielectric permittivity
"coul/dsf"_pair_coul.html - Coulombics with damped-shifted-force model
"coul/long"_pair_coul.html - long-range Coulombic potential
"coul/long/cs"_pair_cs.html - long-range Coulombic potential and core/shell
"coul/long/soft"_pair_fep_soft.html - long-range Coulombic potential with a soft core
"coul/msm"_pair_coul.html - long-range MSM Coulombics
"coul/shield"_pair_coul_shield.html - Coulombics for boron nitride for use with "ilp/graphene/hbn"_pair_ilp_graphene_hbn.html potential
"coul/streitz"_pair_coul.html - Coulombics via Streitz/Mintmire Slater orbitals
"coul/wolf"_pair_coul.html - Coulombics via Wolf potential
"coul/wolf/cs"_pair_cs.html - ditto with core/shell adjustments
"dpd"_pair_dpd.html - dissipative particle dynamics (DPD)
"dpd/fdt"_pair_dpd_fdt.html - DPD for constant temperature and pressure
"dpd/fdt/energy"_pair_dpd_fdt.html - DPD for constant energy and enthalpy
"dpd/tstat"_pair_dpd.html - pair-wise DPD thermostatting
"dsmc"_pair_dsmc.html - Direct Simulation Monte Carlo (DSMC)
"e3b"_pair_e3b.html - Explicit-three body (E3B) water model
"drip"_pair_drip.html - Dihedral-angle-corrected registry-dependent interlayer potential (DRIP)
"eam"_pair_eam.html - embedded atom method (EAM)
"eam/alloy"_pair_eam.html - alloy EAM
"eam/cd"_pair_eam.html - concentration-dependent EAM
"eam/cd/old"_pair_eam.html - older two-site model for concentration-dependent EAM
"eam/fs"_pair_eam.html - Finnis-Sinclair EAM
"edip"_pair_edip.html - three-body EDIP potential
"edip/multi"_pair_edip.html - multi-element EDIP potential
"edpd"_pair_meso.html - eDPD particle interactions
"eff/cut"_pair_eff.html - electron force field with a cutoff
"eim"_pair_eim.html - embedded ion method (EIM)
"exp6/rx"_pair_exp6_rx.html - reactive DPD potential
"extep"_pair_extep.html - extended Tersoff potential
"gauss"_pair_gauss.html - Gaussian potential
"gauss/cut"_pair_gauss.html - generalized Gaussian potential
"gayberne"_pair_gayberne.html - Gay-Berne ellipsoidal potential
"gran/hertz/history"_pair_gran.html - granular potential with Hertzian interactions
"gran/hooke"_pair_gran.html - granular potential with history effects
"gran/hooke/history"_pair_gran.html - granular potential without history effects
"gw"_pair_gw.html - Gao-Weber potential
"gw/zbl"_pair_gw.html - Gao-Weber potential with a repulsive ZBL core
"hbond/dreiding/lj"_pair_hbond_dreiding.html - DREIDING hydrogen bonding LJ potential
"hbond/dreiding/morse"_pair_hbond_dreiding.html - DREIDING hydrogen bonding Morse potential
"ilp/graphene/hbn"_pair_ilp_graphene_hbn.html - registry-dependent interlayer potential (ILP)
"kim"_pair_kim.html - interface to potentials provided by KIM project
"kolmogorov/crespi/full"_pair_kolmogorov_crespi_full.html - Kolmogorov-Crespi (KC) potential with no simplifications
"kolmogorov/crespi/z"_pair_kolmogorov_crespi_z.html - Kolmogorov-Crespi (KC) potential with normals along z-axis
"lcbop"_pair_lcbop.html - long-range bond-order potential (LCBOP)
"lebedeva/z"_pair_lebedeva_z.html - Lebedeva interlayer potential for graphene with normals along z-axis
"lennard/mdf"_pair_mdf.html - LJ potential in A/B form with a taper function
"line/lj"_pair_line_lj.html - LJ potential between line segments
"list"_pair_list.html - potential between pairs of atoms explicitly listed in an input file
"lj/charmm/coul/charmm"_pair_charmm.html - CHARMM potential with cutoff Coulomb
"lj/charmm/coul/charmm/implicit"_pair_charmm.html - CHARMM for implicit solvent
"lj/charmm/coul/long"_pair_charmm.html - CHARMM with long-range Coulomb
"lj/charmm/coul/long/soft"_pair_fep_soft.html - CHARMM with long-range Coulomb and a soft core
"lj/charmm/coul/msm"_pair_charmm.html - CHARMM with long-range MSM Coulombics
"lj/charmmfsw/coul/charmmfsh"_pair_charmm.html - CHARMM with force switching and shifting
"lj/charmmfsw/coul/long"_pair_charmm.html - CHARMM with force switching and long-rnage Coulombics
"lj/class2"_pair_class2.html - COMPASS (class 2) force field with no Coulomb
"lj/class2/coul/cut"_pair_class2.html - COMPASS with cutoff Coulomb
"lj/class2/coul/cut/soft"_pair_fep_soft.html - COMPASS with cutoff Coulomb with a soft core
"lj/class2/coul/long"_pair_class2.html - COMPASS with long-range Coulomb
"lj/class2/coul/long/soft"_pair_fep_soft.html - COMPASS with long-range Coulomb with a soft core
"lj/class2/soft"_pair_fep_soft.html - COMPASS (class 2) force field with no Coulomb with a soft core
"lj/cubic"_pair_lj_cubic.html - LJ with cubic after inflection point
"lj/cut"_pair_lj.html - cutoff Lennard-Jones potential with no Coulomb
"lj/cut/coul/cut"_pair_lj.html - LJ with cutoff Coulomb
"lj/cut/coul/cut/soft"_pair_fep_soft.html - LJ with cutoff Coulomb with a soft core
"lj/cut/coul/debye"_pair_lj.html - LJ with Debye screening added to Coulomb
"lj/cut/coul/dsf"_pair_lj.html - LJ with Coulombics via damped shifted forces
"lj/cut/coul/long"_pair_lj.html - LJ with long-range Coulombics
"lj/cut/coul/long/cs"_pair_cs.html - ditto with core/shell adjustments
"lj/cut/coul/long/soft"_pair_fep_soft.html - LJ with long-range Coulombics with a soft core
"lj/cut/coul/msm"_pair_lj.html - LJ with long-range MSM Coulombics
"lj/cut/coul/wolf"_pair_lj.html - LJ with Coulombics via Wolf potential
"lj/cut/dipole/cut"_pair_dipole.html - point dipoles with cutoff
"lj/cut/dipole/long"_pair_dipole.html - point dipoles with long-range Ewald
"lj/cut/soft"_pair_fep_soft.html - LJ with a soft core
"lj/cut/thole/long"_pair_thole.html - LJ with Coulombics with thole damping
"lj/cut/tip4p/cut"_pair_lj.html - LJ with cutoff Coulomb for TIP4P water
"lj/cut/tip4p/long"_pair_lj.html - LJ with long-range Coulomb for TIP4P water
"lj/cut/tip4p/long/soft"_pair_fep_soft.html - LJ with cutoff Coulomb for TIP4P water with a soft core
"lj/expand"_pair_lj_expand.html - Lennard-Jones for variable size particles
"lj/expand/coul/long"_pair_lj_expand.html - Lennard-Jones for variable size particles with long-range Coulombics
"lj/gromacs"_pair_gromacs.html - GROMACS-style Lennard-Jones potential
"lj/gromacs/coul/gromacs"_pair_gromacs.html - GROMACS-style LJ and Coulombic potential
"lj/long/coul/long"_pair_lj_long.html - long-range LJ and long-range Coulombics
"lj/long/dipole/long"_pair_dipole.html - long-range LJ and long-range point dipoles
"lj/long/tip4p/long"_pair_lj_long.html - long-range LJ and long-range Coulombics for TIP4P water
"lj/mdf"_pair_mdf.html - LJ potential with a taper function
"lj/sdk"_pair_sdk.html - LJ for SDK coarse-graining
"lj/sdk/coul/long"_pair_sdk.html - LJ for SDK coarse-graining with long-range Coulombics
"lj/sdk/coul/msm"_pair_sdk.html - LJ for SDK coarse-graining with long-range Coulombics via MSM
"lj/sf/dipole/sf"_pair_dipole.html - LJ with dipole interaction with shifted forces
"lj/smooth"_pair_lj_smooth.html - smoothed Lennard-Jones potential
"lj/smooth/linear"_pair_lj_smooth_linear.html - linear smoothed LJ potential
"lj/switch3/coulgauss"_pair_lj_switch3_coulgauss - smoothed LJ vdW potential with Gaussian electrostatics
"lj96/cut"_pair_lj96.html - Lennard-Jones 9/6 potential
"local/density"_pair_local_density.html - generalized basic local density potential
"lubricate"_pair_lubricate.html - hydrodynamic lubrication forces
"lubricate/poly"_pair_lubricate.html - hydrodynamic lubrication forces with polydispersity
"lubricateU"_pair_lubricateU.html - hydrodynamic lubrication forces for Fast Lubrication Dynamics
"lubricateU/poly"_pair_lubricateU.html - hydrodynamic lubrication forces for Fast Lubrication with polydispersity
"mdpd"_pair_meso.html - mDPD particle interactions
"mdpd/rhosum"_pair_meso.html - mDPD particle interactions for mass density
"meam/c"_pair_meamc.html - modified embedded atom method (MEAM) in C
"meam/spline"_pair_meam_spline.html - splined version of MEAM
"meam/sw/spline"_pair_meam_sw_spline.html - splined version of MEAM with a Stillinger-Weber term
"mgpt"_pair_mgpt.html - simplified model generalized pseudopotential theory (MGPT) potential
"mie/cut"_pair_mie.html - Mie potential
"mm3/switch3/coulgauss"_pair_mm3_switch3_coulgauss - smoothed MM3 vdW potential with Gaussian electrostatics
"momb"_pair_momb.html - Many-Body Metal-Organic (MOMB) force field
"morse"_pair_morse.html - Morse potential
"morse/smooth/linear"_pair_morse.html - linear smoothed Morse potential
"morse/soft"_pair_morse.html - Morse potential with a soft core
"multi/lucy"_pair_multi_lucy.html - DPD potential with density-dependent force
"multi/lucy/rx"_pair_multi_lucy_rx.html - reactive DPD potential with density-dependent force
"nb3b/harmonic"_pair_nb3b_harmonic.html - non-bonded 3-body harmonic potential
"nm/cut"_pair_nm.html - N-M potential
"nm/cut/coul/cut"_pair_nm.html - N-M potential with cutoff Coulomb
"nm/cut/coul/long"_pair_nm.html - N-M potential with long-range Coulombics
"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/hbond"_pair_oxdna2.html -
"oxdna2/stk"_pair_oxdna2.html -
"oxdna2/xstk"_pair_oxdna2.html -
"peri/eps"_pair_peri.html - peridynamic EPS potential
"peri/lps"_pair_peri.html - peridynamic LPS potential
"peri/pmb"_pair_peri.html - peridynamic PMB potential
"peri/ves"_pair_peri.html - peridynamic VES potential
"polymorphic"_pair_polymorphic.html - polymorphic 3-body potential
"python"_pair_python.html -
"quip"_pair_quip.html -
"reax/c"_pair_reaxc.html - ReaxFF potential in C
"rebo"_pair_airebo.html - 2nd generation REBO potential of Brenner
"resquared"_pair_resquared.html - Everaers RE-Squared ellipsoidal potential
"sdpd/taitwater/isothermal"_pair_sdpd_taitwater_isothermal.html - smoothed dissipative particle dynamics for water at isothermal conditions
"smd/hertz"_pair_smd_hertz.html -
"smd/tlsph"_pair_smd_tlsph.html -
"smd/tri_surface"_pair_smd_triangulated_surface.html -
"smd/ulsph"_pair_smd_ulsph.html -
"smtbq"_pair_smtbq.html -
"snap"_pair_snap.html - SNAP quantum-accurate potential
"soft"_pair_soft.html - Soft (cosine) potential
"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/dipole/cut"_pair_spin_dipole.html -
"spin/dipole/long"_pair_spin_dipole.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"_pair_sw.html - Stillinger-Weber 3-body potential
"table"_pair_table.html - tabulated pair potential
"table/rx"_pair_table_rx.html -
"tdpd"_pair_meso.html - tDPD particle interactions
"tersoff"_pair_tersoff.html - Tersoff 3-body potential
"tersoff/mod"_pair_tersoff_mod.html - modified Tersoff 3-body potential
"tersoff/mod/c"_pair_tersoff_mod.html -
"tersoff/table"_pair_tersoff.html -
"tersoff/zbl"_pair_tersoff_zbl.html - Tersoff/ZBL 3-body potential
"thole"_pair_thole.html - Coulomb interactions with thole damping
"tip4p/cut"_pair_coul.html - Coulomb for TIP4P water w/out LJ
"tip4p/long"_pair_coul.html - long-range Coulombics for TIP4P water w/out LJ
"tip4p/long/soft"_pair_fep_soft.html -
"tri/lj"_pair_tri_lj.html - LJ potential between triangles
"ufm"_pair_ufm.html -
"vashishta"_pair_vashishta.html - Vashishta 2-body and 3-body potential
"vashishta/table"_pair_vashishta.html -
"yukawa"_pair_yukawa.html - Yukawa potential
"yukawa/colloid"_pair_yukawa_colloid.html - screened Yukawa potential for finite-size particles
"zbl"_pair_zbl.html - Ziegler-Biersack-Littmark potential :ul
:line
[Restrictions:]
This command must be used before any coefficients are set by the
"pair_coeff"_pair_coeff.html, "read_data"_read_data.html, or
"read_restart"_read_restart.html commands.
Some pair styles are part of specific packages. They are only enabled
if LAMMPS was built with that package. See the "Build
package"_Build_package.html doc page for more info. The doc pages for
individual pair potentials tell if it is part of a package.
[Related commands:]
"pair_coeff"_pair_coeff.html, "read_data"_read_data.html,
"pair_modify"_pair_modify.html, "kspace_style"_kspace_style.html,
"dielectric"_dielectric.html, "pair_write"_pair_write.html
[Default:]
pair_style none :pre

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