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

Merge branch 'master' into fix-active-rebase-5

Browse Source
This commit is contained in:
Pierre de Buyl
2020-01-17 22:11:55 +01:00
parent a93ba8ab74 868df1f640
commit 4c8a857960
231 changed files with 2038824 additions and 22913 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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})

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/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,26 +25,26 @@ 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 image <dump_image>`
@ -52,75 +52,77 @@ An alphabetic list of all general LAMMPS commands.
* :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 +131,11 @@ 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>`
*
*
*
*

14
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,14 @@ 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
@ -93,11 +91,9 @@ OPT.
* :doc:`table (o) <angle_table>`
*
---
.. _dihedral:
dihedral_style potentials
Dihedral_style potentials
=========================
All LAMMPS :doc:`dihedral_style <dihedral_style>` commands. Some styles
@ -136,7 +132,7 @@ OPT.
.. _improper:
improper_style potentials
Improper_style potentials
=========================
All LAMMPS :doc:`improper\_style <improper_style>` commands. Some styles

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>`
@ -189,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>`
@ -234,7 +236,11 @@ 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>`
*
*
*
*

10
doc/src/Commands_kspace.rst
View File

@ -24,12 +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>`

20
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>`
@ -249,4 +258,3 @@ OPT.
* :doc:`yukawa/colloid (go) <pair_yukawa_colloid>`
* :doc:`zbl (gko) <pair_zbl>`
*
*

6
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.

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 |

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
----------

4
doc/src/Packages_details.rst
View File

@ -2438,8 +2438,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

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

24
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
@ -339,15 +341,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 +387,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 +403,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

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

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.
----------

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

6
doc/src/pair_lj.rst
View File

@ -90,6 +90,9 @@ pair\_style lj/cut/coul/wolf/omp command
pair\_style lj/cut/tip4p/cut command
====================================
pair\_style lj/cut/tip4p/cut/gpu command
========================================
pair\_style lj/cut/tip4p/cut/omp command
========================================
@ -102,9 +105,6 @@ pair\_style lj/cut/tip4p/long/omp command
pair\_style lj/cut/tip4p/long/opt command
=========================================
pair\_style lj/cut/tip4p/long/gpu command
=====================================
Syntax
""""""

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

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.

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

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

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

393
doc/txt/fix.txt
View File

@ -1,393 +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
"propel/self"_fix_propel_self.html - add self-propelling force
"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

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

402
doc/txt/pair_meamc.txt
View File

@ -1,402 +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
This field is only read for compatibility, the correct
value is inferred from the lattice 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

498
doc/txt/python.txt
View File

@ -1,498 +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
python command :h3
[Syntax:]
python func keyword args ... :pre
func = name of Python function :ulb,l
one or more keyword/args pairs must be appended :l
keyword = {invoke} or {input} or {return} or {format} or {length} or {file} or {here} or {exists} or {source}
{invoke} arg = none = invoke the previously defined Python function
{input} args = N i1 i2 ... iN
N = # of inputs to function
i1,...,iN = value, SELF, or LAMMPS variable name
value = integer number, floating point number, or string
SELF = reference to LAMMPS itself which can be accessed by Python function
variable = v_name, where name = name of LAMMPS variable, e.g. v_abc
{return} arg = varReturn
varReturn = v_name = LAMMPS variable name which return value of function will be assigned to
{format} arg = fstring with M characters
M = N if no return value, where N = # of inputs
M = N+1 if there is a return value
fstring = each character (i,f,s,p) corresponds in order to an input or return value
'i' = integer, 'f' = floating point, 's' = string, 'p' = SELF
{length} arg = Nlen
Nlen = max length of string returned from Python function
{file} arg = filename
filename = file of Python code, which defines func
{here} arg = inline
inline = one or more lines of Python code which defines func
must be a single argument, typically enclosed between triple quotes
{exists} arg = none = Python code has been loaded by previous python command
{source} arg = {filename} or {inline}
filename = file of Python code which will be executed immediately
inline = one or more lines of Python code which will be executed immediately
must be a single argument, typically enclosed between triple quotes
:pre
:ule
[Examples:]
python pForce input 2 v_x 20.0 return v_f format fff file force.py
python pForce invoke :pre
python factorial input 1 myN return v_fac format ii here """
def factorial(n):
if n == 1: return n
return n * factorial(n-1)
""" :pre
python loop input 1 SELF return v_value format pf here """
def loop(lmpptr,N,cut0):
from lammps import lammps
lmp = lammps(ptr=lmpptr) :pre
# loop N times, increasing cutoff each time :pre
for i in range(N):
cut = cut0 + i*0.1
lmp.set_variable("cut",cut) # set a variable in LAMMPS
lmp.command("pair_style lj/cut $\{cut\}") # LAMMPS commands
lmp.command("pair_coeff * * 1.0 1.0")
lmp.command("run 100")
""" :pre
[Description:]
Define a Python function or execute a previously defined function or
execute some arbitrary python code.
Arguments, including LAMMPS variables, can be passed to the function
from the LAMMPS input script and a value returned by the Python
function to a LAMMPS variable. The Python code for the function can
be included directly in the input script or in a separate Python file.
The function can be standard Python code or it can make "callbacks" to
LAMMPS through its library interface to query or set internal values
within LAMMPS. This is a powerful mechanism for performing complex
operations in a LAMMPS input script that are not possible with the
simple input script and variable syntax which LAMMPS defines. Thus
your input script can operate more like a true programming language.
Use of this command requires building LAMMPS with the PYTHON package
which links to the Python library so that the Python interpreter is
embedded in LAMMPS. More details about this process are given below.
There are two ways to invoke a Python function once it has been
defined. One is using the {invoke} keyword. The other is to assign
the function to a "python-style variable"_variable.html defined in
your input script. Whenever the variable is evaluated, it will
execute the Python function to assign a value to the variable. Note
that variables can be evaluated in many different ways within LAMMPS.
They can be substituted for directly in an input script. Or they can
be passed to various commands as arguments, so that the variable is
evaluated during a simulation run.
A broader overview of how Python can be used with LAMMPS is given on
the "Python"_Python_head.html doc page. There is an examples/python
directory which illustrates use of the python command.
:line
The {func} setting specifies the name of the Python function. The
code for the function is defined using the {file} or {here} keywords
as explained below. In case of the {source} keyword, the name of
the function is ignored.
If the {invoke} keyword is used, no other keywords can be used, and a
previous python command must have defined the Python function
referenced by this command. This invokes the Python function with the
previously defined arguments and return value processed as explained
below. You can invoke the function as many times as you wish in your
input script.
If the {source} keyword is used, no other keywords can be used.
The argument can be a filename or a string with python commands,
either on a single line enclosed in quotes, or as multiple lines
enclosed in triple quotes. These python commands will be passed
to the python interpreter and executed immediately without registering
a python function for future execution.
The {input} keyword defines how many arguments {N} the Python function
expects. If it takes no arguments, then the {input} keyword should
not be used. Each argument can be specified directly as a value,
e.g. 6 or 3.14159 or abc (a string of characters). The type of each
argument is specified by the {format} keyword as explained below, so
that Python will know how to interpret the value. If the word SELF is
used for an argument it has a special meaning. A pointer is passed to
the Python function which it converts into a reference to LAMMPS
itself. This enables the function to call back to LAMMPS through its
library interface as explained below. This allows the Python function
to query or set values internal to LAMMPS which can affect the
subsequent execution of the input script. A LAMMPS variable can also
be used as an argument, specified as v_name, where "name" is the name
of the variable. Any style of LAMMPS variable can be used, as defined
by the "variable"_variable.html command. Each time the Python
function is invoked, the LAMMPS variable is evaluated and its value is
passed to the Python function.
The {return} keyword is only needed if the Python function returns a
value. The specified {varReturn} must be of the form v_name, where
"name" is the name of a python-style LAMMPS variable, defined by the
"variable"_variable.html command. The Python function can return a
numeric or string value, as specified by the {format} keyword.
As explained on the "variable"_variable.html doc page, the definition
of a python-style variable associates a Python function name with the
variable. This must match the {func} setting for this command. For
example these two commands would be self-consistent:
variable foo python myMultiply
python myMultiply return v_foo format f file funcs.py :pre
The two commands can appear in either order in the input script so
long as both are specified before the Python function is invoked for
the first time.
The {format} keyword must be used if the {input} or {return} keyword
is used. It defines an {fstring} with M characters, where M = sum of
number of inputs and outputs. The order of characters corresponds to
the N inputs, followed by the return value (if it exists). Each
character must be one of the following: "i" for integer, "f" for
floating point, "s" for string, or "p" for SELF. Each character
defines the type of the corresponding input or output value of the
Python function and affects the type conversion that is performed
internally as data is passed back and forth between LAMMPS and Python.
Note that it is permissible to use a "python-style
variable"_variable.html in a LAMMPS command that allows for an
equal-style variable as an argument, but only if the output of the
Python function is flagged as a numeric value ("i" or "f") via the
{format} keyword.
If the {return} keyword is used and the {format} keyword specifies the
output as a string, then the default maximum length of that string is
63 characters (64-1 for the string terminator). If you want to return
a longer string, the {length} keyword can be specified with its {Nlen}
value set to a larger number (the code allocates space for Nlen+1 to
include the string terminator). If the Python function generates a
string longer than the default 63 or the specified {Nlen}, it will be
truncated.
:line
Either the {file}, {here}, or {exists} keyword must be used, but only
one of them. These keywords specify what Python code to load into the
Python interpreter. The {file} keyword gives the name of a file,
which should end with a ".py" suffix, which contains Python code. The
code will be immediately loaded into and run in the "main" module of
the Python interpreter. Note that Python code which contains a
function definition does not "execute" the function when it is run; it
simply defines the function so that it can be invoked later.
The {here} keyword does the same thing, except that the Python code
follows as a single argument to the {here} keyword. This can be done
using triple quotes as delimiters, as in the examples above. This
allows Python code to be listed verbatim in your input script, with
proper indentation, blank lines, and comments, as desired. See the
"Commands parse"_Commands_parse.html doc page, for an explanation of
how triple quotes can be used as part of input script syntax.
The {exists} keyword takes no argument. It means that Python code
containing the required Python function defined by the {func} setting,
is assumed to have been previously loaded by another python command.
Note that the Python code that is loaded and run must contain a
function with the specified {func} name. To operate properly when
later invoked, the function code must match the {input} and
{return} and {format} keywords specified by the python command.
Otherwise Python will generate an error.
:line
This section describes how Python code can be written to work with
LAMMPS.
Whether you load Python code from a file or directly from your input
script, via the {file} and {here} keywords, the code can be identical.
It must be indented properly as Python requires. It can contain
comments or blank lines. If the code is in your input script, it
cannot however contain triple-quoted Python strings, since that will
conflict with the triple-quote parsing that the LAMMPS input script
performs.
All the Python code you specify via one or more python commands is
loaded into the Python "main" module, i.e. __main__. The code can
define global variables or statements that are outside of function
definitions. It can contain multiple functions, only one of which
matches the {func} setting in the python command. This means you can
use the {file} keyword once to load several functions, and the
{exists} keyword thereafter in subsequent python commands to access
the other functions previously loaded.
A Python function you define (or more generally, the code you load)
can import other Python modules or classes, it can make calls to other
system functions or functions you define, and it can access or modify
global variables (in the "main" module) which will persist between
successive function calls. The latter can be useful, for example, to
prevent a function from being invoke multiple times per timestep by
different commands in a LAMMPS input script that access the returned
python-style variable associated with the function. For example,
consider this function loaded with two global variables defined
outside the function:
nsteplast = -1
nvaluelast = 0 :pre
def expensive(nstep):
global nsteplast,nvaluelast
if nstep == nsteplast: return nvaluelast
nsteplast = nstep
# perform complicated calculation
nvalue = ...
nvaluelast = nvalue
return nvalue :pre
Nsteplast stores the previous timestep the function was invoked
(passed as an argument to the function). Nvaluelast stores the return
value computed on the last function invocation. If the function is
invoked again on the same timestep, the previous value is simply
returned, without re-computing it. The "global" statement inside the
Python function allows it to overwrite the global variables.
Note that if you load Python code multiple times (via multiple python
commands), you can overwrite previously loaded variables and functions
if you are not careful. E.g. if the code above were loaded twice, the
global variables would be re-initialized, which might not be what you
want. Likewise, if a function with the same name exists in two chunks
of Python code you load, the function loaded second will override the
function loaded first.
It's important to realize that if you are running LAMMPS in parallel,
each MPI task will load the Python interpreter and execute a local
copy of the Python function(s) you define. There is no connection
between the Python interpreters running on different processors.
This implies three important things.
First, if you put a print statement in your Python function, you will
see P copies of the output, when running on P processors. If the
prints occur at (nearly) the same time, the P copies of the output may
be mixed together. Welcome to the world of parallel programming and
debugging.
Second, if your Python code loads modules that are not pre-loaded by
the Python library, then it will load the module from disk. This may
be a bottleneck if 1000s of processors try to load a module at the
same time. On some large supercomputers, loading of modules from disk
by Python may be disabled. In this case you would need to pre-build a
Python library that has the required modules pre-loaded and link
LAMMPS with that library.
Third, if your Python code calls back to LAMMPS (discussed in the
next section) and causes LAMMPS to perform an MPI operation requires
global communication (e.g. via MPI_Allreduce), such as computing the
global temperature of the system, then you must insure all your Python
functions (running independently on different processors) call back to
LAMMPS. Otherwise the code may hang.
:line
Your Python function can "call back" to LAMMPS through its
library interface, if you use the SELF input to pass Python
a pointer to LAMMPS. The mechanism for doing this in your
Python function is as follows:
def foo(lmpptr,...):
from lammps import lammps
lmp = lammps(ptr=lmpptr)
lmp.command('print "Hello from inside Python"')
... :pre
The function definition must include a variable (lmpptr in this case)
which corresponds to SELF in the python command. The first line of
the function imports the Python module lammps.py in the python dir of
the distribution. The second line creates a Python object "lmp" which
wraps the instance of LAMMPS that called the function. The
"ptr=lmpptr" argument is what makes that happen. The third line
invokes the command() function in the LAMMPS library interface. It
takes a single string argument which is a LAMMPS input script command
for LAMMPS to execute, the same as if it appeared in your input
script. In this case, LAMMPS should output
Hello from inside Python :pre
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 "Pytnon library"_Python_library.html doc page describes the syntax
for how Python wraps the various functions included in the LAMMPS
library interface.
A more interesting example is in the examples/python/in.python script
which loads and runs the following function from examples/python/funcs.py:
def loop(N,cut0,thresh,lmpptr):
print "LOOP ARGS",N,cut0,thresh,lmpptr
from lammps import lammps
lmp = lammps(ptr=lmpptr)
natoms = lmp.get_natoms() :pre
for i in range(N):
cut = cut0 + i*0.1 :pre
lmp.set_variable("cut",cut) # set a variable in LAMMPS
lmp.command("pair_style lj/cut $\{cut\}") # LAMMPS command
#lmp.command("pair_style lj/cut %d" % cut) # LAMMPS command option :pre
lmp.command("pair_coeff * * 1.0 1.0") # ditto
lmp.command("run 10") # ditto
pe = lmp.extract_compute("thermo_pe",0,0) # extract total PE from LAMMPS
print "PE",pe/natoms,thresh
if pe/natoms < thresh: return :pre
with these input script commands:
python loop input 4 10 1.0 -4.0 SELF format iffp file funcs.py
python loop invoke :pre
This has the effect of looping over a series of 10 short runs (10
timesteps each) where the pair style cutoff is increased from a value
of 1.0 in distance units, in increments of 0.1. The looping stops
when the per-atom potential energy falls below a threshold of -4.0 in
energy units. More generally, Python can be used to implement a loop
with complex logic, much more so than can be created using the LAMMPS
"jump"_jump.html and "if"_if.html commands.
Several LAMMPS library functions are called from the loop function.
Get_natoms() returns the number of atoms in the simulation, so that it
can be used to normalize the potential energy that is returned by
extract_compute() for the "thermo_pe" compute that is defined by
default for LAMMPS thermodynamic output. Set_variable() sets the
value of a string variable defined in LAMMPS. This library function
is a useful way for a Python function to return multiple values to
LAMMPS, more than the single value that can be passed back via a
return statement. This cutoff value in the "cut" variable is then
substituted (by LAMMPS) in the pair_style command that is executed
next. Alternatively, the "LAMMPS command option" line could be used
in place of the 2 preceding lines, to have Python insert the value
into the LAMMPS command string.
NOTE: When using the callback mechanism just described, recognize that
there are some operations you should not attempt because LAMMPS cannot
execute them correctly. If the Python function is invoked between
runs in the LAMMPS input script, then it should be OK to invoke any
LAMMPS input script command via the library interface command() or
file() functions, so long as the command would work if it were
executed in the LAMMPS input script directly at the same point.
However, a Python function can also be invoked during a run, whenever
an associated LAMMPS variable it is assigned to is evaluated. If the
variable is an input argument to another LAMMPS command (e.g. "fix
setforce"_fix_setforce.html), then the Python function will be invoked
inside the class for that command, in one of its methods that is
invoked in the middle of a timestep. You cannot execute arbitrary
input script commands from the Python function (again, via the
command() or file() functions) at that point in the run and expect it
to work. Other library functions such as those that invoke computes
or other variables may have hidden side effects as well. In these
cases, LAMMPS has no simple way to check that something illogical is
being attempted.
The same applies to Python functions called during a simulation run at
each time step using "fix python/invoke"_fix_python_invoke.html.
:line
If you run Python code directly on your workstation, either
interactively or by using Python to launch a Python script stored in a
file, and your code has an error, you will typically see informative
error messages. That is not the case when you run Python code from
LAMMPS using an embedded Python interpreter. The code will typically
fail silently. LAMMPS will catch some errors but cannot tell you
where in the Python code the problem occurred. For example, if the
Python code cannot be loaded and run because it has syntax or other
logic errors, you may get an error from Python pointing to the
offending line, or you may get one of these generic errors from
LAMMPS:
Could not process Python file
Could not process Python string :pre
When the Python function is invoked, if it does not return properly,
you will typically get this generic error from LAMMPS:
Python function evaluation failed :pre
Here are three suggestions for debugging your Python code while
running it under LAMMPS.
First, don't run it under LAMMPS, at least to start with! Debug it
using plain Python. Load and invoke your function, pass it arguments,
check return values, etc.
Second, add Python print statements to the function to check how far
it gets and intermediate values it calculates. See the discussion
above about printing from Python when running in parallel.
Third, use Python exception handling. For example, say this statement
in your Python function is failing, because you have not initialized the
variable foo:
foo += 1 :pre
If you put one (or more) statements inside a "try" statement,
like this:
import exceptions
print "Inside simple function"
try:
foo += 1 # one or more statements here
except Exception, e:
print "FOO error:",e :pre
then you will get this message printed to the screen:
FOO error: local variable 'foo' referenced before assignment :pre
If there is no error in the try statements, then nothing is printed.
Either way the function continues on (unless you put a return or
sys.exit() in the except clause).
:line
[Restrictions:]
This command is part of the PYTHON package. It is only enabled if
LAMMPS was built with that package. See the "Build
package"_Build_package.html doc page for more info.
Building LAMMPS with the PYTHON package will link LAMMPS with the
Python library on your system. Settings to enable this are in the
lib/python/Makefile.lammps file. See the lib/python/README file for
information on those settings.
If you use Python code which calls back to LAMMPS, via the SELF input
argument explained above, there is an extra step required when
building LAMMPS. LAMMPS must also be built as a shared library and
your Python function must be able to load the Python module in
python/lammps.py that wraps the LAMMPS library interface. These are
the same steps required to use Python by itself to wrap LAMMPS.
Details on these steps are explained on the "Python"_Python_head.html
doc page. Note that it is important that the stand-alone LAMMPS
executable and the LAMMPS shared library be consistent (built from the
same source code files) in order for this to work. If the two have
been built at different times using different source files, problems
may occur.
[Related commands:]
"shell"_shell.html, "variable"_variable.html, "fix
python/invoke"_fix_python_invoke.html
[Default:] none

71
doc/txt/server.txt
View File

@ -1,71 +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
server command :h3
[Syntax:]
server protocol :pre
protocol = {md} or {mc} :ul
[Examples:]
server md :pre
[Description:]
This command starts LAMMPS running in "server" mode, where it receives
messages from a separate "client" code and responds by sending a reply
message back to the client. The specified {protocol} determines the
format and content of messages LAMMPS expects to receive and how it
responds.
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 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
processed.
The {protocol} argument defines the format and content of messages
that will be exchanged between the two codes. The current options
are:
"md"_server_md.html = run dynamics with another code
"mc"_server_mc.html = perform Monte Carlo moves with another code :ul
For protocol {md}, LAMMPS can be either a client (via the "fix
client/md"_fix_client_md.html command) 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
[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.
A script that uses this command must also use the
"message"_message.html command to setup the messaging protocol with
the other client code.
[Related commands:]
"message"_message.html, "fix client/md"_fix_client_md.html
[Default:] none

244
doc/utils/check-styles.py Executable file
View File

@ -0,0 +1,244 @@
#!/usr/bin/env python3
from __future__ import print_function
from glob import glob
from argparse import ArgumentParser
import os, re, sys
parser = ArgumentParser(prog='check-styles.py',
description="Check style table completeness")
parser.add_argument("-v", "--verbose",
action='store_const',
const=True, default=False,
help="Enable verbose output")
parser.add_argument("-d", "--doc",
help="Path to LAMMPS documentation sources")
parser.add_argument("-s", "--src",
help="Path to LAMMPS sources")
args = parser.parse_args()
verbose = args.verbose
src = args.src
doc = args.doc
if not args.src or not args.doc:
parser.print_help()
sys.exit(1)
if not os.path.isdir(src):
sys.exit("LAMMPS source path %s does not exist" % src)
if not os.path.isdir(doc):
sys.exit("LAMMPS documentation source path %s does not exist" % doc)
headers = glob(os.path.join(src, '*', '*.h'))
headers += glob(os.path.join(src, '*.h'))
angle = {}
atom = {}
body = {}
bond = {}
command = {}
compute = {}
dihedral = {}
dump = {}
fix = {}
improper = {}
integrate = {}
kspace = {}
minimize = {}
pair = {}
reader = {}
region = {}
upper = re.compile("[A-Z]+")
gpu = re.compile("(.+)/gpu$")
intel = re.compile("(.+)/intel$")
kokkos = re.compile("(.+)/kk$")
kokkos_skip = re.compile("(.+)/kk/(host|device)$")
omp = re.compile("(.+)/omp$")
opt = re.compile("(.+)/opt$")
removed = re.compile("(.+)Deprecated$")
def register_style(list,style,info):
if style in list.keys():
list[style]['gpu'] += info['gpu']
list[style]['intel'] += info['intel']
list[style]['kokkos'] += info['kokkos']
list[style]['omp'] += info['omp']
list[style]['opt'] += info['opt']
list[style]['removed'] += info['removed']
else:
list[style] = info
def add_suffix(list,style):
suffix = ""
if list[style]['gpu']:
suffix += 'g'
if list[style]['intel']:
suffix += 'i'
if list[style]['kokkos']:
suffix += 'k'
if list[style]['omp']:
suffix += 'o'
if list[style]['opt']:
suffix += 't'
if suffix:
return style + ' (' + suffix + ')'
else:
return style
def check_style(file,dir,pattern,list,name,suffix=False,skip=()):
f = os.path.join(dir, file)
fp = open(f)
text = fp.read()
fp.close()
matches = re.findall(pattern,text,re.MULTILINE)
counter = 0
for c in list.keys():
# known undocumented aliases we need to skip
if c in skip: continue
s = c
if suffix: s = add_suffix(list,c)
if not s in matches:
if not list[c]['removed']:
print("%s style entry %s" % (name,s),
"is missing or incomplete in %s" % file)
counter += 1
return counter
for h in headers:
if verbose: print("Checking ", h)
fp = open(h)
text = fp.read()
fp.close()
matches = re.findall("(.+)Style\((.+),(.+)\)",text,re.MULTILINE)
for m in matches:
# skip over internal styles w/o explicit documentation
style = m[1]
if upper.match(style):
continue
# detect, process, and flag suffix styles:
info = { 'kokkos': 0, 'gpu': 0, 'intel': 0, \
'omp': 0, 'opt': 0, 'removed': 0 }
suffix = kokkos_skip.match(style)
if suffix:
continue
suffix = gpu.match(style)
if suffix:
style = suffix.groups()[0]
info['gpu'] = 1
suffix = intel.match(style)
if suffix:
style = suffix.groups()[0]
info['intel'] = 1
suffix = kokkos.match(style)
if suffix:
style = suffix.groups()[0]
info['kokkos'] = 1
suffix = omp.match(style)
if suffix:
style = suffix.groups()[0]
info['omp'] = 1
suffix = opt.match(style)
if suffix:
style = suffix.groups()[0]
info['opt'] = 1
deprecated = removed.match(m[2])
if deprecated:
info['removed'] = 1
# register style and suffix flags
if m[0] == 'Angle':
register_style(angle,style,info)
elif m[0] == 'Atom':
register_style(atom,style,info)
elif m[0] == 'Body':
register_style(body,style,info)
elif m[0] == 'Bond':
register_style(bond,style,info)
elif m[0] == 'Command':
register_style(command,style,info)
elif m[0] == 'Compute':
register_style(compute,style,info)
elif m[0] == 'Dihedral':
register_style(dihedral,style,info)
elif m[0] == 'Dump':
register_style(dump,style,info)
elif m[0] == 'Fix':
register_style(fix,style,info)
elif m[0] == 'Improper':
register_style(improper,style,info)
elif m[0] == 'Integrate':
register_style(integrate,style,info)
elif m[0] == 'KSpace':
register_style(kspace,style,info)
elif m[0] == 'Minimize':
register_style(minimize,style,info)
elif m[0] == 'Pair':
register_style(pair,style,info)
elif m[0] == 'Reader':
register_style(reader,style,info)
elif m[0] == 'Region':
register_style(region,style,info)
else:
print("Skipping over: ",m)
print("""Parsed style names w/o suffixes from C++ tree in %s:
Angle styles: %3d Atom styles: %3d
Body styles: %3d Bond styles: %3d
Command styles: %3d Compute styles: %3d
Dihedral styles: %3d Dump styles: %3d
Fix styles: %3d Improper styles: %3d
Integrate styles: %3d Kspace styles: %3d
Minimize styles: %3d Pair styles: %3d
Reader styles: %3d Region styles: %3d""" \
% (src, len(angle), len(atom), len(body), len(bond), \
len(command), len(compute), len(dihedral), len(dump), \
len(fix), len(improper), len(integrate), len(kspace), \
len(minimize), len(pair), len(reader), len(region)))
counter = 0
counter += check_style('Commands_all.rst',doc,":doc:`(.+) <.+>`",
command,'Command',suffix=False)
counter += check_style('Commands_compute.rst',doc,":doc:`(.+) <compute.+>`",
compute,'Compute',suffix=True)
counter += check_style('compute.rst',doc,":doc:`(.+) <compute.+>` -",
compute,'Compute',suffix=False)
counter += check_style('Commands_fix.rst',doc,":doc:`(.+) <fix.+>`",
fix,'Fix',skip=('python'),suffix=True)
counter += check_style('fix.rst',doc,":doc:`(.+) <fix.+>` -",
fix,'Fix',skip=('python'),suffix=False)
counter += check_style('Commands_pair.rst',doc,":doc:`(.+) <pair.+>`",
pair,'Pair',skip=('meam','lj/sf'),suffix=True)
counter += check_style('pair_style.rst',doc,":doc:`(.+) <pair.+>` -",
pair,'Pair',skip=('meam','lj/sf'),suffix=False)
counter += check_style('Commands_bond.rst',doc,":doc:`(.+) <bond.+>`",
bond,'Bond',suffix=True)
counter += check_style('bond_style.rst',doc,":doc:`(.+) <bond.+>` -",
bond,'Bond',suffix=False)
counter += check_style('Commands_bond.rst',doc,":doc:`(.+) <angle.+>`",
angle,'Angle',suffix=True)
counter += check_style('angle_style.rst',doc,":doc:`(.+) <angle.+>` -",
angle,'Angle',suffix=False)
counter += check_style('Commands_bond.rst',doc,":doc:`(.+) <dihedral.+>`",
dihedral,'Dihedral',suffix=True)
counter += check_style('dihedral_style.rst',doc,":doc:`(.+) <dihedral.+>` -",
dihedral,'Dihedral',suffix=False)
counter += check_style('Commands_bond.rst',doc,":doc:`(.+) <improper.+>`",
improper,'Improper',suffix=True)
counter += check_style('improper_style.rst',doc,":doc:`(.+) <improper.+>` -",
improper,'Improper',suffix=False)
counter += check_style('Commands_kspace.rst',doc,":doc:`(.+) <kspace_style>`",
kspace,'KSpace',suffix=True)
if counter:
print("Found %d issue(s) with style lists" % counter)

2
doc/utils/converters/lammpsdoc/rst_anchor_check.py
View File

@ -42,7 +42,7 @@ def main():
else:
anchors[label] = [(filename, line_number+1)]
print("found %d anchor labels" % len(anchors))
print("Found %d anchor labels" % len(anchors))
count = 0

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

@ -12,6 +12,9 @@ Accelrys
acceptor
Acceptor
acceptors
accomx
accomy
accomz
accuracies
ach
ackland
@ -214,6 +217,7 @@ Bertotti
Bessarab
Beutler
Bext
Bfrac
bgq
Bh
Biersack
@ -307,11 +311,14 @@ cartesian
CasP
Caswell
Cates
cauchy
cauchystat
Cavium
Cawkwell
cbecker
ccache
ccachepiecewise
ccl
ccmake
ccNspecies
CCu
@ -325,6 +332,8 @@ centro
centroid
Centroid
centrosymmetry
Cercignani
cercignanilampis
Cerda
ceriotti
Ceriotti
@ -586,6 +595,7 @@ diagonalized
Diallo
diel
differentiable
diffusively
diffusivity
dihedral
dihedrals
@ -773,6 +783,7 @@ equi
equil
equilibrate
equilibrated
equilibrates
equilibrating
equilibration
Equilibria
@ -1141,6 +1152,7 @@ ico
icosahedral
idealgas
IDR
idx
ielement
ieni
ifdefs
@ -1405,6 +1417,7 @@ lammps
Lammps
LAMMPS
lammpsplot
Lampis
Lamoureux
Lande
Landron
@ -1421,6 +1434,7 @@ Latour
latourr
lattce
Laupretre
Lauriat
lavenderblush
lawngreen
lB
@ -1617,6 +1631,8 @@ maxsize
maxspecial
maxSteps
maxstrain
maxwell
Maxwellian
maxX
Mayergoyz
mbt
@ -1660,6 +1676,7 @@ Mersenne
Merz
meshless
meso
mesocnt
mesoparticle
mesoscale
mesoscopic
@ -2115,6 +2132,7 @@ pathangle
Patomtrans
Pattnaik
Pavese
Pavia
Paxton
pbc
pc
@ -2153,6 +2171,7 @@ pfactor
pgi
ph
Phillpot
Philos
phiphi
phonon
phonons
@ -2173,6 +2192,7 @@ piecewise
Pieniazek
Pieter
pimd
Piola
Pisarev
Pishevar
Pitera
@ -2354,6 +2374,7 @@ rebo
recursing
Ree
refactored
reflectionstyle
regoin
Reinders
reinit
@ -2465,6 +2486,7 @@ Rr
rRESPA
Rspace
rsq
rstyle
Rubensson
Rubia
Rudd
@ -2475,6 +2497,8 @@ Runge
runtime
Rutuparna
rx
ry
rz
Ryckaert
Rycroft
Rydbergs
@ -2569,6 +2593,7 @@ Sikandar
Silbert
Silling
Sim
Simov
Simul
simulations
Sinnott
@ -2621,6 +2646,7 @@ Souza
sp
spacings
Spearot
specular
Spellmeyer
sph
SPH
@ -2665,6 +2691,8 @@ Stillinger
stk
Stockmayer
Stoddard
stochastically
stochasticity
stoichiometric
stoichiometry
Stokesian
@ -2900,6 +2928,7 @@ UEF
ufm
Uhlenbeck
Ui
uInfParallel
uk
ul
ulb
@ -2940,6 +2969,7 @@ upto
Urbakh
Urbana
usec
uSemiParallel
userguide
username
usr
@ -3007,6 +3037,7 @@ VMDHOME
vn
Voigt
volfactor
Volkov
Volpe
volpress
volumetric
@ -3029,6 +3060,7 @@ VTK
vtp
vtr
vtu
Vu
vv
vx
Vx
@ -3158,6 +3190,7 @@ zflag
Zhang
Zhen
zhi
Zhigilei
Zhou
Zhu
zi

1
examples/COUPLE/lammps_vasp/in.client.W
View File

@ -32,3 +32,4 @@ fix_modify 2 energy yes
thermo 1
run 3
message quit

5
examples/README
View File

@ -101,6 +101,7 @@ prd: parallel replica dynamics of vacancy diffusion in bulk Si
python: use of PYTHON package to invoke Python code from input script
qeq: use of QEQ package for charge equilibration
reax: RDX and TATB and several other models using 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: examples for using several bundled SNAP potentials
@ -111,6 +112,7 @@ tad: temperature-accelerated dynamics of vacancy diffusion in bulk Si
threebody: regression test input for a variety of manybody potentials
vashishta: models using the Vashishta potential
voronoi: Voronoi tesselation via compute voronoi/atom command
wall: use of reflective walls with different stochastic models
Here is how you might run and visualize one of the sample problems:
@ -164,6 +166,9 @@ The MC directory has an example script for using LAMMPS as an
energy-evaluation engine in a iterative Monte Carlo energy-relaxation
loop.
The TIP4P directory has an example for testing forces computed on a
GPU.
The UNITS directory contains examples of input scripts modeling the
same Lennard-Jones liquid model, written in 3 different unit systems:
lj, real, and metal. So that you can see how to scale/unscale input

1
examples/USER/misc/cauchy/NiAlH_jea.eam.alloy Symbolic link
View File

@ -0,0 +1 @@
../../../../potentials/NiAlH_jea.eam.alloy

10
examples/USER/misc/cauchy/README Normal file
View File

@ -0,0 +1,10 @@
Run this example by executing:
% lmp -in in.cauchystat
Note that this example use an EAM potential, and therefore must be
run with a LAMMPS executable built with the MANYBODY package.
The first cauchystat fix equilibrates the temperature at zero stress,
the second fix applies a shear stress. Output in avg.txt shows
convergence to correct values.

68
examples/USER/misc/cauchy/in.cauchystat Normal file
View File

@ -0,0 +1,68 @@
units metal
atom_style atomic
atom_modify map array
# Box and atom positions:
boundary p p p
# Defining lattice and creating simulation
# box with atoms inside
lattice fcc 4.05
region simbox prism 0 5 0 5 0 5 0 0 0 units lattice
create_box 2 simbox
create_atoms 2 box
# Atomic mass:
mass 1 58.69
mass 2 26.98154
# Potential, Al fcc crystal
pair_style eam/alloy
pair_coeff * * NiAlH_jea.eam.alloy Ni Al
neigh_modify delay 5
thermo 100
thermo_style custom step temp pxx pyy pzz pxy pxz pyz
compute cna all cna/atom 2.8
fix 1 all npt/cauchy temp 600.0 600.0 1.0 &
x 0.0 0.0 0.1 &
y 0.0 0.0 0.1 &
z 0.0 0.0 0.1 &
couple none alpha 0.001 continue no
# dump 1 all cfg 1000 test*.cfg mass type xs ys zs type c_cna
timestep 0.002
variable px equal pxx
variable py equal pyy
variable pz equal pzz
variable sxy equal pxy
variable sxz equal pxz
variable syz equal pyz
variable t equal temp
fix avg all ave/time 1 100 100 v_t v_px v_py v_pz v_sxy v_sxz v_syz file avg.txt
variable lx equal lx
variable ly equal ly
variable lz equal ly
variable xy equal xy
variable xz equal xz
variable yz equal yz
fix box all ave/time 1 100 100 v_lx v_ly v_lz v_xy v_xz v_yz file box.txt
velocity all create 1200 4928459 rot yes dist gaussian
run 1000
fix 1 all npt/cauchy temp 600.0 600.0 1.0 &
x 0.0 0.0 0.1 &
y 0.0 0.0 0.1 &
z 0.0 0.0 0.1 &
xy -10000.0 -10000.0 0.1 &
couple none alpha 0.001 continue yes
run 1000

172
examples/USER/misc/cauchy/log.9Jan2020.cauchystat.g++.1 Normal file
View File

@ -0,0 +1,172 @@
LAMMPS (09 Jan 2020)
OMP_NUM_THREADS environment is not set. Defaulting to 1 thread. (src/comm.cpp:93)
using 1 OpenMP thread(s) per MPI task
units metal
atom_style atomic
atom_modify map array
# Box and atom positions:
boundary p p p
# Defining lattice and creating simulation
# box with atoms inside
lattice fcc 4.05
Lattice spacing in x,y,z = 4.05 4.05 4.05
region simbox prism 0 5 0 5 0 5 0 0 0 units lattice
create_box 2 simbox
Created triclinic box = (0 0 0) to (20.25 20.25 20.25) with tilt (0 0 0)
1 by 1 by 1 MPI processor grid
create_atoms 2 box
Created 500 atoms
create_atoms CPU = 0.000987053 secs
# Atomic mass:
mass 1 58.69
mass 2 26.98154
# Potential, Al fcc crystal
pair_style eam/alloy
pair_coeff * * NiAlH_jea.eam.alloy Ni Al
Reading potential file NiAlH_jea.eam.alloy with DATE: 2007-11-30
neigh_modify delay 5
thermo 100
thermo_style custom step temp pxx pyy pzz pxy pxz pyz
compute cna all cna/atom 2.8
fix 1 all npt/cauchy temp 600.0 600.0 1.0 x 0.0 0.0 0.1 y 0.0 0.0 0.1 z 0.0 0.0 0.1 couple none alpha 0.001 continue no
Using fix npt/cauchy with alpha=0.001000
this is NOT a continuation run
# dump 1 all cfg 1000 test*.cfg mass type xs ys zs type c_cna
timestep 0.002
variable px equal pxx
variable py equal pyy
variable pz equal pzz
variable sxy equal pxy
variable sxz equal pxz
variable syz equal pyz
variable t equal temp
fix avg all ave/time 1 100 100 v_t v_px v_py v_pz v_sxy v_sxz v_syz file avg.txt
variable lx equal lx
variable ly equal ly
variable lz equal ly
variable xy equal xy
variable xz equal xz
variable yz equal yz
fix box all ave/time 1 100 100 v_lx v_ly v_lz v_xy v_xz v_yz file box.txt
velocity all create 1200 4928459 rot yes dist gaussian
run 1000
Neighbor list info ...
update every 1 steps, delay 5 steps, check yes
max neighbors/atom: 2000, page size: 100000
master list distance cutoff = 7.65
ghost atom cutoff = 7.65
binsize = 3.825, bins = 6 6 6
2 neighbor lists, perpetual/occasional/extra = 1 1 0
(1) pair eam/alloy, perpetual
attributes: half, newton on
pair build: half/bin/newton/tri
stencil: half/bin/3d/newton/tri
bin: standard
(2) compute cna/atom, occasional
attributes: full, newton on
pair build: full/bin/atomonly
stencil: full/bin/3d
bin: standard
Per MPI rank memory allocation (min/avg/max) = 4.04 | 4.04 | 4.04 Mbytes
Step Temp Pxx Pyy Pzz Pxy Pxz Pyz
0 1200 9859.2374 9729.7389 10279.526 -110.10907 -391.60768 295.10918
100 461.95579 11262.405 9918.4702 7373.1896 1389.9833 -165.54737 -128.04989
200 452.7497 4758.0631 6285.2022 9593.9725 389.15901 835.71435 -1853.9679
300 451.50974 7980.6036 7524.3514 9584.5276 297.33672 -154.88768 -1927.573
400 461.52812 5074.9544 4877.0864 2689.9029 389.66084 224.44814 563.12739
500 458.17416 7672.6668 5358.5073 4670.0236 -1251.047 1175.8268 -373.96822
600 461.28593 3629.8562 7265.1611 6970.1746 523.3139 1295.8252 -121.17116
700 466.86592 5224.2421 4121.434 4368.4226 230.85768 -65.765274 -1271.8354
800 491.38828 -233.79818 2799.6028 5023.998 919.08469 -411.66796 422.33219
900 473.16465 6486.5426 4028.6955 2503.9771 451.96928 1309.8322 -557.83472
1000 472.85932 4303.6923 4674.969 5268.2263 94.551286 1425.2222 -1352.0883
Loop time of 1.24705 on 1 procs for 1000 steps with 500 atoms
Performance: 138.567 ns/day, 0.173 hours/ns, 801.892 timesteps/s
94.0% CPU use with 1 MPI tasks x 1 OpenMP threads
MPI task timing breakdown:
Section | min time | avg time | max time |%varavg| %total
---------------------------------------------------------------
Pair | 1.112 | 1.112 | 1.112 | 0.0 | 89.17
Neigh | 0.063329 | 0.063329 | 0.063329 | 0.0 | 5.08
Comm | 0.01994 | 0.01994 | 0.01994 | 0.0 | 1.60
Output | 0.0014246 | 0.0014246 | 0.0014246 | 0.0 | 0.11
Modify | 0.045429 | 0.045429 | 0.045429 | 0.0 | 3.64
Other | | 0.004881 | | | 0.39
Nlocal: 500 ave 500 max 500 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Nghost: 2017 ave 2017 max 2017 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Neighs: 24689 ave 24689 max 24689 min
Histogram: 1 0 0 0 0 0 0 0 0 0
FullNghs: 0 ave 0 max 0 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Total # of neighbors = 24689
Ave neighs/atom = 49.378
Neighbor list builds = 34
Dangerous builds = 0
fix 1 all npt/cauchy temp 600.0 600.0 1.0 x 0.0 0.0 0.1 y 0.0 0.0 0.1 z 0.0 0.0 0.1 xy -10000.0 -10000.0 0.1 couple none alpha 0.001 continue yes
Using fix npt/cauchy with alpha=0.001000
this is a continuation run
run 1000
Per MPI rank memory allocation (min/avg/max) = 4.056 | 4.056 | 4.056 Mbytes
Step Temp Pxx Pyy Pzz Pxy Pxz Pyz
1000 472.85932 4303.6923 4674.969 5268.2263 94.551286 1425.2222 -1352.0883
1100 471.04772 5593.1614 5874.9867 3608.9922 -1861.938 459.86813 -813.36882
1200 473.34727 2337.4765 2050.4694 4330.2198 -3590.2198 -1285.2197 748.05137
1300 465.46145 4909.5722 2880.9183 4995.0091 -2860.6934 -895.40937 -382.07531
1400 508.53262 92.57534 3722.1136 557.50974 -3121.7615 349.6147 194.5089
1500 498.34579 -5755.2352 -3798.1466 -1445.2047 -3218.0887 1733.9103 -555.96371
1600 546.45882 -257.80132 407.73403 -39.803803 -3578.1137 1438.3526 -1710.3139
1700 570.72785 -2951.9658 -622.89945 1138.4113 -4573.7982 -984.65235 2906.3144
1800 650.75622 6086.1524 1111.2919 1726.5115 -3504.716 1140.9767 414.81284
1900 690.32264 2763.2044 -609.41535 289.85307 -3788.8761 -1306.8569 760.00116
2000 724.01451 -675.72484 522.04263 -468.58167 -6603.3906 -1712.7317 47.61212
Loop time of 1.27211 on 1 procs for 1000 steps with 500 atoms
Performance: 135.837 ns/day, 0.177 hours/ns, 786.093 timesteps/s
93.9% CPU use with 1 MPI tasks x 1 OpenMP threads
MPI task timing breakdown:
Section | min time | avg time | max time |%varavg| %total
---------------------------------------------------------------
Pair | 1.0529 | 1.0529 | 1.0529 | 0.0 | 82.77
Neigh | 0.13671 | 0.13671 | 0.13671 | 0.0 | 10.75
Comm | 0.018747 | 0.018747 | 0.018747 | 0.0 | 1.47
Output | 0.00075722 | 0.00075722 | 0.00075722 | 0.0 | 0.06
Modify | 0.057984 | 0.057984 | 0.057984 | 0.0 | 4.56
Other | | 0.00499 | | | 0.39
Nlocal: 500 ave 500 max 500 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Nghost: 2040 ave 2040 max 2040 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Neighs: 23757 ave 23757 max 23757 min
Histogram: 1 0 0 0 0 0 0 0 0 0
FullNghs: 0 ave 0 max 0 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Total # of neighbors = 23757
Ave neighs/atom = 47.514
Neighbor list builds = 78
Dangerous builds = 0
Total wall time: 0:00:02

1
examples/USER/misc/mesocnt/C_10_10.mesocnt Symbolic link
View File

@ -0,0 +1 @@
../../../../potentials/C_10_10.mesocnt

1521
examples/USER/misc/mesocnt/cnt.data Normal file
View File

File diff suppressed because it is too large Load Diff

38
examples/USER/misc/mesocnt/in.cnt Normal file
View File

@ -0,0 +1,38 @@
#Initialisation
units nano
dimension 3
boundary p p p
atom_style full
comm_modify cutoff 11.0
neighbor 7.80 bin
newton on
#Read data
read_data cnt.data
replicate 1 2 2
#Force field
bond_style harmonic
bond_coeff 1 268896.77 2.0
angle_style harmonic
angle_coeff 1 46562.17 180.0
pair_style mesocnt
pair_coeff * * C_10_10.mesocnt
#Output
thermo 1000
dump xyz all xyz 1000 cnt.xyz
#Simulation setup
timestep 1.0e-05
#Nose-Hoover thermostat
fix nvt all nvt temp 300 300 0.001
run 10000

126
examples/USER/misc/mesocnt/log.9Jan20.cnt.g++.1 Normal file
View File

@ -0,0 +1,126 @@
LAMMPS (09 Jan 2020)
#Initialisation
units nano
dimension 3
boundary p p p
atom_style full
comm_modify cutoff 11.0
neighbor 7.80 bin
newton on
#Read data
read_data cnt.data
orthogonal box = (0 0 0) to (600 600 60)
1 by 1 by 1 MPI processor grid
reading atoms ...
500 atoms
scanning bonds ...
1 = max bonds/atom
scanning angles ...
1 = max angles/atom
reading bonds ...
498 bonds
reading angles ...
496 angles
2 = max # of 1-2 neighbors
2 = max # of 1-3 neighbors
4 = max # of 1-4 neighbors
6 = max # of special neighbors
special bonds CPU = 0.000180006 secs
read_data CPU = 0.00125766 secs
replicate 1 2 2
orthogonal box = (0 0 0) to (600 1200 120)
1 by 1 by 1 MPI processor grid
2000 atoms
1992 bonds
1984 angles
2 = max # of 1-2 neighbors
2 = max # of 1-3 neighbors
4 = max # of 1-4 neighbors
6 = max # of special neighbors
special bonds CPU = 0.00054121 secs
replicate CPU = 0.000902414 secs
#Force field
bond_style harmonic
bond_coeff 1 268896.77 2.0
angle_style harmonic
angle_coeff 1 46562.17 180.0
pair_style mesocnt
pair_coeff * * 10_10.cnt
Reading potential file 10_10.cnt with DATE: 2020-01-13
#Output
thermo 1000
dump xyz all xyz 1000 cnt.xyz
#Simulation setup
timestep 1.0e-05
#Nose-Hoover thermostat
fix nvt all nvt temp 300 300 0.001
run 10000
WARNING: Using a manybody potential with bonds/angles/dihedrals and special_bond exclusions (src/pair.cpp:226)
Neighbor list info ...
update every 1 steps, delay 10 steps, check yes
max neighbors/atom: 2000, page size: 100000
master list distance cutoff = 10.177
ghost atom cutoff = 11
binsize = 5.0885, bins = 118 236 24
1 neighbor lists, perpetual/occasional/extra = 1 0 0
(1) pair mesocnt, perpetual
attributes: full, newton on
pair build: full/bin
stencil: full/bin/3d
bin: standard
Per MPI rank memory allocation (min/avg/max) = 11.21 | 11.21 | 11.21 Mbytes
Step Temp E_pair E_mol TotEng Press
0 0 -4632.0136 5.7939238e-17 -4632.0136 -0.00015032304
1000 298.82235 -19950.274 13208.089 5628.7024 -0.0056205182
2000 300.43933 -28320.212 11980.296 -3902.0877 -0.0045324757
3000 300.4263 -36049.855 11338.405 -12274.161 -0.0018833539
4000 299.13368 -43471.21 11926.882 -19160.553 -0.00043030866
5000 293.77858 -50083.893 12334.927 -25586.884 -0.0015653738
6000 296.4851 -56330.135 12325.63 -31730.376 -0.0012795986
7000 298.20879 -62120.359 12582.297 -37192.574 -0.0013845796
8000 299.45547 -67881.692 13058.926 -42425.669 -0.00021100885
9000 301.82622 -73333.698 13598.257 -47240.197 -0.0006009197
10000 307.16873 -78292.306 13818.929 -51756.96 -0.0005609903
Loop time of 4.0316 on 1 procs for 10000 steps with 2000 atoms
Performance: 2143.072 ns/day, 0.011 hours/ns, 2480.408 timesteps/s
99.9% CPU use with 1 MPI tasks x no OpenMP threads
MPI task timing breakdown:
Section | min time | avg time | max time |%varavg| %total
---------------------------------------------------------------
Pair | 2.5955 | 2.5955 | 2.5955 | 0.0 | 64.38
Bond | 1.1516 | 1.1516 | 1.1516 | 0.0 | 28.57
Neigh | 0.001163 | 0.001163 | 0.001163 | 0.0 | 0.03
Comm | 0.0019577 | 0.0019577 | 0.0019577 | 0.0 | 0.05
Output | 0.020854 | 0.020854 | 0.020854 | 0.0 | 0.52
Modify | 0.21637 | 0.21637 | 0.21637 | 0.0 | 5.37
Other | | 0.04409 | | | 1.09
Nlocal: 2000 ave 2000 max 2000 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Nghost: 0 ave 0 max 0 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Neighs: 0 ave 0 max 0 min
Histogram: 1 0 0 0 0 0 0 0 0 0
FullNghs: 13320 ave 13320 max 13320 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Total # of neighbors = 13320
Ave neighs/atom = 6.66
Ave special neighs/atom = 5.952
Neighbor list builds = 1
Dangerous builds = 0
Total wall time: 0:00:05

126
examples/USER/misc/mesocnt/log.9Jan20.cnt.g++.4 Normal file
View File

@ -0,0 +1,126 @@
LAMMPS (09 Jan 2020)
#Initialisation
units nano
dimension 3
boundary p p p
atom_style full
comm_modify cutoff 11.0
neighbor 7.80 bin
newton on
#Read data
read_data cnt.data
orthogonal box = (0 0 0) to (600 600 60)
2 by 2 by 1 MPI processor grid
reading atoms ...
500 atoms
scanning bonds ...
1 = max bonds/atom
scanning angles ...
1 = max angles/atom
reading bonds ...
498 bonds
reading angles ...
496 angles
2 = max # of 1-2 neighbors
2 = max # of 1-3 neighbors
4 = max # of 1-4 neighbors
6 = max # of special neighbors
special bonds CPU = 0.000354767 secs
read_data CPU = 0.00286365 secs
replicate 1 2 2
orthogonal box = (0 0 0) to (600 1200 120)
1 by 4 by 1 MPI processor grid
2000 atoms
1992 bonds
1984 angles
2 = max # of 1-2 neighbors
2 = max # of 1-3 neighbors
4 = max # of 1-4 neighbors
6 = max # of special neighbors
special bonds CPU = 0.00019598 secs
replicate CPU = 0.00055337 secs
#Force field
bond_style harmonic
bond_coeff 1 268896.77 2.0
angle_style harmonic
angle_coeff 1 46562.17 180.0
pair_style mesocnt
pair_coeff * * 10_10.cnt
Reading potential file 10_10.cnt with DATE: 2020-01-13
#Output
thermo 1000
dump xyz all xyz 1000 cnt.xyz
#Simulation setup
timestep 1.0e-05
#Nose-Hoover thermostat
fix nvt all nvt temp 300 300 0.001
run 10000
WARNING: Using a manybody potential with bonds/angles/dihedrals and special_bond exclusions (src/pair.cpp:226)
Neighbor list info ...
update every 1 steps, delay 10 steps, check yes
max neighbors/atom: 2000, page size: 100000
master list distance cutoff = 10.177
ghost atom cutoff = 11
binsize = 5.0885, bins = 118 236 24
1 neighbor lists, perpetual/occasional/extra = 1 0 0
(1) pair mesocnt, perpetual
attributes: full, newton on
pair build: full/bin
stencil: full/bin/3d
bin: standard
Per MPI rank memory allocation (min/avg/max) = 2.725 | 2.725 | 2.725 Mbytes
Step Temp E_pair E_mol TotEng Press
0 0 -4632.0136 5.7939238e-17 -4632.0136 -0.00015032304
1000 298.82235 -19950.274 13208.089 5628.7024 -0.0056205182
2000 300.43861 -28320.205 11980.287 -3902.1202 -0.0045324738
3000 300.41076 -36049.308 11339.149 -12273.513 -0.0018848513
4000 299.13326 -43471.424 11927.668 -19159.998 -0.00042845101
5000 293.78857 -50083.216 12333.969 -25586.752 -0.0015664633
6000 296.45482 -56329.621 12326.419 -31730.328 -0.0012773686
7000 298.19097 -62119.086 12581.4 -37192.937 -0.0013862831
8000 299.46424 -67880.989 13057.62 -42425.908 -0.00020874264
9000 301.80677 -73332.208 13597.237 -47240.532 -0.00060074773
10000 307.17104 -78292.912 13818.889 -51757.51 -0.00056148282
Loop time of 1.23665 on 4 procs for 10000 steps with 2000 atoms
Performance: 6986.607 ns/day, 0.003 hours/ns, 8086.351 timesteps/s
96.1% CPU use with 4 MPI tasks x no OpenMP threads
MPI task timing breakdown:
Section | min time | avg time | max time |%varavg| %total
---------------------------------------------------------------
Pair | 0.66321 | 0.68439 | 0.71413 | 2.5 | 55.34
Bond | 0.28561 | 0.29434 | 0.30976 | 1.7 | 23.80
Neigh | 0.00043321 | 0.00043637 | 0.00043917 | 0.0 | 0.04
Comm | 0.026656 | 0.05346 | 0.097228 | 12.7 | 4.32
Output | 0.0070224 | 0.0073031 | 0.0081415 | 0.6 | 0.59
Modify | 0.12769 | 0.15394 | 0.18743 | 6.5 | 12.45
Other | | 0.04279 | | | 3.46
Nlocal: 500 ave 504 max 496 min
Histogram: 2 0 0 0 0 0 0 0 0 2
Nghost: 22 ave 24 max 20 min
Histogram: 2 0 0 0 0 0 0 0 0 2
Neighs: 0 ave 0 max 0 min
Histogram: 4 0 0 0 0 0 0 0 0 0
FullNghs: 3330 ave 3368 max 3292 min
Histogram: 2 0 0 0 0 0 0 0 0 2
Total # of neighbors = 13320
Ave neighs/atom = 6.66
Ave special neighs/atom = 5.952
Neighbor list builds = 1
Dangerous builds = 0
Total wall time: 0:00:02

184
examples/hyper/adatoms.list.37K
View File

@ -1,184 +0,0 @@
create_atoms 1 single 27.5 9.5 4
create_atoms 1 single 16 9 4
create_atoms 1 single 10 12 4
create_atoms 1 single 31 44 4
create_atoms 1 single 13 17 4
create_atoms 1 single 8.5 28.5 4
create_atoms 1 single 23 26 4
create_atoms 1 single 38 27 4
create_atoms 1 single 37.5 4.5 4
create_atoms 1 single 41.5 47.5 4
create_atoms 1 single 20.5 37.5 4
create_atoms 1 single 5 8 4
create_atoms 1 single 2.5 16.5 4
create_atoms 1 single 38.5 45.5 4
create_atoms 1 single 9 0 4
create_atoms 1 single 39 32 4
create_atoms 1 single 45.5 11.5 4
create_atoms 1 single 40 0 4
create_atoms 1 single 44.5 2.5 4
create_atoms 1 single 4.5 44.5 4
create_atoms 1 single 24.5 13.5 4
create_atoms 1 single 47.5 23.5 4
create_atoms 1 single 1 20 4
create_atoms 1 single 38.5 31.5 4
create_atoms 1 single 12.5 12.5 4
create_atoms 1 single 2 27 4
create_atoms 1 single 21 5 4
create_atoms 1 single 47 12 4
create_atoms 1 single 32.5 46.5 4
create_atoms 1 single 9.5 40.5 4
create_atoms 1 single 8.5 2.5 4
create_atoms 1 single 41.5 22.5 4
create_atoms 1 single 29 11 4
create_atoms 1 single 3.5 3.5 4
create_atoms 1 single 5 21 4
create_atoms 1 single 46.5 31.5 4
create_atoms 1 single 35 46 4
create_atoms 1 single 40.5 41.5 4
create_atoms 1 single 10 22 4
create_atoms 1 single 43.5 14.5 4
create_atoms 1 single 42 42 4
create_atoms 1 single 4 26 4
create_atoms 1 single 19 34 4
create_atoms 1 single 33 9 4
create_atoms 1 single 0.5 45.5 4
create_atoms 1 single 30.5 32.5 4
create_atoms 1 single 25.5 5.5 4
create_atoms 1 single 47.5 39.5 4
create_atoms 1 single 15 13 4
create_atoms 1 single 21 21 4
create_atoms 1 single 14 28 4
create_atoms 1 single 9 34 4
create_atoms 1 single 7 38 4
create_atoms 1 single 11 35 4
create_atoms 1 single 20.5 45.5 4
create_atoms 1 single 30.5 31.5 4
create_atoms 1 single 32.5 2.5 4
create_atoms 1 single 21.5 3.5 4
create_atoms 1 single 23 12 4
create_atoms 1 single 4.5 33.5 4
create_atoms 1 single 46 43 4
create_atoms 1 single 42.5 45.5 4
create_atoms 1 single 4.5 10.5 4
create_atoms 1 single 33.5 15.5 4
create_atoms 1 single 24 5 4
create_atoms 1 single 13 16 4
create_atoms 1 single 16.5 23.5 4
create_atoms 1 single 45.5 28.5 4
create_atoms 1 single 44.5 5.5 4
create_atoms 1 single 27.5 46.5 4
create_atoms 1 single 44.5 12.5 4
create_atoms 1 single 12 41 4
create_atoms 1 single 6 4 4
create_atoms 1 single 31.5 10.5 4
create_atoms 1 single 1 44 4
create_atoms 1 single 31 4 4
create_atoms 1 single 21 33 4
create_atoms 1 single 3 33 4
create_atoms 1 single 15 10 4
create_atoms 1 single 28.5 22.5 4
create_atoms 1 single 43 1 4
create_atoms 1 single 3.5 0.5 4
create_atoms 1 single 41 37 4
create_atoms 1 single 18.5 43.5 4
create_atoms 1 single 17 27 4
create_atoms 1 single 3 5 4
create_atoms 1 single 18.5 23.5 4
create_atoms 1 single 31.5 14.5 4
create_atoms 1 single 41 31 4
create_atoms 1 single 22 3 4
create_atoms 1 single 14.5 40.5 4
create_atoms 1 single 9 38 4
create_atoms 1 single 36 42 4
create_atoms 1 single 33 22 4
create_atoms 1 single 15.5 47.5 4
create_atoms 1 single 3 0 4
create_atoms 1 single 25.5 27.5 4
create_atoms 1 single 2.5 28.5 4
create_atoms 1 single 29.5 28.5 4
create_atoms 1 single 44.5 18.5 4
create_atoms 1 single 26 40 4
create_atoms 1 single 41 27 4
create_atoms 1 single 39.5 5.5 4
create_atoms 1 single 3 38 4
create_atoms 1 single 35 29 4
create_atoms 1 single 11 19 4
create_atoms 1 single 18 1 4
create_atoms 1 single 39.5 40.5 4
create_atoms 1 single 46 17 4
create_atoms 1 single 1.5 23.5 4
create_atoms 1 single 28.5 23.5 4
create_atoms 1 single 10 28 4
create_atoms 1 single 19 47 4
create_atoms 1 single 10.5 16.5 4
create_atoms 1 single 38 45 4
create_atoms 1 single 42.5 41.5 4
create_atoms 1 single 47.5 42.5 4
create_atoms 1 single 38 7 4
create_atoms 1 single 10 44 4
create_atoms 1 single 29.5 27.5 4
create_atoms 1 single 45 30 4
create_atoms 1 single 3 9 4
create_atoms 1 single 8.5 35.5 4
create_atoms 1 single 24 44 4
create_atoms 1 single 47 4 4
create_atoms 1 single 7.5 8.5 4
create_atoms 1 single 32.5 41.5 4
create_atoms 1 single 0.5 34.5 4
create_atoms 1 single 11 8 4
create_atoms 1 single 2 40 4
create_atoms 1 single 25 24 4
create_atoms 1 single 47.5 6.5 4
create_atoms 1 single 39.5 28.5 4
create_atoms 1 single 17 21 4
create_atoms 1 single 32 43 4
create_atoms 1 single 16.5 29.5 4
create_atoms 1 single 34 34 4
create_atoms 1 single 11.5 3.5 4
create_atoms 1 single 39 22 4
create_atoms 1 single 24.5 36.5 4
create_atoms 1 single 33 31 4
create_atoms 1 single 35.5 35.5 4
create_atoms 1 single 14.5 34.5 4
create_atoms 1 single 34 28 4
create_atoms 1 single 37 41 4
create_atoms 1 single 33 46 4
create_atoms 1 single 27.5 28.5 4
create_atoms 1 single 40.5 22.5 4
create_atoms 1 single 27.5 1.5 4
create_atoms 1 single 12 2 4
create_atoms 1 single 36 43 4
create_atoms 1 single 28.5 9.5 4
create_atoms 1 single 20.5 25.5 4
create_atoms 1 single 3 3 4
create_atoms 1 single 38 33 4
create_atoms 1 single 3 20 4
create_atoms 1 single 35 11 4
create_atoms 1 single 5 25 4
create_atoms 1 single 36.5 6.5 4
create_atoms 1 single 19.5 24.5 4
create_atoms 1 single 27 41 4
create_atoms 1 single 39.5 11.5 4
create_atoms 1 single 21.5 2.5 4
create_atoms 1 single 46.5 15.5 4
create_atoms 1 single 13 24 4
create_atoms 1 single 11 37 4
create_atoms 1 single 11.5 31.5 4
create_atoms 1 single 47 0 4
create_atoms 1 single 25.5 17.5 4
create_atoms 1 single 32 11 4
create_atoms 1 single 8 17 4
create_atoms 1 single 27.5 12.5 4
create_atoms 1 single 25 7 4
create_atoms 1 single 25.5 37.5 4
create_atoms 1 single 12 15 4
create_atoms 1 single 1 7 4
create_atoms 1 single 18.5 47.5 4
create_atoms 1 single 5 38 4
create_atoms 1 single 42 19 4
create_atoms 1 single 30.5 7.5 4
create_atoms 1 single 42.5 7.5 4
create_atoms 1 single 26.5 18.5 4
create_atoms 1 single 18.5 1.5 4
create_atoms 1 single 41.5 10.5 4

50
examples/hyper/adatoms.list.50 Normal file
View File

@ -0,0 +1,50 @@
create_atoms 1 single 5 9 4
create_atoms 1 single 4.5 7.5 4
create_atoms 1 single 6 6 4
create_atoms 1 single 5 6 4
create_atoms 1 single 4.5 1.5 4
create_atoms 1 single 6.5 7.5 4
create_atoms 1 single 10.5 5.5 4
create_atoms 1 single 2.5 1.5 4
create_atoms 1 single 3.5 4.5 4
create_atoms 1 single 0 10 4
create_atoms 1 single 11 10 4
create_atoms 1 single 6.5 10.5 4
create_atoms 1 single 3.5 5.5 4
create_atoms 1 single 7.5 10.5 4
create_atoms 1 single 1.5 1.5 4
create_atoms 1 single 1.5 6.5 4
create_atoms 1 single 7 2 4
create_atoms 1 single 4 0 4
create_atoms 1 single 9 0 4
create_atoms 1 single 4 9 4
create_atoms 1 single 10 7 4
create_atoms 1 single 4 4 4
create_atoms 1 single 9.5 2.5 4
create_atoms 1 single 1 5 4
create_atoms 1 single 7 10 4
create_atoms 1 single 0 4 4
create_atoms 1 single 1 10 4
create_atoms 1 single 7.5 6.5 4
create_atoms 1 single 4 10 4
create_atoms 1 single 6.5 3.5 4
create_atoms 1 single 3 6 4
create_atoms 1 single 8.5 4.5 4
create_atoms 1 single 6.5 0.5 4
create_atoms 1 single 1 4 4
create_atoms 1 single 8.5 11.5 4
create_atoms 1 single 3 9 4
create_atoms 1 single 2 3 4
create_atoms 1 single 6.5 8.5 4
create_atoms 1 single 1 0 4
create_atoms 1 single 0.5 10.5 4
create_atoms 1 single 4 11 4
create_atoms 1 single 3 5 4
create_atoms 1 single 0 1 4
create_atoms 1 single 2 11 4
create_atoms 1 single 2 0 4
create_atoms 1 single 7.5 11.5 4
create_atoms 1 single 1 7 4
create_atoms 1 single 3.5 10.5 4
create_atoms 1 single 0 2 4
create_atoms 1 single 8 4 4

BIN
examples/hyper/global.000000.jpg
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 71 KiB

After

Width:  |  Height:  |  Size: 70 KiB

BIN
examples/hyper/global.041000.jpg
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 70 KiB

After

Width:  |  Height:  |  Size: 70 KiB

BIN
examples/hyper/global.045000.jpg
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 70 KiB

After

Width:  |  Height:  |  Size: 69 KiB

BIN
examples/hyper/global.048000.jpg
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 69 KiB

After

Width:  |  Height:  |  Size: 69 KiB

BIN
examples/hyper/global.089000.jpg
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 69 KiB

After

Width:  |  Height:  |  Size: 69 KiB

16
examples/hyper/in.hyper.local
View File

@ -13,14 +13,14 @@ variable cutevent index 1.1
variable alpha index 200.0
variable boost index 4000.0
variable ghostcut index 12.0
variable steps index 1500
variable steps index 2000
variable nevent index 100
variable nx index 8
variable ny index 8
variable nx index 2
variable ny index 2
variable zoom index 1.8
variable seed index 826626413
variable seed index 3875984
variable tol index 1.0e-15
variable add index 37K
variable add index 50
units metal
atom_style atomic
@ -107,12 +107,6 @@ dump 1 all image 10000000 local.*.jpg v_acolor type size 1024 1024 &
zoom ${zoom} adiam 2.5 view 0.0 0.0 up 0 1 0 axes yes 0.9 0.01
dump_modify 1 pad 6 amap 1 3 sa 1 3 blue red green
# test of histogramming and dump output of bias coeffs
#fix histo all ave/histo 10 100 1000 0.9 1.1 100 f_HL &
# mode vector kind local file tmp.histo
#dump 2 all local 1000 tmp.local f_HL
# run
hyper ${steps} ${nevent} HL event min ${tol} ${tol} 1000 1000 dump 1

BIN
examples/hyper/local.000000.jpg
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 482 KiB

After

Width:  |  Height:  |  Size: 246 KiB

BIN
examples/hyper/local.000400.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 244 KiB

BIN
examples/hyper/local.001200.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 479 KiB

BIN
examples/hyper/local.001300.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 243 KiB

1002
examples/hyper/log.25Mar19.hyper.local.g++.16
View File

File diff suppressed because it is too large Load Diff

1264
examples/hyper/log.25Mar19.hyper.global.g++.4 → examples/hyper/log.9Jan20.hyper.global.g++.4
View File

File diff suppressed because it is too large Load Diff

646
examples/hyper/log.9Jan20.hyper.local.g++.4 Normal file
View File

@ -0,0 +1,646 @@
LAMMPS (09 Jan 2020)
# 3d EAM surface for local HD
# nearest neighbor distance = a * sqrt(2)/2 = 2.77 Angs for Pt with a = 3.92
# hop event on (100) surface is same distance
# exchange event is 2 atoms moving same distance
variable Tequil index 400.0
variable Vmax index 0.4
variable qfactor index 0.3
variable cutbond index 3.2
variable Dcut index 10.0
variable cutevent index 1.1
variable alpha index 200.0
variable boost index 4000.0
variable ghostcut index 12.0
variable steps index 2000
variable nevent index 100
variable nx index 2
variable ny index 2
variable zoom index 1.8
variable seed index 3875984
variable tol index 1.0e-15
variable add index 50
units metal
atom_style atomic
atom_modify map array
boundary p p p
comm_modify cutoff ${ghostcut}
comm_modify cutoff 12.0
lattice fcc 3.92
Lattice spacing in x,y,z = 3.92 3.92 3.92
region box block 0 6 0 6 0 4
create_box 2 box
Created orthogonal box = (0 0 0) to (23.52 23.52 15.68)
2 by 2 by 1 MPI processor grid
create_atoms 1 box
Created 576 atoms
create_atoms CPU = 0 secs
mass * 1.0
change_box all z final -0.1 5.0 boundary p p f
orthogonal box = (0 0 -0.392) to (23.52 23.52 19.6)
# replicate in xy
replicate ${nx} ${ny} 1
replicate 2 ${ny} 1
replicate 2 2 1
orthogonal box = (0 0 -0.392) to (47.04 47.04 19.6)
2 by 2 by 1 MPI processor grid
2304 atoms
replicate CPU = 0.00200009 secs
# add adatoms
include adatoms.list.${add}
include adatoms.list.50
create_atoms 1 single 5 9 4
Created 1 atoms
create_atoms CPU = 0 secs
create_atoms 1 single 4.5 7.5 4
Created 1 atoms
create_atoms CPU = 0 secs
create_atoms 1 single 6 6 4
Created 1 atoms
create_atoms CPU = 0 secs
create_atoms 1 single 5 6 4
Created 1 atoms
create_atoms CPU = 0 secs
create_atoms 1 single 4.5 1.5 4
Created 1 atoms
create_atoms CPU = 0 secs
create_atoms 1 single 6.5 7.5 4
Created 1 atoms
create_atoms CPU = 0 secs
create_atoms 1 single 10.5 5.5 4
Created 1 atoms
create_atoms CPU = 0 secs
create_atoms 1 single 2.5 1.5 4
Created 1 atoms
create_atoms CPU = 0 secs
create_atoms 1 single 3.5 4.5 4
Created 1 atoms
create_atoms CPU = 0 secs
create_atoms 1 single 0 10 4
Created 1 atoms
create_atoms CPU = 0 secs
create_atoms 1 single 11 10 4
Created 1 atoms
create_atoms CPU = 0 secs
create_atoms 1 single 6.5 10.5 4
Created 1 atoms
create_atoms CPU = 0 secs
create_atoms 1 single 3.5 5.5 4
Created 1 atoms
create_atoms CPU = 0 secs
create_atoms 1 single 7.5 10.5 4
Created 1 atoms
create_atoms CPU = 0 secs
create_atoms 1 single 1.5 1.5 4
Created 1 atoms
create_atoms CPU = 0 secs
create_atoms 1 single 1.5 6.5 4
Created 1 atoms
create_atoms CPU = 0 secs
create_atoms 1 single 7 2 4
Created 1 atoms
create_atoms CPU = 0 secs
create_atoms 1 single 4 0 4
Created 1 atoms
create_atoms CPU = 0 secs
create_atoms 1 single 9 0 4
Created 1 atoms
create_atoms CPU = 0 secs
create_atoms 1 single 4 9 4
Created 1 atoms
create_atoms CPU = 0 secs
create_atoms 1 single 10 7 4
Created 1 atoms
create_atoms CPU = 0 secs
create_atoms 1 single 4 4 4
Created 1 atoms
create_atoms CPU = 0 secs
create_atoms 1 single 9.5 2.5 4
Created 1 atoms
create_atoms CPU = 0 secs
create_atoms 1 single 1 5 4
Created 1 atoms
create_atoms CPU = 0 secs
create_atoms 1 single 7 10 4
Created 1 atoms
create_atoms CPU = 0 secs
create_atoms 1 single 0 4 4
Created 1 atoms
create_atoms CPU = 0 secs
create_atoms 1 single 1 10 4
Created 1 atoms
create_atoms CPU = 0 secs
create_atoms 1 single 7.5 6.5 4
Created 1 atoms
create_atoms CPU = 0 secs
create_atoms 1 single 4 10 4
Created 1 atoms
create_atoms CPU = 0 secs
create_atoms 1 single 6.5 3.5 4
Created 1 atoms
create_atoms CPU = 0 secs
create_atoms 1 single 3 6 4
Created 1 atoms
create_atoms CPU = 0 secs
create_atoms 1 single 8.5 4.5 4
Created 1 atoms
create_atoms CPU = 0 secs
create_atoms 1 single 6.5 0.5 4
Created 1 atoms
create_atoms CPU = 0 secs
create_atoms 1 single 1 4 4
Created 1 atoms
create_atoms CPU = 0 secs
create_atoms 1 single 8.5 11.5 4
Created 1 atoms
create_atoms CPU = 0 secs
create_atoms 1 single 3 9 4
Created 1 atoms
create_atoms CPU = 0 secs
create_atoms 1 single 2 3 4
Created 1 atoms
create_atoms CPU = 0 secs
create_atoms 1 single 6.5 8.5 4
Created 1 atoms
create_atoms CPU = 0 secs
create_atoms 1 single 1 0 4
Created 1 atoms
create_atoms CPU = 0 secs
create_atoms 1 single 0.5 10.5 4
Created 1 atoms
create_atoms CPU = 0 secs
create_atoms 1 single 4 11 4
Created 1 atoms
create_atoms CPU = 0 secs
create_atoms 1 single 3 5 4
Created 1 atoms
create_atoms CPU = 0 secs
create_atoms 1 single 0 1 4
Created 1 atoms
create_atoms CPU = 0 secs
create_atoms 1 single 2 11 4
Created 1 atoms
create_atoms CPU = 0 secs
create_atoms 1 single 2 0 4
Created 1 atoms
create_atoms CPU = 0 secs
create_atoms 1 single 7.5 11.5 4
Created 1 atoms
create_atoms CPU = 0 secs
create_atoms 1 single 1 7 4
Created 1 atoms
create_atoms CPU = 0 secs
create_atoms 1 single 3.5 10.5 4
Created 1 atoms
create_atoms CPU = 0 secs
create_atoms 1 single 0 2 4
Created 1 atoms
create_atoms CPU = 0 secs
create_atoms 1 single 8 4 4
Created 1 atoms
create_atoms CPU = 0 secs
# define frozen substrate and mobile atoms
region base block INF INF INF INF 0 1.8
set region base type 2
1152 settings made for type
group base type 2
1152 atoms in group base
group mobile type 1
1202 atoms in group mobile
# pair style
pair_style eam/alloy
pair_coeff * * ptvoterlammps.eam Pt Pt
neighbor 0.5 bin
neigh_modify every 1 delay 5 check yes
fix 1 mobile nve
fix 2 mobile langevin ${Tequil} ${Tequil} 1.0 ${seed} zero yes
fix 2 mobile langevin 400.0 ${Tequil} 1.0 ${seed} zero yes
fix 2 mobile langevin 400.0 400.0 1.0 ${seed} zero yes
fix 2 mobile langevin 400.0 400.0 1.0 3875984 zero yes
timestep 0.005
compute tmobile mobile temp
thermo 100
thermo_modify temp tmobile
WARNING: Temperature for thermo pressure is not for group all (../thermo.cpp:485)
# thermal equilibration
run 1000
Neighbor list info ...
update every 1 steps, delay 5 steps, check yes
max neighbors/atom: 2000, page size: 100000
master list distance cutoff = 6.07583
ghost atom cutoff = 12
binsize = 3.03792, bins = 16 16 7
1 neighbor lists, perpetual/occasional/extra = 1 0 0
(1) pair eam/alloy, perpetual
attributes: half, newton on
pair build: half/bin/atomonly/newton
stencil: half/bin/3d/newton
bin: standard
Per MPI rank memory allocation (min/avg/max) = 3.082 | 3.082 | 3.082 Mbytes
Step Temp E_pair E_mol TotEng Press
0 0 -13067.188 0 -13067.188 -53763.139
100 216.49187 -13065.694 0 -13032.085 -24077.115
200 285.11905 -13057.047 0 -13012.785 -38815.844
300 321.67264 -13048.005 0 -12998.068 -29296.124
400 352.90893 -13045.707 0 -12990.92 -34630.884
500 371.9393 -13041.234 0 -12983.494 -28913.827
600 379.08135 -13040.06 0 -12981.211 -33399.8
700 388.73836 -13039.691 0 -12979.343 -29446.954
800 402.13628 -13040.606 0 -12978.178 -33026.861
900 389.43806 -13036.884 0 -12976.427 -30328.658
1000 388.66198 -13037.479 0 -12977.142 -30859.145
Loop time of 1.28003 on 4 procs for 1000 steps with 2354 atoms
Performance: 337.492 ns/day, 0.071 hours/ns, 781.232 timesteps/s
100.0% CPU use with 4 MPI tasks x no OpenMP threads
MPI task timing breakdown:
Section | min time | avg time | max time |%varavg| %total
---------------------------------------------------------------
Pair | 1.054 | 1.077 | 1.094 | 1.6 | 84.14
Neigh | 0.054002 | 0.056502 | 0.060002 | 1.0 | 4.41
Comm | 0.087002 | 0.11025 | 0.133 | 5.6 | 8.61
Output | 0 | 0 | 0 | 0.0 | 0.00
Modify | 0.031003 | 0.031502 | 0.032002 | 0.3 | 2.46
Other | | 0.00475 | | | 0.37
Nlocal: 588.5 ave 592 max 581 min
Histogram: 1 0 0 0 0 0 0 1 0 2
Nghost: 1964 ave 1973 max 1959 min
Histogram: 2 0 0 1 0 0 0 0 0 1
Neighs: 14148.8 ave 14283 max 13931 min
Histogram: 1 0 0 0 0 0 1 1 0 1
Total # of neighbors = 56595
Ave neighs/atom = 24.0421
Neighbor list builds = 91
Dangerous builds = 0
reset_timestep 0
# pin base so will not move during quenches
fix freeze base setforce 0.0 0.0 0.0
# event detection
compute event all event/displace ${cutevent}
compute event all event/displace 1.1
# hyper/local
fix HL mobile hyper/local ${cutbond} ${qfactor} ${Vmax} ${Tequil} ${Dcut} ${alpha} ${boost}
fix HL mobile hyper/local 3.2 ${qfactor} ${Vmax} ${Tequil} ${Dcut} ${alpha} ${boost}
fix HL mobile hyper/local 3.2 0.3 ${Vmax} ${Tequil} ${Dcut} ${alpha} ${boost}
fix HL mobile hyper/local 3.2 0.3 0.4 ${Tequil} ${Dcut} ${alpha} ${boost}
fix HL mobile hyper/local 3.2 0.3 0.4 400.0 ${Dcut} ${alpha} ${boost}
fix HL mobile hyper/local 3.2 0.3 0.4 400.0 10.0 ${alpha} ${boost}
fix HL mobile hyper/local 3.2 0.3 0.4 400.0 10.0 200.0 ${boost}
fix HL mobile hyper/local 3.2 0.3 0.4 400.0 10.0 200.0 4000.0
# thermo output
thermo_style custom step temp pe f_HL f_HL[*]
WARNING: New thermo_style command, previous thermo_modify settings will be lost (../output.cpp:708)
thermo_modify lost ignore
thermo_modify temp tmobile
WARNING: Temperature for thermo pressure is not for group all (../thermo.cpp:485)
thermo ${nevent}
thermo 100
# dump
region substrate block INF INF INF INF 1.8 3.8
region adatoms block INF INF INF INF 3.8 INF
variable acolor atom rmask(base)+2*rmask(substrate)+3*rmask(adatoms)
dump 1 all image 10000000 local.*.jpg v_acolor type size 1024 1024 zoom ${zoom} adiam 2.5 view 0.0 0.0 up 0 1 0 axes yes 0.9 0.01
dump 1 all image 10000000 local.*.jpg v_acolor type size 1024 1024 zoom 1.8 adiam 2.5 view 0.0 0.0 up 0 1 0 axes yes 0.9 0.01
dump_modify 1 pad 6 amap 1 3 sa 1 3 blue red green
# run
hyper ${steps} ${nevent} HL event min ${tol} ${tol} 1000 1000 dump 1
hyper 2000 ${nevent} HL event min ${tol} ${tol} 1000 1000 dump 1
hyper 2000 100 HL event min ${tol} ${tol} 1000 1000 dump 1
hyper 2000 100 HL event min 1.0e-15 ${tol} 1000 1000 dump 1
hyper 2000 100 HL event min 1.0e-15 1.0e-15 1000 1000 dump 1
WARNING: Resetting reneighboring criteria during hyper (../hyper.cpp:131)
Neighbor list info ...
update every 1 steps, delay 0 steps, check yes
max neighbors/atom: 2000, page size: 100000
master list distance cutoff = 6.07583
ghost atom cutoff = 12
binsize = 3.03792, bins = 16 16 7
3 neighbor lists, perpetual/occasional/extra = 1 2 0
(1) pair eam/alloy, perpetual
attributes: half, newton on
pair build: half/bin/atomonly/newton
stencil: half/bin/3d/newton
bin: standard
(2) fix hyper/local, occasional
attributes: full, newton on, cut 10
pair build: full/bin/atomonly
stencil: full/bin/3d
bin: standard
(3) fix hyper/local, occasional, copy from (1)
attributes: half, newton on
pair build: copy
stencil: none
bin: none
Per MPI rank memory allocation (min/avg/max) = 6.666 | 6.666 | 6.666 Mbytes
Step Temp PotEng f_HL f_HL[1] f_HL[2] f_HL[3] f_HL[4] f_HL[5] f_HL[6] f_HL[7] f_HL[8] f_HL[9] f_HL[10] f_HL[11] f_HL[12] f_HL[13] f_HL[14] f_HL[15] f_HL[16] f_HL[17] f_HL[18] f_HL[19] f_HL[20] f_HL[21] f_HL[22] f_HL[23] f_HL[24] f_HL[25] f_HL[26] f_HL[27] f_HL[28]
0 388.66198 -13037.479 0 1 0 0 0.4 1 0 0 0 0 0 0 0 0 0 0 1e+20 0 0 0 0 0 0 0 0 0 0 1 0
77 388.66198 -13101.057 0 1 0 0 0.4 1 0 0 0 0 0 0 0 0 0 0 1e+20 0 0 0 0 0 0 1540 0 0 0 1 0
Loop time of 0.179004 on 4 procs for 77 steps with 2354 atoms
Step Temp PotEng f_HL f_HL[1] f_HL[2] f_HL[3] f_HL[4] f_HL[5] f_HL[6] f_HL[7] f_HL[8] f_HL[9] f_HL[10] f_HL[11] f_HL[12] f_HL[13] f_HL[14] f_HL[15] f_HL[16] f_HL[17] f_HL[18] f_HL[19] f_HL[20] f_HL[21] f_HL[22] f_HL[23] f_HL[24] f_HL[25] f_HL[26] f_HL[27] f_HL[28]
0 388.66198 -13037.479 2.1560984 0 7 0.19075508 0.4 0 0 0 5.9276206 1380.4406 0 0 0 0 3.2725891 0 1e+20 0 0 0 0 0 0 0 0 0 0 10345.205 0
100 398.83324 -13036.879 2.1057282 8397.3244 7 0.17605069 0.4 0.99370412 0.98222607 1.0036767 5.9276206 1380.4406 8029.3662 4.83 0 0 3.3896963 0.9967648 0.98222607 1.0036767 0 0 0 0 0 2000 0 0 0 8152.8259 0
Loop time of 0.127003 on 4 procs for 100 steps with 2354 atoms
Step Temp PotEng f_HL f_HL[1] f_HL[2] f_HL[3] f_HL[4] f_HL[5] f_HL[6] f_HL[7] f_HL[8] f_HL[9] f_HL[10] f_HL[11] f_HL[12] f_HL[13] f_HL[14] f_HL[15] f_HL[16] f_HL[17] f_HL[18] f_HL[19] f_HL[20] f_HL[21] f_HL[22] f_HL[23] f_HL[24] f_HL[25] f_HL[26] f_HL[27] f_HL[28]
100 398.83324 -13036.879 2.1057282 8397.3244 7 0.17605069 0.4 0.99370412 0.98222607 1.0036767 5.9276206 1380.4406 8029.3662 4.83 0 0 3.3896963 0.9967648 0.98222607 1.0036767 0 0 0 0 0 2000 0 0 0 8152.8259 0
167 398.83324 -13101.057 2.1057282 8397.3244 7 0.17605069 0.4 0.99370412 0.98222607 1.0036767 5.9276206 1380.4406 8029.3662 2.8922156 0 0 3.3896963 0.9967648 0.98222607 1.0036767 0 0 0 0 0 3340 0 0 0 8152.8259 0
Loop time of 0.127003 on 4 procs for 67 steps with 2354 atoms
Step Temp PotEng f_HL f_HL[1] f_HL[2] f_HL[3] f_HL[4] f_HL[5] f_HL[6] f_HL[7] f_HL[8] f_HL[9] f_HL[10] f_HL[11] f_HL[12] f_HL[13] f_HL[14] f_HL[15] f_HL[16] f_HL[17] f_HL[18] f_HL[19] f_HL[20] f_HL[21] f_HL[22] f_HL[23] f_HL[24] f_HL[25] f_HL[26] f_HL[27] f_HL[28]
100 398.83324 -13036.879 2.1055533 8397.3244 7 0.17605069 0.4 0.99370412 0.98222607 1.0036767 5.9276206 1380.4406 8029.3662 4.83 0 0 3.3896963 0.9967648 0.98222607 1.0036767 0 0 0 0 0 2000 0 0 0 8129.9856 0
200 389.68041 -13036.5 1.3143359 4136.9005 6 0.31228203 0.4 0.99085481 0.96933773 1.0092702 5.9276206 1380.4406 6926.4597 5.43 0.035911602 0.00092081031 3.7338089 0.99450416 0.96933773 1.0092702 0 0 0 0 0 4000 0 0 0 3361.4715 1
Loop time of 0.127003 on 4 procs for 100 steps with 2354 atoms
Step Temp PotEng f_HL f_HL[1] f_HL[2] f_HL[3] f_HL[4] f_HL[5] f_HL[6] f_HL[7] f_HL[8] f_HL[9] f_HL[10] f_HL[11] f_HL[12] f_HL[13] f_HL[14] f_HL[15] f_HL[16] f_HL[17] f_HL[18] f_HL[19] f_HL[20] f_HL[21] f_HL[22] f_HL[23] f_HL[24] f_HL[25] f_HL[26] f_HL[27] f_HL[28]
200 389.68041 -13036.5 1.3143359 4136.9005 6 0.31228203 0.4 0.99085481 0.96933773 1.0092702 5.9276206 1380.4406 6926.4597 5.43 0.035911602 0.00092081031 3.7338089 0.99450416 0.96933773 1.0092702 0 0 0 0 0 4000 0 0 0 3361.4715 1
270 389.68041 -13101.057 1.3143359 4136.9005 6 0.31228203 0.4 0.99085481 0.96933773 1.0092702 5.9276206 1380.4406 6926.4597 4.0222222 0.035911602 0.00092081031 3.7338089 0.99450416 0.96933773 1.0092702 0 0 0 0 0 5400 0 0 0 3361.4715 1
Loop time of 0.134003 on 4 procs for 70 steps with 2354 atoms
Step Temp PotEng f_HL f_HL[1] f_HL[2] f_HL[3] f_HL[4] f_HL[5] f_HL[6] f_HL[7] f_HL[8] f_HL[9] f_HL[10] f_HL[11] f_HL[12] f_HL[13] f_HL[14] f_HL[15] f_HL[16] f_HL[17] f_HL[18] f_HL[19] f_HL[20] f_HL[21] f_HL[22] f_HL[23] f_HL[24] f_HL[25] f_HL[26] f_HL[27] f_HL[28]
200 389.68041 -13036.5 1.3143057 4136.9005 6 0.31228203 0.4 0.99085481 0.96933773 1.0092702 5.9276206 1380.4406 6926.4597 5.43 0.035911602 0.00092081031 3.7338089 0.99450416 0.96933773 1.0092702 0 0 0 0 0 4000 0 0 0 3356.2384 1
300 410.34512 -13036.301 1.3677603 4656.4226 6 0.33838934 0.4 0.99110308 0.96057751 1.0154382 5.9276206 1380.4406 5898.0094 5.44 0.036764706 0.0006127451 3.7338089 0.9934181 0.96057751 1.0154382 0 0 0 0 0 6000 0 0 0 4213.1218 1
Loop time of 0.129003 on 4 procs for 100 steps with 2354 atoms
Step Temp PotEng f_HL f_HL[1] f_HL[2] f_HL[3] f_HL[4] f_HL[5] f_HL[6] f_HL[7] f_HL[8] f_HL[9] f_HL[10] f_HL[11] f_HL[12] f_HL[13] f_HL[14] f_HL[15] f_HL[16] f_HL[17] f_HL[18] f_HL[19] f_HL[20] f_HL[21] f_HL[22] f_HL[23] f_HL[24] f_HL[25] f_HL[26] f_HL[27] f_HL[28]
300 410.34512 -13036.301 1.3677603 4656.4226 6 0.33838934 0.4 0.99110308 0.96057751 1.0154382 5.9276206 1380.4406 5898.0094 5.44 0.036764706 0.0006127451 3.7338089 0.9934181 0.96057751 1.0154382 0 0 0 0 0 6000 0 0 0 4213.1218 1
375 410.34512 -13101.057 1.3677603 4656.4226 6 0.33838934 0.4 0.99110308 0.96057751 1.0154382 5.9276206 1380.4406 5898.0094 4.352 0.036764706 0.0006127451 3.7338089 0.9934181 0.96057751 1.0154382 0 0 0 0 0 7500 0 0 0 4213.1218 1
Loop time of 0.143004 on 4 procs for 75 steps with 2354 atoms
Step Temp PotEng f_HL f_HL[1] f_HL[2] f_HL[3] f_HL[4] f_HL[5] f_HL[6] f_HL[7] f_HL[8] f_HL[9] f_HL[10] f_HL[11] f_HL[12] f_HL[13] f_HL[14] f_HL[15] f_HL[16] f_HL[17] f_HL[18] f_HL[19] f_HL[20] f_HL[21] f_HL[22] f_HL[23] f_HL[24] f_HL[25] f_HL[26] f_HL[27] f_HL[28]
300 410.34512 -13036.301 1.3677058 4656.4226 6 0.33838934 0.4 0.99110308 0.96057751 1.0154382 5.9276206 1380.4406 5898.0094 5.44 0.036764706 0.0006127451 3.7338089 0.9934181 0.96057751 1.0154382 0 0 0 0 0 6000 0 0 0 4207.0688 1
400 408.54896 -13036.835 1.090295 4172.0981 6 0.46750515 0.4 0.99130905 0.95644819 1.0207114 5.9276206 1380.4406 5390.5516 5.365 0.095060578 0.00046598322 3.9885296 0.9928942 0.95644819 1.0207114 0 0 0 0 0 8000 0 0 0 3865.6547 3
Loop time of 0.126003 on 4 procs for 100 steps with 2354 atoms
Step Temp PotEng f_HL f_HL[1] f_HL[2] f_HL[3] f_HL[4] f_HL[5] f_HL[6] f_HL[7] f_HL[8] f_HL[9] f_HL[10] f_HL[11] f_HL[12] f_HL[13] f_HL[14] f_HL[15] f_HL[16] f_HL[17] f_HL[18] f_HL[19] f_HL[20] f_HL[21] f_HL[22] f_HL[23] f_HL[24] f_HL[25] f_HL[26] f_HL[27] f_HL[28]
400 408.54896 -13036.835 1.090295 4172.0981 6 0.46750515 0.4 0.99130905 0.95644819 1.0207114 5.9276206 1380.4406 5390.5516 5.365 0.095060578 0.00046598322 3.9885296 0.9928942 0.95644819 1.0207114 0 0 0 0 0 8000 0 0 0 3865.6547 3
471 408.54896 -13101.694 1.090295 4172.0981 6 0.46750515 0.4 0.99130905 0.95644819 1.0207114 5.9276206 1380.4406 5390.5516 4.5562633 0.095060578 0.00046598322 3.9885296 0.9928942 0.95644819 1.0207114 0 0 0 0 0 9420 0 0 0 3865.6547 3
Loop time of 0.131003 on 4 procs for 71 steps with 2354 atoms
Step Temp PotEng f_HL f_HL[1] f_HL[2] f_HL[3] f_HL[4] f_HL[5] f_HL[6] f_HL[7] f_HL[8] f_HL[9] f_HL[10] f_HL[11] f_HL[12] f_HL[13] f_HL[14] f_HL[15] f_HL[16] f_HL[17] f_HL[18] f_HL[19] f_HL[20] f_HL[21] f_HL[22] f_HL[23] f_HL[24] f_HL[25] f_HL[26] f_HL[27] f_HL[28]
400 408.54896 -13036.835 1.090341 4171.5126 6 0.33910027 0.4 0.99116994 0.95644819 1.0207114 5.9284526 1380.3372 5390.5516 5.365 0.095060578 0.00046598322 3.9885296 0.9928942 0.95644819 1.0207114 2.7381277 0 0 0 0 8000 1 1 3 3863.7908 2
500 408.04798 -13035.819 1.887274 2622.1876 8 0.25727119 0.4 0.99128739 0.95020853 1.0240862 5.9284526 1380.3372 5115.3824 5.63 0.077087034 0.00071047957 3.9885296 0.99251152 0.95020853 1.0240862 2.7381277 0 0 0 0 10000 1 1 3 4184.3452 0
Loop time of 0.128003 on 4 procs for 100 steps with 2354 atoms
Step Temp PotEng f_HL f_HL[1] f_HL[2] f_HL[3] f_HL[4] f_HL[5] f_HL[6] f_HL[7] f_HL[8] f_HL[9] f_HL[10] f_HL[11] f_HL[12] f_HL[13] f_HL[14] f_HL[15] f_HL[16] f_HL[17] f_HL[18] f_HL[19] f_HL[20] f_HL[21] f_HL[22] f_HL[23] f_HL[24] f_HL[25] f_HL[26] f_HL[27] f_HL[28]
500 408.04798 -13035.819 1.887274 2622.1876 8 0.25727119 0.4 0.99128739 0.95020853 1.0240862 5.9284526 1380.3372 5115.3824 5.63 0.077087034 0.00071047957 3.9885296 0.99251152 0.95020853 1.0240862 2.7381277 0 0 0 0 10000 1 1 3 4184.3452 0
569 408.04798 -13101.694 1.887274 2622.1876 8 0.25727119 0.4 0.99128739 0.95020853 1.0240862 5.9284526 1380.3372 5115.3824 4.9472759 0.077087034 0.00071047957 3.9885296 0.99251152 0.95020853 1.0240862 2.7381277 0 0 0 0 11380 1 1 3 4184.3452 0
Loop time of 0.135003 on 4 procs for 69 steps with 2354 atoms
Step Temp PotEng f_HL f_HL[1] f_HL[2] f_HL[3] f_HL[4] f_HL[5] f_HL[6] f_HL[7] f_HL[8] f_HL[9] f_HL[10] f_HL[11] f_HL[12] f_HL[13] f_HL[14] f_HL[15] f_HL[16] f_HL[17] f_HL[18] f_HL[19] f_HL[20] f_HL[21] f_HL[22] f_HL[23] f_HL[24] f_HL[25] f_HL[26] f_HL[27] f_HL[28]
500 408.04798 -13035.819 1.8872278 2622.1876 8 0.25727119 0.4 0.99128739 0.95020853 1.0240862 5.9284526 1380.3372 5115.3824 5.63 0.077087034 0.00071047957 3.9885296 0.99251152 0.95020853 1.0240862 2.7381277 0 0 0 0 10000 1 1 3 4177.8105 0
600 419.0918 -13035.34 1.0950129 5050.5345 5 0.30933918 0.4 0.99315523 0.94243697 1.0303 5.9284526 1380.3372 4730.2494 5.7483333 0.082052769 0.00057987823 4.0620002 0.99251861 0.94243697 1.0303 2.7381277 0 0 0 0 12000 1 1 3 4375.7612 1
Loop time of 0.128003 on 4 procs for 100 steps with 2354 atoms
Step Temp PotEng f_HL f_HL[1] f_HL[2] f_HL[3] f_HL[4] f_HL[5] f_HL[6] f_HL[7] f_HL[8] f_HL[9] f_HL[10] f_HL[11] f_HL[12] f_HL[13] f_HL[14] f_HL[15] f_HL[16] f_HL[17] f_HL[18] f_HL[19] f_HL[20] f_HL[21] f_HL[22] f_HL[23] f_HL[24] f_HL[25] f_HL[26] f_HL[27] f_HL[28]
600 419.0918 -13035.34 1.0950129 5050.5345 5 0.30933918 0.4 0.99315523 0.94243697 1.0303 5.9284526 1380.3372 4730.2494 5.7483333 0.082052769 0.00057987823 4.0620002 0.99251861 0.94243697 1.0303 2.7381277 0 0 0 0 12000 1 1 3 4375.7612 1
669 419.0918 -13101.694 1.0950129 5050.5345 5 0.30933918 0.4 0.99315523 0.94243697 1.0303 5.9284526 1380.3372 4730.2494 5.1554559 0.082052769 0.00057987823 4.0620002 0.99251861 0.94243697 1.0303 2.7381277 0 0 0 0 13380 1 1 3 4375.7612 1
Loop time of 0.131003 on 4 procs for 69 steps with 2354 atoms
Step Temp PotEng f_HL f_HL[1] f_HL[2] f_HL[3] f_HL[4] f_HL[5] f_HL[6] f_HL[7] f_HL[8] f_HL[9] f_HL[10] f_HL[11] f_HL[12] f_HL[13] f_HL[14] f_HL[15] f_HL[16] f_HL[17] f_HL[18] f_HL[19] f_HL[20] f_HL[21] f_HL[22] f_HL[23] f_HL[24] f_HL[25] f_HL[26] f_HL[27] f_HL[28]
600 419.0918 -13035.34 1.0949592 5050.5345 5 0.30933918 0.4 0.99315523 0.94243697 1.0303 5.9284526 1380.3372 4730.2494 5.7483333 0.082052769 0.00057987823 4.0620002 0.99251861 0.94243697 1.0303 2.7381277 0 0 0 0 12000 1 1 3 4366.2434 1
700 404.99792 -13038.375 1.7496634 5457.7386 6 0.20603012 0.4 0.99311471 0.93767338 1.0364661 5.9284526 1380.3372 4629.6326 5.7757143 0.077170418 0.00049468217 4.0620002 0.99261201 0.93732488 1.0364661 2.7381277 0 0 0 0 14000 1 1 3 5897.4776 0
Loop time of 0.128003 on 4 procs for 100 steps with 2354 atoms
Step Temp PotEng f_HL f_HL[1] f_HL[2] f_HL[3] f_HL[4] f_HL[5] f_HL[6] f_HL[7] f_HL[8] f_HL[9] f_HL[10] f_HL[11] f_HL[12] f_HL[13] f_HL[14] f_HL[15] f_HL[16] f_HL[17] f_HL[18] f_HL[19] f_HL[20] f_HL[21] f_HL[22] f_HL[23] f_HL[24] f_HL[25] f_HL[26] f_HL[27] f_HL[28]
700 404.99792 -13038.375 1.7496634 5457.7386 6 0.20603012 0.4 0.99311471 0.93767338 1.0364661 5.9284526 1380.3372 4629.6326 5.7757143 0.077170418 0.00049468217 4.0620002 0.99261201 0.93732488 1.0364661 2.7381277 0 0 0 0 14000 1 1 3 5897.4776 0
775 404.99792 -13101.694 1.7496634 5457.7386 6 0.20603012 0.4 0.99311471 0.93767338 1.0364661 5.9284526 1380.3372 4629.6326 5.2167742 0.077170418 0.00049468217 4.0620002 0.99261201 0.93732488 1.0364661 2.7381277 0 0 0 0 15500 1 1 3 5897.4776 0
Loop time of 0.166004 on 4 procs for 75 steps with 2354 atoms
Step Temp PotEng f_HL f_HL[1] f_HL[2] f_HL[3] f_HL[4] f_HL[5] f_HL[6] f_HL[7] f_HL[8] f_HL[9] f_HL[10] f_HL[11] f_HL[12] f_HL[13] f_HL[14] f_HL[15] f_HL[16] f_HL[17] f_HL[18] f_HL[19] f_HL[20] f_HL[21] f_HL[22] f_HL[23] f_HL[24] f_HL[25] f_HL[26] f_HL[27] f_HL[28]
700 404.99792 -13038.375 1.7495648 5457.7386 6 0.20603012 0.4 0.99311471 0.93767338 1.0364661 5.9284526 1380.3372 4629.6326 5.7757143 0.077170418 0.00049468217 4.0620002 0.99261201 0.93732488 1.0364661 2.7381277 0 0 0 0 14000 1 1 3 5888.5728 0
800 421.10795 -13037.462 1.8512835 3051.7064 8 0.31933951 0.4 0.9902351 0.93814672 1.0426311 5.9284526 1380.3372 4781.2974 5.8125 0.070322581 0.00043010753 4.0620002 0.99242754 0.93732488 1.0426311 2.7381277 0 0 0 0 16000 1 1 3 3122.0342 1
Loop time of 0.245005 on 4 procs for 100 steps with 2354 atoms
Step Temp PotEng f_HL f_HL[1] f_HL[2] f_HL[3] f_HL[4] f_HL[5] f_HL[6] f_HL[7] f_HL[8] f_HL[9] f_HL[10] f_HL[11] f_HL[12] f_HL[13] f_HL[14] f_HL[15] f_HL[16] f_HL[17] f_HL[18] f_HL[19] f_HL[20] f_HL[21] f_HL[22] f_HL[23] f_HL[24] f_HL[25] f_HL[26] f_HL[27] f_HL[28]
800 421.10795 -13037.462 1.8512835 3051.7064 8 0.31933951 0.4 0.9902351 0.93814672 1.0426311 5.9284526 1380.3372 4781.2974 5.8125 0.070322581 0.00043010753 4.0620002 0.99242754 0.93732488 1.0426311 2.7381277 0 0 0 0 16000 1 1 3 3122.0342 1
869 421.10795 -13101.694 1.8512835 3051.7064 8 0.31933951 0.4 0.9902351 0.93814672 1.0426311 5.9284526 1380.3372 4781.2974 5.3509781 0.070322581 0.00043010753 4.0620002 0.99242754 0.93732488 1.0426311 2.7381277 0 0 0 0 17380 1 1 3 3122.0342 1
Loop time of 0.180005 on 4 procs for 69 steps with 2354 atoms
Step Temp PotEng f_HL f_HL[1] f_HL[2] f_HL[3] f_HL[4] f_HL[5] f_HL[6] f_HL[7] f_HL[8] f_HL[9] f_HL[10] f_HL[11] f_HL[12] f_HL[13] f_HL[14] f_HL[15] f_HL[16] f_HL[17] f_HL[18] f_HL[19] f_HL[20] f_HL[21] f_HL[22] f_HL[23] f_HL[24] f_HL[25] f_HL[26] f_HL[27] f_HL[28]
800 421.10795 -13037.462 1.8512626 3051.7064 8 0.31933951 0.4 0.9902351 0.93814672 1.0426311 5.9284526 1380.3372 4781.2974 5.8125 0.070322581 0.00043010753 4.0620002 0.99242754 0.93732488 1.0426311 2.7381277 0 0 0 0 16000 1 1 3 3118.9745 1
900 424.48211 -13036.231 1.5461807 1757.5544 7 0.25079261 0.4 0.99160613 0.94071212 1.0485957 5.9284526 1380.3372 4596.991 5.8511111 0.073300418 0.00037979491 4.0620002 0.99224254 0.93732488 1.0485957 2.7381277 0 0 0 0 18000 1 1 3 1803.828 0
Loop time of 0.158003 on 4 procs for 100 steps with 2354 atoms
Step Temp PotEng f_HL f_HL[1] f_HL[2] f_HL[3] f_HL[4] f_HL[5] f_HL[6] f_HL[7] f_HL[8] f_HL[9] f_HL[10] f_HL[11] f_HL[12] f_HL[13] f_HL[14] f_HL[15] f_HL[16] f_HL[17] f_HL[18] f_HL[19] f_HL[20] f_HL[21] f_HL[22] f_HL[23] f_HL[24] f_HL[25] f_HL[26] f_HL[27] f_HL[28]
900 424.48211 -13036.231 1.5461807 1757.5544 7 0.25079261 0.4 0.99160613 0.94071212 1.0485957 5.9284526 1380.3372 4596.991 5.8511111 0.073300418 0.00037979491 4.0620002 0.99224254 0.93732488 1.0485957 2.7381277 0 0 0 0 18000 1 1 3 1803.828 0
969 424.48211 -13101.694 1.5461807 1757.5544 7 0.25079261 0.4 0.99160613 0.94071212 1.0485957 5.9284526 1380.3372 4596.991 5.4344685 0.073300418 0.00037979491 4.0620002 0.99224254 0.93732488 1.0485957 2.7381277 0 0 0 0 19380 1 1 3 1803.828 0
Loop time of 0.165004 on 4 procs for 69 steps with 2354 atoms
Step Temp PotEng f_HL f_HL[1] f_HL[2] f_HL[3] f_HL[4] f_HL[5] f_HL[6] f_HL[7] f_HL[8] f_HL[9] f_HL[10] f_HL[11] f_HL[12] f_HL[13] f_HL[14] f_HL[15] f_HL[16] f_HL[17] f_HL[18] f_HL[19] f_HL[20] f_HL[21] f_HL[22] f_HL[23] f_HL[24] f_HL[25] f_HL[26] f_HL[27] f_HL[28]
900 424.48211 -13036.231 1.5462201 1757.5544 7 0.25079261 0.4 0.99160613 0.94071212 1.0485957 5.9284526 1380.3372 4596.991 5.8511111 0.073300418 0.00037979491 4.0620002 0.99224254 0.93732488 1.0485957 2.7381277 0 0 0 0 18000 1 1 3 1803.5841 0
1000 392.14281 -13033.226 1.3114425 4884.4012 6 0.28781471 0.4 0.99342697 0.93855058 1.0449678 5.9284526 1380.3372 4420.7581 5.862 0.076765609 0.00034118048 4.0620002 0.99230204 0.93732488 1.0514799 2.7381277 0 0 0 0 20000 1 1 3 6648.5089 0
Loop time of 0.159004 on 4 procs for 100 steps with 2354 atoms
Step Temp PotEng f_HL f_HL[1] f_HL[2] f_HL[3] f_HL[4] f_HL[5] f_HL[6] f_HL[7] f_HL[8] f_HL[9] f_HL[10] f_HL[11] f_HL[12] f_HL[13] f_HL[14] f_HL[15] f_HL[16] f_HL[17] f_HL[18] f_HL[19] f_HL[20] f_HL[21] f_HL[22] f_HL[23] f_HL[24] f_HL[25] f_HL[26] f_HL[27] f_HL[28]
1000 392.14281 -13033.226 1.3114425 4884.4012 6 0.28781471 0.4 0.99342697 0.93855058 1.0449678 5.9284526 1380.3372 4420.7581 5.862 0.076765609 0.00034118048 4.0620002 0.99230204 0.93732488 1.0514799 2.7381277 0 0 0 0 20000 1 1 3 6648.5089 0
1070 392.14281 -13101.694 1.3114425 4884.4012 6 0.28781471 0.4 0.99342697 0.93855058 1.0449678 5.9284526 1380.3372 4420.7581 5.4785047 0.076765609 0.00034118048 4.0620002 0.99230204 0.93732488 1.0514799 2.7381277 0 0 0 0 21400 1 1 3 6648.5089 0
Loop time of 0.167004 on 4 procs for 70 steps with 2354 atoms
Step Temp PotEng f_HL f_HL[1] f_HL[2] f_HL[3] f_HL[4] f_HL[5] f_HL[6] f_HL[7] f_HL[8] f_HL[9] f_HL[10] f_HL[11] f_HL[12] f_HL[13] f_HL[14] f_HL[15] f_HL[16] f_HL[17] f_HL[18] f_HL[19] f_HL[20] f_HL[21] f_HL[22] f_HL[23] f_HL[24] f_HL[25] f_HL[26] f_HL[27] f_HL[28]
1000 392.14281 -13033.226 1.3113308 4884.4012 6 0.28781471 0.4 0.99342697 0.93855058 1.0449678 5.9284526 1380.3372 4420.7581 5.862 0.076765609 0.00034118048 4.0620002 0.99230204 0.93732488 1.0514799 2.7381277 0 0 0 0 20000 1 1 3 6627.3707 0
1100 403.51397 -13035.66 0.54686506 3968.0952 5 0.36081738 0.4 0.99442104 0.93685489 1.0457452 5.9284526 1380.3372 4324.6709 5.89 0.077944127 0.00030868961 4.0620002 0.99241625 0.93604385 1.0514799 2.7381277 0 0 0 0 22000 1 1 3 1724.5221 2
Loop time of 0.143003 on 4 procs for 100 steps with 2354 atoms
Step Temp PotEng f_HL f_HL[1] f_HL[2] f_HL[3] f_HL[4] f_HL[5] f_HL[6] f_HL[7] f_HL[8] f_HL[9] f_HL[10] f_HL[11] f_HL[12] f_HL[13] f_HL[14] f_HL[15] f_HL[16] f_HL[17] f_HL[18] f_HL[19] f_HL[20] f_HL[21] f_HL[22] f_HL[23] f_HL[24] f_HL[25] f_HL[26] f_HL[27] f_HL[28]
1100 403.51397 -13035.66 0.54686506 3968.0952 5 0.36081738 0.4 0.99442104 0.93685489 1.0457452 5.9284526 1380.3372 4324.6709 5.89 0.077944127 0.00030868961 4.0620002 0.99241625 0.93604385 1.0514799 2.7381277 0 0 0 0 22000 1 1 3 1724.5221 2
1170 403.51397 -13101.694 0.54686506 3968.0952 5 0.36081738 0.4 0.99442104 0.93685489 1.0457452 5.9284526 1380.3372 4324.6709 5.5376068 0.077944127 0.00030868961 4.0620002 0.99241625 0.93604385 1.0514799 2.7381277 0 0 0 0 23400 1 1 3 1724.5221 2
Loop time of 0.134003 on 4 procs for 70 steps with 2354 atoms
Step Temp PotEng f_HL f_HL[1] f_HL[2] f_HL[3] f_HL[4] f_HL[5] f_HL[6] f_HL[7] f_HL[8] f_HL[9] f_HL[10] f_HL[11] f_HL[12] f_HL[13] f_HL[14] f_HL[15] f_HL[16] f_HL[17] f_HL[18] f_HL[19] f_HL[20] f_HL[21] f_HL[22] f_HL[23] f_HL[24] f_HL[25] f_HL[26] f_HL[27] f_HL[28]
1100 403.51397 -13035.66 0.54686188 3968.0952 5 0.36081738 0.4 0.99442104 0.93685489 1.0457452 5.9284526 1380.3372 4324.6709 5.89 0.077944127 0.00030868961 4.0620002 0.99241625 0.93604385 1.0514799 2.7381277 0 0 0 0 22000 1 1 3 1722.7748 2
1200 407.58933 -13037.757 0.83605065 5192.3954 5 0.3055123 0.4 0.99647568 0.93650885 1.0519936 5.9284526 1380.3372 4188.034 5.8883333 0.092838947 0.0022643646 4.0620002 0.99266277 0.9344152 1.0519936 2.7381277 0 0 0 0 24000 1 1 3 3708.6014 1
Loop time of 0.127003 on 4 procs for 100 steps with 2354 atoms
Step Temp PotEng f_HL f_HL[1] f_HL[2] f_HL[3] f_HL[4] f_HL[5] f_HL[6] f_HL[7] f_HL[8] f_HL[9] f_HL[10] f_HL[11] f_HL[12] f_HL[13] f_HL[14] f_HL[15] f_HL[16] f_HL[17] f_HL[18] f_HL[19] f_HL[20] f_HL[21] f_HL[22] f_HL[23] f_HL[24] f_HL[25] f_HL[26] f_HL[27] f_HL[28]
1200 407.58933 -13037.757 0.83605065 5192.3954 5 0.3055123 0.4 0.99647568 0.93650885 1.0519936 5.9284526 1380.3372 4188.034 5.8883333 0.092838947 0.0022643646 4.0620002 0.99266277 0.9344152 1.0519936 2.7381277 0 0 0 0 24000 1 1 3 3708.6014 1
1275 407.58933 -13101.694 0.83605065 5192.3954 5 0.3055123 0.4 0.99647568 0.93650885 1.0519936 5.9284526 1380.3372 4188.034 5.5419608 0.092838947 0.0022643646 4.0620002 0.99266277 0.9344152 1.0519936 2.7381277 0 0 0 0 25500 1 1 3 3708.6014 1
Loop time of 0.147004 on 4 procs for 75 steps with 2354 atoms
Step Temp PotEng f_HL f_HL[1] f_HL[2] f_HL[3] f_HL[4] f_HL[5] f_HL[6] f_HL[7] f_HL[8] f_HL[9] f_HL[10] f_HL[11] f_HL[12] f_HL[13] f_HL[14] f_HL[15] f_HL[16] f_HL[17] f_HL[18] f_HL[19] f_HL[20] f_HL[21] f_HL[22] f_HL[23] f_HL[24] f_HL[25] f_HL[26] f_HL[27] f_HL[28]
1200 407.58933 -13037.757 0.83600436 5192.3954 5 0.3055123 0.4 0.99647568 0.93650885 1.0519936 5.9284526 1380.3372 4188.034 5.8883333 0.092838947 0.0022643646 4.0620002 0.99266277 0.9344152 1.0519936 2.7381277 0 0 0 0 24000 1 1 3 3695.4259 1
1300 397.34752 -13035.27 1.143529 3889.5642 6 0.59455796 0.4 0.99734951 0.93577374 1.0582257 5.9284526 1380.3372 4130.5503 5.9123077 0.094977882 0.002081707 4.1048198 0.99297572 0.9344152 1.0582257 2.7381277 0 0 0 0 26000 1 1 3 2236.4525 2
Loop time of 0.129003 on 4 procs for 100 steps with 2354 atoms
Step Temp PotEng f_HL f_HL[1] f_HL[2] f_HL[3] f_HL[4] f_HL[5] f_HL[6] f_HL[7] f_HL[8] f_HL[9] f_HL[10] f_HL[11] f_HL[12] f_HL[13] f_HL[14] f_HL[15] f_HL[16] f_HL[17] f_HL[18] f_HL[19] f_HL[20] f_HL[21] f_HL[22] f_HL[23] f_HL[24] f_HL[25] f_HL[26] f_HL[27] f_HL[28]
1300 397.34752 -13035.27 1.143529 3889.5642 6 0.59455796 0.4 0.99734951 0.93577374 1.0582257 5.9284526 1380.3372 4130.5503 5.9123077 0.094977882 0.002081707 4.1048198 0.99297572 0.9344152 1.0582257 2.7381277 0 0 0 0 26000 1 1 3 2236.4525 2
1379 397.34752 -13102.882 1.143529 3889.5642 6 0.59455796 0.4 0.99734951 0.93577374 1.0582257 5.9284526 1380.3372 4130.5503 5.5736041 0.094977882 0.002081707 4.1048198 0.99297572 0.9344152 1.0582257 2.7381277 0 0 0 0 27580 1 1 3 2236.4525 2
Loop time of 0.130003 on 4 procs for 79 steps with 2354 atoms
Step Temp PotEng f_HL f_HL[1] f_HL[2] f_HL[3] f_HL[4] f_HL[5] f_HL[6] f_HL[7] f_HL[8] f_HL[9] f_HL[10] f_HL[11] f_HL[12] f_HL[13] f_HL[14] f_HL[15] f_HL[16] f_HL[17] f_HL[18] f_HL[19] f_HL[20] f_HL[21] f_HL[22] f_HL[23] f_HL[24] f_HL[25] f_HL[26] f_HL[27] f_HL[28]
1300 397.34752 -13035.27 0.8513344 3888.4728 5 0.43479061 0.4 0.99706967 0.93577374 1.0582257 5.9301165 1379.4348 4130.5503 5.9123077 0.094977882 0.002081707 4.1048198 0.99297572 0.9344152 1.0582257 2.7473869 0 0 0 0 26000 2 2 7 1674.6282 2
1400 406.75788 -13035.822 0.98339012 2583.5703 5 0.26687439 0.4 0.99725016 0.93341809 1.0565516 5.9301165 1379.4348 4125.2065 5.9 0.09503632 0.001937046 4.1048198 0.99327179 0.93335055 1.0582257 2.7473869 0 0 0 0 28000 2 2 7 1900.8002 0
Loop time of 0.145003 on 4 procs for 100 steps with 2354 atoms
Step Temp PotEng f_HL f_HL[1] f_HL[2] f_HL[3] f_HL[4] f_HL[5] f_HL[6] f_HL[7] f_HL[8] f_HL[9] f_HL[10] f_HL[11] f_HL[12] f_HL[13] f_HL[14] f_HL[15] f_HL[16] f_HL[17] f_HL[18] f_HL[19] f_HL[20] f_HL[21] f_HL[22] f_HL[23] f_HL[24] f_HL[25] f_HL[26] f_HL[27] f_HL[28]
1400 406.75788 -13035.822 0.98339012 2583.5703 5 0.26687439 0.4 0.99725016 0.93341809 1.0565516 5.9301165 1379.4348 4125.2065 5.9 0.09503632 0.001937046 4.1048198 0.99327179 0.93335055 1.0582257 2.7473869 0 0 0 0 28000 2 2 7 1900.8002 0
1471 406.75788 -13102.882 0.98339012 2583.5703 5 0.26687439 0.4 0.99725016 0.93341809 1.0565516 5.9301165 1379.4348 4125.2065 5.6152277 0.09503632 0.001937046 4.1048198 0.99327179 0.93335055 1.0582257 2.7473869 0 0 0 0 29420 2 2 7 1900.8002 0
Loop time of 0.134003 on 4 procs for 71 steps with 2354 atoms
Step Temp PotEng f_HL f_HL[1] f_HL[2] f_HL[3] f_HL[4] f_HL[5] f_HL[6] f_HL[7] f_HL[8] f_HL[9] f_HL[10] f_HL[11] f_HL[12] f_HL[13] f_HL[14] f_HL[15] f_HL[16] f_HL[17] f_HL[18] f_HL[19] f_HL[20] f_HL[21] f_HL[22] f_HL[23] f_HL[24] f_HL[25] f_HL[26] f_HL[27] f_HL[28]
1400 406.75788 -13035.822 0.98339747 2583.5703 5 0.26687439 0.4 0.99725016 0.93341809 1.0565516 5.9301165 1379.4348 4125.2065 5.9 0.09503632 0.001937046 4.1048198 0.99327179 0.93335055 1.0582257 2.7473869 0 0 0 0 28000 2 2 7 1898.7054 0
1500 403.04712 -13038.033 1.7734093 2587.2539 8 0.26021596 0.4 0.99949004 0.93136824 1.0627109 5.9301165 1379.4348 4021.2913 5.914 0.094465111 0.0018036298 4.1048198 0.99360825 0.93115568 1.0627109 2.7473869 0 0 0 0 30000 2 2 7 4239.5287 0
Loop time of 0.124003 on 4 procs for 100 steps with 2354 atoms
Step Temp PotEng f_HL f_HL[1] f_HL[2] f_HL[3] f_HL[4] f_HL[5] f_HL[6] f_HL[7] f_HL[8] f_HL[9] f_HL[10] f_HL[11] f_HL[12] f_HL[13] f_HL[14] f_HL[15] f_HL[16] f_HL[17] f_HL[18] f_HL[19] f_HL[20] f_HL[21] f_HL[22] f_HL[23] f_HL[24] f_HL[25] f_HL[26] f_HL[27] f_HL[28]
1500 403.04712 -13038.033 1.7734093 2587.2539 8 0.26021596 0.4 0.99949004 0.93136824 1.0627109 5.9301165 1379.4348 4021.2913 5.914 0.094465111 0.0018036298 4.1048198 0.99360825 0.93115568 1.0627109 2.7473869 0 0 0 0 30000 2 2 7 4239.5287 0
1568 403.04712 -13102.882 1.7734093 2587.2539 8 0.26021596 0.4 0.99949004 0.93136824 1.0627109 5.9301165 1379.4348 4021.2913 5.6575255 0.094465111 0.0018036298 4.1048198 0.99360825 0.93115568 1.0627109 2.7473869 0 0 0 0 31360 2 2 7 4239.5287 0
Loop time of 0.135003 on 4 procs for 68 steps with 2354 atoms
Step Temp PotEng f_HL f_HL[1] f_HL[2] f_HL[3] f_HL[4] f_HL[5] f_HL[6] f_HL[7] f_HL[8] f_HL[9] f_HL[10] f_HL[11] f_HL[12] f_HL[13] f_HL[14] f_HL[15] f_HL[16] f_HL[17] f_HL[18] f_HL[19] f_HL[20] f_HL[21] f_HL[22] f_HL[23] f_HL[24] f_HL[25] f_HL[26] f_HL[27] f_HL[28]
1500 403.04712 -13038.033 1.7733495 2587.2539 8 0.26021596 0.4 0.99949004 0.93136824 1.0627109 5.9301165 1379.4348 4021.2913 5.914 0.094465111 0.0018036298 4.1048198 0.99360825 0.93115568 1.0627109 2.7473869 0 0 0 0 30000 2 2 7 4227.4184 0
1600 413.63587 -13039.863 0.67705876 2150.6698 5 0.32653141 0.4 1.0004587 0.9309105 1.06525 5.9301165 1379.4348 3981.2133 5.93375 0.090478197 0.0016852749 4.1048198 0.99397193 0.92879897 1.06525 2.7473869 0 0 0 0 32000 2 2 7 822.48747 1
Loop time of 0.132003 on 4 procs for 100 steps with 2354 atoms
Step Temp PotEng f_HL f_HL[1] f_HL[2] f_HL[3] f_HL[4] f_HL[5] f_HL[6] f_HL[7] f_HL[8] f_HL[9] f_HL[10] f_HL[11] f_HL[12] f_HL[13] f_HL[14] f_HL[15] f_HL[16] f_HL[17] f_HL[18] f_HL[19] f_HL[20] f_HL[21] f_HL[22] f_HL[23] f_HL[24] f_HL[25] f_HL[26] f_HL[27] f_HL[28]
1600 413.63587 -13039.863 0.67705876 2150.6698 5 0.32653141 0.4 1.0004587 0.9309105 1.06525 5.9301165 1379.4348 3981.2133 5.93375 0.090478197 0.0016852749 4.1048198 0.99397193 0.92879897 1.06525 2.7473869 0 0 0 0 32000 2 2 7 822.48747 1
1669 413.63587 -13102.882 0.67705876 2150.6698 5 0.32653141 0.4 1.0004587 0.9309105 1.06525 5.9301165 1379.4348 3981.2133 5.6884362 0.090478197 0.0016852749 4.1048198 0.99397193 0.92879897 1.06525 2.7473869 0 0 0 0 33380 2 2 7 822.48747 1
Loop time of 0.135003 on 4 procs for 69 steps with 2354 atoms
Step Temp PotEng f_HL f_HL[1] f_HL[2] f_HL[3] f_HL[4] f_HL[5] f_HL[6] f_HL[7] f_HL[8] f_HL[9] f_HL[10] f_HL[11] f_HL[12] f_HL[13] f_HL[14] f_HL[15] f_HL[16] f_HL[17] f_HL[18] f_HL[19] f_HL[20] f_HL[21] f_HL[22] f_HL[23] f_HL[24] f_HL[25] f_HL[26] f_HL[27] f_HL[28]
1600 413.63587 -13039.863 0.67707996 2150.6698 5 0.32653141 0.4 1.0004587 0.9309105 1.06525 5.9301165 1379.4348 3981.2133 5.93375 0.090478197 0.0016852749 4.1048198 0.99397193 0.92879897 1.06525 2.7473869 0 0 0 0 32000 2 2 7 822.44597 1
1700 410.04422 -13040.035 1.0190943 1598.6072 7 0.29206253 0.4 1.0030056 0.92869822 1.0714971 5.9301165 1379.4348 3886.4362 5.9435294 0.093527316 0.0015835313 4.1048198 0.99441728 0.92869822 1.0714971 2.7473869 0 0 0 0 34000 2 2 7 1041.7855 0
Loop time of 0.129003 on 4 procs for 100 steps with 2354 atoms
Step Temp PotEng f_HL f_HL[1] f_HL[2] f_HL[3] f_HL[4] f_HL[5] f_HL[6] f_HL[7] f_HL[8] f_HL[9] f_HL[10] f_HL[11] f_HL[12] f_HL[13] f_HL[14] f_HL[15] f_HL[16] f_HL[17] f_HL[18] f_HL[19] f_HL[20] f_HL[21] f_HL[22] f_HL[23] f_HL[24] f_HL[25] f_HL[26] f_HL[27] f_HL[28]
1700 410.04422 -13040.035 1.0190943 1598.6072 7 0.29206253 0.4 1.0030056 0.92869822 1.0714971 5.9301165 1379.4348 3886.4362 5.9435294 0.093527316 0.0015835313 4.1048198 0.99441728 0.92869822 1.0714971 2.7473869 0 0 0 0 34000 2 2 7 1041.7855 0
1770 410.04422 -13102.882 1.0190943 1598.6072 7 0.29206253 0.4 1.0030056 0.92869822 1.0714971 5.9301165 1379.4348 3886.4362 5.7084746 0.093527316 0.0015835313 4.1048198 0.99441728 0.92869822 1.0714971 2.7473869 0 0 0 0 35400 2 2 7 1041.7855 0
Loop time of 0.145004 on 4 procs for 70 steps with 2354 atoms
Step Temp PotEng f_HL f_HL[1] f_HL[2] f_HL[3] f_HL[4] f_HL[5] f_HL[6] f_HL[7] f_HL[8] f_HL[9] f_HL[10] f_HL[11] f_HL[12] f_HL[13] f_HL[14] f_HL[15] f_HL[16] f_HL[17] f_HL[18] f_HL[19] f_HL[20] f_HL[21] f_HL[22] f_HL[23] f_HL[24] f_HL[25] f_HL[26] f_HL[27] f_HL[28]
1700 410.04422 -13040.035 1.0191295 1598.6072 7 0.29206253 0.4 1.0030056 0.92869822 1.0714971 5.9301165 1379.4348 3886.4362 5.9435294 0.093527316 0.0015835313 4.1048198 0.99441728 0.92869822 1.0714971 2.7473869 0 0 0 0 34000 2 2 7 1041.6898 0
1800 413.56333 -13039.872 1.6705072 5357.337 7 0.28802305 0.4 1.0045556 0.92823157 1.0777313 5.9301165 1379.4348 3837.633 5.9366667 0.095545574 0.0014972862 4.1048198 0.99496874 0.92821036 1.0777313 2.7473869 0 0 0 0 36000 2 2 7 7008.708 0
Loop time of 0.157003 on 4 procs for 100 steps with 2354 atoms
Step Temp PotEng f_HL f_HL[1] f_HL[2] f_HL[3] f_HL[4] f_HL[5] f_HL[6] f_HL[7] f_HL[8] f_HL[9] f_HL[10] f_HL[11] f_HL[12] f_HL[13] f_HL[14] f_HL[15] f_HL[16] f_HL[17] f_HL[18] f_HL[19] f_HL[20] f_HL[21] f_HL[22] f_HL[23] f_HL[24] f_HL[25] f_HL[26] f_HL[27] f_HL[28]
1800 413.56333 -13039.872 1.6705072 5357.337 7 0.28802305 0.4 1.0045556 0.92823157 1.0777313 5.9301165 1379.4348 3837.633 5.9366667 0.095545574 0.0014972862 4.1048198 0.99496874 0.92821036 1.0777313 2.7473869 0 0 0 0 36000 2 2 7 7008.708 0
1868 413.56333 -13102.882 1.6705072 5357.337 7 0.28802305 0.4 1.0045556 0.92823157 1.0777313 5.9301165 1379.4348 3837.633 5.7205567 0.095545574 0.0014972862 4.1048198 0.99496874 0.92821036 1.0777313 2.7473869 0 0 0 0 37360 2 2 7 7008.708 0
Loop time of 0.143003 on 4 procs for 68 steps with 2354 atoms
Step Temp PotEng f_HL f_HL[1] f_HL[2] f_HL[3] f_HL[4] f_HL[5] f_HL[6] f_HL[7] f_HL[8] f_HL[9] f_HL[10] f_HL[11] f_HL[12] f_HL[13] f_HL[14] f_HL[15] f_HL[16] f_HL[17] f_HL[18] f_HL[19] f_HL[20] f_HL[21] f_HL[22] f_HL[23] f_HL[24] f_HL[25] f_HL[26] f_HL[27] f_HL[28]
1800 413.56333 -13039.872 1.6703547 5357.337 7 0.28802305 0.4 1.0045556 0.92823157 1.0777313 5.9301165 1379.4348 3837.633 5.9366667 0.095545574 0.0014972862 4.1048198 0.99496874 0.92821036 1.0777313 2.7473869 0 0 0 0 36000 2 2 7 6990.9088 0
1900 389.96327 -13036.384 0.50418526 2970.8471 5 0.2897091 0.4 1.0069357 0.92635421 1.083738 5.9301165 1379.4348 3766.0095 5.9652632 0.092376919 0.0014116817 4.1048198 0.9955231 0.92635421 1.083738 2.7473869 0 0 0 0 38000 2 2 7 102.84786 0
Loop time of 0.161004 on 4 procs for 100 steps with 2354 atoms
Step Temp PotEng f_HL f_HL[1] f_HL[2] f_HL[3] f_HL[4] f_HL[5] f_HL[6] f_HL[7] f_HL[8] f_HL[9] f_HL[10] f_HL[11] f_HL[12] f_HL[13] f_HL[14] f_HL[15] f_HL[16] f_HL[17] f_HL[18] f_HL[19] f_HL[20] f_HL[21] f_HL[22] f_HL[23] f_HL[24] f_HL[25] f_HL[26] f_HL[27] f_HL[28]
1900 389.96327 -13036.384 0.50418526 2970.8471 5 0.2897091 0.4 1.0069357 0.92635421 1.083738 5.9301165 1379.4348 3766.0095 5.9652632 0.092376919 0.0014116817 4.1048198 0.9955231 0.92635421 1.083738 2.7473869 0 0 0 0 38000 2 2 7 102.84786 0
1970 389.96327 -13102.882 0.50418526 2970.8471 5 0.2897091 0.4 1.0069357 0.92635421 1.083738 5.9301165 1379.4348 3766.0095 5.7532995 0.092376919 0.0014116817 4.1048198 0.9955231 0.92635421 1.083738 2.7473869 0 0 0 0 39400 2 2 7 102.84786 0
Loop time of 0.221005 on 4 procs for 70 steps with 2354 atoms
Step Temp PotEng f_HL f_HL[1] f_HL[2] f_HL[3] f_HL[4] f_HL[5] f_HL[6] f_HL[7] f_HL[8] f_HL[9] f_HL[10] f_HL[11] f_HL[12] f_HL[13] f_HL[14] f_HL[15] f_HL[16] f_HL[17] f_HL[18] f_HL[19] f_HL[20] f_HL[21] f_HL[22] f_HL[23] f_HL[24] f_HL[25] f_HL[26] f_HL[27] f_HL[28]
1900 389.96327 -13036.384 0.50421483 2970.8471 5 0.2897091 0.4 1.0069357 0.92635421 1.083738 5.9301165 1379.4348 3766.0095 5.9652632 0.092376919 0.0014116817 4.1048198 0.9955231 0.92635421 1.083738 2.7473869 0 0 0 0 38000 2 2 7 102.91265 0
2000 397.57054 -13037.793 1.296998 2702.0288 7 0.3344139 0.4 1.0080872 0.9254519 1.089981 5.9301165 1379.4348 3740.858 5.9815 0.094708685 0.0013374572 4.1048198 0.99612398 0.9252451 1.089981 2.7473869 0 0 0 0 40000 2 2 7 2970.9196 1
Loop time of 0.125003 on 4 procs for 100 steps with 2354 atoms
Step Temp PotEng f_HL f_HL[1] f_HL[2] f_HL[3] f_HL[4] f_HL[5] f_HL[6] f_HL[7] f_HL[8] f_HL[9] f_HL[10] f_HL[11] f_HL[12] f_HL[13] f_HL[14] f_HL[15] f_HL[16] f_HL[17] f_HL[18] f_HL[19] f_HL[20] f_HL[21] f_HL[22] f_HL[23] f_HL[24] f_HL[25] f_HL[26] f_HL[27] f_HL[28]
2000 397.57054 -13037.793 1.296998 2702.0288 7 0.3344139 0.4 1.0080872 0.9254519 1.089981 5.9301165 1379.4348 3740.858 5.9815 0.094708685 0.0013374572 4.1048198 0.99612398 0.9252451 1.089981 2.7473869 0 0 0 0 40000 2 2 7 2970.9196 1
2074 397.57054 -13102.882 1.296998 2702.0288 7 0.3344139 0.4 1.0080872 0.9254519 1.089981 5.9301165 1379.4348 3740.858 5.768081 0.094708685 0.0013374572 4.1048198 0.99612398 0.9252451 1.089981 2.7473869 0 0 0 0 41480 2 2 7 2970.9196 1
Loop time of 0.138003 on 4 procs for 74 steps with 2354 atoms
Final hyper stats ...
Cummulative quantities for fix hyper:
hyper time = 40000
time boost factor = 4000
event timesteps = 2
# of atoms in events = 2
Quantities for this hyper run:
event timesteps = 2
# of atoms in events = 2
max length of any bond = 4.10482
max drift distance of any atom = 2.74739
fraction of biased bonds with zero bias = 0.0947087
fraction of biased bonds with negative strain = 0.00133746
Current quantities:
ave bonds/atom = 5.93012
Cummulative quantities specific to fix hyper/local:
# of new bonds formed = 7
max bonds/atom = 12
Quantities for this hyper run specific to fix hyper/local:
ave boost for all bonds/step = 3740.86
ave biased bonds/step = 5.9815
ave bias coeff of all bonds = 0.996124
min bias coeff of any bond = 0.925245
max bias coeff of any bond = 1.08998
max dist from my subbox of any non-maxstrain bond ghost atom = 0
max dist from my box of any bond ghost atom = 0
count of bond ghost neighbors not found on reneighbor steps = 0
bias overlaps = 0
CPU time for bond builds = 0.00900006
Current quantities specific to fix hyper/local:
neighbor bonds/bond = 1379.43
ave boost coeff for all bonds = 1.00809
Loop time of 6.39915 on 4 procs for 2000 steps with 2354 atoms
Performance: 135.018 ns/day, 0.178 hours/ns, 312.542 timesteps/s
124.8% CPU use with 4 MPI tasks x no OpenMP threads
Hyper stats:
Dynamics time (%) = 2.82706 (44.1788)
Quench time (%) = 2.94107 (45.9603)
Other time (%) = 0.559511 (8.74353)
MPI task timing breakdown:
Section | min time | avg time | max time |%varavg| %total
---------------------------------------------------------------
Pair | 4.2581 | 4.3754 | 4.4861 | 4.4 | 68.37
Neigh | 0.165 | 0.171 | 0.178 | 1.1 | 2.67
Comm | 0.40501 | 0.50426 | 0.58801 | 9.7 | 7.88
Output | 0 | 0.00049996 | 0.0019999 | 0.0 | 0.01
Modify | 0.74901 | 0.78851 | 0.82701 | 3.4 | 12.32
Other | | 0.5595 | | | 8.74
Nlocal: 588.5 ave 610 max 570 min
Histogram: 1 0 0 0 2 0 0 0 0 1
Nghost: 1965.75 ave 1984 max 1944 min
Histogram: 1 0 0 0 0 1 1 0 0 1
Neighs: 13783.2 ave 14264 max 13396 min
Histogram: 1 0 0 1 1 0 0 0 0 1
FullNghs: 136894 ave 139463 max 134036 min
Histogram: 1 0 0 0 1 0 1 0 0 1
Total # of neighbors = 547576
Ave neighs/atom = 232.615
Neighbor list builds = 192
Dangerous builds = 0
Total wall time: 0:00:08

2
examples/message/in.message.client
View File

@ -39,3 +39,5 @@ fix_modify 2 energy yes
thermo 10
run 50
message quit

2
examples/message/in.message.tilt.client
View File

@ -40,3 +40,5 @@ thermo_style custom step temp epair etotal press xy
thermo 1000
run 50000
message quit

17
examples/rerun/README Normal file
View File

@ -0,0 +1,17 @@
Examples of how to use the rerun and read_dump commands
in.first - run on any number of procs for any size problem
in.rerun - run on same or different proc count for same size problem
in.read_dump - ditto to in.rerun
The thermo output on the same timesteps should be identical
to within round-off errors.
in.rdf.first - produces RDF in rdf.first, 50 bins out to 2.5 sigma
in.rdf.rerun - produces RDF in rdf.rerun, 100 bins out to 5 sigma
In both bases the time averaged RDF is computed 10x times, every 100
steps for 1000 total. In the rerun, the pair style cutoff is changed
so the RDF can be computed to a longer distance without re-running the
simulation. The RDF values in the 2 files should be the same (within
round-off) for the first 50 bins.

33
examples/rerun/in.first Normal file
View File

@ -0,0 +1,33 @@
# 3d Lennard-Jones melt
variable x index 1
variable y index 1
variable z index 1
variable xx equal 20*$x
variable yy equal 20*$y
variable zz equal 20*$z
units lj
atom_style atomic
lattice fcc 0.8442
region box block 0 ${xx} 0 ${yy} 0 ${zz}
create_box 1 box
create_atoms 1 box
mass 1 1.0
velocity all create 1.44 87287 loop geom
pair_style lj/cut 2.5
pair_coeff 1 1 1.0 1.0 2.5
neighbor 0.3 bin
neigh_modify delay 0 every 20 check no
fix 1 all nve
dump 1 all custom 100 lj.dump id type x y z vx vy vz
thermo 100
run 1000

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