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

Merge branch 'master' into pair-bop-updates

This commit is contained in:
Axel Kohlmeyer 2020-01-14 13:15:05 -05:00
parent 9ed9b4338b 126bc01dd4
commit 2f83b32030
No known key found for this signature in database
GPG Key ID: D9B44E93BF0C375A
129 changed files with 1596 additions and 5636 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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)

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

16
doc/src/Commands_fix.rst
View File

@ -105,13 +105,13 @@ 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>`
@ -188,15 +188,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>`
@ -237,4 +238,3 @@ OPT.
* :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>`

18
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>`
@ -176,6 +176,7 @@ OPT.
* :doc:`meam/sw/spline <pair_meam_sw_spline>`
* :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 +198,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 +217,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>`

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

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

22
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
@ -339,15 +340,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
@ -399,7 +401,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

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

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

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

37
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
@ -245,7 +246,7 @@ accelerated styles exist.
* :doc:`meam/sw/spline <pair_meam_sw_spline>` - splined version of MEAM with a Stillinger-Weber term
* :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 +268,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 +287,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 +335,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 +345,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/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

7
doc/txt/Errors_warnings.txt
View File

@ -239,6 +239,13 @@ will be truncated to attempt to prevent the bond from blowing up. :dd
You likely want to set this in your input script. :dd
{ Fix bond/create is used multiple times or with fix bond/break - may not work as expected} :dt
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. :dd
{Fix bond/swap will ignore defined angles} :dt
See the doc page for fix bond/swap for more info on this

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.

2157
doc/txt/Packages_details.txt
View File

File diff suppressed because it is too large Load Diff

392
doc/txt/fix.txt
View File

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

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.

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

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

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

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

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

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

@ -1141,6 +1141,7 @@ ico
icosahedral
idealgas
IDR
idx
ielement
ieni
ifdefs
@ -2475,6 +2476,8 @@ Runge
runtime
Rutuparna
rx
ry
rz
Ryckaert
Rycroft
Rydbergs

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

4
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
@ -164,6 +165,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

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

36
examples/rerun/in.rdf.first Normal file
View File

@ -0,0 +1,36 @@
# 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
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
compute myRDF all rdf 50 cutoff 2.5
fix 2 all ave/time 100 10 1000 c_myRDF[*] file rdf.first mode vector
thermo 100
run 1000

31
examples/rerun/in.rdf.rerun Normal file
View File

@ -0,0 +1,31 @@
# 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
pair_style lj/cut 5.0
pair_coeff 1 1 1.0 1.0
neighbor 0.3 bin
compute myRDF all rdf 100 cutoff 5.0
fix 2 all ave/time 100 10 1000 c_myRDF[*] file rdf.rerun mode vector
thermo 100
rerun lj.dump dump x y z

37
examples/rerun/in.read_dump Normal file
View File

@ -0,0 +1,37 @@
# 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
pair_style lj/cut 2.5
pair_coeff 1 1 1.0 1.0 2.5
neighbor 0.3 bin
thermo 100
read_dump lj.dump 200 x y z vx vy vz
run 0 post no
read_dump lj.dump 800 x y z vx vy vz
run 0 post no
read_dump lj.dump 600 x y z vx vy vz
run 0 post no
read_dump lj.dump 400 x y z vx vy vz
run 0 post no

29
examples/rerun/in.rerun Normal file
View File

@ -0,0 +1,29 @@
# 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
pair_style lj/cut 2.5
pair_coeff 1 1 1.0 1.0 2.5
neighbor 0.3 bin
thermo 100
rerun lj.dump first 200 last 800 every 200 &
dump x y z vx vy vz

97
examples/rerun/log.09Jan20.first.g++.4 Normal file
View File

@ -0,0 +1,97 @@
LAMMPS (09 Jan 2020)
# 3d Lennard-Jones melt
variable x index 1
variable y index 1
variable z index 1
variable xx equal 20*$x
variable xx equal 20*1
variable yy equal 20*$y
variable yy equal 20*1
variable zz equal 20*$z
variable zz equal 20*1
units lj
atom_style atomic
lattice fcc 0.8442
Lattice spacing in x,y,z = 1.6796 1.6796 1.6796
region box block 0 ${xx} 0 ${yy} 0 ${zz}
region box block 0 20 0 ${yy} 0 ${zz}
region box block 0 20 0 20 0 ${zz}
region box block 0 20 0 20 0 20
create_box 1 box
Created orthogonal box = (0 0 0) to (33.5919 33.5919 33.5919)
1 by 2 by 2 MPI processor grid
create_atoms 1 box
Created 32000 atoms
create_atoms CPU = 0.00173283 secs
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
Neighbor list info ...
update every 20 steps, delay 0 steps, check no
max neighbors/atom: 2000, page size: 100000
master list distance cutoff = 2.8
ghost atom cutoff = 2.8
binsize = 1.4, bins = 24 24 24
1 neighbor lists, perpetual/occasional/extra = 1 0 0
(1) pair lj/cut, 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) = 7.869 | 7.869 | 7.869 Mbytes
Step Temp E_pair E_mol TotEng Press
0 1.44 -6.7733681 0 -4.6134356 -5.0197073
100 0.7574531 -5.7585055 0 -4.6223613 0.20726105
200 0.75953175 -5.7618892 0 -4.6226272 0.20910575
300 0.74624286 -5.741962 0 -4.6226327 0.32016436
400 0.74155675 -5.7343359 0 -4.6220356 0.3777989
500 0.73249345 -5.7206946 0 -4.6219887 0.44253023
600 0.72087255 -5.7029314 0 -4.6216563 0.55730354
700 0.71489947 -5.693532 0 -4.6212164 0.61322381
800 0.70876958 -5.6840594 0 -4.6209382 0.66822293
900 0.70799522 -5.6828388 0 -4.6208791 0.66961272
1000 0.70325878 -5.6750833 0 -4.6202281 0.7112575
Loop time of 6.3349 on 4 procs for 1000 steps with 32000 atoms
Performance: 68193.673 tau/day, 157.856 timesteps/s
99.8% CPU use with 4 MPI tasks x no OpenMP threads
MPI task timing breakdown:
Section | min time | avg time | max time |%varavg| %total
---------------------------------------------------------------
Pair | 4.3538 | 4.6712 | 5.0021 | 12.8 | 73.74
Neigh | 0.59378 | 0.65229 | 0.75202 | 8.0 | 10.30
Comm | 0.28101 | 0.69839 | 1.0586 | 38.5 | 11.02
Output | 0.21601 | 0.21682 | 0.21718 | 0.1 | 3.42
Modify | 0.074002 | 0.074803 | 0.075779 | 0.2 | 1.18
Other | | 0.0214 | | | 0.34
Nlocal: 8000 ave 8049 max 7942 min
Histogram: 1 0 0 1 0 0 0 1 0 1
Nghost: 8632.5 ave 8685 max 8591 min
Histogram: 1 0 0 1 1 0 0 0 0 1
Neighs: 299934 ave 303105 max 295137 min
Histogram: 1 0 0 0 0 0 1 1 0 1
Total # of neighbors = 1199738
Ave neighs/atom = 37.4918
Neighbor list builds = 50
Dangerous builds not checked
Total wall time: 0:00:06

105
examples/rerun/log.09Jan20.rdf.first.g++.4 Normal file
View File

@ -0,0 +1,105 @@
LAMMPS (09 Jan 2020)
# 3d Lennard-Jones melt
variable x index 1
variable y index 1
variable z index 1
variable xx equal 20*$x
variable xx equal 20*1
variable yy equal 20*$y
variable yy equal 20*1
variable zz equal 20*$z
variable zz equal 20*1
units lj
atom_style atomic
lattice fcc 0.8442
Lattice spacing in x,y,z = 1.6796 1.6796 1.6796
region box block 0 ${xx} 0 ${yy} 0 ${zz}
region box block 0 20 0 ${yy} 0 ${zz}
region box block 0 20 0 20 0 ${zz}
region box block 0 20 0 20 0 20
create_box 1 box
Created orthogonal box = (0 0 0) to (33.5919 33.5919 33.5919)
1 by 2 by 2 MPI processor grid
create_atoms 1 box
Created 32000 atoms
create_atoms CPU = 0.00100017 secs
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
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
compute myRDF all rdf 50 cutoff 2.5
fix 2 all ave/time 100 10 1000 c_myRDF[*] file rdf.first mode vector
thermo 100
run 1000
Neighbor list info ...
update every 20 steps, delay 0 steps, check no
max neighbors/atom: 2000, page size: 100000
master list distance cutoff = 2.8
ghost atom cutoff = 2.8
binsize = 1.4, bins = 24 24 24
2 neighbor lists, perpetual/occasional/extra = 1 1 0
(1) pair lj/cut, perpetual
attributes: half, newton on
pair build: half/bin/atomonly/newton
stencil: half/bin/3d/newton
bin: standard
(2) compute rdf, occasional
attributes: half, newton on, cut 2.8
pair build: half/bin/atomonly/newton
stencil: half/bin/3d/newton
bin: standard
Per MPI rank memory allocation (min/avg/max) = 8.487 | 8.487 | 8.487 Mbytes
Step Temp E_pair E_mol TotEng Press
0 1.44 -6.7733681 0 -4.6134356 -5.0197073
100 0.7574531 -5.7585055 0 -4.6223613 0.20726105
200 0.75953175 -5.7618892 0 -4.6226272 0.20910575
300 0.74624286 -5.741962 0 -4.6226327 0.32016436
400 0.74155675 -5.7343359 0 -4.6220356 0.3777989
500 0.73249345 -5.7206946 0 -4.6219887 0.44253023
600 0.72087255 -5.7029314 0 -4.6216563 0.55730354
700 0.71489947 -5.693532 0 -4.6212164 0.61322381
800 0.70876958 -5.6840594 0 -4.6209382 0.66822293
900 0.70799522 -5.6828388 0 -4.6208791 0.66961272
1000 0.70325878 -5.6750833 0 -4.6202281 0.7112575
Loop time of 7.44016 on 4 procs for 1000 steps with 32000 atoms
Performance: 58063.267 tau/day, 134.406 timesteps/s
99.7% CPU use with 4 MPI tasks x no OpenMP threads
MPI task timing breakdown:
Section | min time | avg time | max time |%varavg| %total
---------------------------------------------------------------
Pair | 5.3881 | 5.5809 | 5.7111 | 5.4 | 75.01
Neigh | 0.80101 | 0.82776 | 0.85702 | 2.2 | 11.13
Comm | 0.31801 | 0.48426 | 0.72201 | 22.5 | 6.51
Output | 0.17801 | 0.17801 | 0.17801 | 0.0 | 2.39
Modify | 0.31201 | 0.33076 | 0.33701 | 1.9 | 4.45
Other | | 0.0385 | | | 0.52
Nlocal: 8000 ave 8049 max 7942 min
Histogram: 1 0 0 1 0 0 0 1 0 1
Nghost: 8632.5 ave 8685 max 8591 min
Histogram: 1 0 0 1 1 0 0 0 0 1
Neighs: 299934 ave 303105 max 295137 min
Histogram: 1 0 0 0 0 0 1 1 0 1
Total # of neighbors = 1199738
Ave neighs/atom = 37.4918
Neighbor list builds = 50
Dangerous builds not checked
Total wall time: 0:00:07

100
examples/rerun/log.09Jan20.rdf.rerun.g++.4 Normal file
View File

@ -0,0 +1,100 @@
LAMMPS (09 Jan 2020)
# 3d Lennard-Jones melt
variable x index 1
variable y index 1
variable z index 1
variable xx equal 20*$x
variable xx equal 20*1
variable yy equal 20*$y
variable yy equal 20*1
variable zz equal 20*$z
variable zz equal 20*1
units lj
atom_style atomic
lattice fcc 0.8442
Lattice spacing in x,y,z = 1.6796 1.6796 1.6796
region box block 0 ${xx} 0 ${yy} 0 ${zz}
region box block 0 20 0 ${yy} 0 ${zz}
region box block 0 20 0 20 0 ${zz}
region box block 0 20 0 20 0 20
create_box 1 box
Created orthogonal box = (0 0 0) to (33.5919 33.5919 33.5919)
1 by 2 by 2 MPI processor grid
create_atoms 1 box
Created 32000 atoms
create_atoms CPU = 0.00183487 secs
mass 1 1.0
pair_style lj/cut 5.0
pair_coeff 1 1 1.0 1.0
neighbor 0.3 bin
compute myRDF all rdf 100 cutoff 5.0
fix 2 all ave/time 100 10 1000 c_myRDF[*] file rdf.rerun mode vector
thermo 100
rerun lj.dump dump x y z
Neighbor list info ...
update every 1 steps, delay 10 steps, check yes
max neighbors/atom: 2000, page size: 100000
master list distance cutoff = 5.3
ghost atom cutoff = 5.3
binsize = 2.65, bins = 13 13 13
2 neighbor lists, perpetual/occasional/extra = 1 1 0
(1) pair lj/cut, perpetual
attributes: half, newton on
pair build: half/bin/atomonly/newton
stencil: half/bin/3d/newton
bin: standard
(2) compute rdf, occasional
attributes: half, newton on, cut 5.3
pair build: half/bin/atomonly/newton
stencil: half/bin/3d/newton
bin: standard
Per MPI rank memory allocation (min/avg/max) = 15.19 | 15.19 | 15.19 Mbytes
Step Temp E_pair E_mol TotEng Press
0 0 -7.1616928 0 -7.1616928 -6.8899898
100 0 -6.1442754 0 -6.1442754 -1.0825318
200 0 -6.1472483 0 -6.1472483 -1.0817213
300 0 -6.1274033 0 -6.1274033 -0.95961014
400 0 -6.1202956 0 -6.1202956 -0.8988851
500 0 -6.1067136 0 -6.1067136 -0.82660368
600 0 -6.0893179 0 -6.0893179 -0.70264528
700 0 -6.0803044 0 -6.0803044 -0.64232743
800 0 -6.0710303 0 -6.0710303 -0.5824798
900 0 -6.0698963 0 -6.0698963 -0.58057929
1000 0 -6.0627642 0 -6.0627642 -0.53599799
Loop time of 3.07661 on 4 procs for 11 steps with 32000 atoms
Performance: 1544.558 tau/day, 3.575 timesteps/s
99.8% 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 | 0 | 0 | 0.0 | 0.00
Neigh | 0 | 0 | 0 | 0.0 | 0.00
Comm | 0 | 0 | 0 | 0.0 | 0.00
Output | 0 | 0 | 0 | 0.0 | 0.00
Modify | 0 | 0 | 0 | 0.0 | 0.00
Other | | 3.077 | | |100.00
Nlocal: 8000 ave 8049 max 7942 min
Histogram: 1 0 0 1 0 0 0 1 0 1
Nghost: 20028 ave 20060 max 19988 min
Histogram: 1 0 0 0 1 0 0 0 1 1
Neighs: 2.10417e+06 ave 2.12604e+06 max 2.07878e+06 min
Histogram: 1 0 0 1 0 0 0 0 1 1
Total # of neighbors = 8416685
Ave neighs/atom = 263.021
Neighbor list builds = 0
Dangerous builds = 0
Total wall time: 0:00:03

118
examples/rerun/log.09Jan20.read_dump.g++.4 Normal file
View File

@ -0,0 +1,118 @@
LAMMPS (09 Jan 2020)
# 3d Lennard-Jones melt
variable x index 1
variable y index 1
variable z index 1
variable xx equal 20*$x
variable xx equal 20*1
variable yy equal 20*$y
variable yy equal 20*1
variable zz equal 20*$z
variable zz equal 20*1
units lj
atom_style atomic
lattice fcc 0.8442
Lattice spacing in x,y,z = 1.6796 1.6796 1.6796
region box block 0 ${xx} 0 ${yy} 0 ${zz}
region box block 0 20 0 ${yy} 0 ${zz}
region box block 0 20 0 20 0 ${zz}
region box block 0 20 0 20 0 20
create_box 1 box
Created orthogonal box = (0 0 0) to (33.5919 33.5919 33.5919)
1 by 2 by 2 MPI processor grid
create_atoms 1 box
Created 32000 atoms
create_atoms CPU = 0.001724 secs
mass 1 1.0
pair_style lj/cut 2.5
pair_coeff 1 1 1.0 1.0 2.5
neighbor 0.3 bin
thermo 100
read_dump lj.dump 200 x y z vx vy vz
orthogonal box = (0 0 0) to (33.5919 33.5919 33.5919)
32000 atoms before read
32000 atoms in snapshot
0 atoms purged
32000 atoms replaced
0 atoms trimmed
0 atoms added
32000 atoms after read
run 0 post no
WARNING: No fixes defined, atoms won't move (../verlet.cpp:52)
Neighbor list info ...
update every 1 steps, delay 10 steps, check yes
max neighbors/atom: 2000, page size: 100000
master list distance cutoff = 2.8
ghost atom cutoff = 2.8
binsize = 1.4, bins = 24 24 24
1 neighbor lists, perpetual/occasional/extra = 1 0 0
(1) pair lj/cut, 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) = 6.841 | 6.843 | 6.846 Mbytes
Step Temp E_pair E_mol TotEng Press
200 0.75953173 -5.7618854 0 -4.6226234 0.20912952
Loop time of 2.26498e-06 on 4 procs for 0 steps with 32000 atoms
read_dump lj.dump 800 x y z vx vy vz
orthogonal box = (0 0 0) to (33.5919 33.5919 33.5919)
32000 atoms before read
32000 atoms in snapshot
0 atoms purged
32000 atoms replaced
0 atoms trimmed
0 atoms added
32000 atoms after read
run 0 post no
WARNING: No fixes defined, atoms won't move (../verlet.cpp:52)
Per MPI rank memory allocation (min/avg/max) = 6.841 | 6.843 | 6.846 Mbytes
Step Temp E_pair E_mol TotEng Press
800 0.70876957 -5.6840545 0 -4.6209334 0.66823926
Loop time of 5.36442e-07 on 4 procs for 0 steps with 32000 atoms
read_dump lj.dump 600 x y z vx vy vz
orthogonal box = (0 0 0) to (33.5919 33.5919 33.5919)
32000 atoms before read
32000 atoms in snapshot
0 atoms purged
32000 atoms replaced
0 atoms trimmed
0 atoms added
32000 atoms after read
run 0 post no
WARNING: No fixes defined, atoms won't move (../verlet.cpp:52)
Per MPI rank memory allocation (min/avg/max) = 6.841 | 6.843 | 6.846 Mbytes
Step Temp E_pair E_mol TotEng Press
600 0.72087256 -5.7029306 0 -4.6216556 0.55729873
Loop time of 7.7486e-07 on 4 procs for 0 steps with 32000 atoms
read_dump lj.dump 400 x y z vx vy vz
orthogonal box = (0 0 0) to (33.5919 33.5919 33.5919)
32000 atoms before read
32000 atoms in snapshot
0 atoms purged
32000 atoms replaced
0 atoms trimmed
0 atoms added
32000 atoms after read
run 0 post no
WARNING: No fixes defined, atoms won't move (../verlet.cpp:52)
Per MPI rank memory allocation (min/avg/max) = 6.841 | 6.843 | 6.846 Mbytes
Step Temp E_pair E_mol TotEng Press
400 0.74155677 -5.7343336 0 -4.6220332 0.37780193
Loop time of 5.36442e-07 on 4 procs for 0 steps with 32000 atoms
Total wall time: 0:00:00

86
examples/rerun/log.09Jan20.rerun.g++.4 Normal file
View File

@ -0,0 +1,86 @@
LAMMPS (09 Jan 2020)
# 3d Lennard-Jones melt
variable x index 1
variable y index 1
variable z index 1
variable xx equal 20*$x
variable xx equal 20*1
variable yy equal 20*$y
variable yy equal 20*1
variable zz equal 20*$z
variable zz equal 20*1
units lj
atom_style atomic
lattice fcc 0.8442
Lattice spacing in x,y,z = 1.6796 1.6796 1.6796
region box block 0 ${xx} 0 ${yy} 0 ${zz}
region box block 0 20 0 ${yy} 0 ${zz}
region box block 0 20 0 20 0 ${zz}
region box block 0 20 0 20 0 20
create_box 1 box
Created orthogonal box = (0 0 0) to (33.5919 33.5919 33.5919)
1 by 2 by 2 MPI processor grid
create_atoms 1 box
Created 32000 atoms
create_atoms CPU = 0.00100017 secs
mass 1 1.0
pair_style lj/cut 2.5
pair_coeff 1 1 1.0 1.0 2.5
neighbor 0.3 bin
thermo 100
rerun lj.dump first 200 last 800 every 200 dump x y z vx vy vz
WARNING: No fixes defined, atoms won't move (../verlet.cpp:52)
Neighbor list info ...
update every 1 steps, delay 10 steps, check yes
max neighbors/atom: 2000, page size: 100000
master list distance cutoff = 2.8
ghost atom cutoff = 2.8
binsize = 1.4, bins = 24 24 24
1 neighbor lists, perpetual/occasional/extra = 1 0 0
(1) pair lj/cut, 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) = 6.716 | 6.718 | 6.721 Mbytes
Step Temp E_pair E_mol TotEng Press
200 0.75953173 -5.7618854 0 -4.6226234 0.20912952
400 0.74155677 -5.7343336 0 -4.6220332 0.37780193
600 0.72087256 -5.7029306 0 -4.6216556 0.55729873
800 0.70876957 -5.6840545 0 -4.6209334 0.66823926
Loop time of 0.375898 on 4 procs for 4 steps with 32000 atoms
Performance: 4596.990 tau/day, 10.641 timesteps/s
98.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 | 0 | 0 | 0 | 0.0 | 0.00
Neigh | 0 | 0 | 0 | 0.0 | 0.00
Comm | 0 | 0 | 0 | 0.0 | 0.00
Output | 0 | 0 | 0 | 0.0 | 0.00
Modify | 0 | 0 | 0 | 0.0 | 0.00
Other | | 0.3759 | | |100.00
Nlocal: 8000 ave 8073 max 7933 min
Histogram: 1 0 1 0 0 0 1 0 0 1
Nghost: 8693.25 ave 8731 max 8658 min
Histogram: 1 1 0 0 0 0 0 0 1 1
Neighs: 299786 ave 302947 max 293888 min
Histogram: 1 0 0 0 0 0 0 1 1 1
Total # of neighbors = 1199142
Ave neighs/atom = 37.4732
Neighbor list builds = 0
Dangerous builds = 0
Total wall time: 0:00:00

54
examples/rerun/rdf.09Jan20.first.g++.4 Normal file
View File

@ -0,0 +1,54 @@
# Time-averaged data for fix 2
# TimeStep Number-of-rows
# Row c_myRDF[1] c_myRDF[2] c_myRDF[3]
1000 50
1 0.025 0 0
2 0.075 0 0
3 0.125 0 0
4 0.175 0 0
5 0.225 0 0
6 0.275 0 0
7 0.325 0 0
8 0.375 0 0
9 0.425 0 0
10 0.475 0 0
11 0.525 0 0
12 0.575 0 0
13 0.625 0 0
14 0.675 0 0
15 0.725 0 0
16 0.775 0 0
17 0.825 0 0
18 0.875 1.53863e-05 6.25e-06
19 0.925 0.0217263 0.00986875
20 0.975 0.506735 0.265431
21 1.025 1.92083 1.33605
22 1.075 2.8749 3.09855
23 1.125 2.7805 4.96541
24 1.175 2.21879 6.59047
25 1.225 1.67622 7.92484
26 1.275 1.25407 9.00629
27 1.325 0.963413 9.90353
28 1.375 0.774441 10.6802
29 1.425 0.656196 11.3871
30 1.475 0.589364 12.0672
31 1.525 0.560681 12.7589
32 1.575 0.560195 13.4961
33 1.625 0.587995 14.3197
34 1.675 0.632155 15.2605
35 1.725 0.706585 16.3758
36 1.775 0.805303 17.7216
37 1.825 0.925415 19.3565
38 1.875 1.05672 21.3271
39 1.925 1.17634 23.6394
40 1.975 1.2557 26.2375
41 2.025 1.30009 29.0653
42 2.075 1.30889 32.0546
43 2.125 1.27704 35.1135
44 2.175 1.21808 38.17
45 2.225 1.13622 41.1536
46 2.275 1.05072 44.0382
47 2.325 0.973786 46.8303
48 2.375 0.910095 49.5533
49 2.425 0.866474 52.256
50 2.475 0.841724 54.991

104
examples/rerun/rdf.09Jan20.rerun.g++.4 Normal file
View File

@ -0,0 +1,104 @@
# Time-averaged data for fix 2
# TimeStep Number-of-rows
# Row c_myRDF[1] c_myRDF[2] c_myRDF[3]
1000 100
1 0.025 0 0
2 0.075 0 0
3 0.125 0 0
4 0.175 0 0
5 0.225 0 0
6 0.275 0 0
7 0.325 0 0
8 0.375 0 0
9 0.425 0 0
10 0.475 0 0
11 0.525 0 0
12 0.575 0 0
13 0.625 0 0
14 0.675 0 0
15 0.725 0 0
16 0.775 0 0
17 0.825 0 0
18 0.875 1.53863e-05 6.25e-06
19 0.925 0.021685 0.00985
20 0.975 0.506834 0.265463
21 1.025 1.92047 1.33588
22 1.075 2.87514 3.09853
23 1.125 2.78062 4.96547
24 1.175 2.21869 6.59046
25 1.225 1.67626 7.92486
26 1.275 1.25409 9.00633
27 1.325 0.963245 9.90341
28 1.375 0.774535 10.6802
29 1.425 0.65626 11.3871
30 1.475 0.58925 12.0672
31 1.525 0.560782 12.759
32 1.575 0.560133 13.496
33 1.625 0.588008 14.3197
34 1.675 0.632185 15.2605
35 1.725 0.706541 16.3757
36 1.775 0.805341 17.7216
37 1.825 0.925351 19.3565
38 1.875 1.05677 21.3271
39 1.925 1.17639 23.6395
40 1.975 1.25571 26.2376
41 2.025 1.30011 29.0655
42 2.075 1.30883 32.0547
43 2.125 1.27702 35.1134
44 2.175 1.21813 38.17
45 2.225 1.13617 41.1536
46 2.275 1.05073 44.0382
47 2.325 0.97376 46.8302
48 2.375 0.91012 49.5533
49 2.425 0.866556 52.2563
50 2.475 0.841651 54.991
51 2.525 0.839516 57.8301
52 2.575 0.848795 60.8153
53 2.625 0.868861 63.991
54 2.675 0.896335 67.393
55 2.725 0.925794 71.0395
56 2.775 0.961909 74.9685
57 2.825 0.999727 79.2005
58 2.875 1.03745 83.749
59 2.925 1.07355 88.6208
60 2.975 1.10406 93.8039
61 3.025 1.11993 99.2397
62 3.075 1.12062 104.86
63 3.125 1.10531 110.586
64 3.175 1.07711 116.345
65 3.225 1.04268 122.097
66 3.275 1.00838 127.834
67 3.325 0.974855 133.55
68 3.375 0.949817 139.289
69 3.425 0.936519 145.116
70 3.475 0.92942 151.069
71 3.525 0.930926 157.205
72 3.575 0.940561 163.581
73 3.625 0.94956 170.199
74 3.675 0.964202 177.107
75 3.725 0.97905 184.312
76 3.775 0.991906 191.81
77 3.825 1.00093 199.577
78 3.875 1.01248 207.641
79 3.925 1.02301 216.001
80 3.975 1.03474 224.673
81 4.025 1.04171 233.624
82 4.075 1.04725 242.849
83 4.125 1.04997 252.325
84 4.175 1.04758 262.01
85 4.225 1.03985 271.856
86 4.275 1.02755 281.817
87 4.325 1.00883 291.826
88 4.375 0.99045 301.882
89 4.425 0.97287 311.986
90 4.475 0.958469 322.166
91 4.525 0.952552 332.512
92 4.575 0.948064 343.037
93 4.625 0.952592 353.845
94 4.675 0.958837 364.96
95 4.725 0.970831 376.457
96 4.775 0.985248 388.372
97 4.825 0.998873 400.707
98 4.875 1.0119 413.462
99 4.925 1.02446 426.643
100 4.975 1.03613 440.245

2
src/GPU/pair_beck_gpu.cpp
View File

@ -35,6 +35,7 @@
#include "domain.h"
#include "gpu_extra.h"
#include "math_special.h"
#include "suffix.h"
using namespace LAMMPS_NS;
using namespace MathSpecial;
@ -68,6 +69,7 @@ PairBeckGPU::PairBeckGPU(LAMMPS *lmp) : PairBeck(lmp), gpu_mode(GPU_FORCE)
respa_enable = 0;
reinitflag = 0;
cpu_time = 0.0;
suffix_flag |= Suffix::GPU;
GPU_EXTRA::gpu_ready(lmp->modify, lmp->error);
}

2
src/GPU/pair_born_coul_long_cs_gpu.cpp
View File

@ -36,6 +36,7 @@
#include "domain.h"
#include "kspace.h"
#include "gpu_extra.h"
#include "suffix.h"
using namespace LAMMPS_NS;
using namespace MathConst;
@ -90,6 +91,7 @@ PairBornCoulLongCSGPU::PairBornCoulLongCSGPU(LAMMPS *lmp) :
respa_enable = 0;
reinitflag = 0;
cpu_time = 0.0;
suffix_flag |= Suffix::GPU;
GPU_EXTRA::gpu_ready(lmp->modify, lmp->error);
}

2
src/GPU/pair_born_coul_long_gpu.cpp
View File

@ -36,6 +36,7 @@
#include "domain.h"
#include "kspace.h"
#include "gpu_extra.h"
#include "suffix.h"
#define EWALD_F 1.12837917
#define EWALD_P 0.3275911
@ -85,6 +86,7 @@ PairBornCoulLongGPU::PairBornCoulLongGPU(LAMMPS *lmp) :
respa_enable = 0;
reinitflag = 0;
cpu_time = 0.0;
suffix_flag |= Suffix::GPU;
GPU_EXTRA::gpu_ready(lmp->modify, lmp->error);
}

2
src/GPU/pair_born_coul_wolf_cs_gpu.cpp
View File

@ -35,6 +35,7 @@
#include "update.h"
#include "domain.h"
#include "gpu_extra.h"
#include "suffix.h"
using namespace LAMMPS_NS;
using namespace MathConst;
@ -78,6 +79,7 @@ PairBornCoulWolfCSGPU::PairBornCoulWolfCSGPU(LAMMPS *lmp) : PairBornCoulWolfCS(l
respa_enable = 0;
reinitflag = 0;
cpu_time = 0.0;
suffix_flag |= Suffix::GPU;
GPU_EXTRA::gpu_ready(lmp->modify, lmp->error);
}

2
src/GPU/pair_born_coul_wolf_gpu.cpp
View File

@ -35,6 +35,7 @@
#include "update.h"
#include "domain.h"
#include "gpu_extra.h"
#include "suffix.h"
using namespace LAMMPS_NS;
using namespace MathConst;
@ -76,6 +77,7 @@ PairBornCoulWolfGPU::PairBornCoulWolfGPU(LAMMPS *lmp) : PairBornCoulWolf(lmp),
respa_enable = 0;
reinitflag = 0;
cpu_time = 0.0;
suffix_flag |= Suffix::GPU;
GPU_EXTRA::gpu_ready(lmp->modify, lmp->error);
}

2
src/GPU/pair_born_gpu.cpp
View File

@ -34,6 +34,7 @@
#include "update.h"
#include "domain.h"
#include "gpu_extra.h"
#include "suffix.h"
using namespace LAMMPS_NS;
@ -71,6 +72,7 @@ PairBornGPU::PairBornGPU(LAMMPS *lmp) : PairBorn(lmp), gpu_mode(GPU_FORCE)
{
respa_enable = 0;
cpu_time = 0.0;
suffix_flag |= Suffix::GPU;
GPU_EXTRA::gpu_ready(lmp->modify, lmp->error);
}

2
src/GPU/pair_buck_coul_cut_gpu.cpp
View File

@ -34,6 +34,7 @@
#include "update.h"
#include "domain.h"
#include "gpu_extra.h"
#include "suffix.h"
using namespace LAMMPS_NS;
@ -72,6 +73,7 @@ PairBuckCoulCutGPU::PairBuckCoulCutGPU(LAMMPS *lmp) : PairBuckCoulCut(lmp),
respa_enable = 0;
reinitflag = 0;
cpu_time = 0.0;
suffix_flag |= Suffix::GPU;
GPU_EXTRA::gpu_ready(lmp->modify, lmp->error);
}

2
src/GPU/pair_buck_coul_long_gpu.cpp
View File

@ -35,6 +35,7 @@
#include "domain.h"
#include "kspace.h"
#include "gpu_extra.h"
#include "suffix.h"
#define EWALD_F 1.12837917
#define EWALD_P 0.3275911
@ -81,6 +82,7 @@ PairBuckCoulLongGPU::PairBuckCoulLongGPU(LAMMPS *lmp) :
respa_enable = 0;
reinitflag = 0;
cpu_time = 0.0;
suffix_flag |= Suffix::GPU;
GPU_EXTRA::gpu_ready(lmp->modify, lmp->error);
}

2
src/GPU/pair_buck_gpu.cpp
View File

@ -34,6 +34,7 @@
#include "update.h"
#include "domain.h"
#include "gpu_extra.h"
#include "suffix.h"
using namespace LAMMPS_NS;
@ -69,6 +70,7 @@ PairBuckGPU::PairBuckGPU(LAMMPS *lmp) : PairBuck(lmp), gpu_mode(GPU_FORCE)
{
respa_enable = 0;
cpu_time = 0.0;
suffix_flag |= Suffix::GPU;
GPU_EXTRA::gpu_ready(lmp->modify, lmp->error);
}

2
src/GPU/pair_colloid_gpu.cpp
View File

@ -34,6 +34,7 @@
#include "update.h"
#include "domain.h"
#include "gpu_extra.h"
#include "suffix.h"
using namespace LAMMPS_NS;
@ -69,6 +70,7 @@ PairColloidGPU::PairColloidGPU(LAMMPS *lmp) : PairColloid(lmp), gpu_mode(GPU_FOR
respa_enable = 0;
reinitflag = 0;
cpu_time = 0.0;
suffix_flag |= Suffix::GPU;
GPU_EXTRA::gpu_ready(lmp->modify, lmp->error);
}

2
src/GPU/pair_coul_cut_gpu.cpp
View File

@ -34,6 +34,7 @@
#include "update.h"
#include "domain.h"
#include "gpu_extra.h"
#include "suffix.h"
using namespace LAMMPS_NS;
@ -69,6 +70,7 @@ PairCoulCutGPU::PairCoulCutGPU(LAMMPS *lmp) : PairCoulCut(lmp), gpu_mode(GPU_FOR
{
respa_enable = 0;
cpu_time = 0.0;
suffix_flag |= Suffix::GPU;
GPU_EXTRA::gpu_ready(lmp->modify, lmp->error);
}

2
src/GPU/pair_coul_debye_gpu.cpp
View File

@ -34,6 +34,7 @@
#include "update.h"
#include "domain.h"
#include "gpu_extra.h"
#include "suffix.h"
using namespace LAMMPS_NS;
@ -70,6 +71,7 @@ PairCoulDebyeGPU::PairCoulDebyeGPU(LAMMPS *lmp) :
{
respa_enable = 0;
cpu_time = 0.0;
suffix_flag |= Suffix::GPU;
GPU_EXTRA::gpu_ready(lmp->modify, lmp->error);
}

2
src/GPU/pair_coul_dsf_gpu.cpp
View File

@ -34,6 +34,7 @@
#include "update.h"
#include "domain.h"
#include "gpu_extra.h"
#include "suffix.h"
#define MY_PIS 1.77245385090551602729
#define EWALD_F 1.12837917
@ -81,6 +82,7 @@ PairCoulDSFGPU::PairCoulDSFGPU(LAMMPS *lmp) : PairCoulDSF(lmp),
respa_enable = 0;
reinitflag = 0;
cpu_time = 0.0;
suffix_flag |= Suffix::GPU;
GPU_EXTRA::gpu_ready(lmp->modify, lmp->error);
}

2
src/GPU/pair_coul_long_cs_gpu.cpp
View File

@ -35,6 +35,7 @@
#include "domain.h"
#include "kspace.h"
#include "gpu_extra.h"
#include "suffix.h"
using namespace LAMMPS_NS;
@ -83,6 +84,7 @@ PairCoulLongCSGPU::PairCoulLongCSGPU(LAMMPS *lmp) :
{
respa_enable = 0;
cpu_time = 0.0;
suffix_flag |= Suffix::GPU;
GPU_EXTRA::gpu_ready(lmp->modify, lmp->error);
}

2
src/GPU/pair_coul_long_gpu.cpp
View File

@ -35,6 +35,7 @@
#include "domain.h"
#include "kspace.h"
#include "gpu_extra.h"
#include "suffix.h"
#define EWALD_F 1.12837917
#define EWALD_P 0.3275911
@ -78,6 +79,7 @@ PairCoulLongGPU::PairCoulLongGPU(LAMMPS *lmp) :
{
respa_enable = 0;
cpu_time = 0.0;
suffix_flag |= Suffix::GPU;
GPU_EXTRA::gpu_ready(lmp->modify, lmp->error);
}

2
src/GPU/pair_dpd_gpu.cpp
View File

@ -35,6 +35,7 @@
#include "update.h"
#include "domain.h"
#include "gpu_extra.h"
#include "suffix.h"
using namespace LAMMPS_NS;
@ -209,6 +210,7 @@ PairDPDGPU::PairDPDGPU(LAMMPS *lmp) : PairDPD(lmp), gpu_mode(GPU_FORCE)
respa_enable = 0;
reinitflag = 0;
cpu_time = 0.0;
suffix_flag |= Suffix::GPU;
GPU_EXTRA::gpu_ready(lmp->modify, lmp->error);
}

2
src/GPU/pair_dpd_tstat_gpu.cpp
View File

@ -35,6 +35,7 @@
#include "update.h"
#include "domain.h"
#include "gpu_extra.h"
#include "suffix.h"
using namespace LAMMPS_NS;
@ -212,6 +213,7 @@ PairDPDTstatGPU::PairDPDTstatGPU(LAMMPS *lmp) : PairDPDTstat(lmp),
respa_enable = 0;
reinitflag = 0;
cpu_time = 0.0;
suffix_flag |= Suffix::GPU;
GPU_EXTRA::gpu_ready(lmp->modify, lmp->error);
}

3
src/GPU/pair_eam_alloy_gpu.cpp
View File

@ -30,7 +30,7 @@
#include "gpu_extra.h"
#include "domain.h"
#include "utils.h"
#include "suffix.h"
using namespace LAMMPS_NS;
@ -72,6 +72,7 @@ PairEAMAlloyGPU::PairEAMAlloyGPU(LAMMPS *lmp) : PairEAM(lmp), gpu_mode(GPU_FORCE
respa_enable = 0;
reinitflag = 0;
cpu_time = 0.0;
suffix_flag |= Suffix::GPU;
GPU_EXTRA::gpu_ready(lmp->modify, lmp->error);
}

2
src/GPU/pair_eam_fs_gpu.cpp
View File

@ -29,6 +29,7 @@
#include "neigh_request.h"
#include "gpu_extra.h"
#include "domain.h"
#include "suffix.h"
using namespace LAMMPS_NS;
@ -70,6 +71,7 @@ PairEAMFSGPU::PairEAMFSGPU(LAMMPS *lmp) : PairEAM(lmp), gpu_mode(GPU_FORCE)
respa_enable = 0;
reinitflag = 0;
cpu_time = 0.0;
suffix_flag |= Suffix::GPU;
GPU_EXTRA::gpu_ready(lmp->modify, lmp->error);
}

2
src/GPU/pair_eam_gpu.cpp
View File

@ -30,6 +30,7 @@
#include "error.h"
#include "neigh_request.h"
#include "gpu_extra.h"
#include "suffix.h"
#define MAXLINE 1024
@ -71,6 +72,7 @@ PairEAMGPU::PairEAMGPU(LAMMPS *lmp) : PairEAM(lmp), gpu_mode(GPU_FORCE)
respa_enable = 0;
reinitflag = 0;
cpu_time = 0.0;
suffix_flag |= Suffix::GPU;
GPU_EXTRA::gpu_ready(lmp->modify, lmp->error);
}

2
src/GPU/pair_gauss_gpu.cpp
View File

@ -34,6 +34,7 @@
#include "update.h"
#include "domain.h"
#include "gpu_extra.h"
#include "suffix.h"
using namespace LAMMPS_NS;
@ -66,6 +67,7 @@ PairGaussGPU::PairGaussGPU(LAMMPS *lmp) : PairGauss(lmp), gpu_mode(GPU_FORCE)
{
respa_enable = 0;
cpu_time = 0.0;
suffix_flag |= Suffix::GPU;
GPU_EXTRA::gpu_ready(lmp->modify, lmp->error);
}

2
src/GPU/pair_gayberne_gpu.cpp
View File

@ -36,6 +36,7 @@
#include "domain.h"
#include "update.h"
#include "gpu_extra.h"
#include "suffix.h"
using namespace LAMMPS_NS;
@ -74,6 +75,7 @@ PairGayBerneGPU::PairGayBerneGPU(LAMMPS *lmp) : PairGayBerne(lmp),
quat_nmax = 0;
reinitflag = 0;
quat = NULL;
suffix_flag |= Suffix::GPU;
GPU_EXTRA::gpu_ready(lmp->modify, lmp->error);
}

2
src/GPU/pair_lj96_cut_gpu.cpp
View File

@ -34,6 +34,7 @@
#include "update.h"
#include "domain.h"
#include "gpu_extra.h"
#include "suffix.h"
using namespace LAMMPS_NS;
@ -66,6 +67,7 @@ PairLJ96CutGPU::PairLJ96CutGPU(LAMMPS *lmp) : PairLJ96Cut(lmp), gpu_mode(GPU_FOR
respa_enable = 0;
reinitflag = 0;
cpu_time = 0.0;
suffix_flag |= Suffix::GPU;
GPU_EXTRA::gpu_ready(lmp->modify, lmp->error);
}

2
src/GPU/pair_lj_charmm_coul_long_gpu.cpp
View File

@ -35,6 +35,7 @@
#include "domain.h"
#include "kspace.h"
#include "gpu_extra.h"
#include "suffix.h"
#define EWALD_F 1.12837917
#define EWALD_P 0.3275911
@ -83,6 +84,7 @@ PairLJCharmmCoulLongGPU::PairLJCharmmCoulLongGPU(LAMMPS *lmp) :
respa_enable = 0;
reinitflag = 0;
cpu_time = 0.0;
suffix_flag |= Suffix::GPU;
GPU_EXTRA::gpu_ready(lmp->modify, lmp->error);
}

2
src/GPU/pair_lj_class2_coul_long_gpu.cpp
View File

@ -35,6 +35,7 @@
#include "domain.h"
#include "kspace.h"
#include "gpu_extra.h"
#include "suffix.h"
#define EWALD_F 1.12837917
#define EWALD_P 0.3275911
@ -80,6 +81,7 @@ PairLJClass2CoulLongGPU::PairLJClass2CoulLongGPU(LAMMPS *lmp) :
{
cpu_time = 0.0;
reinitflag = 0;
suffix_flag |= Suffix::GPU;
GPU_EXTRA::gpu_ready(lmp->modify, lmp->error);
}

2
src/GPU/pair_lj_class2_gpu.cpp
View File

@ -34,6 +34,7 @@
#include "update.h"
#include "domain.h"
#include "gpu_extra.h"
#include "suffix.h"
using namespace LAMMPS_NS;
@ -65,6 +66,7 @@ PairLJClass2GPU::PairLJClass2GPU(LAMMPS *lmp) : PairLJClass2(lmp), gpu_mode(GPU_
{
reinitflag = 0;
cpu_time = 0.0;
suffix_flag |= Suffix::GPU;
GPU_EXTRA::gpu_ready(lmp->modify, lmp->error);
}

2
src/GPU/pair_lj_cubic_gpu.cpp
View File

@ -34,6 +34,7 @@
#include "update.h"
#include "domain.h"
#include "gpu_extra.h"
#include "suffix.h"
using namespace LAMMPS_NS;
using namespace PairLJCubicConstants;
@ -70,6 +71,7 @@ PairLJCubicGPU::PairLJCubicGPU(LAMMPS *lmp) : PairLJCubic(lmp),
respa_enable = 0;
cpu_time = 0.0;
reinitflag = 0;
suffix_flag |= Suffix::GPU;
GPU_EXTRA::gpu_ready(lmp->modify, lmp->error);
}

2
src/GPU/pair_lj_cut_coul_cut_gpu.cpp
View File

@ -34,6 +34,7 @@
#include "update.h"
#include "domain.h"
#include "gpu_extra.h"
#include "suffix.h"
using namespace LAMMPS_NS;
@ -71,6 +72,7 @@ PairLJCutCoulCutGPU::PairLJCutCoulCutGPU(LAMMPS *lmp) : PairLJCutCoulCut(lmp), g
respa_enable = 0;
reinitflag = 0;
cpu_time = 0.0;
suffix_flag |= Suffix::GPU;
GPU_EXTRA::gpu_ready(lmp->modify, lmp->error);
}

2
src/GPU/pair_lj_cut_coul_debye_gpu.cpp
View File

@ -34,6 +34,7 @@
#include "update.h"
#include "domain.h"
#include "gpu_extra.h"
#include "suffix.h"
using namespace LAMMPS_NS;
@ -73,6 +74,7 @@ PairLJCutCoulDebyeGPU::PairLJCutCoulDebyeGPU(LAMMPS *lmp) :
respa_enable = 0;
reinitflag = 0;
cpu_time = 0.0;
suffix_flag |= Suffix::GPU;
GPU_EXTRA::gpu_ready(lmp->modify, lmp->error);
}

2
src/GPU/pair_lj_cut_coul_dsf_gpu.cpp
View File

@ -34,6 +34,7 @@
#include "update.h"
#include "domain.h"
#include "gpu_extra.h"
#include "suffix.h"
#define MY_PIS 1.77245385090551602729
#define EWALD_F 1.12837917
@ -82,6 +83,7 @@ PairLJCutCoulDSFGPU::PairLJCutCoulDSFGPU(LAMMPS *lmp) : PairLJCutCoulDSF(lmp), g
respa_enable = 0;
reinitflag = 0;
cpu_time = 0.0;
suffix_flag |= Suffix::GPU;
GPU_EXTRA::gpu_ready(lmp->modify, lmp->error);
}

2
src/GPU/pair_lj_cut_coul_long_gpu.cpp
View File

@ -35,6 +35,7 @@
#include "domain.h"
#include "kspace.h"
#include "gpu_extra.h"
#include "suffix.h"
#define EWALD_F 1.12837917
#define EWALD_P 0.3275911
@ -83,6 +84,7 @@ PairLJCutCoulLongGPU::PairLJCutCoulLongGPU(LAMMPS *lmp) :
{
respa_enable = 0;
cpu_time = 0.0;
suffix_flag |= Suffix::GPU;
GPU_EXTRA::gpu_ready(lmp->modify, lmp->error);
}

2
src/GPU/pair_lj_cut_coul_msm_gpu.cpp
View File

@ -35,6 +35,7 @@
#include "domain.h"
#include "kspace.h"
#include "gpu_extra.h"
#include "suffix.h"
using namespace LAMMPS_NS;
@ -72,6 +73,7 @@ PairLJCutCoulMSMGPU::PairLJCutCoulMSMGPU(LAMMPS *lmp) :
respa_enable = 0;
reinitflag = 0;
cpu_time = 0.0;
suffix_flag |= Suffix::GPU;
GPU_EXTRA::gpu_ready(lmp->modify, lmp->error);
}

2
src/GPU/pair_lj_cut_dipole_cut_gpu.cpp
View File

@ -34,6 +34,7 @@
#include "update.h"
#include "domain.h"
#include "gpu_extra.h"
#include "suffix.h"
using namespace LAMMPS_NS;
@ -73,6 +74,7 @@ PairLJCutDipoleCutGPU::PairLJCutDipoleCutGPU(LAMMPS *lmp) : PairLJCutDipoleCut(l
respa_enable = 0;
reinitflag = 0;
cpu_time = 0.0;
suffix_flag |= Suffix::GPU;
GPU_EXTRA::gpu_ready(lmp->modify, lmp->error);
}

2
src/GPU/pair_lj_cut_dipole_long_gpu.cpp
View File

@ -36,6 +36,7 @@
#include "update.h"
#include "domain.h"
#include "gpu_extra.h"
#include "suffix.h"
#define EWALD_F 1.12837917
#define EWALD_P 0.3275911
@ -84,6 +85,7 @@ PairLJCutDipoleLongGPU::PairLJCutDipoleLongGPU(LAMMPS *lmp) : PairLJCutDipoleLon
respa_enable = 0;
reinitflag = 0;
cpu_time = 0.0;
suffix_flag |= Suffix::GPU;
GPU_EXTRA::gpu_ready(lmp->modify, lmp->error);
}

2
src/GPU/pair_lj_cut_gpu.cpp
View File

@ -34,6 +34,7 @@
#include "update.h"
#include "domain.h"
#include "gpu_extra.h"
#include "suffix.h"
using namespace LAMMPS_NS;
@ -70,6 +71,7 @@ PairLJCutGPU::PairLJCutGPU(LAMMPS *lmp) : PairLJCut(lmp), gpu_mode(GPU_FORCE)
{
respa_enable = 0;
cpu_time = 0.0;
suffix_flag |= Suffix::GPU;
GPU_EXTRA::gpu_ready(lmp->modify, lmp->error);
}

2
src/GPU/pair_lj_cut_tip4p_long_gpu.cpp
View File

@ -37,6 +37,7 @@
#include "angle.h"
#include "bond.h"
#include "gpu_extra.h"
#include "suffix.h"
#define EWALD_F 1.12837917
#define EWALD_P 0.3275911
@ -91,6 +92,7 @@ PairLJCutTIP4PLongGPU::PairLJCutTIP4PLongGPU(LAMMPS *lmp)
respa_enable = 0;
reinitflag = 0;
cpu_time = 0.0;
suffix_flag |= Suffix::GPU;
GPU_EXTRA::gpu_ready(lmp->modify, lmp->error);
}

2
src/GPU/pair_lj_expand_coul_long_gpu.cpp
View File

@ -35,6 +35,7 @@
#include "domain.h"
#include "kspace.h"
#include "gpu_extra.h"
#include "suffix.h"
#define EWALD_F 1.12837917
#define EWALD_P 0.3275911
@ -83,6 +84,7 @@ PairLJExpandCoulLongGPU::PairLJExpandCoulLongGPU(LAMMPS *lmp) :
{
respa_enable = 0;
cpu_time = 0.0;
suffix_flag |= Suffix::GPU;
GPU_EXTRA::gpu_ready(lmp->modify, lmp->error);
}

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