Compare commits
230 Commits
patch_24Ma
...
patch_19Ma
| Author | SHA1 | Date | |
|---|---|---|---|
| 2225fce94e | |||
| 941b737319 | |||
| 654e09e999 | |||
| 8751850eca | |||
| 0f88348917 | |||
| b28ecd44c2 | |||
| 9db9fc9de3 | |||
| 6ac9b7a1b0 | |||
| 34dbf6b225 | |||
| 26d71b66e4 | |||
| 65eacb6b90 | |||
| cb3344a337 | |||
| 5d38cbbce9 | |||
| 30babd8157 | |||
| aa09f45b7e | |||
| 4b61cf6f52 | |||
| 683f3d9d2a | |||
| ce18524251 | |||
| 95dae9737b | |||
| 4b1914aa1f | |||
| bd11479a16 | |||
| 0208fe9996 | |||
| 24654ad28f | |||
| 8d46aa6056 | |||
| 09f3b687f7 | |||
| 436d3fd761 | |||
| 9833f38499 | |||
| 9725708b90 | |||
| 67962b15fc | |||
| 1d48f287f0 | |||
| 43efe9e417 | |||
| 278b9f7fba | |||
| 085f3afdfb | |||
| 45becfb235 | |||
| a34c935e20 | |||
| 13e16dc3f1 | |||
| 96f0a82aa5 | |||
| 7caf6cf459 | |||
| 8936b99e9f | |||
| d2810f9f83 | |||
| 597f95fb1b | |||
| 7f9a331c73 | |||
| 35e92733e9 | |||
| c11e87618b | |||
| ca87e57129 | |||
| 66084ad1f4 | |||
| d807ba1974 | |||
| 51fc386e72 | |||
| a6f0d700f1 | |||
| 14f3deed6b | |||
| d66a696a84 | |||
| 69ccbd1562 | |||
| d9d4ef17c8 | |||
| 93cc6f4a5d | |||
| 0a40a7af7b | |||
| eb6f6a77e5 | |||
| fb7164a811 | |||
| 64cf52d3b5 | |||
| 6a1f7e61f2 | |||
| d662f5d429 | |||
| df55a90ef6 | |||
| 6e113c1eaf | |||
| f484ab6dfb | |||
| 86283c6309 | |||
| 34cc3946b8 | |||
| 6aa0250bc5 | |||
| c5db3ff401 | |||
| 06c151421c | |||
| 0008b6fc2d | |||
| b6a70ec6fd | |||
| c4d0f07093 | |||
| 93f6033061 | |||
| 110bb79b14 | |||
| d84f8898b7 | |||
| 27a6371f9b | |||
| 7c3b8e014c | |||
| a069d21621 | |||
| d7f54464c6 | |||
| 998eb44e83 | |||
| 96d1de8575 | |||
| deff6ffaac | |||
| 328ef873d8 | |||
| 4ecf876a64 | |||
| c4ac5773cb | |||
| cac1bf83ef | |||
| abeb1e096a | |||
| 9f7ce39f9f | |||
| 29ae8d4ca3 | |||
| 3f4aee1046 | |||
| d0da0639f0 | |||
| 390ceb1475 | |||
| 6c5edf6c70 | |||
| 9cd994f57c | |||
| a6e2d5b5f7 | |||
| 08ec55743e | |||
| c4f90b3841 | |||
| f8af7edf92 | |||
| a73402ad93 | |||
| d7dbff0f54 | |||
| 42531389df | |||
| f7230006fe | |||
| 754b40cb31 | |||
| ffdc8b556d | |||
| 5accce976a | |||
| 349c1443a1 | |||
| 2f71245d82 | |||
| 51c6d50268 | |||
| 6499cfcf52 | |||
| f08e206991 | |||
| fbddfe2729 | |||
| dcc5472cba | |||
| addd87c0f7 | |||
| 480727815a | |||
| 45187a0fc7 | |||
| 7409c6d781 | |||
| 11cb0212b7 | |||
| 7f49ee8fd7 | |||
| f5cf1f1314 | |||
| 50c7234f26 | |||
| f58fc9488f | |||
| 408cc19885 | |||
| c76d27373e | |||
| fb08dc09f3 | |||
| 8bddf105bf | |||
| 31446e35b9 | |||
| 9bdc43bb66 | |||
| a0b61d17b5 | |||
| 8cc8441367 | |||
| 7d9670bc6c | |||
| b8cb80b219 | |||
| cd435c0c58 | |||
| 548c589f82 | |||
| 5c7a631988 | |||
| af74874516 | |||
| 949d61e01e | |||
| 3e60f79f1d | |||
| 8f9cb3590a | |||
| 0565b1df5f | |||
| d73d70fa1f | |||
| cc6104aeaf | |||
| 8910ec6e59 | |||
| ddc1e4e86e | |||
| 2e1f8b4aef | |||
| 958f05a6f3 | |||
| 0ac22e034c | |||
| 197ce4580b | |||
| 8f14511831 | |||
| 396e0b5423 | |||
| 4e411364ff | |||
| f0681f7e12 | |||
| dfa9815246 | |||
| 25e8ed63a2 | |||
| 8d390100e0 | |||
| dee3536144 | |||
| 73c210b665 | |||
| 4bad52f30c | |||
| 481927ff16 | |||
| dec36e9bfe | |||
| dd90c860ee | |||
| c9bc141335 | |||
| 3cbf4f3b58 | |||
| 6c2dd7ebb1 | |||
| d3187b22c4 | |||
| 2f32fb7f8b | |||
| e6f30ebc9c | |||
| cb867ea91d | |||
| 961096f9df | |||
| 3fa9f0a27b | |||
| 05d7bc556f | |||
| 2d8bce78a6 | |||
| 9a027a01da | |||
| 4da8c1c4e2 | |||
| 49dd9449b8 | |||
| 76fd936972 | |||
| 06cebb9fb4 | |||
| b9d844ca8d | |||
| ccc9367de7 | |||
| 4c4a3fe5d1 | |||
| 84ea8a79e6 | |||
| 3d3d1061d3 | |||
| b9177fd6dc | |||
| 8051b12ffc | |||
| f19f558220 | |||
| 1ad7d856fe | |||
| d6357420ae | |||
| 62b9fa22b8 | |||
| 1725832b6c | |||
| 874944f2ec | |||
| 497a5d88af | |||
| 8993daaa31 | |||
| e190eb15f5 | |||
| b6bc33bac6 | |||
| 03a6f5237f | |||
| 28e86917a0 | |||
| 6f1bbd3cec | |||
| ae56b9ad89 | |||
| 4466d9fb4a | |||
| ac1aa9edea | |||
| c733204a70 | |||
| 1544b51dcb | |||
| 4b9d0a9566 | |||
| 0637f23875 | |||
| 9f6e126a2f | |||
| 645f56cf70 | |||
| 80e5111dca | |||
| 7e9f05b617 | |||
| 1d8f0c762d | |||
| ef6070cbde | |||
| 61f3ff1d2b | |||
| 111d350a22 | |||
| 1dfd61f532 | |||
| 5c1f5462e7 | |||
| 66a6375405 | |||
| 604afebf6f | |||
| 8afed61db1 | |||
| ee55a98103 | |||
| f8da9a866a | |||
| 28bdebd3c0 | |||
| fc51c38abb | |||
| 443ea13eff | |||
| 5feeb79c13 | |||
| a241b2d0f7 | |||
| 61e7595a94 | |||
| da9096750e | |||
| 87ea9ba661 | |||
| c041727e4f | |||
| 3feffbe1de | |||
| 04fd038d35 | |||
| af0b5b0e84 | |||
| 7435084375 |
@ -158,7 +158,7 @@ $(VENV):
|
||||
@( \
|
||||
virtualenv -p $(PYTHON) $(VENV); \
|
||||
. $(VENV)/bin/activate; \
|
||||
pip install Sphinx; \
|
||||
pip install Sphinx==1.5.6; \
|
||||
pip install sphinxcontrib-images; \
|
||||
deactivate;\
|
||||
)
|
||||
|
||||
BIN
doc/src/Eqs/fix_gcmc1.jpg
Normal file
BIN
doc/src/Eqs/fix_gcmc1.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 5.5 KiB |
9
doc/src/Eqs/fix_gcmc1.tex
Normal file
9
doc/src/Eqs/fix_gcmc1.tex
Normal file
@ -0,0 +1,9 @@
|
||||
\documentclass[12pt]{article}
|
||||
|
||||
\begin{document}
|
||||
|
||||
\begin{eqnarray*}
|
||||
\mu &=&\mu^{id} + \mu^{ex}
|
||||
\end{eqnarray*}
|
||||
|
||||
\end{document}
|
||||
BIN
doc/src/Eqs/fix_gcmc2.jpg
Normal file
BIN
doc/src/Eqs/fix_gcmc2.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 10 KiB |
10
doc/src/Eqs/fix_gcmc2.tex
Normal file
10
doc/src/Eqs/fix_gcmc2.tex
Normal file
@ -0,0 +1,10 @@
|
||||
\documentclass[12pt]{article}
|
||||
|
||||
\begin{document}
|
||||
|
||||
\begin{eqnarray*}
|
||||
\mu^{id} &=& k T \ln{\rho \Lambda^3} \\
|
||||
&=& k T \ln{\frac{\phi P \Lambda^3}{k T}}
|
||||
\end{eqnarray*}
|
||||
|
||||
\end{document}
|
||||
BIN
doc/src/Eqs/fix_gcmc3.jpg
Normal file
BIN
doc/src/Eqs/fix_gcmc3.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 7.3 KiB |
9
doc/src/Eqs/fix_gcmc3.tex
Normal file
9
doc/src/Eqs/fix_gcmc3.tex
Normal file
@ -0,0 +1,9 @@
|
||||
\documentclass[12pt]{article}
|
||||
|
||||
\begin{document}
|
||||
|
||||
\begin{eqnarray*}
|
||||
\Lambda &=& \sqrt{ \frac{h^2}{2 \pi m k T}}
|
||||
\end{eqnarray*}
|
||||
|
||||
\end{document}
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 10 KiB After Width: | Height: | Size: 21 KiB |
@ -1,13 +1,14 @@
|
||||
\documentclass[12pt]{article}
|
||||
\usepackage{amsmath}
|
||||
|
||||
\begin{document}
|
||||
|
||||
$$
|
||||
E=\sum_{ij}\phi(r_{ij})+\sum_{i}U(\rho_{i}),
|
||||
E=\sum_{i<j}\phi(r_{ij})+\sum_{i}U(n_{i}),
|
||||
$$
|
||||
|
||||
$$
|
||||
\rho_{i}=\sum_{j}\rho(r_{ij})+\sum_{jk}f(r_{ij})f(r_{ik})g[\cos(\theta_{jik})]
|
||||
n_{i}=\sum_{j}\rho(r_{ij})+\sum_{\substack{j<k,\\j,k\neq i}}f(r_{ij})f(r_{ik})g[\cos(\theta_{jik})]
|
||||
$$
|
||||
|
||||
\end{document}
|
||||
|
||||
BIN
doc/src/Eqs/pair_meam_spline_multicomponent.jpg
Normal file
BIN
doc/src/Eqs/pair_meam_spline_multicomponent.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 22 KiB |
14
doc/src/Eqs/pair_meam_spline_multicomponent.tex
Normal file
14
doc/src/Eqs/pair_meam_spline_multicomponent.tex
Normal file
@ -0,0 +1,14 @@
|
||||
\documentclass[12pt]{article}
|
||||
\usepackage{amsmath}
|
||||
|
||||
\begin{document}
|
||||
|
||||
$$
|
||||
E=\sum_{i<j}\phi_{ij}(r_{ij})+\sum_{i}U_i(n_{i}),
|
||||
$$
|
||||
|
||||
$$
|
||||
n_{i}=\sum_{j\ne i}\rho_j(r_{ij})+\sum_{\substack{j<k,\\j,k\neq i}}f_{j}(r_{ij})f_{k}(r_{ik})g_{jk}[\cos(\theta_{jik})]
|
||||
$$
|
||||
|
||||
\end{document}
|
||||
@ -1,7 +1,7 @@
|
||||
<!-- HTML_ONLY -->
|
||||
<HEAD>
|
||||
<TITLE>LAMMPS Users Manual</TITLE>
|
||||
<META NAME="docnumber" CONTENT="24 Mar 2017 version">
|
||||
<META NAME="docnumber" CONTENT="19 May 2017 version">
|
||||
<META NAME="author" CONTENT="http://lammps.sandia.gov - Sandia National Laboratories">
|
||||
<META NAME="copyright" CONTENT="Copyright (2003) Sandia Corporation. This software and manual is distributed under the GNU General Public License.">
|
||||
</HEAD>
|
||||
@ -21,7 +21,7 @@
|
||||
<H1></H1>
|
||||
|
||||
LAMMPS Documentation :c,h3
|
||||
24 Mar 2017 version :c,h4
|
||||
19 May 2017 version :c,h4
|
||||
|
||||
Version info: :h4
|
||||
|
||||
@ -158,12 +158,11 @@ END_RST -->
|
||||
2.1 "What's in the LAMMPS distribution"_start_1 :ulb,b
|
||||
2.2 "Making LAMMPS"_start_2 :b
|
||||
2.3 "Making LAMMPS with optional packages"_start_3 :b
|
||||
2.4 "Building LAMMPS via the Make.py script"_start_4 :b
|
||||
2.5 "Building LAMMPS as a library"_start_5 :b
|
||||
2.6 "Running LAMMPS"_start_6 :b
|
||||
2.7 "Command-line options"_start_7 :b
|
||||
2.8 "Screen output"_start_8 :b
|
||||
2.9 "Tips for users of previous versions"_start_9 :ule,b
|
||||
2.4 "Building LAMMPS as a library"_start_4 :b
|
||||
2.5 "Running LAMMPS"_start_5 :b
|
||||
2.6 "Command-line options"_start_6 :b
|
||||
2.7 "Screen output"_start_7 :b
|
||||
2.8 "Tips for users of previous versions"_start_8 :ule,b
|
||||
"Commands"_Section_commands.html :l
|
||||
3.1 "LAMMPS input script"_cmd_1 :ulb,b
|
||||
3.2 "Parsing rules"_cmd_2 :b
|
||||
|
||||
Binary file not shown.
@ -527,9 +527,9 @@ These are additional commands in USER packages, which can be used if
|
||||
"LAMMPS is built with the appropriate
|
||||
package"_Section_start.html#start_3.
|
||||
|
||||
"dump custom/vtk"_dump_custom_vtk.html,
|
||||
"dump nc"_dump_nc.html,
|
||||
"dump nc/mpiio"_dump_nc.html,
|
||||
"dump netcdf"_dump_netcdf.html,
|
||||
"dump netcdf/mpiio"_dump_netcdf.html,
|
||||
"dump vtk"_dump_vtk.html,
|
||||
"group2ndx"_group2ndx.html,
|
||||
"ndx2group"_group2ndx.html,
|
||||
"temper/grem"_temper_grem.html :tb(c=3,ea=c)
|
||||
@ -618,6 +618,7 @@ USER-INTEL, k = KOKKOS, o = USER-OMP, t = OPT.
|
||||
"press/berendsen"_fix_press_berendsen.html,
|
||||
"print"_fix_print.html,
|
||||
"property/atom"_fix_property_atom.html,
|
||||
"python"_fix_python.html,
|
||||
"qeq/comb (o)"_fix_qeq_comb.html,
|
||||
"qeq/dynamic"_fix_qeq.html,
|
||||
"qeq/fire"_fix_qeq.html,
|
||||
@ -931,6 +932,8 @@ KOKKOS, o = USER-OMP, t = OPT.
|
||||
"gran/hertz/history (o)"_pair_gran.html,
|
||||
"gran/hooke (o)"_pair_gran.html,
|
||||
"gran/hooke/history (o)"_pair_gran.html,
|
||||
"gw"_pair_gw.html,
|
||||
"gw/zbl"_pair_gw.html,
|
||||
"hbond/dreiding/lj (o)"_pair_hbond_dreiding.html,
|
||||
"hbond/dreiding/morse (o)"_pair_hbond_dreiding.html,
|
||||
"kim"_pair_kim.html,
|
||||
@ -982,6 +985,7 @@ KOKKOS, o = USER-OMP, t = OPT.
|
||||
"peri/pmb (o)"_pair_peri.html,
|
||||
"peri/ves"_pair_peri.html,
|
||||
"polymorphic"_pair_polymorphic.html,
|
||||
"python"_pair_python.html,
|
||||
"reax"_pair_reax.html,
|
||||
"rebo (o)"_pair_airebo.html,
|
||||
"resquared (go)"_pair_resquared.html,
|
||||
@ -1016,6 +1020,7 @@ package"_Section_start.html#start_3.
|
||||
"dpd/fdt/energy"_pair_dpd_fdt.html,
|
||||
"eam/cd (o)"_pair_eam.html,
|
||||
"edip (o)"_pair_edip.html,
|
||||
"edip/multi"_pair_edip.html,
|
||||
"eff/cut"_pair_eff.html,
|
||||
"exp6/rx"_pair_exp6_rx.html,
|
||||
"gauss/cut"_pair_gauss.html,
|
||||
@ -1047,8 +1052,12 @@ package"_Section_start.html#start_3.
|
||||
"oxdna/hbond"_pair_oxdna.html,
|
||||
"oxdna/stk"_pair_oxdna.html,
|
||||
"oxdna/xstk"_pair_oxdna.html,
|
||||
"oxdna2/coaxstk"_pair_oxdna2.html,
|
||||
"oxdna2/dh"_pair_oxdna2.html,
|
||||
"oxdna2/excv"_pair_oxdna2.html,
|
||||
"oxdna2/stk"_pair_oxdna2.html,
|
||||
"quip"_pair_quip.html,
|
||||
"reax/c (k)"_pair_reax_c.html,
|
||||
"reax/c (k)"_pair_reaxc.html,
|
||||
"smd/hertz"_pair_smd_hertz.html,
|
||||
"smd/tlsph"_pair_smd_tlsph.html,
|
||||
"smd/triangulated/surface"_pair_smd_triangulated_surface.html,
|
||||
@ -1096,7 +1105,8 @@ package"_Section_start.html#start_3.
|
||||
|
||||
"harmonic/shift (o)"_bond_harmonic_shift.html,
|
||||
"harmonic/shift/cut (o)"_bond_harmonic_shift_cut.html,
|
||||
"oxdna/fene"_bond_oxdna.html :tb(c=4,ea=c)
|
||||
"oxdna/fene"_bond_oxdna.html,
|
||||
"oxdna2/fene"_bond_oxdna.html :tb(c=4,ea=c)
|
||||
|
||||
:line
|
||||
|
||||
@ -1150,7 +1160,7 @@ USER-OMP, t = OPT.
|
||||
"zero"_dihedral_zero.html,
|
||||
"hybrid"_dihedral_hybrid.html,
|
||||
"charmm (ko)"_dihedral_charmm.html,
|
||||
"charmmfsh"_dihedral_charmm.html,
|
||||
"charmmfsw"_dihedral_charmm.html,
|
||||
"class2 (ko)"_dihedral_class2.html,
|
||||
"harmonic (io)"_dihedral_harmonic.html,
|
||||
"helix (o)"_dihedral_helix.html,
|
||||
|
||||
@ -11171,6 +11171,12 @@ Self-explanatory. :dd
|
||||
If the fix changes the timestep, the dump dcd file will not
|
||||
reflect the change. :dd
|
||||
|
||||
{Energy due to X extra global DOFs will be included in minimizer energies} :dt
|
||||
|
||||
When using fixes like box/relax, the potential energy used by the minimizer
|
||||
is augmented by an additional energy provided by the fix. Thus the printed
|
||||
converged energy may be different from the total potential energy. :dd
|
||||
|
||||
{Energy tally does not account for 'zero yes'} :dt
|
||||
|
||||
The energy removed by using the 'zero yes' flag is not accounted
|
||||
|
||||
@ -215,7 +215,7 @@ documentation for the formula it computes.
|
||||
"special_bonds"_special_bonds.html charmm
|
||||
"special_bonds"_special_bonds.html amber :ul
|
||||
|
||||
NOTE: For CHARMM, the newer {charmmfsw} or {charmmfsh} styles were
|
||||
NOTE: For CHARMM, newer {charmmfsw} or {charmmfsh} styles were
|
||||
released in March 2017. We recommend they be used instead of the
|
||||
older {charmm} styles. See discussion of the differences on the "pair
|
||||
charmm"_pair_charmm.html and "dihedral charmm"_dihedral_charmm.html
|
||||
@ -759,23 +759,14 @@ LAMMPS itself does not do visualization, but snapshots from LAMMPS
|
||||
simulations can be visualized (and analyzed) in a variety of ways.
|
||||
|
||||
LAMMPS snapshots are created by the "dump"_dump.html command which can
|
||||
create files in several formats. The native LAMMPS dump format is a
|
||||
create files in several formats. The native LAMMPS dump format is a
|
||||
text file (see "dump atom" or "dump custom") which can be visualized
|
||||
by the "xmovie"_Section_tools.html#xmovie program, included with the
|
||||
LAMMPS package. This produces simple, fast 2d projections of 3d
|
||||
systems, and can be useful for rapid debugging of simulation geometry
|
||||
and atom trajectories.
|
||||
|
||||
by several popular visualization tools. The "dump image"_dump_image.html
|
||||
and "dump movie"_dump_image.html styles can output internally rendered
|
||||
images and convert a sequence of them to a movie during the MD run.
|
||||
Several programs included with LAMMPS as auxiliary tools can convert
|
||||
native LAMMPS dump files to other formats. See the
|
||||
"Section 9"_Section_tools.html doc page for details. The first is
|
||||
the "ch2lmp tool"_Section_tools.html#charmm, which contains a
|
||||
lammps2pdb Perl script which converts LAMMPS dump files into PDB
|
||||
files. The second is the "lmp2arc tool"_Section_tools.html#arc which
|
||||
converts LAMMPS dump files into Accelrys' Insight MD program files.
|
||||
The third is the "lmp2cfg tool"_Section_tools.html#cfg which converts
|
||||
LAMMPS dump files into CFG files which can be read into the
|
||||
"AtomEye"_atomeye visualizer.
|
||||
between LAMMPS format files and other formats.
|
||||
See the "Section 9"_Section_tools.html doc page for details.
|
||||
|
||||
A Python-based toolkit distributed by our group can read native LAMMPS
|
||||
dump files, including custom dump files with additional columns of
|
||||
@ -788,22 +779,7 @@ RasMol visualization programs. Pizza.py has tools that do interactive
|
||||
3d OpenGL visualization and one that creates SVG images of dump file
|
||||
snapshots.
|
||||
|
||||
LAMMPS can create XYZ files directly (via "dump xyz") which is a
|
||||
simple text-based file format used by many visualization programs
|
||||
including "VMD"_vmd.
|
||||
|
||||
LAMMPS can create DCD files directly (via "dump dcd") which can be
|
||||
read by "VMD"_vmd in conjunction with a CHARMM PSF file. Using this
|
||||
form of output avoids the need to convert LAMMPS snapshots to PDB
|
||||
files. See the "dump"_dump.html command for more information on DCD
|
||||
files.
|
||||
|
||||
LAMMPS can create XTC files directly (via "dump xtc") which is GROMACS
|
||||
file format which can also be read by "VMD"_vmd for visualization.
|
||||
See the "dump"_dump.html command for more information on XTC files.
|
||||
|
||||
:link(pizza,http://www.sandia.gov/~sjplimp/pizza.html)
|
||||
:link(vmd,http://www.ks.uiuc.edu/Research/vmd)
|
||||
:link(ensight,http://www.ensight.com)
|
||||
:link(atomeye,http://mt.seas.upenn.edu/Archive/Graphics/A)
|
||||
|
||||
@ -1710,7 +1686,7 @@ nph) and Berendsen:
|
||||
The "fix npt"_fix_nh.html commands include a Nose-Hoover thermostat
|
||||
and barostat. "Fix nph"_fix_nh.html is just a Nose/Hoover barostat;
|
||||
it does no thermostatting. Both "fix nph"_fix_nh.html and "fix
|
||||
press/bernendsen"_fix_press_berendsen.html can be used in conjunction
|
||||
press/berendsen"_fix_press_berendsen.html can be used in conjunction
|
||||
with any of the thermostatting fixes.
|
||||
|
||||
As with the thermostats, "fix npt"_fix_nh.html and "fix
|
||||
@ -2013,6 +1989,11 @@ Both methods are thus a means to extract or assign (overwrite) any
|
||||
peratom quantities within LAMMPS. See the extract() method in the
|
||||
src/atom.cpp file for a list of valid per-atom properties. New names
|
||||
could easily be added if the property you want is not listed.
|
||||
A special treatment is applied for accessing image flags via the
|
||||
"image" property. Image flags are stored in a packed format with all
|
||||
three image flags stored in a single integer. When signaling to access
|
||||
the image flags as 3 individual values per atom instead of 1, the data
|
||||
is transparently packed or unpacked by the library interface.
|
||||
|
||||
The lammps_create_atoms() function takes a list of N atoms as input
|
||||
with atom types and coords (required), an optionally atom IDs and
|
||||
|
||||
@ -249,8 +249,12 @@ Pizza.py WWW site"_pizza. :l
|
||||
|
||||
Specialized features :h5
|
||||
|
||||
These are LAMMPS capabilities which you may not think of as typical
|
||||
molecular dynamics options:
|
||||
LAMMPS can be built with optional packages which implement a variety
|
||||
of additional capabilities. An overview of all the packages is "given
|
||||
here"_Section_packages.html.
|
||||
|
||||
These are some LAMMPS capabilities which you may not think of as
|
||||
typical classical molecular dynamics options:
|
||||
|
||||
"static"_balance.html and "dynamic load-balancing"_fix_balance.html
|
||||
"generalized aspherical particles"_body.html
|
||||
@ -338,15 +342,13 @@ dynamics timestepping, particularly if the computations are not
|
||||
parallel, so it is often better to leave such analysis to
|
||||
post-processing codes.
|
||||
|
||||
A very simple (yet fast) visualizer is provided with the LAMMPS
|
||||
package - see the "xmovie"_Section_tools.html#xmovie tool in "this
|
||||
section"_Section_tools.html. It creates xyz projection views of
|
||||
atomic coordinates and animates them. We find it very useful for
|
||||
debugging purposes. For high-quality visualization we recommend the
|
||||
For high-quality visualization we recommend the
|
||||
following packages:
|
||||
|
||||
"VMD"_http://www.ks.uiuc.edu/Research/vmd
|
||||
"AtomEye"_http://mt.seas.upenn.edu/Archive/Graphics/A
|
||||
"OVITO"_http://www.ovito.org/
|
||||
"ParaView"_http://www.paraview.org/
|
||||
"PyMol"_http://www.pymol.org
|
||||
"Raster3d"_http://www.bmsc.washington.edu/raster3d/raster3d.html
|
||||
"RasMol"_http://www.openrasmol.org :ul
|
||||
@ -517,7 +519,7 @@ the packages they have written are somewhat unique to LAMMPS and the
|
||||
code would not be as general-purpose as it is without their expertise
|
||||
and efforts.
|
||||
|
||||
Axel Kohlmeyer (Temple U), akohlmey at gmail.com, SVN and Git repositories, indefatigable mail list responder, USER-CG-CMM and USER-OMP packages
|
||||
Axel Kohlmeyer (Temple U), akohlmey at gmail.com, SVN and Git repositories, indefatigable mail list responder, USER-CGSDK and USER-OMP packages
|
||||
Roy Pollock (LLNL), Ewald and PPPM solvers
|
||||
Mike Brown (ORNL), brownw at ornl.gov, GPU package
|
||||
Greg Wagner (Sandia), gjwagne at sandia.gov, MEAM package for MEAM potential
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@ -118,18 +118,21 @@ check which version of Python you have installed, by simply typing
|
||||
|
||||
11.2 Overview of using Python from a LAMMPS script :link(py_2),h4
|
||||
|
||||
NOTE: It is not currently possible to use the "python"_python.html
|
||||
command described in this section with Python 3, only with Python 2.
|
||||
The C API changed from Python 2 to 3 and the LAMMPS code is not
|
||||
compatible with both.
|
||||
LAMMPS has several commands which can be used to invoke Python
|
||||
code directly from an input script:
|
||||
|
||||
LAMMPS has a "python"_python.html command which can be used in an
|
||||
input script to define and execute a Python function that you write
|
||||
the code for. The Python function can also be assigned to a LAMMPS
|
||||
python-style variable via the "variable"_variable.html command. Each
|
||||
time the variable is evaluated, either in the LAMMPS input script
|
||||
itself, or by another LAMMPS command that uses the variable, this will
|
||||
trigger the Python function to be invoked.
|
||||
"python"_python.html
|
||||
"variable python"_variable.html
|
||||
"fix python"_fix_python.html
|
||||
"pair_style python"_pair_python.html :ul
|
||||
|
||||
The "python"_python.html command which can be used to define and
|
||||
execute a Python function that you write the code for. The Python
|
||||
function can also be assigned to a LAMMPS python-style variable via
|
||||
the "variable"_variable.html command. Each time the variable is
|
||||
evaluated, either in the LAMMPS input script itself, or by another
|
||||
LAMMPS command that uses the variable, this will trigger the Python
|
||||
function to be invoked.
|
||||
|
||||
The Python code for the function can be included directly in the input
|
||||
script or in an auxiliary file. The function can have arguments which
|
||||
@ -162,8 +165,16 @@ doc page for its python-style variables for more info, including
|
||||
examples of Python code you can write for both pure Python operations
|
||||
and callbacks to LAMMPS.
|
||||
|
||||
To run pure Python code from LAMMPS, you only need to build LAMMPS
|
||||
with the PYTHON package installed:
|
||||
The "fix python"_fix_python.html command can execute
|
||||
Python code at selected timesteps during a simulation run.
|
||||
|
||||
The "pair_style python"_pair_python command allows you to define
|
||||
pairwise potentials as python code which encodes a single pairwise
|
||||
interaction. This is useful for rapid-developement and debugging of a
|
||||
new potential.
|
||||
|
||||
To use any of these commands, you only need to build LAMMPS with the
|
||||
PYTHON package installed:
|
||||
|
||||
make yes-python
|
||||
make machine :pre
|
||||
@ -698,7 +709,12 @@ method in the src/atom.cpp file for a list of valid names. Again, new
|
||||
names could easily be added if the property you want is missing. The
|
||||
vector can be used via normal Python subscripting. If atom IDs are
|
||||
not consecutively ordered within LAMMPS, a None is returned as
|
||||
indication of an error.
|
||||
indication of an error. A special treatment is applied for image flags
|
||||
stored in the "image" property. All three image flags are stored in
|
||||
a packed format in a single integer, so count would be 1 to retrieve
|
||||
that integer, however also a count value of 3 can be used and then
|
||||
the image flags will be unpacked into 3 individual integers, ordered
|
||||
in a similar fashion as coordinates.
|
||||
|
||||
Note that the data structure gather_atoms("x") returns is different
|
||||
from the data structure returned by extract_atom("x") in four ways.
|
||||
@ -727,6 +743,10 @@ corresponding properties for each atom inside LAMMPS. This requires
|
||||
LAMMPS to have its "map" option enabled; see the
|
||||
"atom_modify"_atom_modify.html command for details. If it is not, or
|
||||
if atom IDs are not consecutively ordered, no coordinates are reset.
|
||||
Similar as for gather_atoms() a special treatment is applied for image
|
||||
flags, which can be provided in packed (count = 1) or unpacked (count = 3)
|
||||
format and in the latter case, they will be packed before applied to
|
||||
atoms.
|
||||
|
||||
The array of coordinates passed to scatter_atoms() must be a ctypes
|
||||
vector of ints or doubles, allocated and initialized something like
|
||||
|
||||
@ -14,12 +14,11 @@ experienced users.
|
||||
2.1 "What's in the LAMMPS distribution"_#start_1
|
||||
2.2 "Making LAMMPS"_#start_2
|
||||
2.3 "Making LAMMPS with optional packages"_#start_3
|
||||
2.4 "Building LAMMPS via the Make.py script"_#start_4
|
||||
2.5 "Building LAMMPS as a library"_#start_5
|
||||
2.6 "Running LAMMPS"_#start_6
|
||||
2.7 "Command-line options"_#start_7
|
||||
2.8 "Screen output"_#start_8
|
||||
2.9 "Tips for users of previous versions"_#start_9 :all(b)
|
||||
2.5 "Building LAMMPS as a library"_#start_4
|
||||
2.6 "Running LAMMPS"_#start_5
|
||||
2.7 "Command-line options"_#start_6
|
||||
2.8 "Screen output"_#start_7
|
||||
2.9 "Tips for users of previous versions"_#start_8 :all(b)
|
||||
|
||||
:line
|
||||
|
||||
@ -80,7 +79,7 @@ This section has the following sub-sections:
|
||||
|
||||
Read this first :h5,link(start_2_1)
|
||||
|
||||
If you want to avoid building LAMMPS yourself, read the preceding
|
||||
If you want to avoid building LAMMPS yourself, read the preceeding
|
||||
section about options available for downloading and installing
|
||||
executables. Details are discussed on the "download"_download page.
|
||||
|
||||
@ -96,7 +95,7 @@ make serial :pre
|
||||
Note that on a facility supercomputer, there are often "modules"
|
||||
loaded in your environment that provide the compilers and MPI you
|
||||
should use. In this case, the "mpicxx" compile/link command in
|
||||
Makefile.mpi should just work by accessing those modules.
|
||||
Makefile.mpi should simply work by accessing those modules.
|
||||
|
||||
It may be the case that one of the other Makefile.machine files in the
|
||||
src/MAKE sub-directories is a better match to your system (type "make"
|
||||
@ -107,33 +106,35 @@ make stampede :pre
|
||||
If any of these builds (with an existing Makefile.machine) works on
|
||||
your system, then you're done!
|
||||
|
||||
If you need to install an optional package with a LAMMPS command you
|
||||
want to use, and the package does not depend on an extra library, you
|
||||
can simply type
|
||||
|
||||
make name :pre
|
||||
|
||||
before invoking (or re-invoking) the above steps. "Name" is the
|
||||
lower-case name of the package, e.g. replica or user-misc.
|
||||
|
||||
If you want to do one of the following:
|
||||
|
||||
use optional LAMMPS features that require additional libraries
|
||||
use optional packages that require additional libraries
|
||||
use optional accelerator packages that require special compiler/linker settings
|
||||
run on a specialized platform that has its own compilers, settings, or other libs to use :ul
|
||||
use a LAMMPS command that requires an extra library (e.g. "dump image"_dump_image.html)
|
||||
build with a package that requires an extra library
|
||||
build with an accelerator package that requires special compiler/linker settings
|
||||
run on a machine that has its own compilers, settings, or libraries :ul
|
||||
|
||||
then building LAMMPS is more complicated. You may need to find where
|
||||
auxiliary libraries exist on your machine or install them if they
|
||||
don't. You may need to build additional libraries that are part of
|
||||
the LAMMPS package, before building LAMMPS. You may need to edit a
|
||||
extra libraries exist on your machine or install them if they don't.
|
||||
You may need to build extra libraries that are included in the LAMMPS
|
||||
distribution, before building LAMMPS itself. You may need to edit a
|
||||
Makefile.machine file to make it compatible with your system.
|
||||
|
||||
Note that there is a Make.py tool in the src directory that automates
|
||||
several of these steps, but you still have to know what you are doing.
|
||||
"Section 2.4"_#start_4 below describes the tool. It is a convenient
|
||||
way to work with installing/un-installing various packages, the
|
||||
Makefile.machine changes required by some packages, and the auxiliary
|
||||
libraries some of them use.
|
||||
|
||||
Please read the following sections carefully. If you are not
|
||||
comfortable with makefiles, or building codes on a Unix platform, or
|
||||
running an MPI job on your machine, please find a local expert to help
|
||||
you. Many compilation, linking, and run problems that users have are
|
||||
often not really LAMMPS issues - they are peculiar to the user's
|
||||
system, compilers, libraries, etc. Such questions are better answered
|
||||
by a local expert.
|
||||
you. Many compilation, linking, and run problems users experience are
|
||||
often not LAMMPS issues - they are peculiar to the user's system,
|
||||
compilers, libraries, etc. Such questions are better answered by a
|
||||
local expert.
|
||||
|
||||
If you have a build problem that you are convinced is a LAMMPS issue
|
||||
(e.g. the compiler complains about a line of LAMMPS source code), then
|
||||
@ -251,7 +252,7 @@ re-compile, after typing "make clean" (which will describe different
|
||||
clean options).
|
||||
|
||||
The LMP_INC variable is used to include options that turn on ifdefs
|
||||
within the LAMMPS code. The options that are currently recognized are:
|
||||
within the LAMMPS code. The options that are currently recogized are:
|
||||
|
||||
-DLAMMPS_GZIP
|
||||
-DLAMMPS_JPEG
|
||||
@ -362,7 +363,7 @@ installed on your platform. If MPI is installed on your system in the
|
||||
usual place (under /usr/local), you also may not need to specify these
|
||||
3 variables, assuming /usr/local is in your path. On some large
|
||||
parallel machines which use "modules" for their compile/link
|
||||
environments, you may simply need to include the correct module in
|
||||
environements, you may simply need to include the correct module in
|
||||
your build environment, before building LAMMPS. Or the parallel
|
||||
machine may have a vendor-provided MPI which the compiler has no
|
||||
trouble finding.
|
||||
@ -430,7 +431,7 @@ use the KISS library described above.
|
||||
You may also need to set the FFT_INC, FFT_PATH, and FFT_LIB variables,
|
||||
so the compiler and linker can find the needed FFT header and library
|
||||
files. Note that on some large parallel machines which use "modules"
|
||||
for their compile/link environments, you may simply need to include
|
||||
for their compile/link environements, you may simply need to include
|
||||
the correct module in your build environment. Or the parallel machine
|
||||
may have a vendor-provided FFT library which the compiler has no
|
||||
trouble finding.
|
||||
@ -450,7 +451,7 @@ you must also manually specify the correct library, namely -lsfftw or
|
||||
|
||||
The FFT_INC variable also allows for a -DFFT_SINGLE setting that will
|
||||
use single-precision FFTs with PPPM, which can speed-up long-range
|
||||
calculations, particularly in parallel or on GPUs. Fourier transform
|
||||
calulations, particularly in parallel or on GPUs. Fourier transform
|
||||
and related PPPM operations are somewhat insensitive to floating point
|
||||
truncation errors and thus do not always need to be performed in
|
||||
double precision. Using the -DFFT_SINGLE setting trades off a little
|
||||
@ -508,13 +509,13 @@ You should get the executable lmp_foo when the build is complete.
|
||||
|
||||
Errors that can occur when making LAMMPS: h5 :link(start_2_3)
|
||||
|
||||
NOTE: If an error occurs when building LAMMPS, the compiler or linker
|
||||
will state very explicitly what the problem is. The error message
|
||||
should give you a hint as to which of the steps above has failed, and
|
||||
what you need to do in order to fix it. Building a code with a
|
||||
Makefile is a very logical process. The compiler and linker need to
|
||||
find the appropriate files and those files need to be compatible with
|
||||
LAMMPS source files. When a make fails, there is usually a very
|
||||
If an error occurs when building LAMMPS, the compiler or linker will
|
||||
state very explicitly what the problem is. The error message should
|
||||
give you a hint as to which of the steps above has failed, and what
|
||||
you need to do in order to fix it. Building a code with a Makefile is
|
||||
a very logical process. The compiler and linker need to find the
|
||||
appropriate files and those files need to be compatible with LAMMPS
|
||||
settings and source files. When a make fails, there is usually a very
|
||||
simple reason, which you or a local expert will need to fix.
|
||||
|
||||
Here are two non-obvious errors that can occur:
|
||||
@ -557,7 +558,8 @@ Typing "make clean-all" or "make clean-machine" will delete *.o object
|
||||
files created when LAMMPS is built, for either all builds or for a
|
||||
particular machine.
|
||||
|
||||
Changing the LAMMPS size limits via -DLAMMPS_SMALLBIG or -DLAMMPS_BIGBIG or -DLAMMPS_SMALLSMALL :h6
|
||||
Changing the LAMMPS size limits via -DLAMMPS_SMALLBIG or
|
||||
-DLAMMPS_BIGBIG or -DLAMMPS_SMALLSMALL :h6
|
||||
|
||||
As explained above, any of these 3 settings can be specified on the
|
||||
LMP_INC line in your low-level src/MAKE/Makefile.foo.
|
||||
@ -653,13 +655,7 @@ This section has the following sub-sections:
|
||||
|
||||
2.3.1 "Package basics"_#start_3_1
|
||||
2.3.2 "Including/excluding packages"_#start_3_2
|
||||
2.3.3 "Packages that require extra libraries"_#start_3_3
|
||||
2.3.4 "Packages that require Makefile.machine settings"_#start_3_4 :all(b)
|
||||
|
||||
Note that the following "Section 2.4"_#start_4 describes the Make.py
|
||||
tool which can be used to install/un-install packages and build the
|
||||
auxiliary libraries which some of them use. It can also auto-edit a
|
||||
Makefile.machine to add settings needed by some packages.
|
||||
2.3.3 "Packages that require extra libraries"_#start_3_3 :all(b)
|
||||
|
||||
:line
|
||||
|
||||
@ -670,235 +666,221 @@ are always included, plus optional packages. Packages are groups of
|
||||
files that enable a specific set of features. For example, force
|
||||
fields for molecular systems or granular systems are in packages.
|
||||
|
||||
"Section 4"_Section_packages.html in the manual has details
|
||||
about all the packages, including specific instructions for building
|
||||
LAMMPS with each package, which are covered in a more general manner
|
||||
"Section 4"_Section_packages.html in the manual has details about all
|
||||
the packages, which come in two flavors: [standard] and [user]
|
||||
packages. It also has specific instructions for building LAMMPS with
|
||||
any package which requires an extra library. General instructions are
|
||||
below.
|
||||
|
||||
You can see the list of all packages by typing "make package" from
|
||||
within the src directory of the LAMMPS distribution. This also lists
|
||||
various make commands that can be used to manipulate packages.
|
||||
within the src directory of the LAMMPS distribution. It will also
|
||||
list various make commands that can be used to manage packages.
|
||||
|
||||
If you use a command in a LAMMPS input script that is part of a
|
||||
package, you must have built LAMMPS with that package, else you will
|
||||
get an error that the style is invalid or the command is unknown.
|
||||
Every command's doc page specifies if it is part of a package. You can
|
||||
also type
|
||||
Every command's doc page specfies if it is part of a package. You can
|
||||
type
|
||||
|
||||
lmp_machine -h :pre
|
||||
|
||||
to run your executable with the optional "-h command-line
|
||||
switch"_#start_7 for "help", which will simply list the styles and
|
||||
commands known to your executable, and immediately exit.
|
||||
|
||||
There are two kinds of packages in LAMMPS, standard and user packages.
|
||||
More information about the contents of standard and user packages is
|
||||
given in "Section 4"_Section_packages.html of the manual. The
|
||||
difference between standard and user packages is as follows:
|
||||
|
||||
Standard packages, such as molecule or kspace, are supported by the
|
||||
LAMMPS developers and are written in a syntax and style consistent
|
||||
with the rest of LAMMPS. This means we will answer questions about
|
||||
them, debug and fix them if necessary, and keep them compatible with
|
||||
future changes to LAMMPS.
|
||||
|
||||
User packages, such as user-atc or user-omp, have been contributed by
|
||||
users, and always begin with the user prefix. If they are a single
|
||||
command (single file), they are typically in the user-misc package.
|
||||
Otherwise, they are a set of files grouped together which add a
|
||||
specific functionality to the code.
|
||||
|
||||
User packages don't necessarily meet the requirements of the standard
|
||||
packages. If you have problems using a feature provided in a user
|
||||
package, you may need to contact the contributor directly to get help.
|
||||
Information on how to submit additions you make to LAMMPS as single
|
||||
files or either a standard or user-contributed package are given in
|
||||
"this section"_Section_modify.html#mod_15 of the documentation.
|
||||
switch"_#start_7 for "help", which will list the styles and commands
|
||||
known to your executable, and immediately exit.
|
||||
|
||||
:line
|
||||
|
||||
Including/excluding packages :h5,link(start_3_2)
|
||||
|
||||
To use (or not use) a package you must include it (or exclude it)
|
||||
before building LAMMPS. From the src directory, this is typically as
|
||||
simple as:
|
||||
To use (or not use) a package you must install it (or un-install it)
|
||||
before building LAMMPS. From the src directory, this is as simple as:
|
||||
|
||||
make yes-colloid
|
||||
make mpi :pre
|
||||
|
||||
or
|
||||
|
||||
make no-manybody
|
||||
make no-user-omp
|
||||
make mpi :pre
|
||||
|
||||
NOTE: You should NOT include/exclude packages and build LAMMPS in a
|
||||
NOTE: You should NOT install/un-install packages and build LAMMPS in a
|
||||
single make command using multiple targets, e.g. make yes-colloid mpi.
|
||||
This is because the make procedure creates a list of source files that
|
||||
will be out-of-date for the build if the package configuration changes
|
||||
within the same command.
|
||||
|
||||
Some packages have individual files that depend on other packages
|
||||
being included. LAMMPS checks for this and does the right thing.
|
||||
I.e. individual files are only included if their dependencies are
|
||||
already included. Likewise, if a package is excluded, other files
|
||||
Any package can be installed or not in a LAMMPS build, independent of
|
||||
all other packages. However, some packages include files derived from
|
||||
files in other packages. LAMMPS checks for this and does the right
|
||||
thing. I.e. individual files are only included if their dependencies
|
||||
are already included. Likewise, if a package is excluded, other files
|
||||
dependent on that package are also excluded.
|
||||
|
||||
NOTE: The one exception is that we do not recommend building with both
|
||||
the KOKKOS package installed and any of the other acceleration
|
||||
packages (GPU, OPT, USER-INTEL, USER-OMP) also installed. This is
|
||||
because of how Kokkos sometimes builds using a wrapper compiler which
|
||||
can make it difficult to invoke all the compile/link flags correctly
|
||||
for both Kokkos and non-Kokkos files.
|
||||
|
||||
If you will never run simulations that use the features in a
|
||||
particular packages, there is no reason to include it in your build.
|
||||
For some packages, this will keep you from having to build auxiliary
|
||||
libraries (see below), and will also produce a smaller executable
|
||||
which may run a bit faster.
|
||||
For some packages, this will keep you from having to build extra
|
||||
libraries, and will also produce a smaller executable which may run a
|
||||
bit faster.
|
||||
|
||||
When you download a LAMMPS tarball, these packages are pre-installed
|
||||
in the src directory: KSPACE, MANYBODY,MOLECULE, because they are so
|
||||
commonly used. When you download LAMMPS source files from the SVN or
|
||||
Git repositories, no packages are pre-installed.
|
||||
When you download a LAMMPS tarball, three packages are pre-installed
|
||||
in the src directory -- KSPACE, MANYBODY, MOLECULE -- because they are
|
||||
so commonly used. When you download LAMMPS source files from the SVN
|
||||
or Git repositories, no packages are pre-installed.
|
||||
|
||||
Packages are included or excluded by typing "make yes-name" or "make
|
||||
no-name", where "name" is the name of the package in lower-case, e.g.
|
||||
name = kspace for the KSPACE package or name = user-atc for the
|
||||
USER-ATC package. You can also type "make yes-standard", "make
|
||||
no-standard", "make yes-std", "make no-std", "make yes-user", "make
|
||||
no-user", "make yes-lib", "make no-lib", "make yes-all", or "make
|
||||
no-all" to include/exclude various sets of packages. Type "make
|
||||
package" to see all of the package-related make options.
|
||||
Packages are installed or un-installed by typing
|
||||
|
||||
NOTE: Inclusion/exclusion of a package works by simply moving files
|
||||
back and forth between the main src directory and sub-directories with
|
||||
the package name (e.g. src/KSPACE, src/USER-ATC), so that the files
|
||||
are seen or not seen when LAMMPS is built. After you have included or
|
||||
excluded a package, you must re-build LAMMPS.
|
||||
make yes-name
|
||||
make no-name :pre
|
||||
|
||||
Additional package-related make options exist to help manage LAMMPS
|
||||
files that exist in both the src directory and in package
|
||||
sub-directories. You do not normally need to use these commands
|
||||
unless you are editing LAMMPS files or have downloaded a patch from
|
||||
the LAMMPS WWW site.
|
||||
where "name" is the name of the package in lower-case, e.g. name =
|
||||
kspace for the KSPACE package or name = user-atc for the USER-ATC
|
||||
package. You can also type any of these commands:
|
||||
|
||||
Typing "make package-update" or "make pu" will overwrite src files
|
||||
with files from the package sub-directories if the package has been
|
||||
included. It should be used after a patch is installed, since patches
|
||||
only update the files in the package sub-directory, but not the src
|
||||
files. Typing "make package-overwrite" will overwrite files in the
|
||||
package sub-directories with src files.
|
||||
make yes-all | install all packages
|
||||
make no-all | un-install all packages
|
||||
make yes-standard or make yes-std | install standard packages
|
||||
make no-standard or make no-std| un-install standard packages
|
||||
make yes-user | install user packages
|
||||
make no-user | un-install user packages
|
||||
make yes-lib | install packages that require extra libraries
|
||||
make no-lib | un-install packages that require extra libraries
|
||||
make yes-ext | install packages that require external libraries
|
||||
make no-ext | un-install packages that require external libraries :tb(s=|)
|
||||
|
||||
which install/un-install various sets of packages. Typing "make
|
||||
package" will list all the these commands.
|
||||
|
||||
NOTE: Installing or un-installing a package works by simply moving
|
||||
files back and forth between the main src directory and
|
||||
sub-directories with the package name (e.g. src/KSPACE, src/USER-ATC),
|
||||
so that the files are included or excluded when LAMMPS is built.
|
||||
After you have installed or un-installed a package, you must re-build
|
||||
LAMMPS for the action to take effect.
|
||||
|
||||
The following make commands help manage files that exist in both the
|
||||
src directory and in package sub-directories. You do not normally
|
||||
need to use these commands unless you are editing LAMMPS files or have
|
||||
downloaded a patch from the LAMMPS web site.
|
||||
|
||||
Typing "make package-status" or "make ps" will show which packages are
|
||||
currently included. For those that are included, it will list any
|
||||
currently installed. For those that are installed, it will list any
|
||||
files that are different in the src directory and package
|
||||
sub-directory. Typing "make package-diff" lists all differences
|
||||
between these files. Again, type "make package" to see all of the
|
||||
package-related make options.
|
||||
sub-directory.
|
||||
|
||||
Typing "make package-update" or "make pu" will overwrite src files
|
||||
with files from the package sub-directories if the package is
|
||||
installed. It should be used after a patch has been applied, since
|
||||
patches only update the files in the package sub-directory, but not
|
||||
the src files.
|
||||
|
||||
Typing "make package-overwrite" will overwrite files in the package
|
||||
sub-directories with src files.
|
||||
|
||||
Typing "make package-diff" lists all differences between these files.
|
||||
|
||||
Again, just type "make package" to see all of the package-related make
|
||||
options.
|
||||
|
||||
:line
|
||||
|
||||
Packages that require extra libraries :h5,link(start_3_3)
|
||||
|
||||
A few of the standard and user packages require additional auxiliary
|
||||
libraries. Many of them are provided with LAMMPS, in which case they
|
||||
must be compiled first, before LAMMPS is built, if you wish to include
|
||||
that package. If you get a LAMMPS build error about a missing
|
||||
library, this is likely the reason. See the
|
||||
"Section 4"_Section_packages.html doc page for a list of
|
||||
packages that have these kinds of auxiliary libraries.
|
||||
A few of the standard and user packages require extra libraries. See
|
||||
"Section 4"_Section_packages.html for two tables of packages which
|
||||
indicate which ones require libraries. For each such package, the
|
||||
Section 4 doc page gives details on how to build the extra library,
|
||||
including how to download it if necessary. The basic ideas are
|
||||
summarized here.
|
||||
|
||||
The lib directory in the distribution has sub-directories with package
|
||||
names that correspond to the needed auxiliary libs, e.g. lib/gpu.
|
||||
Each sub-directory has a README file that gives more details. Code
|
||||
for most of the auxiliary libraries is included in that directory.
|
||||
Examples are the USER-ATC and MEAM packages.
|
||||
[System libraries:]
|
||||
|
||||
A few of the lib sub-directories do not include code, but do include
|
||||
instructions (and sometimes scripts) that automate the process of
|
||||
downloading the auxiliary library and installing it so LAMMPS can link
|
||||
to it. Examples are the KIM, VORONOI, USER-MOLFILE, and USER-SMD
|
||||
packages.
|
||||
Packages in the tables "Section 4"_Section_packages.html with a "sys"
|
||||
in the last column link to system libraries that typically already
|
||||
exist on your machine. E.g. the python package links to a system
|
||||
Python library. If your machine does not have the required library,
|
||||
you will have to download and install it on your machine, in either
|
||||
the system or user space.
|
||||
|
||||
The lib/python directory (for the PYTHON package) contains only a
|
||||
choice of Makefile.lammps.* files. This is because no auxiliary code
|
||||
or libraries are needed, only the Python library and other system libs
|
||||
that should already available on your system. However, the
|
||||
Makefile.lammps file is needed to tell LAMMPS which libs to use and
|
||||
where to find them.
|
||||
[Internal libraries:]
|
||||
|
||||
For libraries with provided code, the sub-directory README file
|
||||
(e.g. lib/atc/README) has instructions on how to build that library.
|
||||
This information is also summarized in "Section
|
||||
4"_Section_packages.html. Typically this is done by typing
|
||||
something like:
|
||||
Packages in the tables "Section 4"_Section_packages.html with an "int"
|
||||
in the last column link to internal libraries whose source code is
|
||||
included with LAMMPS, in the lib/name directory where name is the
|
||||
package name. You must first build the library in that directory
|
||||
before building LAMMPS with that package installed. E.g. the gpu
|
||||
package links to a library you build in the lib/gpu dir. You can
|
||||
often do the build in one step by typing "make lib-name args=..."
|
||||
from the src dir, with appropriate arguments. You can leave off the
|
||||
args to see a help message. See "Section 4"_Section_packages.html for
|
||||
details for each package.
|
||||
|
||||
make -f Makefile.g++ :pre
|
||||
[External libraries:]
|
||||
|
||||
If one of the provided Makefiles is not appropriate for your system
|
||||
you will need to edit or add one. Note that all the Makefiles have a
|
||||
setting for EXTRAMAKE at the top that specifies a Makefile.lammps.*
|
||||
file.
|
||||
Packages in the tables "Section 4"_Section_packages.html with an "ext"
|
||||
in the last column link to exernal libraries whose source code is not
|
||||
included with LAMMPS. You must first download and install the library
|
||||
before building LAMMPS with that package installed. E.g. the voronoi
|
||||
package links to the freely available "Voro++ library"_voro_home2. You
|
||||
can often do the download/build in one step by typing "make lib-name
|
||||
args=..." from the src dir, with appropriate arguments. You can leave
|
||||
off the args to see a help message. See "Section
|
||||
4"_Section_packages.html for details for each package.
|
||||
|
||||
If the library build is successful, it will produce 2 files in the lib
|
||||
directory:
|
||||
:link(voro_home2,http://math.lbl.gov/voro++)
|
||||
|
||||
libpackage.a
|
||||
Makefile.lammps :pre
|
||||
[Possible errors:]
|
||||
|
||||
The Makefile.lammps file will typically be a copy of one of the
|
||||
Makefile.lammps.* files in the library directory.
|
||||
There are various common errors which can occur when building extra
|
||||
libraries or when building LAMMPS with packages that require the extra
|
||||
libraries.
|
||||
|
||||
Note that you must insure that the settings in Makefile.lammps are
|
||||
appropriate for your system. If they are not, the LAMMPS build may
|
||||
fail. To fix this, you can edit or create a new Makefile.lammps.*
|
||||
file for your system, and copy it to Makefile.lammps.
|
||||
If you cannot build the extra library itself successfully, you may
|
||||
need to edit or create an appropriate Makefile for your machine, e.g.
|
||||
with appropriate compiler or system settings. Provided makefiles are
|
||||
typically in the lib/name directory. E.g. see the Makefile.* files in
|
||||
lib/gpu.
|
||||
|
||||
As explained in the lib/package/README files, the settings in
|
||||
Makefile.lammps are used to specify additional system libraries and
|
||||
their locations so that LAMMPS can build with the auxiliary library.
|
||||
For example, if the MEAM package is used, the auxiliary library
|
||||
consists of F90 code, built with a Fortran complier. To link that
|
||||
library with LAMMPS (a C++ code) via whatever C++ compiler LAMMPS is
|
||||
built with, typically requires additional Fortran-to-C libraries be
|
||||
included in the link. Another example are the BLAS and LAPACK
|
||||
libraries needed to use the USER-ATC or USER-AWPMD packages.
|
||||
The LAMMPS build often uses settings in a lib/name/Makefile.lammps
|
||||
file which either exists in the LAMMPS distribution or is created or
|
||||
copied from a lib/name/Makefile.lammps.* file when the library is
|
||||
built. If those settings are not correct for your machine you will
|
||||
need to edit or create an appropriate Makefile.lammps file.
|
||||
|
||||
For libraries without provided code, the sub-directory README file has
|
||||
information on where to download the library and how to build it,
|
||||
e.g. lib/voronoi/README and lib/smd/README. The README files also
|
||||
describe how you must either (a) create soft links, via the "ln"
|
||||
command, in those directories to point to where you built or installed
|
||||
the packages, or (b) check or edit the Makefile.lammps file in the
|
||||
same directory to provide that information.
|
||||
Package-specific details for these steps are given in "Section
|
||||
4"_Section_packages.html an in README files in the lib/name
|
||||
directories.
|
||||
|
||||
Some of the sub-directories, e.g. lib/voronoi, also have an install.py
|
||||
script which can be used to automate the process of
|
||||
downloading/building/installing the auxiliary library, and setting the
|
||||
needed soft links. Type "python install.py" for further instructions.
|
||||
[Compiler options needed for accelerator packages:]
|
||||
|
||||
As with the sub-directories containing library code, if the soft links
|
||||
or settings in the lib/package/Makefile.lammps files are not correct,
|
||||
the LAMMPS build will typically fail.
|
||||
Several packages contain code that is optimized for specific hardware,
|
||||
e.g. CPU, KNL, or GPU. These are the OPT, GPU, KOKKOS, USER-INTEL,
|
||||
and USER-OMP packages. Compiling and linking the source files in
|
||||
these accelerator packages for optimal performance requires specific
|
||||
settings in the Makefile.machine file you use.
|
||||
|
||||
:line
|
||||
|
||||
Packages that require Makefile.machine settings :h5,link(start_3_4)
|
||||
|
||||
A few packages require specific settings in Makefile.machine, to
|
||||
either build or use the package effectively. These are the
|
||||
USER-INTEL, KOKKOS, USER-OMP, and OPT packages, used for accelerating
|
||||
code performance on CPUs or other hardware, as discussed in "Section
|
||||
5.3"_Section_accelerate.html#acc_3.
|
||||
|
||||
A summary of what Makefile.machine changes are needed for each of
|
||||
these packages is given in "Section 4"_Section_packages.html.
|
||||
The details are given on the doc pages that describe each of these
|
||||
accelerator packages in detail:
|
||||
A summary of the Makefile.machine settings needed for each of these
|
||||
packages is given in "Section 4"_Section_packages.html. More info is
|
||||
given on the doc pages that describe each package in detail:
|
||||
|
||||
5.3.1 "USER-INTEL package"_accelerate_intel.html
|
||||
5.3.2 "GPU package"_accelerate_intel.html
|
||||
5.3.3 "KOKKOS package"_accelerate_kokkos.html
|
||||
5.3.4 "USER-OMP package"_accelerate_omp.html
|
||||
5.3.5 "OPT package"_accelerate_opt.html :all(b)
|
||||
|
||||
You can also look at the following machine Makefiles in
|
||||
src/MAKE/OPTIONS, which include the changes. Note that the USER-INTEL
|
||||
and KOKKOS packages allow for settings that build LAMMPS for different
|
||||
hardware. The USER-INTEL package builds for CPU and the Xeon Phi, the
|
||||
KOKKOS package builds for OpenMP, GPUs (Cuda), and the Xeon Phi.
|
||||
You can also use or examine the following machine Makefiles in
|
||||
src/MAKE/OPTIONS, which include the settings. Note that the
|
||||
USER-INTEL and KOKKOS packages can use settings that build LAMMPS for
|
||||
different hardware. The USER-INTEL package can be compiled for Intel
|
||||
CPUs and KNLs; the KOKKOS package builds for CPUs (OpenMP), GPUs
|
||||
(Cuda), and Intel KNLs.
|
||||
|
||||
Makefile.intel_cpu
|
||||
Makefile.intel_phi
|
||||
@ -908,127 +890,9 @@ Makefile.kokkos_phi
|
||||
Makefile.omp
|
||||
Makefile.opt :ul
|
||||
|
||||
Also note that the Make.py tool, described in the next "Section
|
||||
2.4"_#start_4 can automatically add the needed info to an existing
|
||||
machine Makefile, using simple command-line arguments.
|
||||
|
||||
:line
|
||||
|
||||
2.4 Building LAMMPS via the Make.py tool :h4,link(start_4)
|
||||
|
||||
The src directory includes a Make.py script, written in Python, which
|
||||
can be used to automate various steps of the build process. It is
|
||||
particularly useful for working with the accelerator packages, as well
|
||||
as other packages which require auxiliary libraries to be built.
|
||||
|
||||
The goal of the Make.py tool is to allow any complex multi-step LAMMPS
|
||||
build to be performed as a single Make.py command. And you can
|
||||
archive the commands, so they can be re-invoked later via the -r
|
||||
(redo) switch. If you find some LAMMPS build procedure that can't be
|
||||
done in a single Make.py command, let the developers know, and we'll
|
||||
see if we can augment the tool.
|
||||
|
||||
You can run Make.py from the src directory by typing either:
|
||||
|
||||
Make.py -h
|
||||
python Make.py -h :pre
|
||||
|
||||
which will give you help info about the tool. For the former to work,
|
||||
you may need to edit the first line of Make.py to point to your local
|
||||
Python. And you may need to insure the script is executable:
|
||||
|
||||
chmod +x Make.py :pre
|
||||
|
||||
Here are examples of build tasks you can perform with Make.py:
|
||||
|
||||
Install/uninstall packages: Make.py -p no-lib kokkos omp intel
|
||||
Build specific auxiliary libs: Make.py -a lib-atc lib-meam
|
||||
Build libs for all installed packages: Make.py -p cuda gpu -gpu mode=double arch=31 -a lib-all
|
||||
Create a Makefile from scratch with compiler and MPI settings: Make.py -m none -cc g++ -mpi mpich -a file
|
||||
Augment Makefile.serial with settings for installed packages: Make.py -p intel -intel cpu -m serial -a file
|
||||
Add JPG and FFTW support to Makefile.mpi: Make.py -m mpi -jpg -fft fftw -a file
|
||||
Build LAMMPS with a parallel make using Makefile.mpi: Make.py -j 16 -m mpi -a exe
|
||||
Build LAMMPS and libs it needs using Makefile.serial with accelerator settings: Make.py -p gpu intel -intel cpu -a lib-all file serial :tb(s=:)
|
||||
|
||||
The bench and examples directories give Make.py commands that can be
|
||||
used to build LAMMPS with the various packages and options needed to
|
||||
run all the benchmark and example input scripts. See these files for
|
||||
more details:
|
||||
|
||||
bench/README
|
||||
bench/FERMI/README
|
||||
bench/KEPLER/README
|
||||
bench/PHI/README
|
||||
examples/README
|
||||
examples/accelerate/README
|
||||
examples/accelerate/make.list :ul
|
||||
|
||||
All of the Make.py options and syntax help can be accessed by using
|
||||
the "-h" switch.
|
||||
|
||||
E.g. typing "Make.py -h" gives
|
||||
|
||||
Syntax: Make.py switch args ...
|
||||
switches can be listed in any order
|
||||
help switch:
|
||||
-h prints help and syntax for all other specified switches
|
||||
switch for actions:
|
||||
-a lib-all, lib-dir, clean, file, exe or machine
|
||||
list one or more actions, in any order
|
||||
machine is a Makefile.machine suffix, must be last if used
|
||||
one-letter switches:
|
||||
-d (dir), -j (jmake), -m (makefile), -o (output),
|
||||
-p (packages), -r (redo), -s (settings), -v (verbose)
|
||||
switches for libs:
|
||||
-atc, -awpmd, -colvars, -cuda
|
||||
-gpu, -meam, -poems, -qmmm, -reax
|
||||
switches for build and makefile options:
|
||||
-intel, -kokkos, -cc, -mpi, -fft, -jpg, -png :pre
|
||||
|
||||
Using the "-h" switch with other switches and actions gives additional
|
||||
info on all the other specified switches or actions. The "-h" can be
|
||||
anywhere in the command-line and the other switches do not need their
|
||||
arguments. E.g. type "Make.py -h -d -atc -intel" will print:
|
||||
|
||||
-d dir
|
||||
dir = LAMMPS home dir
|
||||
if -d not specified, working dir must be lammps/src :pre
|
||||
|
||||
-atc make=suffix lammps=suffix2
|
||||
all args are optional and can be in any order
|
||||
make = use Makefile.suffix (def = g++)
|
||||
lammps = use Makefile.lammps.suffix2 (def = EXTRAMAKE in makefile) :pre
|
||||
|
||||
-intel mode
|
||||
mode = cpu or phi (def = cpu)
|
||||
build Intel package for CPU or Xeon Phi :pre
|
||||
|
||||
Note that Make.py never overwrites an existing Makefile.machine.
|
||||
Instead, it creates src/MAKE/MINE/Makefile.auto, which you can save or
|
||||
rename if desired. Likewise it creates an executable named
|
||||
src/lmp_auto, which you can rename using the -o switch if desired.
|
||||
|
||||
The most recently executed Make.py command is saved in
|
||||
src/Make.py.last. You can use the "-r" switch (for redo) to re-invoke
|
||||
the last command, or you can save a sequence of one or more Make.py
|
||||
commands to a file and invoke the file of commands using "-r". You
|
||||
can also label the commands in the file and invoke one or more of them
|
||||
by name.
|
||||
|
||||
A typical use of Make.py is to start with a valid Makefile.machine for
|
||||
your system, that works for a vanilla LAMMPS build, i.e. when optional
|
||||
packages are not installed. You can then use Make.py to add various
|
||||
settings (FFT, JPG, PNG) to the Makefile.machine as well as change its
|
||||
compiler and MPI options. You can also add additional packages to the
|
||||
build, as well as build the needed supporting libraries.
|
||||
|
||||
You can also use Make.py to create a new Makefile.machine from
|
||||
scratch, using the "-m none" switch, if you also specify what compiler
|
||||
and MPI options to use, via the "-cc" and "-mpi" switches.
|
||||
|
||||
:line
|
||||
|
||||
2.5 Building LAMMPS as a library :h4,link(start_5)
|
||||
2.4 Building LAMMPS as a library :h4,link(start_4)
|
||||
|
||||
LAMMPS can be built as either a static or shared library, which can
|
||||
then be called from another application or a scripting language. See
|
||||
@ -1064,7 +928,7 @@ src/MAKE/Makefile.foo and perform the build in the directory
|
||||
Obj_shared_foo. This is so that each file can be compiled with the
|
||||
-fPIC flag which is required for inclusion in a shared library. The
|
||||
build will create the file liblammps_foo.so which another application
|
||||
can link to dynamically. It will also create a soft link liblammps.so,
|
||||
can link to dyamically. It will also create a soft link liblammps.so,
|
||||
which will point to the most recently built shared library. This is
|
||||
the file the Python wrapper loads by default.
|
||||
|
||||
@ -1150,7 +1014,7 @@ interface and how to extend it for your needs.
|
||||
|
||||
:line
|
||||
|
||||
2.6 Running LAMMPS :h4,link(start_6)
|
||||
2.5 Running LAMMPS :h4,link(start_5)
|
||||
|
||||
By default, LAMMPS runs by reading commands from standard input. Thus
|
||||
if you run the LAMMPS executable by itself, e.g.
|
||||
@ -1282,7 +1146,7 @@ more processors or setup a smaller problem.
|
||||
|
||||
:line
|
||||
|
||||
2.7 Command-line options :h4,link(start_7)
|
||||
2.6 Command-line options :h4,link(start_6)
|
||||
|
||||
At run time, LAMMPS recognizes several optional command-line switches
|
||||
which may be used in any order. Either the full word or a one-or-two
|
||||
@ -1416,8 +1280,8 @@ LAMMPS is compiled with CUDA=yes.
|
||||
numa Nm :pre
|
||||
|
||||
This option is only relevant when using pthreads with hwloc support.
|
||||
In this case Nm defines the number of NUMA regions (typically sockets)
|
||||
on a node which will be utilized by a single MPI rank. By default Nm
|
||||
In this case Nm defines the number of NUMA regions (typicaly sockets)
|
||||
on a node which will be utilizied by a single MPI rank. By default Nm
|
||||
= 1. If this option is used the total number of worker-threads per
|
||||
MPI rank is threads*numa. Currently it is always almost better to
|
||||
assign at least one MPI rank per NUMA region, and leave numa set to
|
||||
@ -1481,7 +1345,7 @@ replica runs on on one or a few processors. Note that with MPI
|
||||
installed on a machine (e.g. your desktop), you can run on more
|
||||
(virtual) processors than you have physical processors.
|
||||
|
||||
To run multiple independent simulations from one input script, using
|
||||
To run multiple independent simulatoins from one input script, using
|
||||
multiple partitions, see "Section 6.4"_Section_howto.html#howto_4
|
||||
of the manual. World- and universe-style "variables"_variable.html
|
||||
are useful in this context.
|
||||
@ -1712,7 +1576,7 @@ negative numeric value. It is OK if the first value1 starts with a
|
||||
|
||||
:line
|
||||
|
||||
2.8 LAMMPS screen output :h4,link(start_8)
|
||||
2.7 LAMMPS screen output :h4,link(start_7)
|
||||
|
||||
As LAMMPS reads an input script, it prints information to both the
|
||||
screen and a log file about significant actions it takes to setup a
|
||||
@ -1760,7 +1624,7 @@ The first section provides a global loop timing summary. The {loop time}
|
||||
is the total wall time for the section. The {Performance} line is
|
||||
provided for convenience to help predicting the number of loop
|
||||
continuations required and for comparing performance with other,
|
||||
similar MD codes. The {CPU use} line provides the CPU utilization per
|
||||
similar MD codes. The {CPU use} line provides the CPU utilzation per
|
||||
MPI task; it should be close to 100% times the number of OpenMP
|
||||
threads (or 1 of no OpenMP). Lower numbers correspond to delays due
|
||||
to file I/O or insufficient thread utilization.
|
||||
@ -1868,7 +1732,7 @@ communication, roughly 75% in the example above.
|
||||
|
||||
:line
|
||||
|
||||
2.9 Tips for users of previous LAMMPS versions :h4,link(start_9)
|
||||
2.8 Tips for users of previous LAMMPS versions :h4,link(start_8)
|
||||
|
||||
The current C++ began with a complete rewrite of LAMMPS 2001, which
|
||||
was written in F90. Features of earlier versions of LAMMPS are listed
|
||||
|
||||
@ -369,15 +369,18 @@ supports it. It has its own WWW page at
|
||||
|
||||
msi2lmp tool :h4,link(msi)
|
||||
|
||||
The msi2lmp sub-directory contains a tool for creating LAMMPS input
|
||||
data files from BIOVIA's Materias Studio files (formerly Accelrys'
|
||||
The msi2lmp sub-directory contains a tool for creating LAMMPS template
|
||||
input and data files from BIOVIA's Materias Studio files (formerly Accelrys'
|
||||
Insight MD code, formerly MSI/Biosym and its Discover MD code).
|
||||
|
||||
This tool was written by John Carpenter (Cray), Michael Peachey
|
||||
(Cray), and Steve Lustig (Dupont). Several people contributed changes
|
||||
to remove bugs and adapt its output to changes in LAMMPS.
|
||||
|
||||
See the README file for more information.
|
||||
This tool has several known limitations and is no longer under active
|
||||
development, so there are no changes except for the occasional bugfix.
|
||||
|
||||
See the README file in the tools/msi2lmp folder for more information.
|
||||
|
||||
:line
|
||||
|
||||
|
||||
@ -69,8 +69,9 @@ not {hardware thread}.
|
||||
For Intel Xeon CPUs:
|
||||
|
||||
Edit src/MAKE/OPTIONS/Makefile.intel_cpu_intelmpi as necessary. :ulb,l
|
||||
If using {kspace_style pppm} in the input script, add "neigh_modify binsize 3" and "kspace_modify diff ad" to the input script for better
|
||||
performance. :l
|
||||
If using {kspace_style pppm} in the input script, add "neigh_modify binsize cutoff" and "kspace_modify diff ad" to the input script for better
|
||||
performance. Cutoff should be roughly the neighbor list cutoff. By
|
||||
default the binsize is half the neighbor list cutoff. :l
|
||||
"-pk intel 0 omp 2 -sf intel" added to LAMMPS command-line :l
|
||||
:ule
|
||||
|
||||
|
||||
@ -415,15 +415,15 @@ For binding threads with the KOKKOS OMP option, use thread affinity
|
||||
environment variables to force binding. With OpenMP 3.1 (gcc 4.7 or
|
||||
later, intel 12 or later) setting the environment variable
|
||||
OMP_PROC_BIND=true should be sufficient. For binding threads with the
|
||||
KOKKOS pthreads option, compile LAMMPS the KOKKOS HWLOC=yes option, as
|
||||
discussed in "Section 2.3.4"_Sections_start.html#start_3_4 of the
|
||||
manual.
|
||||
KOKKOS pthreads option, compile LAMMPS the KOKKOS HWLOC=yes option
|
||||
(see "this section"_Section_packages.html#KOKKOS of the manual for
|
||||
details).
|
||||
|
||||
[Running on GPUs:]
|
||||
|
||||
Insure the -arch setting in the machine makefile you are using,
|
||||
e.g. src/MAKE/Makefile.cuda, is correct for your GPU hardware/software
|
||||
(see "this section"_Section_start.html#start_3_4 of the manual for
|
||||
e.g. src/MAKE/Makefile.cuda, is correct for your GPU hardware/software.
|
||||
(see "this section"_Section_packages.html#KOKKOS of the manual for
|
||||
details).
|
||||
|
||||
The -np setting of the mpirun command should set the number of MPI
|
||||
|
||||
@ -46,7 +46,7 @@ from the pair_style.
|
||||
[Restrictions:]
|
||||
|
||||
This angle style can only be used if LAMMPS was built with the
|
||||
USER-CG-CMM package. See the "Making
|
||||
USER-CGSDK package. See the "Making
|
||||
LAMMPS"_Section_start.html#start_3 section for more info on packages.
|
||||
|
||||
[Related commands:]
|
||||
|
||||
@ -7,19 +7,24 @@
|
||||
:line
|
||||
|
||||
bond_style oxdna/fene command :h3
|
||||
bond_style oxdna2/fene command :h3
|
||||
|
||||
[Syntax:]
|
||||
|
||||
bond_style oxdna/fene :pre
|
||||
bond_style oxdna2/fene :pre
|
||||
|
||||
[Examples:]
|
||||
|
||||
bond_style oxdna/fene
|
||||
bond_coeff * 2.0 0.25 0.7525 :pre
|
||||
|
||||
bond_style oxdna2/fene
|
||||
bond_coeff * 2.0 0.25 0.7564 :pre
|
||||
|
||||
[Description:]
|
||||
|
||||
The {oxdna/fene} bond style uses the potential
|
||||
The {oxdna/fene} and {oxdna2/fene} bond styles use the potential
|
||||
|
||||
:c,image(Eqs/bond_oxdna_fene.jpg)
|
||||
|
||||
@ -36,13 +41,14 @@ epsilon (energy)
|
||||
Delta (distance)
|
||||
r0 (distance) :ul
|
||||
|
||||
NOTE: This bond style has to be used together with the corresponding oxDNA pair styles
|
||||
NOTE: The oxDNA bond style has to be used together with the corresponding oxDNA pair styles
|
||||
for excluded volume interaction {oxdna/excv}, stacking {oxdna/stk}, cross-stacking {oxdna/xstk}
|
||||
and coaxial stacking interaction {oxdna/coaxstk} as well as hydrogen-bonding interaction {oxdna/hbond} (see also documentation of
|
||||
"pair_style oxdna/excv"_pair_oxdna.html). The coefficients
|
||||
in the above example have to be kept fixed and cannot be changed without reparametrizing the entire model.
|
||||
"pair_style oxdna/excv"_pair_oxdna.html). For the oxDNA2 "(Snodin)"_#oxdna2 bond style the analogous pair styles and an additional Debye-Hueckel pair
|
||||
style {oxdna2/dh} have to be defined.
|
||||
The coefficients in the above example have to be kept fixed and cannot be changed without reparametrizing the entire model.
|
||||
|
||||
Example input and data files can be found in examples/USER/cgdna/examples/duplex1/ and /duplex2/.
|
||||
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/.
|
||||
A technical report with more information on the model, the structure of the input file,
|
||||
@ -60,7 +66,7 @@ LAMMPS"_Section_start.html#start_3 section for more info on packages.
|
||||
|
||||
[Related commands:]
|
||||
|
||||
"pair_style oxdna/excv"_pair_oxdna.html, "fix nve/dotc/langevin"_fix_nve_dotc_langevin.html, "bond_coeff"_bond_coeff.html
|
||||
"pair_style oxdna/excv"_pair_oxdna.html, "pair_style oxdna2/excv"_pair_oxdna2.html, "fix nve/dotc/langevin"_fix_nve_dotc_langevin.html, "bond_coeff"_bond_coeff.html
|
||||
|
||||
[Default:] none
|
||||
|
||||
@ -68,3 +74,6 @@ LAMMPS"_Section_start.html#start_3 section for more info on packages.
|
||||
|
||||
:link(oxdna_fene)
|
||||
[(Ouldridge)] T.E. Ouldridge, A.A. Louis, J.P.K. Doye, J. Chem. Phys. 134, 085101 (2011).
|
||||
|
||||
:link(oxdna2)
|
||||
[(Snodin)] B.E. Snodin, F. Randisi, M. Mosayebi, et al., J. Chem. Phys. 142, 234901 (2015).
|
||||
|
||||
@ -32,12 +32,12 @@ Commands :h1
|
||||
dimension
|
||||
displace_atoms
|
||||
dump
|
||||
dump_custom_vtk
|
||||
dump_h5md
|
||||
dump_image
|
||||
dump_modify
|
||||
dump_molfile
|
||||
dump_nc
|
||||
dump_netcdf
|
||||
dump_vtk
|
||||
echo
|
||||
fix
|
||||
fix_modify
|
||||
|
||||
@ -54,7 +54,7 @@ adding atoms or molecules to the system (see the "fix
|
||||
pour"_fix_pour.html, "fix deposit"_fix_deposit.html, and "fix
|
||||
gcmc"_fix_gcmc.html commands) or expect atoms or molecules to be lost
|
||||
(e.g. due to exiting the simulation box or via "fix
|
||||
evaporation"_fix_evaporation.html), then this option should be used to
|
||||
evaporate"_fix_evaporate.html), then this option should be used to
|
||||
insure the temperature is correctly normalized.
|
||||
|
||||
NOTE: The {extra} and {dynamic} keywords should not be used as they
|
||||
|
||||
@ -24,7 +24,7 @@ twojmax = band limit for bispectrum components (non-negative integer) :l
|
||||
R_1, R_2,... = list of cutoff radii, one for each type (distance units) :l
|
||||
w_1, w_2,... = list of neighbor weights, one for each type :l
|
||||
zero or more keyword/value pairs may be appended :l
|
||||
keyword = {diagonal} or {rmin0} or {switchflag} or {bzeroflag} :l
|
||||
keyword = {diagonal} or {rmin0} or {switchflag} or {bzeroflag} or {quadraticflag}:l
|
||||
{diagonal} value = {0} or {1} or {2} or {3}
|
||||
{0} = all j1, j2, j <= twojmax, j2 <= j1
|
||||
{1} = subset satisfying j1 == j2
|
||||
@ -36,7 +36,10 @@ keyword = {diagonal} or {rmin0} or {switchflag} or {bzeroflag} :l
|
||||
{1} = use switching function
|
||||
{bzeroflag} value = {0} or {1}
|
||||
{0} = do not subtract B0
|
||||
{1} = subtract B0 :pre
|
||||
{1} = subtract B0
|
||||
{quadraticflag} value = {0} or {1}
|
||||
{0} = do not generate quadratic terms
|
||||
{1} = generate quadratic terms :pre
|
||||
:ule
|
||||
|
||||
[Examples:]
|
||||
@ -151,7 +154,7 @@ linear mapping from radial distance to polar angle {theta0} on the
|
||||
The argument {twojmax} and the keyword {diagonal} define which
|
||||
bispectrum components are generated. See section below on output for a
|
||||
detailed explanation of the number of bispectrum components and the
|
||||
ordered in which they are listed
|
||||
ordered in which they are listed.
|
||||
|
||||
The keyword {switchflag} can be used to turn off the switching
|
||||
function.
|
||||
@ -162,6 +165,14 @@ the calculated bispectrum components. This optional keyword is only
|
||||
available for compute {sna/atom}, as {snad/atom} and {snav/atom}
|
||||
are unaffected by the removal of constant terms.
|
||||
|
||||
The keyword {quadraticflag} determines whether or not the
|
||||
quadratic analogs to the bispectrum quantities are generated.
|
||||
These are formed by taking the outer product of the vector
|
||||
of bispectrum components with itself.
|
||||
See section below on output for a
|
||||
detailed explanation of the number of quadratic terms and the
|
||||
ordered in which they are listed.
|
||||
|
||||
NOTE: If you have a bonded system, then the settings of
|
||||
"special_bonds"_special_bonds.html command can remove pairwise
|
||||
interactions between atoms in the same bond, angle, or dihedral. This
|
||||
@ -180,7 +191,7 @@ command that includes all pairs in the neighbor list.
|
||||
|
||||
Compute {sna/atom} calculates a per-atom array, each column
|
||||
corresponding to a particular bispectrum component. The total number
|
||||
of columns and the identities of the bispectrum component contained in
|
||||
of columns and the identity of the bispectrum component contained in
|
||||
each column depend on the values of {twojmax} and {diagonal}, as
|
||||
described by the following piece of python code:
|
||||
|
||||
@ -213,6 +224,19 @@ block contains six sub-blocks corresponding to the {xx}, {yy}, {zz},
|
||||
notation. Each of these sub-blocks contains one column for each
|
||||
bispectrum component, the same as for compute {sna/atom}
|
||||
|
||||
For example, if {K}=30 and ntypes=1, the number of columns in the per-atom
|
||||
arrays generated by {sna/atom}, {snad/atom}, and {snav/atom}
|
||||
are 30, 90, and 180, respectively. With {quadratic} value=1,
|
||||
the numbers of columns are 930, 2790, and 5580, respectively.
|
||||
|
||||
If the {quadratic} keyword value is set to 1, then additional
|
||||
columns are appended to each per-atom array, corresponding to
|
||||
a matrix of quantities that are products of two bispectrum components. If the
|
||||
number of bispectrum components is {K}, then the number of matrix elements
|
||||
is {K}^2. These are output in subblocks of {K}^2 columns, using the same
|
||||
ordering of columns and sub-blocks as was used for the bispectrum
|
||||
components.
|
||||
|
||||
These values can be accessed by any command that uses per-atom values
|
||||
from a compute as input. See "Section
|
||||
6.15"_Section_howto.html#howto_15 for an overview of LAMMPS output
|
||||
@ -231,7 +255,7 @@ LAMMPS"_Section_start.html#start_3 section for more info.
|
||||
[Default:]
|
||||
|
||||
The optional keyword defaults are {diagonal} = 0, {rmin0} = 0,
|
||||
{switchflag} = 1, {bzeroflag} = 0.
|
||||
{switchflag} = 1, {bzeroflag} = 1, {quadraticflag} = 0,
|
||||
|
||||
:line
|
||||
|
||||
|
||||
@ -10,25 +10,25 @@ dihedral_style charmm command :h3
|
||||
dihedral_style charmm/intel command :h3
|
||||
dihedral_style charmm/kk command :h3
|
||||
dihedral_style charmm/omp command :h3
|
||||
dihedral_style charmmfsh command :h3
|
||||
dihedral_style charmmfsw command :h3
|
||||
|
||||
[Syntax:]
|
||||
|
||||
dihedral_style style :pre
|
||||
|
||||
style = {charmm} or {charmmfsh} :ul
|
||||
style = {charmm} or {charmmfsw} :ul
|
||||
|
||||
[Examples:]
|
||||
|
||||
dihedral_style charmm
|
||||
dihedral_style charmmfsh
|
||||
dihedral_style charmmfsw
|
||||
dihedral_coeff 1 0.2 1 180 1.0
|
||||
dihedral_coeff 2 1.8 1 0 1.0
|
||||
dihedral_coeff 1 3.1 2 180 0.5 :pre
|
||||
|
||||
[Description:]
|
||||
|
||||
The {charmm} and {charmmfsh} dihedral styles use the potential
|
||||
The {charmm} and {charmmfsw} dihedral styles use the potential
|
||||
|
||||
:c,image(Eqs/dihedral_charmm.jpg)
|
||||
|
||||
@ -38,10 +38,15 @@ field (see comment on weighting factors below). See
|
||||
"(Cornell)"_#dihedral-Cornell for a description of the AMBER force
|
||||
field.
|
||||
|
||||
NOTE: The newer {charmmfsh} style was released in March 2017. We
|
||||
NOTE: The newer {charmmfsw} style was released in March 2017. We
|
||||
recommend it be used instead of the older {charmm} style when running
|
||||
a simulation with the CHARMM force field. See the discussion below
|
||||
and more details on the "pair_style charmm"_pair_charmm.html doc page.
|
||||
a simulation with the CHARMM force field, either with long-range
|
||||
Coulombics or a Coulomb cutoff, via the "pair_style
|
||||
lj/charmmfsw/coul/long"_pair_charmm.html and "pair_style
|
||||
lj/charmmfsw/coul/charmmfsh"_pair_charmm.html commands respectively.
|
||||
Otherwise the older {charmm} style is fine to use. See the discussion
|
||||
below and more details on the "pair_style charmm"_pair_charmm.html doc
|
||||
page.
|
||||
|
||||
The following coefficients must be defined for each dihedral type via the
|
||||
"dihedral_coeff"_dihedral_coeff.html command as in the example above, or in
|
||||
@ -82,13 +87,19 @@ special_bonds 1-4 scaling factor to 0.0 (which is the
|
||||
default). Otherwise 1-4 non-bonded interactions in dihedrals will be
|
||||
computed twice.
|
||||
|
||||
For simulations using the CHARMM force field, the difference between
|
||||
the {charmm} and {charmmfsh} styles is in the computation of the 1-4
|
||||
non-bond interactions, if the distance between the two atoms is within
|
||||
the switching distance of the pairwise potential defined by the
|
||||
corresponding CHARMM pair style, i.e. between the inner and outer
|
||||
cutoffs specified for the pair style. See the discussion on the
|
||||
"CHARMM pair_style"_pair_charmm.html doc page for details.
|
||||
For simulations using the CHARMM force field with a Coulomb cutoff,
|
||||
the difference between the {charmm} and {charmmfsw} styles is in the
|
||||
computation of the 1-4 non-bond interactions, though only if the
|
||||
distance between the two atoms is within the switching region of the
|
||||
pairwise potential defined by the corresponding CHARMM pair style,
|
||||
i.e. within the outer cutoff specified for the pair style. The
|
||||
{charmmfsw} style should only be used when using the corresponding
|
||||
"pair_style lj/charmmfsw/coul/charmmfsw"_pair_charmm.html or
|
||||
"pair_style lj/charmmfsw/coul/long"_pair_charmm.html commands. Use
|
||||
the {charmm} style with the older "pair_style"_pair_charmm.html
|
||||
commands that have just "charmm" in their style name. See the
|
||||
discussion on the "CHARMM pair_style"_pair_charmm.html doc page for
|
||||
details.
|
||||
|
||||
Note that for AMBER force fields, which use pair styles with "lj/cut",
|
||||
the special_bonds 1-4 scaling factor should be set to the AMBER
|
||||
@ -96,7 +107,7 @@ defaults (1/2 and 5/6) and all the dihedral weighting factors (4th
|
||||
coeff above) must be set to 0.0. In this case, you can use any pair
|
||||
style you wish, since the dihedral does not need any Lennard-Jones
|
||||
parameter information and will not compute any 1-4 non-bonded
|
||||
interactions. Likewise the {charmm} or {charmmfsh} styles are
|
||||
interactions. Likewise the {charmm} or {charmmfsw} styles are
|
||||
identical in this case since no 1-4 non-bonded interactions are
|
||||
computed.
|
||||
|
||||
|
||||
@ -14,10 +14,10 @@ dihedral_style spherical :pre
|
||||
|
||||
[Examples:]
|
||||
|
||||
dihedral_coeff 1 1 286.1 1 124 1 1 90.0 0 1 90.0 0
|
||||
dihedral_coeff 1 3 286.1 1 114 1 1 90 0 1 90.0 0 &
|
||||
17.3 0 0.0 0 1 158 1 0 0.0 0 &
|
||||
15.1 0 0.0 0 0 0.0 0 1 167.3 1 :pre
|
||||
dihedral_coeff 1 1 286.1 1 124 1 1 90.0 0 1 90.0 0
|
||||
dihedral_coeff 1 3 69.3 1 93.9 1 1 90 0 1 90 0 &
|
||||
49.1 0 0.00 0 1 74.4 1 0 0.00 0 &
|
||||
25.2 0 0.00 0 0 0.00 0 1 48.1 1
|
||||
|
||||
[Description:]
|
||||
|
||||
@ -35,13 +35,14 @@ the dihedral interaction even if it requires adding additional terms to
|
||||
the expansion (as was done in the second example). A careful choice of
|
||||
parameters can prevent singularities that occur with traditional
|
||||
force-fields whenever theta1 or theta2 approach 0 or 180 degrees.
|
||||
|
||||
The last example above corresponds to an interaction with a single energy
|
||||
minima located at phi=114, theta1=158, theta2=167.3 degrees, and it remains
|
||||
minima located near phi=93.9, theta1=74.4, theta2=48.1 degrees, and it remains
|
||||
numerically stable at all angles (phi, theta1, theta2). In this example,
|
||||
the coefficients 17.3, and 15.1 can be physically interpreted as the
|
||||
the coefficients 49.1, and 25.2 can be physically interpreted as the
|
||||
harmonic spring constants for theta1 and theta2 around their minima.
|
||||
The coefficient 286.1 is the harmonic spring constant for phi after
|
||||
division by sin(158)*sin(167.3) (the minima positions for theta1 and theta2).
|
||||
The coefficient 69.3 is the harmonic spring constant for phi after
|
||||
division by sin(74.4)*sin(48.1) (the minima positions for theta1 and theta2).
|
||||
|
||||
The following coefficients must be defined for each dihedral type via the
|
||||
"dihedral_coeff"_dihedral_coeff.html command as in the example above, or in
|
||||
|
||||
@ -7,12 +7,12 @@
|
||||
:line
|
||||
|
||||
dump command :h3
|
||||
"dump custom/vtk"_dump_custom_vtk.html command :h3
|
||||
"dump vtk"_dump_vtk.html command :h3
|
||||
"dump h5md"_dump_h5md.html command :h3
|
||||
"dump molfile"_dump_molfile.html command :h3
|
||||
"dump netcdf"_dump_netcdf.html command :h3
|
||||
"dump image"_dump_image.html command :h3
|
||||
"dump movie"_dump_image.html command :h3
|
||||
"dump molfile"_dump_molfile.html command :h3
|
||||
"dump nc"_dump_nc.html command :h3
|
||||
|
||||
[Syntax:]
|
||||
|
||||
@ -20,7 +20,7 @@ dump ID group-ID style N file args :pre
|
||||
|
||||
ID = user-assigned name for the dump :ulb,l
|
||||
group-ID = ID of the group of atoms to be dumped :l
|
||||
style = {atom} or {atom/gz} or {atom/mpiio} or {cfg} or {cfg/gz} or {cfg/mpiio} or {dcd} or {xtc} or {xyz} or {xyz/gz} or {xyz/mpiio} or {h5md} or {image} or {movie} or {molfile} or {local} or {custom} or {custom/gz} or {custom/mpiio} :l
|
||||
style = {atom} or {atom/gz} or {atom/mpiio} or {cfg} or {cfg/gz} or {cfg/mpiio} or {custom} or {custom/gz} or {custom/mpiio} or {dcd} or {h5md} or {image} or or {local} or {molfile} or {movie} or {netcdf} or {netcdf/mpiio} or {vtk} or {xtc} or {xyz} or {xyz/gz} or {xyz/mpiio} :l
|
||||
N = dump every this many timesteps :l
|
||||
file = name of file to write dump info to :l
|
||||
args = list of arguments for a particular style :l
|
||||
@ -30,33 +30,22 @@ args = list of arguments for a particular style :l
|
||||
{cfg} args = same as {custom} args, see below
|
||||
{cfg/gz} args = same as {custom} args, see below
|
||||
{cfg/mpiio} args = same as {custom} args, see below
|
||||
{custom}, {custom/gz}, {custom/mpiio} args = see below
|
||||
{dcd} args = none
|
||||
{h5md} args = discussed on "dump h5md"_dump_h5md.html doc page
|
||||
{image} args = discussed on "dump image"_dump_image.html doc page
|
||||
{local} args = see below
|
||||
{molfile} args = discussed on "dump molfile"_dump_molfile.html doc page
|
||||
{movie} args = discussed on "dump image"_dump_image.html doc page
|
||||
{netcdf} args = discussed on "dump netcdf"_dump_netcdf.html doc page
|
||||
{netcdf/mpiio} args = discussed on "dump netcdf"_dump_netcdf.html doc page
|
||||
{vtk} args = same as {custom} args, see below, also "dump vtk"_dump_vtk.html doc page
|
||||
{xtc} args = none
|
||||
{xyz} args = none :pre
|
||||
{xyz/gz} args = none :pre
|
||||
{xyz} args = none
|
||||
{xyz/gz} args = none
|
||||
{xyz/mpiio} args = none :pre
|
||||
|
||||
{custom/vtk} args = similar to custom args below, discussed on "dump custom/vtk"_dump_custom_vtk.html doc page :pre
|
||||
|
||||
{h5md} args = discussed on "dump h5md"_dump_h5md.html doc page :pre
|
||||
|
||||
{image} args = discussed on "dump image"_dump_image.html doc page :pre
|
||||
|
||||
{movie} args = discussed on "dump image"_dump_image.html doc page :pre
|
||||
|
||||
{molfile} args = discussed on "dump molfile"_dump_molfile.html doc page
|
||||
|
||||
{nc} args = discussed on "dump nc"_dump_nc.html doc page :pre
|
||||
|
||||
{local} args = list of local attributes
|
||||
possible attributes = index, c_ID, c_ID\[I\], f_ID, f_ID\[I\]
|
||||
index = enumeration of local values
|
||||
c_ID = local vector calculated by a compute with ID
|
||||
c_ID\[I\] = Ith column of local array calculated by a compute with ID, I can include wildcard (see below)
|
||||
f_ID = local vector calculated by a fix with ID
|
||||
f_ID\[I\] = Ith column of local array calculated by a fix with ID, I can include wildcard (see below) :pre
|
||||
|
||||
{custom} or {custom/gz} or {custom/mpiio} args = list of atom attributes
|
||||
{custom} or {custom/gz} or {custom/mpiio} args = list of atom attributes :l
|
||||
possible attributes = id, mol, proc, procp1, type, element, mass,
|
||||
x, y, z, xs, ys, zs, xu, yu, zu,
|
||||
xsu, ysu, zsu, ix, iy, iz,
|
||||
@ -94,6 +83,15 @@ args = list of arguments for a particular style :l
|
||||
v_name = per-atom vector calculated by an atom-style variable with name
|
||||
d_name = per-atom floating point vector with name, managed by fix property/atom
|
||||
i_name = per-atom integer vector with name, managed by fix property/atom :pre
|
||||
|
||||
{local} args = list of local attributes :l
|
||||
possible attributes = index, c_ID, c_ID\[I\], f_ID, f_ID\[I\]
|
||||
index = enumeration of local values
|
||||
c_ID = local vector calculated by a compute with ID
|
||||
c_ID\[I\] = Ith column of local array calculated by a compute with ID, I can include wildcard (see below)
|
||||
f_ID = local vector calculated by a fix with ID
|
||||
f_ID\[I\] = Ith column of local array calculated by a fix with ID, I can include wildcard (see below) :pre
|
||||
|
||||
:ule
|
||||
|
||||
[Examples:]
|
||||
@ -331,10 +329,7 @@ bonds and colors.
|
||||
|
||||
Note that {atom}, {custom}, {dcd}, {xtc}, and {xyz} style dump files
|
||||
can be read directly by "VMD"_http://www.ks.uiuc.edu/Research/vmd, a
|
||||
popular molecular viewing program. See
|
||||
"Section 9"_Section_tools.html#vmd of the manual and the
|
||||
tools/lmp2vmd/README.txt file for more information about support in
|
||||
VMD for reading and visualizing LAMMPS dump files.
|
||||
popular molecular viewing program.
|
||||
|
||||
:line
|
||||
|
||||
|
||||
@ -1,339 +0,0 @@
|
||||
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
dump custom/vtk command :h3
|
||||
|
||||
[Syntax:]
|
||||
|
||||
dump ID group-ID style N file args :pre
|
||||
|
||||
ID = user-assigned name for the dump :ulb,l
|
||||
group-ID = ID of the group of atoms to be dumped :l
|
||||
style = {custom/vtk} :l
|
||||
N = dump every this many timesteps :l
|
||||
file = name of file to write dump info to :l
|
||||
args = list of arguments for a particular style :l
|
||||
{custom/vtk} args = list of atom attributes
|
||||
possible attributes = id, mol, proc, procp1, type, element, mass,
|
||||
x, y, z, xs, ys, zs, xu, yu, zu,
|
||||
xsu, ysu, zsu, ix, iy, iz,
|
||||
vx, vy, vz, fx, fy, fz,
|
||||
q, mux, muy, muz, mu,
|
||||
radius, diameter, omegax, omegay, omegaz,
|
||||
angmomx, angmomy, angmomz, tqx, tqy, tqz,
|
||||
spin, eradius, ervel, erforce,
|
||||
c_ID, c_ID\[N\], f_ID, f_ID\[N\], v_name :pre
|
||||
|
||||
id = atom ID
|
||||
mol = molecule ID
|
||||
proc = ID of processor that owns atom
|
||||
procp1 = ID+1 of processor that owns atom
|
||||
type = atom type
|
||||
element = name of atom element, as defined by "dump_modify"_dump_modify.html command
|
||||
mass = atom mass
|
||||
x,y,z = unscaled atom coordinates
|
||||
xs,ys,zs = scaled atom coordinates
|
||||
xu,yu,zu = unwrapped atom coordinates
|
||||
xsu,ysu,zsu = scaled unwrapped atom coordinates
|
||||
ix,iy,iz = box image that the atom is in
|
||||
vx,vy,vz = atom velocities
|
||||
fx,fy,fz = forces on atoms
|
||||
q = atom charge
|
||||
mux,muy,muz = orientation of dipole moment of atom
|
||||
mu = magnitude of dipole moment of atom
|
||||
radius,diameter = radius,diameter of spherical particle
|
||||
omegax,omegay,omegaz = angular velocity of spherical particle
|
||||
angmomx,angmomy,angmomz = angular momentum of aspherical particle
|
||||
tqx,tqy,tqz = torque on finite-size particles
|
||||
c_ID = per-atom vector calculated by a compute with ID
|
||||
c_ID\[N\] = Nth column of per-atom array calculated by a compute with ID
|
||||
f_ID = per-atom vector calculated by a fix with ID
|
||||
f_ID\[N\] = Nth column of per-atom array calculated by a fix with ID
|
||||
v_name = per-atom vector calculated by an atom-style variable with name :pre
|
||||
:ule
|
||||
|
||||
[Examples:]
|
||||
|
||||
dump dmpvtk all custom/vtk 100 dump*.myforce.vtk id type vx fx
|
||||
dump dmpvtp flow custom/vtk 100 dump*.%.displace.vtp id type c_myD\[1\] c_myD\[2\] c_myD\[3\] v_ke
|
||||
dump e_data all custom/vtk 100 dump*.vtu id type spin eradius fx fy fz eforce :pre
|
||||
|
||||
The style {custom/vtk} is similar to the "custom"_dump.html style but
|
||||
uses the VTK library to write data to VTK simple legacy or XML format
|
||||
depending on the filename extension specified. This can be either
|
||||
{*.vtk} for the legacy format or {*.vtp} and {*.vtu}, respectively,
|
||||
for the XML format; see the "VTK
|
||||
homepage"_http://www.vtk.org/VTK/img/file-formats.pdf for a detailed
|
||||
description of these formats. Since this naming convention conflicts
|
||||
with the way binary output is usually specified (see below),
|
||||
"dump_modify binary"_dump_modify.html allows to set the binary
|
||||
flag for this dump style explicitly.
|
||||
|
||||
[Description:]
|
||||
|
||||
Dump a snapshot of atom quantities to one or more files every N
|
||||
timesteps in a format readable by the "VTK visualization
|
||||
toolkit"_http://www.vtk.org or other visualization tools that use it,
|
||||
e.g. "ParaView"_http://www.paraview.org. The timesteps on which dump
|
||||
output is written can also be controlled by a variable; see the
|
||||
"dump_modify every"_dump_modify.html command for details.
|
||||
|
||||
Only information for atoms in the specified group is dumped. The
|
||||
"dump_modify thresh and region"_dump_modify.html commands can also
|
||||
alter what atoms are included; see details below.
|
||||
|
||||
As described below, special characters ("*", "%") in the filename
|
||||
determine the kind of output.
|
||||
|
||||
IMPORTANT NOTE: Because periodic boundary conditions are enforced only
|
||||
on timesteps when neighbor lists are rebuilt, the coordinates of an
|
||||
atom written to a dump file may be slightly outside the simulation
|
||||
box.
|
||||
|
||||
IMPORTANT NOTE: Unless the "dump_modify sort"_dump_modify.html
|
||||
option is invoked, the lines of atom information written to dump files
|
||||
will be in an indeterminate order for each snapshot. This is even
|
||||
true when running on a single processor, if the "atom_modify
|
||||
sort"_atom_modify.html option is on, which it is by default. In this
|
||||
case atoms are re-ordered periodically during a simulation, due to
|
||||
spatial sorting. It is also true when running in parallel, because
|
||||
data for a single snapshot is collected from multiple processors, each
|
||||
of which owns a subset of the atoms.
|
||||
|
||||
For the {custom/vtk} style, sorting is off by default. See the
|
||||
"dump_modify"_dump_modify.html doc page for details.
|
||||
|
||||
:line
|
||||
|
||||
The dimensions of the simulation box are written to a separate file
|
||||
for each snapshot (either in legacy VTK or XML format depending on
|
||||
the format of the main dump file) with the suffix {_boundingBox}
|
||||
appended to the given dump filename.
|
||||
|
||||
For an orthogonal simulation box this information is saved as a
|
||||
rectilinear grid (legacy .vtk or .vtr XML format).
|
||||
|
||||
Triclinic simulation boxes (non-orthogonal) are saved as
|
||||
hexahedrons in either legacy .vtk or .vtu XML format.
|
||||
|
||||
Style {custom/vtk} allows you to specify a list of atom attributes
|
||||
to be written to the dump file for each atom. Possible attributes
|
||||
are listed above. In contrast to the {custom} style, the attributes
|
||||
are rearranged to ensure correct ordering of vector components
|
||||
(except for computes and fixes - these have to be given in the right
|
||||
order) and duplicate entries are removed.
|
||||
|
||||
You cannot specify a quantity that is not defined for a particular
|
||||
simulation - such as {q} for atom style {bond}, since that atom style
|
||||
doesn't assign charges. Dumps occur at the very end of a timestep,
|
||||
so atom attributes will include effects due to fixes that are applied
|
||||
during the timestep. An explanation of the possible dump custom/vtk attributes
|
||||
is given below. Since position data is required to write VTK files "x y z"
|
||||
do not have to be specified explicitly.
|
||||
|
||||
The VTK format uses a single snapshot of the system per file, thus
|
||||
a wildcard "*" must be included in the filename, as discussed below.
|
||||
Otherwise the dump files will get overwritten with the new snapshot
|
||||
each time.
|
||||
|
||||
:line
|
||||
|
||||
Dumps are performed on timesteps that are a multiple of N (including
|
||||
timestep 0) and on the last timestep of a minimization if the
|
||||
minimization converges. Note that this means a dump will not be
|
||||
performed on the initial timestep after the dump command is invoked,
|
||||
if the current timestep is not a multiple of N. This behavior can be
|
||||
changed via the "dump_modify first"_dump_modify.html command, which
|
||||
can also be useful if the dump command is invoked after a minimization
|
||||
ended on an arbitrary timestep. N can be changed between runs by
|
||||
using the "dump_modify every"_dump_modify.html command.
|
||||
The "dump_modify every"_dump_modify.html command
|
||||
also allows a variable to be used to determine the sequence of
|
||||
timesteps on which dump files are written. In this mode a dump on the
|
||||
first timestep of a run will also not be written unless the
|
||||
"dump_modify first"_dump_modify.html command is used.
|
||||
|
||||
Dump filenames can contain two wildcard characters. If a "*"
|
||||
character appears in the filename, then one file per snapshot is
|
||||
written and the "*" character is replaced with the timestep value.
|
||||
For example, tmp.dump*.vtk becomes tmp.dump0.vtk, tmp.dump10000.vtk,
|
||||
tmp.dump20000.vtk, etc. Note that the "dump_modify pad"_dump_modify.html
|
||||
command can be used to insure all timestep numbers are the same length
|
||||
(e.g. 00010), which can make it easier to read a series of dump files
|
||||
in order with some post-processing tools.
|
||||
|
||||
If a "%" character appears in the filename, then each of P processors
|
||||
writes a portion of the dump file, and the "%" character is replaced
|
||||
with the processor ID from 0 to P-1 preceded by an underscore character.
|
||||
For example, tmp.dump%.vtp becomes tmp.dump_0.vtp, tmp.dump_1.vtp, ...
|
||||
tmp.dump_P-1.vtp, etc. This creates smaller files and can be a fast
|
||||
mode of output on parallel machines that support parallel I/O for output.
|
||||
|
||||
By default, P = the number of processors meaning one file per
|
||||
processor, but P can be set to a smaller value via the {nfile} or
|
||||
{fileper} keywords of the "dump_modify"_dump_modify.html command.
|
||||
These options can be the most efficient way of writing out dump files
|
||||
when running on large numbers of processors.
|
||||
|
||||
For the legacy VTK format "%" is ignored and P = 1, i.e., only
|
||||
processor 0 does write files.
|
||||
|
||||
Note that using the "*" and "%" characters together can produce a
|
||||
large number of small dump files!
|
||||
|
||||
If {dump_modify binary} is used, the dump file (or files, if "*" or
|
||||
"%" is also used) is written in binary format. A binary dump file
|
||||
will be about the same size as a text version, but will typically
|
||||
write out much faster.
|
||||
|
||||
:line
|
||||
|
||||
This section explains the atom attributes that can be specified as
|
||||
part of the {custom/vtk} style.
|
||||
|
||||
The {id}, {mol}, {proc}, {procp1}, {type}, {element}, {mass}, {vx},
|
||||
{vy}, {vz}, {fx}, {fy}, {fz}, {q} attributes are self-explanatory.
|
||||
|
||||
{id} is the atom ID. {mol} is the molecule ID, included in the data
|
||||
file for molecular systems. {type} is the atom type. {element} is
|
||||
typically the chemical name of an element, which you must assign to
|
||||
each type via the "dump_modify element"_dump_modify.html command.
|
||||
More generally, it can be any string you wish to associate with an
|
||||
atom type. {mass} is the atom mass. {vx}, {vy}, {vz}, {fx}, {fy},
|
||||
{fz}, and {q} are components of atom velocity and force and atomic
|
||||
charge.
|
||||
|
||||
There are several options for outputting atom coordinates. The {x},
|
||||
{y}, {z} attributes are used to write atom coordinates "unscaled", in
|
||||
the appropriate distance "units"_units.html (Angstroms, sigma, etc).
|
||||
Additionally, you can use {xs}, {ys}, {zs} if you want to also save the
|
||||
coordinates "scaled" to the box size, so that each value is 0.0 to
|
||||
1.0. If the simulation box is triclinic (tilted), then all atom
|
||||
coords will still be between 0.0 and 1.0. Use {xu}, {yu}, {zu} if you
|
||||
want the coordinates "unwrapped" by the image flags for each atom.
|
||||
Unwrapped means that if the atom has passed through a periodic
|
||||
boundary one or more times, the value is printed for what the
|
||||
coordinate would be if it had not been wrapped back into the periodic
|
||||
box. Note that using {xu}, {yu}, {zu} means that the coordinate
|
||||
values may be far outside the box bounds printed with the snapshot.
|
||||
Using {xsu}, {ysu}, {zsu} is similar to using {xu}, {yu}, {zu}, except
|
||||
that the unwrapped coordinates are scaled by the box size. Atoms that
|
||||
have passed through a periodic boundary will have the corresponding
|
||||
coordinate increased or decreased by 1.0.
|
||||
|
||||
The image flags can be printed directly using the {ix}, {iy}, {iz}
|
||||
attributes. For periodic dimensions, they specify which image of the
|
||||
simulation box the atom is considered to be in. An image of 0 means
|
||||
it is inside the box as defined. A value of 2 means add 2 box lengths
|
||||
to get the true value. A value of -1 means subtract 1 box length to
|
||||
get the true value. LAMMPS updates these flags as atoms cross
|
||||
periodic boundaries during the simulation.
|
||||
|
||||
The {mux}, {muy}, {muz} attributes are specific to dipolar systems
|
||||
defined with an atom style of {dipole}. They give the orientation of
|
||||
the atom's point dipole moment. The {mu} attribute gives the
|
||||
magnitude of the atom's dipole moment.
|
||||
|
||||
The {radius} and {diameter} attributes are specific to spherical
|
||||
particles that have a finite size, such as those defined with an atom
|
||||
style of {sphere}.
|
||||
|
||||
The {omegax}, {omegay}, and {omegaz} attributes are specific to
|
||||
finite-size spherical particles that have an angular velocity. Only
|
||||
certain atom styles, such as {sphere} define this quantity.
|
||||
|
||||
The {angmomx}, {angmomy}, and {angmomz} attributes are specific to
|
||||
finite-size aspherical particles that have an angular momentum. Only
|
||||
the {ellipsoid} atom style defines this quantity.
|
||||
|
||||
The {tqx}, {tqy}, {tqz} attributes are for finite-size particles that
|
||||
can sustain a rotational torque due to interactions with other
|
||||
particles.
|
||||
|
||||
The {spin}, {eradius}, {ervel}, and {erforce} attributes are for
|
||||
particles that represent nuclei and electrons modeled with the
|
||||
electronic force field (EFF). See "atom_style
|
||||
electron"_atom_style.html and "pair_style eff"_pair_eff.html for more
|
||||
details.
|
||||
|
||||
The {c_ID} and {c_ID\[N\]} attributes allow per-atom vectors or arrays
|
||||
calculated by a "compute"_compute.html to be output. The ID in the
|
||||
attribute should be replaced by the actual ID of the compute that has
|
||||
been defined previously in the input script. See the
|
||||
"compute"_compute.html command for details. There are computes for
|
||||
calculating the per-atom energy, stress, centro-symmetry parameter,
|
||||
and coordination number of individual atoms.
|
||||
|
||||
Note that computes which calculate global or local quantities, as
|
||||
opposed to per-atom quantities, cannot be output in a dump custom/vtk
|
||||
command. Instead, global quantities can be output by the
|
||||
"thermo_style custom"_thermo_style.html command, and local quantities
|
||||
can be output by the dump local command.
|
||||
|
||||
If {c_ID} is used as an attribute, then the per-atom vector calculated
|
||||
by the compute is printed. If {c_ID\[N\]} is used, then N must be in
|
||||
the range from 1-M, which will print the Nth column of the M-length
|
||||
per-atom array calculated by the compute.
|
||||
|
||||
The {f_ID} and {f_ID\[N\]} attributes allow vector or array per-atom
|
||||
quantities calculated by a "fix"_fix.html to be output. The ID in the
|
||||
attribute should be replaced by the actual ID of the fix that has been
|
||||
defined previously in the input script. The "fix
|
||||
ave/atom"_fix_ave_atom.html command is one that calculates per-atom
|
||||
quantities. Since it can time-average per-atom quantities produced by
|
||||
any "compute"_compute.html, "fix"_fix.html, or atom-style
|
||||
"variable"_variable.html, this allows those time-averaged results to
|
||||
be written to a dump file.
|
||||
|
||||
If {f_ID} is used as a attribute, then the per-atom vector calculated
|
||||
by the fix is printed. If {f_ID\[N\]} is used, then N must be in the
|
||||
range from 1-M, which will print the Nth column of the M-length
|
||||
per-atom array calculated by the fix.
|
||||
|
||||
The {v_name} attribute allows per-atom vectors calculated by a
|
||||
"variable"_variable.html to be output. The name in the attribute
|
||||
should be replaced by the actual name of the variable that has been
|
||||
defined previously in the input script. Only an atom-style variable
|
||||
can be referenced, since it is the only style that generates per-atom
|
||||
values. Variables of style {atom} can reference individual atom
|
||||
attributes, per-atom atom attributes, thermodynamic keywords, or
|
||||
invoke other computes, fixes, or variables when they are evaluated, so
|
||||
this is a very general means of creating quantities to output to a
|
||||
dump file.
|
||||
|
||||
See "Section 10"_Section_modify.html of the manual for information
|
||||
on how to add new compute and fix styles to LAMMPS to calculate
|
||||
per-atom quantities which could then be output into dump files.
|
||||
|
||||
:line
|
||||
|
||||
[Restrictions:]
|
||||
|
||||
The {custom/vtk} style does not support writing of gzipped dump files.
|
||||
|
||||
The {custom/vtk} dump style is part of the USER-VTK package. It is
|
||||
only enabled if LAMMPS was built with that package. See the "Making
|
||||
LAMMPS"_Section_start.html#start_3 section for more info.
|
||||
|
||||
To use this dump style, you also must link to the VTK library. See
|
||||
the info in lib/vtk/README and insure the Makefile.lammps file in that
|
||||
directory is appropriate for your machine.
|
||||
|
||||
The {custom/vtk} dump style neither supports buffering nor custom
|
||||
format strings.
|
||||
|
||||
[Related commands:]
|
||||
|
||||
"dump"_dump.html, "dump image"_dump_image.html,
|
||||
"dump_modify"_dump_modify.html, "undump"_undump.html
|
||||
|
||||
[Default:]
|
||||
|
||||
By default, files are written in ASCII format. If the file extension
|
||||
is not one of .vtk, .vtp or .vtu, the legacy VTK file format is used.
|
||||
|
||||
@ -17,9 +17,7 @@ group-ID = ID of the group of atoms to be imaged :l
|
||||
h5md = style of dump command (other styles {atom} or {cfg} or {dcd} or {xtc} or {xyz} or {local} or {custom} are discussed on the "dump"_dump.html doc page) :l
|
||||
N = dump every this many timesteps :l
|
||||
file.h5 = name of file to write to :l
|
||||
args = list of data elements to dump, with their dump "subintervals".
|
||||
At least one element must be given and image may only be present if
|
||||
position is specified first. :l
|
||||
args = list of data elements to dump, with their dump "subintervals"
|
||||
position options
|
||||
image
|
||||
velocity options
|
||||
@ -29,15 +27,17 @@ position is specified first. :l
|
||||
box value = {yes} or {no}
|
||||
create_group value = {yes} or {no}
|
||||
author value = quoted string :pre
|
||||
:ule
|
||||
|
||||
For the elements {position}, {velocity}, {force} and {species}, one
|
||||
may specify a sub-interval to write the data only every N_element
|
||||
Note that at least one element must be specified and image may only be
|
||||
present if position is specified first.
|
||||
|
||||
For the elements {position}, {velocity}, {force} and {species}, a
|
||||
sub-interval may be specified to write the data only every N_element
|
||||
iterations of the dump (i.e. every N*N_element time steps). This is
|
||||
specified by the option
|
||||
specified by this option directly following the element declaration:
|
||||
|
||||
every N_element :pre
|
||||
|
||||
that follows directly the element declaration.
|
||||
every N_element :pre
|
||||
|
||||
:ule
|
||||
|
||||
|
||||
@ -1,66 +0,0 @@
|
||||
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
dump nc command :h3
|
||||
dump nc/mpiio command :h3
|
||||
|
||||
[Syntax:]
|
||||
|
||||
dump ID group-ID nc N file.nc args
|
||||
dump ID group-ID nc/mpiio N file.nc args :pre
|
||||
|
||||
ID = user-assigned name for the dump :ulb,l
|
||||
group-ID = ID of the group of atoms to be imaged :l
|
||||
{nc} or {nc/mpiio} = style of dump command (other styles {atom} or {cfg} or {dcd} or {xtc} or {xyz} or {local} or {custom} are discussed on the "dump"_dump.html doc page) :l
|
||||
N = dump every this many timesteps :l
|
||||
file.nc = name of file to write to :l
|
||||
args = list of per atom data elements to dump, same as for the 'custom' dump style. :l,ule
|
||||
|
||||
[Examples:]
|
||||
|
||||
dump 1 all nc 100 traj.nc type x y z vx vy vz
|
||||
dump_modify 1 append yes at -1 global c_thermo_pe c_thermo_temp c_thermo_press :pre
|
||||
|
||||
dump 1 all nc/mpiio 1000 traj.nc id type x y z :pre
|
||||
|
||||
[Description:]
|
||||
|
||||
Dump a snapshot of atom coordinates every N timesteps in Amber-style
|
||||
NetCDF file format. NetCDF files are binary, portable and
|
||||
self-describing. This dump style will write only one file on the root
|
||||
node. The dump style {nc} uses the "standard NetCDF
|
||||
library"_netcdf-home all data is collected on one processor and then
|
||||
written to the dump file. Dump style {nc/mpiio} used the "parallel
|
||||
NetCDF library"_pnetcdf-home and MPI-IO; it has better performance on
|
||||
a larger number of processors. Note that 'nc' outputs all atoms sorted
|
||||
by atom tag while 'nc/mpiio' outputs in order of the MPI rank.
|
||||
|
||||
In addition to per-atom data, also global (i.e. not per atom, but per
|
||||
frame) quantities can be included in the dump file. This can be
|
||||
variables, output from computes or fixes data prefixed with v_, c_ and
|
||||
f_, respectively. These properties are included via
|
||||
"dump_modify"_dump_modify.html {global}.
|
||||
|
||||
:link(netcdf-home,http://www.unidata.ucar.edu/software/netcdf/)
|
||||
:link(pnetcdf-home,http://trac.mcs.anl.gov/projects/parallel-netcdf/)
|
||||
|
||||
:line
|
||||
|
||||
[Restrictions:]
|
||||
|
||||
The {nc} and {nc/mpiio} dump styles are part of the USER-NC-DUMP
|
||||
package. It is only enabled if LAMMPS was built with that
|
||||
package. See the "Making LAMMPS"_Section_start.html#start_3 section
|
||||
for more info.
|
||||
|
||||
:line
|
||||
|
||||
[Related commands:]
|
||||
|
||||
"dump"_dump.html, "dump_modify"_dump_modify.html, "undump"_undump.html
|
||||
|
||||
82
doc/src/dump_netcdf.txt
Normal file
82
doc/src/dump_netcdf.txt
Normal file
@ -0,0 +1,82 @@
|
||||
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
dump netcdf command :h3
|
||||
dump netcdf/mpiio command :h3
|
||||
|
||||
[Syntax:]
|
||||
|
||||
dump ID group-ID netcdf N file args
|
||||
dump ID group-ID netcdf/mpiio N file args :pre
|
||||
|
||||
ID = user-assigned name for the dump :ulb,l
|
||||
group-ID = ID of the group of atoms to be imaged :l
|
||||
{netcdf} or {netcdf/mpiio} = style of dump command (other styles {atom} or {cfg} or {dcd} or {xtc} or {xyz} or {local} or {custom} are discussed on the "dump"_dump.html doc page) :l
|
||||
N = dump every this many timesteps :l
|
||||
file = name of file to write dump info to :l
|
||||
args = list of atom attributes, same as for "dump_style custom"_dump.html :l,ule
|
||||
|
||||
[Examples:]
|
||||
|
||||
dump 1 all netcdf 100 traj.nc type x y z vx vy vz
|
||||
dump_modify 1 append yes at -1 global c_thermo_pe c_thermo_temp c_thermo_press
|
||||
dump 1 all netcdf/mpiio 1000 traj.nc id type x y z :pre
|
||||
|
||||
[Description:]
|
||||
|
||||
Dump a snapshot of atom coordinates every N timesteps in Amber-style
|
||||
NetCDF file format. NetCDF files are binary, portable and
|
||||
self-describing. This dump style will write only one file on the root
|
||||
node. The dump style {netcdf} uses the "standard NetCDF
|
||||
library"_netcdf-home. All data is collected on one processor and then
|
||||
written to the dump file. Dump style {netcdf/mpiio} uses the
|
||||
"parallel NetCDF library"_pnetcdf-home and MPI-IO to write to the dump
|
||||
file in parallel; it has better performance on a larger number of
|
||||
processors. Note that style {netcdf} outputs all atoms sorted by atom
|
||||
tag while style {netcdf/mpiio} outputs atoms in order of their MPI
|
||||
rank.
|
||||
|
||||
NetCDF files can be directly visualized via the following tools:
|
||||
|
||||
Ovito (http://www.ovito.org/). Ovito supports the AMBER convention and
|
||||
all of the above extensions. :ule,b
|
||||
|
||||
VMD (http://www.ks.uiuc.edu/Research/vmd/). :l
|
||||
|
||||
AtomEye (http://www.libatoms.org/). The libAtoms version of AtomEye
|
||||
contains a NetCDF reader that is not present in the standard
|
||||
distribution of AtomEye. :l,ule
|
||||
|
||||
In addition to per-atom data, global data can be included in the dump
|
||||
file, which are the kinds of values output by the
|
||||
"thermo_style"_thermo_style.html command . See "Section howto
|
||||
6.15"_Section_howto.html#howto_15 for an explanation of per-atom
|
||||
versus global data. The global output written into the dump file can
|
||||
be from computes, fixes, or variables, by prefixing the compute/fix ID
|
||||
or variable name with "c_" or "f_" or "v_" respectively, as in the
|
||||
example above. These global values are specified via the "dump_modify
|
||||
global"_dump_modify.html command.
|
||||
|
||||
:link(netcdf-home,http://www.unidata.ucar.edu/software/netcdf/)
|
||||
:link(pnetcdf-home,http://trac.mcs.anl.gov/projects/parallel-netcdf/)
|
||||
|
||||
:line
|
||||
|
||||
[Restrictions:]
|
||||
|
||||
The {netcdf} and {netcdf/mpiio} dump styles are part of the
|
||||
USER-NETCDF package. They are only enabled if LAMMPS was built with
|
||||
that package. See the "Making LAMMPS"_Section_start.html#start_3
|
||||
section for more info.
|
||||
|
||||
:line
|
||||
|
||||
[Related commands:]
|
||||
|
||||
"dump"_dump.html, "dump_modify"_dump_modify.html, "undump"_undump.html
|
||||
|
||||
179
doc/src/dump_vtk.txt
Normal file
179
doc/src/dump_vtk.txt
Normal file
@ -0,0 +1,179 @@
|
||||
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
dump vtk command :h3
|
||||
|
||||
[Syntax:]
|
||||
|
||||
dump ID group-ID vtk N file args :pre
|
||||
|
||||
ID = user-assigned name for the dump
|
||||
group-ID = ID of the group of atoms to be dumped
|
||||
vtk = style of dump command (other styles {atom} or {cfg} or {dcd} or {xtc} or {xyz} or {local} or {custom} are discussed on the "dump"_dump.html doc page)
|
||||
N = dump every this many timesteps
|
||||
file = name of file to write dump info to
|
||||
args = same as arguments for "dump_style custom"_dump.html :ul
|
||||
|
||||
[Examples:]
|
||||
|
||||
dump dmpvtk all vtk 100 dump*.myforce.vtk id type vx fx
|
||||
dump dmpvtp flow vtk 100 dump*.%.displace.vtp id type c_myD\[1\] c_myD\[2\] c_myD\[3\] v_ke :pre
|
||||
|
||||
[Description:]
|
||||
|
||||
Dump a snapshot of atom quantities to one or more files every N
|
||||
timesteps in a format readable by the "VTK visualization
|
||||
toolkit"_http://www.vtk.org or other visualization tools that use it,
|
||||
e.g. "ParaView"_http://www.paraview.org. The timesteps on which dump
|
||||
output is written can also be controlled by a variable; see the
|
||||
"dump_modify every"_dump_modify.html command for details.
|
||||
|
||||
This dump style is similar to "dump_style custom"_dump.html but uses
|
||||
the VTK library to write data to VTK simple legacy or XML format
|
||||
depending on the filename extension specified for the dump file. This
|
||||
can be either {*.vtk} for the legacy format or {*.vtp} and {*.vtu},
|
||||
respectively, for XML format; see the "VTK
|
||||
homepage"_http://www.vtk.org/VTK/img/file-formats.pdf for a detailed
|
||||
description of these formats. Since this naming convention conflicts
|
||||
with the way binary output is usually specified (see below), the
|
||||
"dump_modify binary"_dump_modify.html command allows setting of a
|
||||
binary option for this dump style explicitly.
|
||||
|
||||
Only information for atoms in the specified group is dumped. The
|
||||
"dump_modify thresh and region"_dump_modify.html commands can also
|
||||
alter what atoms are included; see details below.
|
||||
|
||||
As described below, special characters ("*", "%") in the filename
|
||||
determine the kind of output.
|
||||
|
||||
IMPORTANT NOTE: Because periodic boundary conditions are enforced only
|
||||
on timesteps when neighbor lists are rebuilt, the coordinates of an
|
||||
atom written to a dump file may be slightly outside the simulation
|
||||
box.
|
||||
|
||||
IMPORTANT NOTE: Unless the "dump_modify sort"_dump_modify.html option
|
||||
is invoked, the lines of atom information written to dump files will
|
||||
be in an indeterminate order for each snapshot. This is even true
|
||||
when running on a single processor, if the "atom_modify
|
||||
sort"_atom_modify.html option is on, which it is by default. In this
|
||||
case atoms are re-ordered periodically during a simulation, due to
|
||||
spatial sorting. It is also true when running in parallel, because
|
||||
data for a single snapshot is collected from multiple processors, each
|
||||
of which owns a subset of the atoms.
|
||||
|
||||
For the {vtk} style, sorting is off by default. See the
|
||||
"dump_modify"_dump_modify.html doc page for details.
|
||||
|
||||
:line
|
||||
|
||||
The dimensions of the simulation box are written to a separate file
|
||||
for each snapshot (either in legacy VTK or XML format depending on the
|
||||
format of the main dump file) with the suffix {_boundingBox} appended
|
||||
to the given dump filename.
|
||||
|
||||
For an orthogonal simulation box this information is saved as a
|
||||
rectilinear grid (legacy .vtk or .vtr XML format).
|
||||
|
||||
Triclinic simulation boxes (non-orthogonal) are saved as
|
||||
hexahedrons in either legacy .vtk or .vtu XML format.
|
||||
|
||||
Style {vtk} allows you to specify a list of atom attributes to be
|
||||
written to the dump file for each atom. The list of possible attributes
|
||||
is the same as for the "dump_style custom"_dump.html command; see
|
||||
its doc page for a listing and an explanation of each attribute.
|
||||
|
||||
NOTE: Since position data is required to write VTK files the atom
|
||||
attributes "x y z" do not have to be specified explicitly; they will
|
||||
be included in the dump file regardless. Also, in contrast to the
|
||||
{custom} style, the specified {vtk} attributes are rearranged to
|
||||
ensure correct ordering of vector components (except for computes and
|
||||
fixes - these have to be given in the right order) and duplicate
|
||||
entries are removed.
|
||||
|
||||
The VTK format uses a single snapshot of the system per file, thus
|
||||
a wildcard "*" must be included in the filename, as discussed below.
|
||||
Otherwise the dump files will get overwritten with the new snapshot
|
||||
each time.
|
||||
|
||||
:line
|
||||
|
||||
Dumps are performed on timesteps that are a multiple of N (including
|
||||
timestep 0) and on the last timestep of a minimization if the
|
||||
minimization converges. Note that this means a dump will not be
|
||||
performed on the initial timestep after the dump command is invoked,
|
||||
if the current timestep is not a multiple of N. This behavior can be
|
||||
changed via the "dump_modify first"_dump_modify.html command, which
|
||||
can also be useful if the dump command is invoked after a minimization
|
||||
ended on an arbitrary timestep. N can be changed between runs by
|
||||
using the "dump_modify every"_dump_modify.html command.
|
||||
The "dump_modify every"_dump_modify.html command
|
||||
also allows a variable to be used to determine the sequence of
|
||||
timesteps on which dump files are written. In this mode a dump on the
|
||||
first timestep of a run will also not be written unless the
|
||||
"dump_modify first"_dump_modify.html command is used.
|
||||
|
||||
Dump filenames can contain two wildcard characters. If a "*"
|
||||
character appears in the filename, then one file per snapshot is
|
||||
written and the "*" character is replaced with the timestep value.
|
||||
For example, tmp.dump*.vtk becomes tmp.dump0.vtk, tmp.dump10000.vtk,
|
||||
tmp.dump20000.vtk, etc. Note that the "dump_modify pad"_dump_modify.html
|
||||
command can be used to insure all timestep numbers are the same length
|
||||
(e.g. 00010), which can make it easier to read a series of dump files
|
||||
in order with some post-processing tools.
|
||||
|
||||
If a "%" character appears in the filename, then each of P processors
|
||||
writes a portion of the dump file, and the "%" character is replaced
|
||||
with the processor ID from 0 to P-1 preceded by an underscore character.
|
||||
For example, tmp.dump%.vtp becomes tmp.dump_0.vtp, tmp.dump_1.vtp, ...
|
||||
tmp.dump_P-1.vtp, etc. This creates smaller files and can be a fast
|
||||
mode of output on parallel machines that support parallel I/O for output.
|
||||
|
||||
By default, P = the number of processors meaning one file per
|
||||
processor, but P can be set to a smaller value via the {nfile} or
|
||||
{fileper} keywords of the "dump_modify"_dump_modify.html command.
|
||||
These options can be the most efficient way of writing out dump files
|
||||
when running on large numbers of processors.
|
||||
|
||||
For the legacy VTK format "%" is ignored and P = 1, i.e., only
|
||||
processor 0 does write files.
|
||||
|
||||
Note that using the "*" and "%" characters together can produce a
|
||||
large number of small dump files!
|
||||
|
||||
If {dump_modify binary} is used, the dump file (or files, if "*" or
|
||||
"%" is also used) is written in binary format. A binary dump file
|
||||
will be about the same size as a text version, but will typically
|
||||
write out much faster.
|
||||
|
||||
:line
|
||||
|
||||
[Restrictions:]
|
||||
|
||||
The {vtk} style does not support writing of gzipped dump files.
|
||||
|
||||
The {vtk} dump style is part of the USER-VTK package. It is
|
||||
only enabled if LAMMPS was built with that package. See the "Making
|
||||
LAMMPS"_Section_start.html#start_3 section for more info.
|
||||
|
||||
To use this dump style, you also must link to the VTK library. See
|
||||
the info in lib/vtk/README and insure the Makefile.lammps file in that
|
||||
directory is appropriate for your machine.
|
||||
|
||||
The {vtk} dump style supports neither buffering or custom format
|
||||
strings.
|
||||
|
||||
[Related commands:]
|
||||
|
||||
"dump"_dump.html, "dump image"_dump_image.html,
|
||||
"dump_modify"_dump_modify.html, "undump"_undump.html
|
||||
|
||||
[Default:]
|
||||
|
||||
By default, files are written in ASCII format. If the file extension
|
||||
is not one of .vtk, .vtp or .vtu, the legacy VTK file format is used.
|
||||
|
||||
@ -22,6 +22,11 @@ attribute = {pair} or {kspace} or {atom} :l
|
||||
pparam = parameter to adapt over time
|
||||
I,J = type pair(s) to set parameter for
|
||||
v_name = variable with name that calculates value of pparam
|
||||
{bond} args = bstyle bparam I v_name
|
||||
bstyle = bond style name, e.g. harmonic
|
||||
bparam = parameter to adapt over time
|
||||
I = type bond to set parameter for
|
||||
v_name = variable with name that calculates value of bparam
|
||||
{kspace} arg = v_name
|
||||
v_name = variable with name that calculates scale factor on K-space terms
|
||||
{atom} args = aparam v_name
|
||||
@ -42,7 +47,10 @@ keyword = {scale} or {reset} :l
|
||||
fix 1 all adapt 1 pair soft a 1 1 v_prefactor
|
||||
fix 1 all adapt 1 pair soft a 2* 3 v_prefactor
|
||||
fix 1 all adapt 1 pair lj/cut epsilon * * v_scale1 coul/cut scale 3 3 v_scale2 scale yes reset yes
|
||||
fix 1 all adapt 10 atom diameter v_size :pre
|
||||
fix 1 all adapt 10 atom diameter v_size
|
||||
|
||||
variable ramp_up equal "ramp(0.01,0.5)"
|
||||
fix stretch all adapt 1 bond harmonic r0 1 v_ramp_up :pre
|
||||
|
||||
[Description:]
|
||||
|
||||
@ -192,6 +200,19 @@ fix 1 all adapt 1 pair soft a * * v_prefactor :pre
|
||||
|
||||
:line
|
||||
|
||||
The {bond} keyword uses the specified variable to change the value of
|
||||
a bond coefficient over time, very similar to how the {pair} keyword
|
||||
operates. The only difference is that now a bond coefficient for a
|
||||
given bond type is adapted.
|
||||
|
||||
Currently {bond} does not support bond_style hybrid nor bond_style
|
||||
hybrid/overlay as bond styles. The only bonds that currently are
|
||||
working with fix_adapt are
|
||||
|
||||
"harmonic"_bond_harmonic.html: k,r0: type bonds :tb(c=3,s=:)
|
||||
|
||||
:line
|
||||
|
||||
The {kspace} keyword used the specified variable as a scale factor on
|
||||
the energy, forces, virial calculated by whatever K-Space solver is
|
||||
defined by the "kspace_style"_kspace_style.html command. If the
|
||||
|
||||
@ -245,8 +245,8 @@ appear the system is converging to your specified pressure. The
|
||||
solution for this is to either (a) zero the velocities of all atoms
|
||||
before performing the minimization, or (b) make sure you are
|
||||
monitoring the pressure without its kinetic component. The latter can
|
||||
be done by outputting the pressure from the fix this command creates
|
||||
(see below) or a pressure fix you define yourself.
|
||||
be done by outputting the pressure from the pressure compute this
|
||||
command creates (see below) or a pressure compute you define yourself.
|
||||
|
||||
NOTE: Because pressure is often a very sensitive function of volume,
|
||||
it can be difficult for the minimizer to equilibrate the system the
|
||||
@ -308,7 +308,7 @@ thermo_modify command (or in two separate commands), then the order in
|
||||
which the keywords are specified is important. Note that a "pressure
|
||||
compute"_compute_pressure.html defines its own temperature compute as
|
||||
an argument when it is specified. The {temp} keyword will override
|
||||
this (for the pressure compute being used by fix npt), but only if the
|
||||
this (for the pressure compute being used by fix box/relax), but only if the
|
||||
{temp} keyword comes after the {press} keyword. If the {temp} keyword
|
||||
comes before the {press} keyword, then the new pressure compute
|
||||
specified by the {press} keyword will be unaffected by the {temp}
|
||||
@ -316,18 +316,16 @@ setting.
|
||||
|
||||
This fix computes a global scalar which can be accessed by various
|
||||
"output commands"_Section_howto.html#howto_15. The scalar is the
|
||||
pressure-volume energy, plus the strain energy, if it exists.
|
||||
|
||||
This fix computes a global scalar which can be accessed by various
|
||||
"output commands"_Section_howto.html#howto_15. The scalar is given
|
||||
by the energy expression shown above. The energy values reported
|
||||
at the end of a minimization run under "Minimization stats" include
|
||||
this energy, and so differ from what LAMMPS normally reports as
|
||||
potential energy. This fix does not support the
|
||||
"fix_modify"_fix_modify.html {energy} option,
|
||||
because that would result in double-counting of the fix energy in the
|
||||
minimization energy. Instead, the fix energy can be explicitly
|
||||
added to the potential energy using one of these two variants:
|
||||
pressure-volume energy, plus the strain energy, if it exists,
|
||||
as described above.
|
||||
The energy values reported at the
|
||||
end of a minimization run under "Minimization stats" include this
|
||||
energy, and so differ from what LAMMPS normally reports as potential
|
||||
energy. This fix does not support the "fix_modify"_fix_modify.html
|
||||
{energy} option, because that would result in double-counting of the
|
||||
fix energy in the minimization energy. Instead, the fix energy can be
|
||||
explicitly added to the potential energy using one of these two
|
||||
variants:
|
||||
|
||||
variable emin equal pe+f_1 :pre
|
||||
|
||||
|
||||
@ -27,7 +27,7 @@ fix_modify myCMAP energy yes :pre
|
||||
This command enables CMAP crossterms to be added to simulations which
|
||||
use the CHARMM force field. These are relevant for any CHARMM model
|
||||
of a peptide or protein sequences that is 3 or more amino-acid
|
||||
residues long; see "(Buck)"_#Buck and "(Brooks)"_#Brooks for details,
|
||||
residues long; see "(Buck)"_#Buck and "(Brooks)"_#Brooks2 for details,
|
||||
including the analytic energy expressions for CMAP interactions. The
|
||||
CMAP crossterms add additional potential energy contributions to pairs
|
||||
of overlapping phi-psi dihedrals of amino-acids, which are important
|
||||
@ -87,8 +87,11 @@ the note below about how to include the CMAP energy when performing an
|
||||
|
||||
[Restart, fix_modify, output, run start/stop, minimize info:]
|
||||
|
||||
No information about this fix is written to "binary restart
|
||||
files"_restart.html.
|
||||
This fix writes the list of CMAP crossterms to "binary restart
|
||||
files"_restart.html. 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.
|
||||
|
||||
The "fix_modify"_fix_modify.html {energy} option is supported by this
|
||||
fix to add the potential "energy" of the CMAP interactions system's
|
||||
@ -128,5 +131,5 @@ LAMMPS"_Section_start.html#start_3 section for more info on packages.
|
||||
[(Buck)] Buck, Bouguet-Bonnet, Pastor, MacKerell Jr., Biophys J, 90, L36
|
||||
(2006).
|
||||
|
||||
:link(Brooks)
|
||||
:link(Brooks2)
|
||||
[(Brooks)] Brooks, Brooks, MacKerell Jr., J Comput Chem, 30, 1545 (2009).
|
||||
|
||||
@ -56,26 +56,25 @@ fix 4 my_gas gcmc 1 10 10 1 123456543 300.0 -12.5 1.0 region disk :pre
|
||||
[Description:]
|
||||
|
||||
This fix performs grand canonical Monte Carlo (GCMC) exchanges of
|
||||
atoms or molecules of the given type with an imaginary ideal gas reservoir at
|
||||
the specified T and chemical potential (mu) as discussed in
|
||||
"(Frenkel)"_#Frenkel. If used with the "fix nvt"_fix_nh.html command,
|
||||
simulations in the grand canonical ensemble (muVT, constant chemical
|
||||
potential, constant volume, and constant temperature) can be
|
||||
atoms or molecules of the given type with an imaginary ideal gas
|
||||
reservoir at the specified T and chemical potential (mu) as discussed
|
||||
in "(Frenkel)"_#Frenkel. If used with the "fix nvt"_fix_nh.html
|
||||
command, simulations in the grand canonical ensemble (muVT, constant
|
||||
chemical potential, constant volume, and constant temperature) can be
|
||||
performed. Specific uses include computing isotherms in microporous
|
||||
materials, or computing vapor-liquid coexistence curves.
|
||||
|
||||
Every N timesteps the fix attempts a number of GCMC exchanges (insertions
|
||||
or deletions) of gas atoms or molecules of
|
||||
the given type between the simulation cell and the imaginary
|
||||
reservoir. It also attempts a number of Monte Carlo
|
||||
moves (translations and molecule rotations) of gas of the given type
|
||||
within the simulation cell or region. The average number of
|
||||
attempted GCMC exchanges is X. The average number of attempted MC moves is M.
|
||||
M should typically be chosen to be
|
||||
approximately equal to the expected number of gas atoms or molecules
|
||||
of the given type within the simulation cell or region,
|
||||
which will result in roughly one
|
||||
MC translation per atom or molecule per MC cycle.
|
||||
Every N timesteps the fix attempts a number of GCMC exchanges
|
||||
(insertions or deletions) of gas atoms or molecules of the given type
|
||||
between the simulation cell and the imaginary reservoir. It also
|
||||
attempts a number of Monte Carlo moves (translations and molecule
|
||||
rotations) of gas of the given type within the simulation cell or
|
||||
region. The average number of attempted GCMC exchanges is X. The
|
||||
average number of attempted MC moves is M. M should typically be
|
||||
chosen to be approximately equal to the expected number of gas atoms
|
||||
or molecules of the given type within the simulation cell or region,
|
||||
which will result in roughly one MC translation per atom or molecule
|
||||
per MC cycle.
|
||||
|
||||
For MC moves of molecular gasses, rotations and translations are each
|
||||
attempted with 50% probability. For MC moves of atomic gasses,
|
||||
@ -83,50 +82,50 @@ translations are attempted 100% of the time. For MC exchanges of
|
||||
either molecular or atomic gasses, deletions and insertions are each
|
||||
attempted with 50% probability.
|
||||
|
||||
All inserted particles are always assigned to two groups: the default group
|
||||
"all" and the group specified in the fix gcmc command (which can also
|
||||
be "all"). In addition, particles are also added to any groups specified
|
||||
by the {group} and {grouptype} keywords.
|
||||
If inserted particles are individual atoms, they are
|
||||
assigned the atom type given by the type argument. If they are molecules,
|
||||
the type argument has no effect and must be set to zero. Instead,
|
||||
the type of each atom in the inserted molecule is specified
|
||||
in the file read by the "molecule"_molecule.html command.
|
||||
All inserted particles are always assigned to two groups: the default
|
||||
group "all" and the group specified in the fix gcmc command (which can
|
||||
also be "all"). In addition, particles are also added to any groups
|
||||
specified by the {group} and {grouptype} keywords. If inserted
|
||||
particles are individual atoms, they are assigned the atom type given
|
||||
by the type argument. If they are molecules, the type argument has no
|
||||
effect and must be set to zero. Instead, the type of each atom in the
|
||||
inserted molecule is specified in the file read by the
|
||||
"molecule"_molecule.html command.
|
||||
|
||||
This fix cannot be used to perform MC insertions of gas atoms or
|
||||
molecules other than the exchanged type, but MC deletions,
|
||||
translations, and rotations can be performed on any atom/molecule in
|
||||
the fix group. All atoms in the simulation cell can be moved using
|
||||
regular time integration translations, e.g. via
|
||||
"fix nvt"_fix_nh.html, resulting in a hybrid GCMC+MD simulation. A
|
||||
smaller-than-usual timestep size may be needed when running such a
|
||||
hybrid simulation, especially if the inserted molecules are not well
|
||||
equilibrated.
|
||||
regular time integration translations, e.g. via "fix nvt"_fix_nh.html,
|
||||
resulting in a hybrid GCMC+MD simulation. A smaller-than-usual
|
||||
timestep size may be needed when running such a hybrid simulation,
|
||||
especially if the inserted molecules are not well equilibrated.
|
||||
|
||||
This command may optionally use the {region} keyword to define an
|
||||
exchange and move volume. The specified region must have been
|
||||
previously defined with a "region"_region.html command. It must be
|
||||
defined with side = {in}. Insertion attempts occur only within the
|
||||
specified region. For non-rectangular regions, random trial
|
||||
points are generated within the rectangular bounding box until a point is found
|
||||
that lies inside the region. If no valid point is generated after 1000 trials,
|
||||
no insertion is performed, but it is counted as an attempted insertion.
|
||||
Move and deletion attempt candidates are selected
|
||||
from gas atoms or molecules within the region. If there are no candidates,
|
||||
no move or deletion is performed, but it is counted as an attempt move
|
||||
or deletion. If an attempted move places the atom or molecule center-of-mass outside
|
||||
the specified region, a new attempted move is generated. This process is repeated
|
||||
until the atom or molecule center-of-mass is inside the specified region.
|
||||
specified region. For non-rectangular regions, random trial points are
|
||||
generated within the rectangular bounding box until a point is found
|
||||
that lies inside the region. If no valid point is generated after 1000
|
||||
trials, no insertion is performed, but it is counted as an attempted
|
||||
insertion. Move and deletion attempt candidates are selected from gas
|
||||
atoms or molecules within the region. If there are no candidates, no
|
||||
move or deletion is performed, but it is counted as an attempt move or
|
||||
deletion. If an attempted move places the atom or molecule
|
||||
center-of-mass outside the specified region, a new attempted move is
|
||||
generated. This process is repeated until the atom or molecule
|
||||
center-of-mass is inside the specified region.
|
||||
|
||||
If used with "fix nvt"_fix_nh.html, the temperature of the imaginary
|
||||
reservoir, T, should be set to be equivalent to the target temperature
|
||||
used in fix nvt. Otherwise, the imaginary reservoir
|
||||
will not be in thermal equilibrium with the simulation cell. Also,
|
||||
it is important that the temperature used by fix nvt be dynamic,
|
||||
which can be achieved as follows:
|
||||
used in fix nvt. Otherwise, the imaginary reservoir will not be in
|
||||
thermal equilibrium with the simulation cell. Also, it is important
|
||||
that the temperature used by fix nvt be dynamic/dof, which can be
|
||||
achieved as follows:
|
||||
|
||||
compute mdtemp mdatoms temp
|
||||
compute_modify mdtemp dynamic yes
|
||||
compute_modify mdtemp dynamic/dof yes
|
||||
fix mdnvt mdatoms nvt temp 300.0 300.0 10.0
|
||||
fix_modify mdnvt temp mdtemp :pre
|
||||
|
||||
@ -137,16 +136,16 @@ interactions. Specifically, avoid performing so many MC translations
|
||||
per timestep that atoms can move beyond the neighbor list skin
|
||||
distance. See the "neighbor"_neighbor.html command for details.
|
||||
|
||||
When an atom or molecule is to be inserted, its
|
||||
coordinates are chosen at a random position within the current
|
||||
simulation cell or region, and new atom velocities are randomly chosen from
|
||||
the specified temperature distribution given by T. The effective
|
||||
temperature for new atom velocities can be increased or decreased
|
||||
using the optional keyword {tfac_insert} (see below). Relative
|
||||
coordinates for atoms in a molecule are taken from the template
|
||||
molecule provided by the user. The center of mass of the molecule
|
||||
is placed at the insertion point. The orientation of the molecule
|
||||
is chosen at random by rotating about this point.
|
||||
When an atom or molecule is to be inserted, its coordinates are chosen
|
||||
at a random position within the current simulation cell or region, and
|
||||
new atom velocities are randomly chosen from the specified temperature
|
||||
distribution given by T. The effective temperature for new atom
|
||||
velocities can be increased or decreased using the optional keyword
|
||||
{tfac_insert} (see below). Relative coordinates for atoms in a
|
||||
molecule are taken from the template molecule provided by the
|
||||
user. The center of mass of the molecule is placed at the insertion
|
||||
point. The orientation of the molecule is chosen at random by rotating
|
||||
about this point.
|
||||
|
||||
Individual atoms are inserted, unless the {mol} keyword is used. It
|
||||
specifies a {template-ID} previously defined using the
|
||||
@ -158,15 +157,15 @@ command for details. The only settings required to be in this file
|
||||
are the coordinates and types of atoms in the molecule.
|
||||
|
||||
When not using the {mol} keyword, you should ensure you do not delete
|
||||
atoms that are bonded to other atoms, or LAMMPS will
|
||||
soon generate an error when it tries to find bonded neighbors. LAMMPS will
|
||||
warn you if any of the atoms eligible for deletion have a non-zero
|
||||
molecule ID, but does not check for this at the time of deletion.
|
||||
atoms that are bonded to other atoms, or LAMMPS will soon generate an
|
||||
error when it tries to find bonded neighbors. LAMMPS will warn you if
|
||||
any of the atoms eligible for deletion have a non-zero molecule ID,
|
||||
but does not check for this at the time of deletion.
|
||||
|
||||
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.
|
||||
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
|
||||
@ -179,43 +178,76 @@ 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.
|
||||
|
||||
Optionally, users may specify the maximum rotation angle for
|
||||
molecular rotations using the {maxangle} keyword and specifying
|
||||
the angle in degrees. Rotations are performed by generating a random
|
||||
point on the unit sphere and a random rotation angle on the
|
||||
range \[0,maxangle). The molecule is then rotated by that angle about an
|
||||
Optionally, users may specify the maximum rotation angle for molecular
|
||||
rotations using the {maxangle} keyword and specifying the angle in
|
||||
degrees. Rotations are performed by generating a random point on the
|
||||
unit sphere and a random rotation angle on the range
|
||||
\[0,maxangle). The molecule is then rotated by that angle about an
|
||||
axis passing through the molecule center of mass. The axis is parallel
|
||||
to the unit vector defined by the point on the unit sphere.
|
||||
The same procedure is used for randomly rotating molecules when they
|
||||
are inserted, except that the maximum angle is 360 degrees.
|
||||
to the unit vector defined by the point on the unit sphere. The same
|
||||
procedure is used for randomly rotating molecules when they are
|
||||
inserted, except that the maximum angle is 360 degrees.
|
||||
|
||||
Note that fix GCMC does not use configurational bias
|
||||
MC or any other kind of sampling of intramolecular degrees of freedom.
|
||||
Inserted molecules can have different orientations, but they will all
|
||||
have the same intramolecular configuration,
|
||||
which was specified in the molecule command input.
|
||||
Note that fix GCMC does not use configurational bias MC or any other
|
||||
kind of sampling of intramolecular degrees of freedom. Inserted
|
||||
molecules can have different orientations, but they will all have the
|
||||
same intramolecular configuration, which was specified in the molecule
|
||||
command input.
|
||||
|
||||
For atomic gasses, inserted atoms have the specified atom type, but
|
||||
deleted atoms are any atoms that have been inserted or that belong
|
||||
to the user-specified fix group. For molecular gasses, exchanged
|
||||
molecules use the same atom types as in the template molecule
|
||||
supplied by the user. In both cases, exchanged
|
||||
atoms/molecules are assigned to two groups: the default group "all"
|
||||
and the group specified in the fix gcmc command (which can also be
|
||||
"all").
|
||||
deleted atoms are any atoms that have been inserted or that belong to
|
||||
the user-specified fix group. For molecular gasses, exchanged
|
||||
molecules use the same atom types as in the template molecule supplied
|
||||
by the user. In both cases, exchanged atoms/molecules are assigned to
|
||||
two groups: the default group "all" and the group specified in the fix
|
||||
gcmc command (which can also be "all").
|
||||
|
||||
The gas reservoir pressure can be specified using the {pressure}
|
||||
keyword, in which case the user-specified chemical potential is
|
||||
ignored. For non-ideal gas reservoirs, the user may also specify the
|
||||
fugacity coefficient using the {fugacity_coeff} keyword.
|
||||
The chemical potential is a user-specified input parameter defined
|
||||
as:
|
||||
|
||||
:c,image(Eqs/fix_gcmc1.jpg)
|
||||
|
||||
The second term mu_ex is the excess chemical potential due to
|
||||
energetic interactions and is formally zero for the fictitious gas
|
||||
reservoir but is non-zero for interacting systems. So, while the
|
||||
chemical potential of the reservoir and the simulation cell are equal,
|
||||
mu_ex is not, and as a result, the densities of the two are generally
|
||||
quite different. The first term mu_id is the ideal gas contribution
|
||||
to the chemical potential. mu_id can be related to the density or
|
||||
pressure of the fictitious gas reservoir by:
|
||||
|
||||
:c,image(Eqs/fix_gcmc2.jpg)
|
||||
|
||||
where k is Boltzman's constant,
|
||||
T is the user-specified temperature, rho is the number density,
|
||||
P is the pressure, and phi is the fugacity coefficient.
|
||||
The constant Lambda is required for dimensional consistency.
|
||||
For all unit styles except {lj} it is defined as the thermal
|
||||
de Broglie wavelength
|
||||
|
||||
:c,image(Eqs/fix_gcmc3.jpg)
|
||||
|
||||
where h is Planck's constant, and m is the mass of the exchanged atom
|
||||
or molecule. For unit style {lj}, Lambda is simply set to the
|
||||
unity. Note that prior to March 2017, lambda for unit style {lj} was
|
||||
calculated using the above formula with h set to the rather specific
|
||||
value of 0.18292026. Chemical potential under the old definition can
|
||||
be converted to an equivalent value under the new definition by
|
||||
subtracting 3kTln(Lambda_old).
|
||||
|
||||
As an alternative to specifying mu directly, the ideal gas reservoir
|
||||
can be defined by its pressure P using the {pressure} keyword, in
|
||||
which case the user-specified chemical potential is ignored. The user
|
||||
may also specify the fugacity coefficient phi using the
|
||||
{fugacity_coeff} keyword, which defaults to unity.
|
||||
|
||||
The {full_energy} option means that fix GCMC will compute the total
|
||||
potential energy of the entire simulated system. The total system
|
||||
energy before and after the proposed GCMC move is then used in the
|
||||
Metropolis criterion to determine whether or not to accept the
|
||||
proposed GCMC move. By default, this option is off, in which case
|
||||
only partial energies are computed to determine the difference in
|
||||
energy that would be caused by the proposed GCMC move.
|
||||
proposed GCMC move. By default, this option is off, in which case only
|
||||
partial energies are computed to determine the difference in energy
|
||||
that would be caused by the proposed GCMC move.
|
||||
|
||||
The {full_energy} option is needed for systems with complicated
|
||||
potential energy calculations, including the following:
|
||||
@ -224,7 +256,7 @@ potential energy calculations, including the following:
|
||||
many-body pair styles
|
||||
hybrid pair styles
|
||||
eam pair styles
|
||||
triclinic systems
|
||||
tail corrections
|
||||
need to include potential energy contributions from other fixes :ul
|
||||
|
||||
In these cases, LAMMPS will automatically apply the {full_energy}
|
||||
@ -233,42 +265,43 @@ keyword and issue a warning message.
|
||||
When the {mol} keyword is used, the {full_energy} option also includes
|
||||
the intramolecular energy of inserted and deleted molecules. If this
|
||||
is not desired, the {intra_energy} keyword can be used to define an
|
||||
amount of energy that is subtracted from the final energy when a molecule
|
||||
is inserted, and added to the initial energy when a molecule is
|
||||
deleted. For molecules that have a non-zero intramolecular energy, this
|
||||
will ensure roughly the same behavior whether or not the {full_energy}
|
||||
option is used.
|
||||
amount of energy that is subtracted from the final energy when a
|
||||
molecule is inserted, and added to the initial energy when a molecule
|
||||
is deleted. For molecules that have a non-zero intramolecular energy,
|
||||
this will ensure roughly the same behavior whether or not the
|
||||
{full_energy} option is used.
|
||||
|
||||
Inserted atoms and molecules are assigned random velocities based on the
|
||||
specified temperature T. Because the relative velocity of
|
||||
all atoms in the molecule is zero, this may result in inserted molecules
|
||||
that are systematically too cold. In addition, the intramolecular potential
|
||||
energy of the inserted molecule may cause the kinetic energy
|
||||
of the molecule to quickly increase or decrease after insertion.
|
||||
The {tfac_insert} keyword allows the user to counteract these effects
|
||||
by changing the temperature used to assign velocities to
|
||||
inserted atoms and molecules by a constant factor. For a
|
||||
particular application, some experimentation may be required
|
||||
to find a value of {tfac_insert} that results in inserted molecules that
|
||||
equilibrate quickly to the correct temperature.
|
||||
Inserted atoms and molecules are assigned random velocities based on
|
||||
the specified temperature T. Because the relative velocity of all
|
||||
atoms in the molecule is zero, this may result in inserted molecules
|
||||
that are systematically too cold. In addition, the intramolecular
|
||||
potential energy of the inserted molecule may cause the kinetic energy
|
||||
of the molecule to quickly increase or decrease after insertion. The
|
||||
{tfac_insert} keyword allows the user to counteract these effects by
|
||||
changing the temperature used to assign velocities to inserted atoms
|
||||
and molecules by a constant factor. For a particular application, some
|
||||
experimentation may be required to find a value of {tfac_insert} that
|
||||
results in inserted molecules that equilibrate quickly to the correct
|
||||
temperature.
|
||||
|
||||
Some fixes have an associated potential energy. Examples of such fixes
|
||||
include: "efield"_fix_efield.html, "gravity"_fix_gravity.html,
|
||||
"addforce"_fix_addforce.html, "langevin"_fix_langevin.html,
|
||||
"restrain"_fix_restrain.html, "temp/berendsen"_fix_temp_berendsen.html,
|
||||
"restrain"_fix_restrain.html,
|
||||
"temp/berendsen"_fix_temp_berendsen.html,
|
||||
"temp/rescale"_fix_temp_rescale.html, and "wall fixes"_fix_wall.html.
|
||||
For that energy to be included in the total potential energy of the
|
||||
system (the quantity used when performing GCMC moves),
|
||||
you MUST enable the "fix_modify"_fix_modify.html {energy} option for
|
||||
that fix. The doc pages for individual "fix"_fix.html commands
|
||||
specify if this should be done.
|
||||
system (the quantity used when performing GCMC moves), you MUST enable
|
||||
the "fix_modify"_fix_modify.html {energy} option for that fix. The
|
||||
doc pages for individual "fix"_fix.html commands specify if this
|
||||
should be done.
|
||||
|
||||
Use the {charge} option to insert atoms with a user-specified point
|
||||
charge. Note that doing so will cause the system to become non-neutral.
|
||||
LAMMPS issues a warning when using long-range electrostatics (kspace)
|
||||
with non-neutral systems. See the
|
||||
"compute group/group"_compute_group_group.html documentation for more
|
||||
details about simulating non-neutral systems with kspace on.
|
||||
charge. Note that doing so will cause the system to become
|
||||
non-neutral. LAMMPS issues a warning when using long-range
|
||||
electrostatics (kspace) with non-neutral systems. See the "compute
|
||||
group/group"_compute_group_group.html documentation for more details
|
||||
about simulating non-neutral systems with kspace on.
|
||||
|
||||
Use of this fix typically will cause the number of atoms to fluctuate,
|
||||
therefore, you will want to use the
|
||||
@ -276,16 +309,23 @@ therefore, you will want to use the
|
||||
current number of atoms is used as a normalizing factor each time
|
||||
temperature is computed. Here is the necessary command:
|
||||
|
||||
NOTE: If the density of the cell is initially very small or zero, and
|
||||
increases to a much larger density after a period of equilibration,
|
||||
then certain quantities that are only calculated once at the start
|
||||
(kspace parameters, tail corrections) may no longer be accurate. The
|
||||
solution is to start a new simulation after the equilibrium density
|
||||
has been reached.
|
||||
|
||||
With some pair_styles, such as "Buckingham"_pair_buck.html,
|
||||
"Born-Mayer-Huggins"_pair_born.html and "ReaxFF"_pair_reax_c.html,
|
||||
two atoms placed close to each other may have an arbitrary large,
|
||||
negative potential energy due to the functional form of the potential.
|
||||
While these unphysical configurations are inaccessible
|
||||
to typical dynamical trajectories,
|
||||
they can be generated by Monte Carlo moves. The {overlap_cutoff}
|
||||
keyword suppresses these moves by effectively assigning an
|
||||
infinite positive energy to all new configurations that place any
|
||||
pair of atoms closer than the specified overlap cutoff distance.
|
||||
"Born-Mayer-Huggins"_pair_born.html and "ReaxFF"_pair_reaxc.html, two
|
||||
atoms placed close to each other may have an arbitrary large, negative
|
||||
potential energy due to the functional form of the potential. While
|
||||
these unphysical configurations are inaccessible to typical dynamical
|
||||
trajectories, they can be generated by Monte Carlo moves. The
|
||||
{overlap_cutoff} keyword suppresses these moves by effectively
|
||||
assigning an infinite positive energy to all new configurations that
|
||||
place any pair of atoms closer than the specified overlap cutoff
|
||||
distance.
|
||||
|
||||
compute_modify thermo_temp dynamic yes :pre
|
||||
|
||||
@ -295,10 +335,10 @@ derived from LJ parameters for argon, where h* = h/sqrt(sigma^2 *
|
||||
epsilon * mass), sigma = 3.429 angstroms, epsilon/k = 121.85 K, and
|
||||
mass = 39.948 amu.
|
||||
|
||||
The {group} keyword assigns all inserted atoms to the "group"_group.html
|
||||
of the group-ID value. The {grouptype} keyword assigns all
|
||||
inserted atoms of the specified type to the "group"_group.html
|
||||
of the group-ID value.
|
||||
The {group} keyword assigns all inserted atoms to the
|
||||
"group"_group.html of the group-ID value. The {grouptype} keyword
|
||||
assigns all inserted atoms of the specified type to the
|
||||
"group"_group.html of the group-ID value.
|
||||
|
||||
[Restart, fix_modify, output, run start/stop, minimize info:]
|
||||
|
||||
@ -346,15 +386,15 @@ well in parallel. Only usable for 3D simulations.
|
||||
Note that very lengthy simulations involving insertions/deletions of
|
||||
billions of gas molecules may run out of atom or molecule IDs and
|
||||
trigger an error, so it is better to run multiple shorter-duration
|
||||
simulations. Likewise, very large molecules have not been tested
|
||||
and may turn out to be problematic.
|
||||
simulations. Likewise, very large molecules have not been tested and
|
||||
may turn out to be problematic.
|
||||
|
||||
Use of multiple fix gcmc commands in the same input script can be
|
||||
problematic if using a template molecule. The issue is that the
|
||||
user-referenced template molecule in the second fix gcmc command
|
||||
may no longer exist since it might have been deleted by the first
|
||||
fix gcmc command. An existing template molecule will need to be
|
||||
referenced by the user for each subsequent fix gcmc command.
|
||||
user-referenced template molecule in the second fix gcmc command may
|
||||
no longer exist since it might have been deleted by the first fix gcmc
|
||||
command. An existing template molecule will need to be referenced by
|
||||
the user for each subsequent fix gcmc command.
|
||||
|
||||
[Related commands:]
|
||||
|
||||
@ -366,7 +406,7 @@ referenced by the user for each subsequent fix gcmc command.
|
||||
[Default:]
|
||||
|
||||
The option defaults are mol = no, maxangle = 10, overlap_cutoff = 0.0,
|
||||
and full_energy = no,
|
||||
fugacity_coeff = 1, and full_energy = no,
|
||||
except for the situations where full_energy is required, as
|
||||
listed above.
|
||||
|
||||
|
||||
@ -67,9 +67,10 @@ target value as the {Tstart} and {Tstop} arguments, so that the diffusion
|
||||
matrix that gives canonical sampling for a given A is computed automatically.
|
||||
However, the GLE framework also allow for non-equilibrium sampling, that
|
||||
can be used for instance to model inexpensively zero-point energy
|
||||
effects "(Ceriotti2)"_#Ceriotti2. This is achieved specifying the
|
||||
{noneq} keyword followed by the name of the file that contains the
|
||||
static covariance matrix for the non-equilibrium dynamics.
|
||||
effects "(Ceriotti2)"_#Ceriotti2. This is achieved specifying the {noneq}
|
||||
keyword followed by the name of the file that contains the static covariance
|
||||
matrix for the non-equilibrium dynamics. Please note, that the covariance
|
||||
matrix is expected to be given in [temperature units].
|
||||
|
||||
Since integrating GLE dynamics can be costly when used together with
|
||||
simple potentials, one can use the {every} optional keyword to
|
||||
@ -148,7 +149,7 @@ dpd/tstat"_pair_dpd.html, "fix gld"_fix_gld.html
|
||||
1170-80 (2010)
|
||||
|
||||
:link(GLE4MD)
|
||||
[(GLE4MD)] "http://epfl-cosmo.github.io/gle4md/"_http://epfl-cosmo.github.io/gle4md/
|
||||
[(GLE4MD)] "http://gle4md.org/"_http://gle4md.org/
|
||||
|
||||
:link(Ceriotti2)
|
||||
[(Ceriotti2)] Ceriotti, Bussi and Parrinello, Phys Rev Lett 103,
|
||||
|
||||
@ -91,7 +91,7 @@ their DOF are assumed to be constant. If you are adding atoms or
|
||||
molecules to the system (see the "fix pour"_fix_pour.html, "fix
|
||||
deposit"_fix_deposit.html, and "fix gcmc"_fix_gcmc.html commands) or
|
||||
expect atoms or molecules to be lost (e.g. due to exiting the
|
||||
simulation box or via "fix evaporation"_fix_evaporation.html), then
|
||||
simulation box or via "fix evaporate"_fix_evaporate.html), then
|
||||
this option should be used to insure the temperature is correctly
|
||||
normalized.
|
||||
|
||||
|
||||
76
doc/src/fix_python.txt
Normal file
76
doc/src/fix_python.txt
Normal file
@ -0,0 +1,76 @@
|
||||
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
fix python command :h3
|
||||
|
||||
[Syntax:]
|
||||
|
||||
fix ID group-ID python N callback function_name :pre
|
||||
|
||||
ID, group-ID are ignored by this fix :ulb,l
|
||||
python = style name of this fix command :l
|
||||
N = execute every N steps :l
|
||||
callback = {post_force} or {end_of_step} :l
|
||||
{post_force} = callback after force computations on atoms every N time steps
|
||||
{end_of_step} = callback after every N time steps :pre
|
||||
:ule
|
||||
|
||||
[Examples:]
|
||||
|
||||
python post_force_callback here """
|
||||
from lammps import lammps :pre
|
||||
|
||||
def post_force_callback(lammps_ptr, vflag):
|
||||
lmp = lammps(ptr=lammps_ptr)
|
||||
# access LAMMPS state using Python interface
|
||||
""" :pre
|
||||
|
||||
python end_of_step_callback here """
|
||||
def end_of_step_callback(lammps_ptr):
|
||||
lmp = lammps(ptr=lammps_ptr)
|
||||
# access LAMMPS state using Python interface
|
||||
""" :pre
|
||||
|
||||
fix pf all python 50 post_force post_force_callback
|
||||
fix eos all python 50 end_of_step end_of_step_callback :pre
|
||||
|
||||
[Description:]
|
||||
|
||||
This fix allows you to call a Python function during a simulation run.
|
||||
The callback is either executed after forces have been applied to atoms
|
||||
or at the end of every N time steps.
|
||||
|
||||
Callback functions must be declared in the global scope of the
|
||||
active Python interpreter. This can either be done by defining it
|
||||
inline using the python command or by importing functions from other
|
||||
Python modules. If LAMMPS is driven using the library interface from
|
||||
Python, functions defined in the driving Python interpreter can also
|
||||
be executed.
|
||||
|
||||
Each callback is given a pointer object as first argument. This can be
|
||||
used to initialize an instance of the lammps Python interface, which
|
||||
gives access to the LAMMPS state from Python.
|
||||
|
||||
IMPORTANT NOTE: While you can access the state of LAMMPS via library functions
|
||||
from these callbacks, trying to execute input script commands will in the best
|
||||
case not work or in the worst case result in undefined behavior.
|
||||
|
||||
[Restrictions:]
|
||||
|
||||
This fix is part of the PYTHON package. It is only enabled if
|
||||
LAMMPS was built with that package. See the "Making
|
||||
LAMMPS"_Section_start.html#start_3 section for more info.
|
||||
|
||||
Building LAMMPS with the PYTHON package will link LAMMPS with the
|
||||
Python library on your system. Settings to enable this are in the
|
||||
lib/python/Makefile.lammps file. See the lib/python/README file for
|
||||
information on those settings.
|
||||
|
||||
[Related commands:]
|
||||
|
||||
"python command"_python.html
|
||||
@ -74,7 +74,7 @@ NOTE: The "fix qeq/comb"_fix_qeq_comb.html command must still be used
|
||||
to perform charge equilibration with the "COMB
|
||||
potential"_pair_comb.html. The "fix qeq/reax"_fix_qeq_reax.html
|
||||
command can be used to perform charge equilibration with the "ReaxFF
|
||||
force field"_pair_reax_c.html, although fix qeq/shielded yields the
|
||||
force field"_pair_reaxc.html, although fix qeq/shielded yields the
|
||||
same results as fix qeq/reax if {Nevery}, {cutoff}, and {tolerance}
|
||||
are the same. Eventually the fix qeq/reax command will be deprecated.
|
||||
|
||||
@ -116,7 +116,7 @@ the shielded Coulomb is given by equation (13) of the "ReaxFF force
|
||||
field"_#vanDuin paper. The shielding accounts for charge overlap
|
||||
between charged particles at small separation. This style is the same
|
||||
as "fix qeq/reax"_fix_qeq_reax.html, and can be used with "pair_style
|
||||
reax/c"_pair_reax_c.html. Only the {chi}, {eta}, and {gamma}
|
||||
reax/c"_pair_reaxc.html. Only the {chi}, {eta}, and {gamma}
|
||||
parameters from the {qfile} file are used. This style solves partial
|
||||
charges on atoms via the matrix inversion method. A tolerance of
|
||||
1.0e-6 is usually a good number.
|
||||
|
||||
@ -30,7 +30,7 @@ fix 1 all qeq/reax 1 0.0 10.0 1.0e-6 param.qeq :pre
|
||||
Perform the charge equilibration (QEq) method as described in "(Rappe
|
||||
and Goddard)"_#Rappe2 and formulated in "(Nakano)"_#Nakano2. It is
|
||||
typically used in conjunction with the ReaxFF force field model as
|
||||
implemented in the "pair_style reax/c"_pair_reax_c.html command, but
|
||||
implemented in the "pair_style reax/c"_pair_reaxc.html command, but
|
||||
it can be used with any potential in LAMMPS, so long as it defines and
|
||||
uses charges on each atom. The "fix qeq/comb"_fix_qeq_comb.html
|
||||
command should be used to perform charge equilibration with the "COMB
|
||||
@ -42,7 +42,7 @@ The QEq method minimizes the electrostatic energy of the system by
|
||||
adjusting the partial charge on individual atoms based on interactions
|
||||
with their neighbors. It requires some parameters for each atom type.
|
||||
If the {params} setting above is the word "reax/c", then these are
|
||||
extracted from the "pair_style reax/c"_pair_reax_c.html command and
|
||||
extracted from the "pair_style reax/c"_pair_reaxc.html command and
|
||||
the ReaxFF force field file it reads in. If a file name is specified
|
||||
for {params}, then the parameters are taken from the specified file
|
||||
and the file must contain one line for each atom type. The latter
|
||||
@ -106,7 +106,7 @@ be used for periodic cell dimensions less than 10 angstroms.
|
||||
|
||||
[Related commands:]
|
||||
|
||||
"pair_style reax/c"_pair_reax_c.html
|
||||
"pair_style reax/c"_pair_reaxc.html
|
||||
|
||||
[Default:] none
|
||||
|
||||
|
||||
@ -28,13 +28,30 @@ fix 1 all reax/c/bonds 100 bonds.reaxc :pre
|
||||
|
||||
Write out the bond information computed by the ReaxFF potential
|
||||
specified by "pair_style reax"_pair_reax.html or "pair_style
|
||||
reax/c"_pair_reax_c.html in the exact same format as the original
|
||||
reax/c"_pair_reaxc.html in the exact same format as the original
|
||||
stand-alone ReaxFF code of Adri van Duin. The bond information is
|
||||
written to {filename} on timesteps that are multiples of {Nevery},
|
||||
including timestep 0. For time-averaged chemical species analysis,
|
||||
please see the "fix reaxc/c/species"_fix_reaxc_species.html command.
|
||||
|
||||
The format of the output file should be self-explanatory.
|
||||
The format of the output file should be reasonably self-explanatory.
|
||||
The meaning of the column header abbreviations is as follows:
|
||||
|
||||
id = atom id
|
||||
type = atom type
|
||||
nb = number of bonds
|
||||
id_1 = atom id of first bond
|
||||
id_nb = atom id of Nth bond
|
||||
mol = molecule id
|
||||
bo_1 = bond order of first bond
|
||||
bo_nb = bond order of Nth bond
|
||||
abo = atom bond order (sum of all bonds)
|
||||
nlp = number of lone pairs
|
||||
q = atomic charge :ul
|
||||
|
||||
If the filename ends with ".gz", the output file is written in gzipped
|
||||
format. A gzipped dump file will be about 3x smaller than the text
|
||||
version, but will also take longer to write.
|
||||
|
||||
:line
|
||||
|
||||
@ -80,14 +97,17 @@ reax"_pair_reax.html be invoked. This fix is part of the REAX
|
||||
package. It is only enabled if LAMMPS was built with that package,
|
||||
which also requires the REAX library be built and linked with LAMMPS.
|
||||
The fix reax/c/bonds command requires that the "pair_style
|
||||
reax/c"_pair_reax_c.html be invoked. This fix is part of the
|
||||
reax/c"_pair_reaxc.html be invoked. This fix is part of the
|
||||
USER-REAXC package. It is only enabled if LAMMPS was built with that
|
||||
package. See the "Making LAMMPS"_Section_start.html#start_3 section
|
||||
for more info.
|
||||
|
||||
To write gzipped bond files, you must compile LAMMPS with the
|
||||
-DLAMMPS_GZIP option.
|
||||
|
||||
[Related commands:]
|
||||
|
||||
"pair_style reax"_pair_reax.html, "pair_style
|
||||
reax/c"_pair_reax_c.html, "fix reax/c/species"_fix_reaxc_species.html
|
||||
reax/c"_pair_reaxc.html, "fix reax/c/species"_fix_reaxc_species.html
|
||||
|
||||
[Default:] none
|
||||
|
||||
@ -41,7 +41,7 @@ fix 1 all reax/c/species 1 100 100 species.out element Au O H position 1000 AuOH
|
||||
[Description:]
|
||||
|
||||
Write out the chemical species information computed by the ReaxFF
|
||||
potential specified by "pair_style reax/c"_pair_reax_c.html.
|
||||
potential specified by "pair_style reax/c"_pair_reaxc.html.
|
||||
Bond-order values (either averaged or instantaneous, depending on
|
||||
value of {Nrepeat}) are used to determine chemical bonds. Every
|
||||
{Nfreq} timesteps, chemical species information is written to
|
||||
@ -52,6 +52,10 @@ number of molecules of each species. In this context, "species" means
|
||||
a unique molecule. The chemical formula of each species is given in
|
||||
the first line.
|
||||
|
||||
If the filename ends with ".gz", the output file is written in gzipped
|
||||
format. A gzipped dump file will be about 3x smaller than the text version,
|
||||
but will also take longer to write.
|
||||
|
||||
Optional keyword {cutoff} can be assigned to change the minimum
|
||||
bond-order values used in identifying chemical bonds between pairs of
|
||||
atoms. Bond-order cutoffs should be carefully chosen, as bond-order
|
||||
@ -65,7 +69,7 @@ symbol printed for each LAMMPS atom type. The number of symbols must
|
||||
match the number of LAMMPS atom types and each symbol must consist of
|
||||
1 or 2 alphanumeric characters. Normally, these symbols should be
|
||||
chosen to match the chemical identity of each LAMMPS atom type, as
|
||||
specified using the "reax/c pair_coeff"_pair_reax_c.html command and
|
||||
specified using the "reax/c pair_coeff"_pair_reaxc.html command and
|
||||
the ReaxFF force field file.
|
||||
|
||||
The optional keyword {position} writes center-of-mass positions of
|
||||
@ -158,19 +162,22 @@ more instructions on how to use the accelerated styles effectively.
|
||||
[Restrictions:]
|
||||
|
||||
The fix species currently only works with
|
||||
"pair_style reax/c"_pair_reax_c.html and it requires that the "pair_style
|
||||
reax/c"_pair_reax_c.html be invoked. This fix is part of the
|
||||
"pair_style reax/c"_pair_reaxc.html and it requires that the "pair_style
|
||||
reax/c"_pair_reaxc.html be invoked. This fix is part of the
|
||||
USER-REAXC package. It is only enabled if LAMMPS was built with that
|
||||
package. See the "Making LAMMPS"_Section_start.html#start_3 section
|
||||
for more info.
|
||||
|
||||
To write gzipped species files, you must compile LAMMPS with the
|
||||
-DLAMMPS_GZIP option.
|
||||
|
||||
It should be possible to extend it to other reactive pair_styles (such as
|
||||
"rebo"_pair_airebo.html, "airebo"_pair_airebo.html,
|
||||
"comb"_pair_comb.html, and "bop"_pair_bop.html), but this has not yet been done.
|
||||
|
||||
[Related commands:]
|
||||
|
||||
"pair_style reax/c"_pair_reax_c.html, "fix
|
||||
"pair_style reax/c"_pair_reaxc.html, "fix
|
||||
reax/bonds"_fix_reax_bonds.html
|
||||
|
||||
[Default:]
|
||||
|
||||
@ -111,6 +111,7 @@ Fixes :h1
|
||||
fix_press_berendsen
|
||||
fix_print
|
||||
fix_property_atom
|
||||
fix_python
|
||||
fix_qbmsst
|
||||
fix_qeq
|
||||
fix_qeq_comb
|
||||
|
||||
@ -45,12 +45,9 @@ above, or in the data file or restart files read by the
|
||||
"read_data"_read_data.html or "read_restart"_read_restart.html
|
||||
commands:
|
||||
|
||||
K (energy/radian^2)
|
||||
K (energy)
|
||||
X0 (degrees) :ul
|
||||
|
||||
X0 is specified in degrees, but LAMMPS converts it to radians
|
||||
internally; hence the units of K are in energy/radian^2.
|
||||
|
||||
:line
|
||||
|
||||
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
|
||||
|
||||
@ -49,12 +49,9 @@ above, or in the data file or restart files read by the
|
||||
"read_data"_read_data.html or "read_restart"_read_restart.html
|
||||
commands:
|
||||
|
||||
K (energy/radian^2)
|
||||
K (energy)
|
||||
theta0 (degrees) :ul
|
||||
|
||||
theta0 is specified in degrees, but LAMMPS converts it to radians
|
||||
internally; hence the units of K are in energy/radian^2.
|
||||
|
||||
:line
|
||||
|
||||
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
|
||||
|
||||
@ -290,9 +290,10 @@ to be specified using the {gewald/disp}, {mesh/disp},
|
||||
{force/disp/real} or {force/disp/kspace} keywords, or
|
||||
the code will stop with an error message. When this option is set to
|
||||
{yes}, the error message will not appear and the simulation will start.
|
||||
For a typical application, using the automatic parameter generation will provide
|
||||
simulations that are either inaccurate or slow. Using this option is thus not
|
||||
recommended. For guidelines on how to obtain good parameters, see the "How-To"_Section_howto.html#howto_23 discussion.
|
||||
For a typical application, using the automatic parameter generation
|
||||
will provide simulations that are either inaccurate or slow. Using this
|
||||
option is thus not recommended. For guidelines on how to obtain good
|
||||
parameters, see the "How-To"_Section_howto.html#howto_24 discussion.
|
||||
|
||||
[Restrictions:] none
|
||||
|
||||
|
||||
@ -55,12 +55,12 @@ dihedral_style.html
|
||||
dimension.html
|
||||
displace_atoms.html
|
||||
dump.html
|
||||
dump_custom_vtk.html
|
||||
dump_h5md.html
|
||||
dump_image.html
|
||||
dump_modify.html
|
||||
dump_molfile.html
|
||||
dump_nc.html
|
||||
dump_netcdf.html
|
||||
dump_vtk.html
|
||||
echo.html
|
||||
fix.html
|
||||
fix_modify.html
|
||||
@ -237,6 +237,7 @@ fix_pour.html
|
||||
fix_press_berendsen.html
|
||||
fix_print.html
|
||||
fix_property_atom.html
|
||||
fix_python.html
|
||||
fix_qbmsst.html
|
||||
fix_qeq.html
|
||||
fix_qeq_comb.html
|
||||
@ -432,6 +433,7 @@ pair_gauss.html
|
||||
pair_gayberne.html
|
||||
pair_gran.html
|
||||
pair_gromacs.html
|
||||
pair_gw.html
|
||||
pair_hbond_dreiding.html
|
||||
pair_hybrid.html
|
||||
pair_kim.html
|
||||
@ -464,11 +466,13 @@ pair_nb3b_harmonic.html
|
||||
pair_nm.html
|
||||
pair_none.html
|
||||
pair_oxdna.html
|
||||
pair_oxdna2.html
|
||||
pair_peri.html
|
||||
pair_polymorphic.html
|
||||
pair_python.html
|
||||
pair_quip.html
|
||||
pair_reax.html
|
||||
pair_reax_c.html
|
||||
pair_reaxc.html
|
||||
pair_resquared.html
|
||||
pair_sdk.html
|
||||
pair_smd_hertz.html
|
||||
|
||||
@ -75,7 +75,7 @@ Lennard-Jones 12/6) given by
|
||||
:c,image(Eqs/pair_buck.jpg)
|
||||
|
||||
where rho is an ionic-pair dependent length parameter, and Rc is the
|
||||
cutoff on both terms.
|
||||
cutoff on both terms.
|
||||
|
||||
The styles with {coul/cut} or {coul/long} or {coul/msm} add a
|
||||
Coulombic term as described for the "lj/cut"_pair_lj.html pair styles.
|
||||
@ -120,6 +120,9 @@ cutoff (distance units)
|
||||
cutoff2 (distance units) :ul
|
||||
|
||||
The second coefficient, rho, must be greater than zero.
|
||||
The coefficients A, rho, and C can be written as analytical expressions
|
||||
of epsilon and sigma, in analogy to the Lennard-Jones potential
|
||||
"(Khrapak)"_#Khrapak.
|
||||
|
||||
The latter 2 coefficients are optional. If not specified, the global
|
||||
A,C and Coulombic cutoffs are used. If only one cutoff is specified,
|
||||
@ -127,7 +130,6 @@ it is used as the cutoff for both A,C and Coulombic interactions for
|
||||
this type pair. If both coefficients are specified, they are used as
|
||||
the A,C and Coulombic cutoffs for this type pair. You cannot specify
|
||||
2 cutoffs for style {buck}, since it has no Coulombic terms.
|
||||
|
||||
For {buck/coul/long} only the LJ cutoff can be specified since a
|
||||
Coulombic cutoff cannot be specified for an individual I,J type pair.
|
||||
All type pairs use the same global Coulombic cutoff specified in the
|
||||
@ -194,3 +196,6 @@ only enabled if LAMMPS was built with that package. See the
|
||||
"pair_coeff"_pair_coeff.html, "pair_style born"_pair_born.html
|
||||
|
||||
[Default:] none
|
||||
|
||||
:link(Khrapak)
|
||||
[(Khrapak)] Khrapak, Chaudhuri, and Morfill, J Chem Phys, 134, 054120 (2011).
|
||||
|
||||
@ -49,8 +49,8 @@ args = list of arguments for a particular style :ul
|
||||
|
||||
pair_style lj/charmm/coul/charmm 8.0 10.0
|
||||
pair_style lj/charmm/coul/charmm 8.0 10.0 7.0 9.0
|
||||
pair_style lj/charmmfsw/coul/charmmfsh 8.0 10.0
|
||||
pair_style lj/charmmfsw/coul/charmmfsh 8.0 10.0 7.0 9.0
|
||||
pair_style lj/charmmfsw/coul/charmmfsh 10.0 12.0
|
||||
pair_style lj/charmmfsw/coul/charmmfsh 10.0 12.0 9.0
|
||||
pair_coeff * * 100.0 2.0
|
||||
pair_coeff 1 1 100.0 2.0 150.0 3.5 :pre
|
||||
|
||||
@ -84,9 +84,9 @@ CHARMM force field.
|
||||
The styles with {charmm} (not {charmmfsw} or {charmmfsh}) in their
|
||||
name are the older, original LAMMPS implementations. They compute the
|
||||
LJ and Coulombic interactions with an energy switching function (esw,
|
||||
a cubic polynomial, shown in the formula below), which ramps the
|
||||
energy smoothly to zero between the inner and outer cutoff. This can
|
||||
cause irregularities in pair-wise forces (due to the discontinuous 2nd
|
||||
shown in the formula below as S(r)), which ramps the energy smoothly
|
||||
to zero between the inner and outer cutoff. This can cause
|
||||
irregularities in pair-wise forces (due to the discontinuous 2nd
|
||||
derivative of energy at the boundaries of the switching region), which
|
||||
in some cases can result in detectable artifacts in an MD simulation.
|
||||
|
||||
@ -94,14 +94,15 @@ The newer styles with {charmmfsw} or {charmmfsh} in their name replace
|
||||
the energy switching with force switching (fsw) and force shifting
|
||||
(fsh) functions, for LJ and Coulombic interactions respectively.
|
||||
These follow the formulas and description given in
|
||||
"(Steinbach)"_#Steinbach and "(Brooks)"_#Brooks to minimize these
|
||||
"(Steinbach)"_#Steinbach and "(Brooks)"_#Brooks1 to minimize these
|
||||
artifacts.
|
||||
|
||||
NOTE: The newer {charmmfsw} or {charmmfsh} styles were released in
|
||||
March 2017. We recommend they be used instead of the older {charmm}
|
||||
styles. Eventually code from the new styles will propagate into the
|
||||
related pair styles (e.g. implicit, accelerator, free energy
|
||||
variants).
|
||||
styles. This includes the newer "dihedral_style
|
||||
charmmfsw"_dihedral_charmm.html command. Eventually code from the new
|
||||
styles will propagate into the related pair styles (e.g. implicit,
|
||||
accelerator, free energy variants).
|
||||
|
||||
The general CHARMM formulas are as follows
|
||||
|
||||
@ -248,7 +249,7 @@ the MOLECULE and KSPACE packages are installed by default.
|
||||
|
||||
:line
|
||||
|
||||
:link(Brooks)
|
||||
:link(Brooks1)
|
||||
[(Brooks)] Brooks, et al, J Comput Chem, 30, 1545 (2009).
|
||||
|
||||
:link(pair-MacKerell)
|
||||
|
||||
@ -7,11 +7,13 @@
|
||||
:line
|
||||
|
||||
pair_style edip command :h3
|
||||
pair_style edip/multi command :h3
|
||||
|
||||
[Syntax:]
|
||||
|
||||
pair_style edip :pre
|
||||
pair_style edip/omp :pre
|
||||
pair_style style :pre
|
||||
|
||||
style = {edip} or {edip/multi} :ul
|
||||
|
||||
[Examples:]
|
||||
|
||||
@ -20,11 +22,14 @@ pair_coeff * * Si.edip Si
|
||||
|
||||
[Description:]
|
||||
|
||||
The {edip} style computes a 3-body "EDIP"_#EDIP potential which is
|
||||
popular for modeling silicon materials where it can have advantages
|
||||
over other models such as the "Stillinger-Weber"_pair_sw.html or
|
||||
"Tersoff"_pair_tersoff.html potentials. In EDIP, the energy E of a
|
||||
system of atoms is
|
||||
The {edip} and {edip/multi} styles compute a 3-body "EDIP"_#EDIP
|
||||
potential which is popular for modeling silicon materials where
|
||||
it can have advantages over other models such as the
|
||||
"Stillinger-Weber"_pair_sw.html or "Tersoff"_pair_tersoff.html
|
||||
potentials. The {edip} style has been programmed for single element
|
||||
potentials, while {edip/multi} supports multi-element EDIP runs.
|
||||
|
||||
In EDIP, the energy E of a system of atoms is
|
||||
|
||||
:c,image(Eqs/pair_edip.jpg)
|
||||
|
||||
@ -142,7 +147,7 @@ This pair style can only be used via the {pair} keyword of the
|
||||
|
||||
[Restrictions:]
|
||||
|
||||
This angle style can only be used if LAMMPS was built with the
|
||||
This pair style can only be used if LAMMPS was built with the
|
||||
USER-MISC package. See the "Making LAMMPS"_Section_start.html#start_3
|
||||
section for more info on packages.
|
||||
|
||||
@ -151,7 +156,7 @@ for pair interactions.
|
||||
|
||||
The EDIP potential files provided with LAMMPS (see the potentials directory)
|
||||
are parameterized for metal "units"_units.html.
|
||||
You can use the SW potential with any LAMMPS units, but you would need
|
||||
You can use the EDIP potential with any LAMMPS units, but you would need
|
||||
to create your own EDIP potential file with coefficients listed in the
|
||||
appropriate units if your simulation doesn't use "metal" units.
|
||||
|
||||
@ -164,4 +169,4 @@ appropriate units if your simulation doesn't use "metal" units.
|
||||
:line
|
||||
|
||||
:link(EDIP)
|
||||
[(EDIP)] J. F. Justo et al., Phys. Rev. B 58, 2539 (1998).
|
||||
[(EDIP)] J F Justo et al, Phys Rev B 58, 2539 (1998).
|
||||
|
||||
@ -128,7 +128,7 @@ The B parameter is converted to a distance (sigma), before mixing
|
||||
afterwards (using B=sigma^2).
|
||||
Negative A values are converted to positive A values (using abs(A))
|
||||
before mixing, and converted back after mixing
|
||||
(by multiplying by sign(Ai)*sign(Aj)).
|
||||
(by multiplying by min(sign(Ai),sign(Aj))).
|
||||
This way, if either particle is repulsive (if Ai<0 or Aj<0),
|
||||
then the default interaction between both particles will be repulsive.
|
||||
|
||||
|
||||
120
doc/src/pair_gw.txt
Normal file
120
doc/src/pair_gw.txt
Normal file
@ -0,0 +1,120 @@
|
||||
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
pair_style gw command :h3
|
||||
pair_style gw/zbl command :h3
|
||||
|
||||
[Syntax:]
|
||||
|
||||
pair_style style :pre
|
||||
|
||||
style = {gw} or {gw/zbl} :ul
|
||||
|
||||
[Examples:]
|
||||
|
||||
pair_style gw
|
||||
pair_coeff * * SiC.gw Si C C
|
||||
|
||||
pair_style gw/zbl
|
||||
pair_coeff * * SiC.gw.zbl C Si :pre
|
||||
|
||||
[Description:]
|
||||
|
||||
The {gw} style computes a 3-body "Gao-Weber"_#Gao potential;
|
||||
similarly {gw/zbl} combines this potential with a modified
|
||||
repulsive ZBL core function in a similar fashion as implemented
|
||||
in the "tersoff/zbl"_pair_tersoff_zbl.html pair style.
|
||||
|
||||
Unfortunately the author of this contributed code has not been
|
||||
able to submit a suitable documentation explaining the details
|
||||
of the potentials. The LAMMPS developers thus have finally decided
|
||||
to release the code anyway with only the technical explanations.
|
||||
For details of the model and the parameters, please refer to the
|
||||
linked publication.
|
||||
|
||||
Only a single pair_coeff command is used with the {gw} and {gw/zbl}
|
||||
styles which specifies a Gao-Weber potential file with parameters
|
||||
for all needed elements. These are mapped to LAMMPS atom types by
|
||||
specifying N additional arguments after the filename in the pair_coeff
|
||||
command, where N is the number of LAMMPS atom types:
|
||||
|
||||
filename
|
||||
N element names = mapping of GW elements to atom types :ul
|
||||
|
||||
See the "pair_coeff"_pair_coeff.html doc page for alternate ways
|
||||
to specify the path for the potential file.
|
||||
|
||||
As an example, imagine a file SiC.gw has Gao-Weber values for Si and C.
|
||||
If your LAMMPS simulation has 4 atoms types and you want the first 3 to
|
||||
be Si, and the 4th to be C, you would use the following pair_coeff command:
|
||||
|
||||
pair_coeff * * SiC.gw Si Si Si C :pre
|
||||
|
||||
The first 2 arguments must be * * so as to span all LAMMPS atom types.
|
||||
The first three Si arguments map LAMMPS atom types 1,2,3 to the Si
|
||||
element in the GW file. The final C argument maps LAMMPS atom type 4
|
||||
to the C element in the GW file. If a mapping value is specified as
|
||||
NULL, the mapping is not performed. This can be used when a {gw}
|
||||
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.
|
||||
|
||||
Gao-Weber files in the {potentials} directory of the LAMMPS
|
||||
distribution have a ".gw" suffix. Gao-Weber with ZBL files
|
||||
have a ".gz.zbl" suffix. The structure of the potential files
|
||||
is similar to other many-body potentials supported by LAMMPS.
|
||||
You have to refer to the comments in the files and the literature
|
||||
to learn more details.
|
||||
|
||||
: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 as
|
||||
described above from values in the potential file.
|
||||
|
||||
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:]
|
||||
|
||||
This pair style is part of the USER-MISC package. It is only enabled
|
||||
if LAMMPS was built with that package. See
|
||||
the "Making LAMMPS"_Section_start.html#start_3 section for more info.
|
||||
|
||||
This pair style requires the "newton"_newton.html setting to be "on"
|
||||
for pair interactions.
|
||||
|
||||
The Gao-Weber potential files provided with LAMMPS (see the
|
||||
potentials directory) are parameterized for metal "units"_units.html.
|
||||
You can use the GW potential with any LAMMPS units, but you would need
|
||||
to create your own GW potential file with coefficients listed in the
|
||||
appropriate units if your simulation doesn't use "metal" units.
|
||||
|
||||
[Related commands:]
|
||||
|
||||
"pair_coeff"_pair_coeff.html
|
||||
|
||||
[Default:] none
|
||||
|
||||
:line
|
||||
|
||||
:link(Gao)
|
||||
[(Gao)] Gao and Weber, Nuclear Instruments and Methods in Physics Research B 191 (2012) 504.
|
||||
@ -73,7 +73,7 @@ pair_coeff command to assign parameters for the different type pairs.
|
||||
NOTE: There are two exceptions to this option to list an individual
|
||||
pair style multiple times. The first is for pair styles implemented
|
||||
as Fortran libraries: "pair_style meam"_pair_meam.html and "pair_style
|
||||
reax"_pair_reax.html ("pair_style reax/c"_pair_reax_c.html is OK).
|
||||
reax"_pair_reax.html ("pair_style reax/c"_pair_reaxc.html is OK).
|
||||
This is because unlike a C++ class, they can not be instantiated
|
||||
multiple times, due to the manner in which they were coded in Fortran.
|
||||
The second is for GPU-enabled pair styles in the GPU package. This is
|
||||
@ -225,6 +225,12 @@ special_bonds lj/coul 1e-20 1e-20 0.5
|
||||
pair_hybrid tersoff lj/cut/coul/long 12.0
|
||||
pair_modify pair tersoff special lj/coul 1.0 1.0 1.0 :pre
|
||||
|
||||
For use with the various "compute */tally"_compute_tally.html
|
||||
computes, the "pair_modify compute/tally"_pair_modify.html
|
||||
command can be used to selectively turn off processing of
|
||||
the compute tally styles, for example, if those pair styles
|
||||
(e.g. manybody styles) do not support this feature.
|
||||
|
||||
See the "pair_modify"_pair_modify.html doc page for details on
|
||||
the specific syntax, requirements and restrictions.
|
||||
|
||||
|
||||
@ -23,7 +23,8 @@ pair_coeff * * Ti.meam.spline Ti Ti Ti :pre
|
||||
|
||||
The {meam/spline} style computes pairwise interactions for metals
|
||||
using a variant of modified embedded-atom method (MEAM) potentials
|
||||
"(Lenosky)"_#Lenosky1. The total energy E is given by
|
||||
"(Lenosky)"_#Lenosky1. For a single species ("old-style") MEAM,
|
||||
the total energy E is given by
|
||||
|
||||
:c,image(Eqs/pair_meam_spline.jpg)
|
||||
|
||||
@ -31,6 +32,20 @@ where rho_i is the density at atom I, theta_jik is the angle between
|
||||
atoms J, I, and K centered on atom I. The five functions Phi, U, rho,
|
||||
f, and g are represented by cubic splines.
|
||||
|
||||
The {meam/spline} style also supports a new style multicomponent
|
||||
modified embedded-atom method (MEAM) potential "(Zhang)"_#Zhang4, where
|
||||
the total energy E is given by
|
||||
|
||||
:c,image(Eqs/pair_meam_spline_multicomponent.jpg)
|
||||
|
||||
where the five functions Phi, U, rho, f, and g depend on the chemistry
|
||||
of the atoms in the interaction. In particular, if there are N different
|
||||
chemistries, there are N different U, rho, and f functions, while there
|
||||
are N(N+1)/2 different Phi and g functions. The new style multicomponent
|
||||
MEAM potential files are indicated by the second line in the file starts
|
||||
with "meam/spline" followed by the number of elements and the name of each
|
||||
element.
|
||||
|
||||
The cutoffs and the coefficients for these spline functions are listed
|
||||
in a parameter file which is specified by the
|
||||
"pair_coeff"_pair_coeff.html command. Parameter files for different
|
||||
@ -59,7 +74,7 @@ N element names = mapping of spline-based 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 file.
|
||||
|
||||
As an example, imagine the Ti.meam.spline file has values for Ti. If
|
||||
As an example, imagine the Ti.meam.spline file has values for Ti (old style). If
|
||||
your LAMMPS simulation has 3 atoms types and they are all to be
|
||||
treated with this potentials, you would use the following pair_coeff
|
||||
command:
|
||||
@ -72,10 +87,19 @@ in the potential file. If a mapping value is specified as NULL, the
|
||||
mapping is not performed. This can be used when a {meam/spline}
|
||||
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.
|
||||
potentials. The old-style potential maps any non-NULL species named
|
||||
on the command line to that single type.
|
||||
|
||||
NOTE: The {meam/spline} style currently supports only single-element
|
||||
MEAM potentials. It may be extended for alloy systems in the future.
|
||||
An example with a two component spline (new style) is TiO.meam.spline, where
|
||||
the command
|
||||
|
||||
pair_coeff * * TiO.meam.spline Ti O :pre
|
||||
|
||||
will map the 1st atom type to Ti and the second atom type to O. Note
|
||||
in this case that the species names need to match exactly with the
|
||||
names of the elements in the TiO.meam.spline file; otherwise an
|
||||
error will be raised. This behavior is different than the old style
|
||||
MEAM files.
|
||||
|
||||
:line
|
||||
|
||||
@ -104,9 +128,6 @@ more instructions on how to use the accelerated styles effectively.
|
||||
|
||||
[Mixing, shift, table, tail correction, restart, rRESPA info]:
|
||||
|
||||
The current version of this pair style does not support multiple
|
||||
element types or mixing. It has been designed for pure elements only.
|
||||
|
||||
This pair style does not support the "pair_modify"_pair_modify.html
|
||||
shift, table, and tail options.
|
||||
|
||||
@ -142,3 +163,6 @@ for more info.
|
||||
[(Lenosky)] Lenosky, Sadigh, Alonso, Bulatov, de la Rubia, Kim, Voter,
|
||||
Kress, Modelling Simulation Materials Science Engineering, 8, 825
|
||||
(2000).
|
||||
|
||||
:link(Zhang4)
|
||||
[(Zhang)] Zhang and Trinkle, Computational Materials Science, 124, 204-210 (2016).
|
||||
|
||||
@ -15,11 +15,13 @@ 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} :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
|
||||
{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
|
||||
@ -40,6 +42,7 @@ 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:]
|
||||
@ -60,9 +63,12 @@ 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} keyword can only be used in conjunction with the {pair}
|
||||
keyword and must directly follow it. It allows to override the
|
||||
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
|
||||
@ -231,6 +237,14 @@ 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
|
||||
@ -240,8 +254,9 @@ conflicting options. You cannot use {tail} yes with 2d simulations.
|
||||
|
||||
[Related commands:]
|
||||
|
||||
"pair_style"_pair_style.html, "pair_coeff"_pair_coeff.html,
|
||||
"thermo_style"_thermo_style.html
|
||||
"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:]
|
||||
|
||||
|
||||
@ -14,15 +14,23 @@ pair_style oxdna/coaxstk command :h3
|
||||
|
||||
[Syntax:]
|
||||
|
||||
pair_style style :pre
|
||||
pair_style style1 :pre
|
||||
|
||||
style = {hybrid/overlay oxdna/excv oxdna/stk oxdna/hbond oxdna/xstk oxdna/coaxstk} :ul
|
||||
pair_coeff * * style2 args :pre
|
||||
|
||||
style1 = {hybrid/overlay oxdna/excv oxdna/stk oxdna/hbond oxdna/xstk oxdna/coaxstk} :ul
|
||||
|
||||
style2 = {oxdna/stk}
|
||||
args = list of arguments for these two particular styles :ul
|
||||
|
||||
{oxdna2/stk} args = T 6.0 0.4 0.9 0.32 0.6 1.3 0 0.8 0.9 0 0.95 0.9 0 0.95 2.0 0.65 2.0 0.65
|
||||
T = temperature (oxDNA units, 0.1 = 300 K) :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 1.61048 6.0 0.4 0.9 0.32 0.6 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/stk 0.1 6.0 0.4 0.9 0.32 0.6 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 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 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 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
|
||||
@ -42,19 +50,23 @@ The exact functional form of the pair styles is rather complex, which manifests
|
||||
in the above example. 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-DPhil and "(Ouldridge)"_#Ouldridge
|
||||
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). The coefficients
|
||||
"bond_style oxdna/fene"_bond_oxdna.html). With one exception the coefficients
|
||||
in the above example have to be kept fixed and cannot be changed without reparametrizing the entire model.
|
||||
The exception is the first coefficient after {oxdna/stk} (T=0.1 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 can be found in examples/USER/cgdna/examples/duplex1/ and /duplex2/.
|
||||
A simple python setup tool which creates single straight or helical DNA strands,
|
||||
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/.
|
||||
A technical report with more information on the model, the structure of the input file,
|
||||
the setup tool and the performance of the LAMMPS-implementation of oxDNA
|
||||
the setup tool and the performance of the LAMMPS-implementation of oxDNA
|
||||
can be found "here"_PDF/USER-CGDNA-overview.pdf.
|
||||
|
||||
:line
|
||||
@ -67,14 +79,14 @@ LAMMPS"_Section_start.html#start_3 section for more info on packages.
|
||||
|
||||
[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 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(Ouldridge-DPhil)
|
||||
:link(Ouldridge-DPhil1)
|
||||
[(Ouldrigde-DPhil)] T.E. Ouldridge, Coarse-grained modelling of DNA and DNA self-assembly, DPhil. University of Oxford (2011).
|
||||
|
||||
:link(Ouldridge)
|
||||
:link(Ouldridge1)
|
||||
[(Ouldridge)] T.E. Ouldridge, A.A. Louis, J.P.K. Doye, J. Chem. Phys. 134, 085101 (2011).
|
||||
|
||||
102
doc/src/pair_oxdna2.txt
Normal file
102
doc/src/pair_oxdna2.txt
Normal file
@ -0,0 +1,102 @@
|
||||
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
pair_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/stk} or {oxdna2/dh}
|
||||
args = list of arguments for these two particular styles :ul
|
||||
|
||||
{oxdna2/stk} args = T 6.0 0.4 0.9 0.32 0.6 1.3 0 0.8 0.9 0 0.95 0.9 0 0.95 2.0 0.65 2.0 0.65
|
||||
T = temperature (oxDNA units, 0.1 = 300 K)
|
||||
{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 0.1 6.0 0.4 0.9 0.32 0.6 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 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 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 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.
|
||||
|
||||
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). Almost all coefficients
|
||||
in the above example have to be kept fixed and cannot be changed without reparametrizing the entire model.
|
||||
Exceptions are the first coefficient after {oxdna2/stk} (T=0.1 in the above example) and the 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/.
|
||||
A technical report with more information on the model, the structure of the input file,
|
||||
the setup tool and the performance of the LAMMPS-implementation of oxDNA
|
||||
can be found "here"_PDF/USER-CGDNA-overview.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 "Making
|
||||
LAMMPS"_Section_start.html#start_3 section for more info on packages.
|
||||
|
||||
[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(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).
|
||||
216
doc/src/pair_python.txt
Normal file
216
doc/src/pair_python.txt
Normal file
@ -0,0 +1,216 @@
|
||||
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
pair_style python command :h3
|
||||
|
||||
[Syntax:]
|
||||
|
||||
pair_style python cutoff :pre
|
||||
|
||||
cutoff = global cutoff for interactions in python potential classes
|
||||
|
||||
[Examples:]
|
||||
|
||||
pair_style python 2.5
|
||||
pair_coeff * * py_pot.LJCutMelt lj :pre
|
||||
|
||||
pair_style hybrid/overlay coul/long 12.0 python 12.0
|
||||
pair_coeff * * coul/long
|
||||
pair_coeff * * python py_pot.LJCutSPCE OW NULL :pre
|
||||
|
||||
[Description:]
|
||||
|
||||
The {python} pair style provides a way to define pairwise additive
|
||||
potential functions as python script code that is loaded into LAMMPS
|
||||
from a python file which must contain specific python class definitions.
|
||||
This allows to rapidly evaluate different potential functions without
|
||||
having to modify and recompile LAMMPS. Due to python being an
|
||||
interpreted language, however, the performance of this pair style is
|
||||
going to be significantly slower (often between 20x and 100x) than
|
||||
corresponding compiled code. This penalty can be significantly reduced
|
||||
through generating tabulations from the python code through the
|
||||
"pair_write"_pair_write.html command, which is supported by this style.
|
||||
|
||||
Only a single pair_coeff command is used with the {python} pair style
|
||||
which specifies a python class inside a python module or file that
|
||||
LAMMPS will look up in the current directory, the folder pointed to by
|
||||
the LAMMPS_POTENTIALS environment variable or somewhere in your python
|
||||
path. A single python module can hold multiple python pair class
|
||||
definitions. The class definitions itself have to follow specific
|
||||
rules that are explained below.
|
||||
|
||||
Atom types in the python class are specified through symbolic
|
||||
constants, typically strings. These are mapped to LAMMPS atom types by
|
||||
specifying N additional arguments after the class name in the
|
||||
pair_coeff command, where N must be the number of currently defined
|
||||
atom types:
|
||||
|
||||
As an example, imagine a file {py_pot.py} has a python potential class
|
||||
names {LJCutMelt} with parameters and potential functions for a two
|
||||
Lennard-Jones atom types labeled as 'LJ1' and 'LJ2'. In your LAMMPS
|
||||
input and you would have defined 3 atom types, out of which the first
|
||||
two are supposed to be using the 'LJ1' parameters and the third the
|
||||
'LJ2' parameters, then you would use the following pair_coeff command:
|
||||
|
||||
pair_coeff * * py_pot.LJCutMelt LJ1 LJ1 LJ2 :pre
|
||||
|
||||
The first two arguments [must] be * * so as to span all LAMMPS atom
|
||||
types. The first two LJ1 arguments map LAMMPS atom types 1 and 2 to
|
||||
the LJ1 atom type in the LJCutMelt class of the py_pot.py file. The
|
||||
final LJ2 argument maps LAMMPS atom type 3 to the LJ2 atom type the
|
||||
python file. If a mapping value is specified as NULL, the mapping is
|
||||
not performed, any pair interaction with this atom type will be
|
||||
skipped. This can be used when a {python} potential is used as part of
|
||||
the {hybrid} or {hybrid/overlay} pair style. The NULL values are then
|
||||
placeholders for atom types that will be used with other potentials.
|
||||
|
||||
:line
|
||||
|
||||
The python potential file has to start with the following code:
|
||||
|
||||
from __future__ import print_function
|
||||
|
||||
class LAMMPSPairPotential(object):
|
||||
def __init__(self):
|
||||
self.pmap=dict()
|
||||
self.units='lj'
|
||||
def map_coeff(self,name,ltype):
|
||||
self.pmap\[ltype\]=name
|
||||
def check_units(self,units):
|
||||
if (units != self.units):
|
||||
raise Exception("Conflicting units: %s vs. %s" % (self.units,units))
|
||||
:pre
|
||||
|
||||
Any classes with definitions of specific potentials have to be derived
|
||||
from this class and should be initialize in a similar fashion to the
|
||||
example given below.
|
||||
|
||||
NOTE: The class constructor has to set up a data structure containing
|
||||
the potential parameters supported by this class. It should also
|
||||
define a variable {self.units} containing a string matching one of the
|
||||
options of LAMMPS' "units"_units.html command, which is used to
|
||||
verify, that the potential definition in the python class and in the
|
||||
LAMMPS input match.
|
||||
|
||||
Here is an example for a single type Lennard-Jones potential class
|
||||
{LJCutMelt} in reducted units, which defines an atom type {lj} for
|
||||
which the parameters epsilon and sigma are both 1.0:
|
||||
|
||||
class LJCutMelt(LAMMPSPairPotential):
|
||||
def __init__(self):
|
||||
super(LJCutMelt,self).__init__()
|
||||
# set coeffs: 48*eps*sig**12, 24*eps*sig**6,
|
||||
# 4*eps*sig**12, 4*eps*sig**6
|
||||
self.units = 'lj'
|
||||
self.coeff = \{'lj' : \{'lj' : (48.0,24.0,4.0,4.0)\}\}
|
||||
:pre
|
||||
|
||||
The class also has to provide two methods for the computation of the
|
||||
potential energy and forces, which have be named {compute_force},
|
||||
and {compute_energy}, which both take 3 numerical arguments:
|
||||
|
||||
rsq = the square of the distance between a pair of atoms (float) :l
|
||||
itype = the (numerical) type of the first atom :l
|
||||
jtype = the (numerical) type of the second atom :ul
|
||||
|
||||
This functions need to compute the force and the energy, respectively,
|
||||
and use the result as return value. The functions need to use the
|
||||
{pmap} dictionary to convert the LAMMPS atom type number to the symbolic
|
||||
value of the internal potential parameter data structure. Following
|
||||
the {LJCutMelt} example, here are the two functions:
|
||||
|
||||
def compute_force(self,rsq,itype,jtype):
|
||||
coeff = self.coeff\[self.pmap\[itype\]\]\[self.pmap\[jtype\]\]
|
||||
r2inv = 1.0/rsq
|
||||
r6inv = r2inv*r2inv*r2inv
|
||||
lj1 = coeff\[0\]
|
||||
lj2 = coeff\[1\]
|
||||
return (r6inv * (lj1*r6inv - lj2))*r2inv :pre
|
||||
|
||||
def compute_energy(self,rsq,itype,jtype):
|
||||
coeff = self.coeff\[self.pmap\[itype\]\]\[self.pmap\[jtype\]\]
|
||||
r2inv = 1.0/rsq
|
||||
r6inv = r2inv*r2inv*r2inv
|
||||
lj3 = coeff\[2\]
|
||||
lj4 = coeff\[3\]
|
||||
return (r6inv * (lj3*r6inv - lj4)) :pre
|
||||
|
||||
NOTE: for consistency with the C++ pair styles in LAMMPS, the
|
||||
{compute_force} function follows the conventions of the Pair::single()
|
||||
methods and does not return the full force, but the force scaled by
|
||||
the distance between the two atoms, so this value only needs to be
|
||||
multiplied by delta x, delta y, and delta z to conveniently obtain the
|
||||
three components of the force vector between these two atoms.
|
||||
|
||||
:line
|
||||
|
||||
NOTE: The evaluation of scripted python code will slow down the
|
||||
computation pair-wise interactions quite significantly. However, this
|
||||
can be largely worked around through using the python pair style not
|
||||
for the actual simulation, but to generate tabulated potentials on the
|
||||
fly using the "pair_write"_pair_write.html command. Please see below
|
||||
for an example LAMMPS input of how to build a table file:
|
||||
|
||||
pair_style python 2.5
|
||||
pair_coeff * * py_pot.LJCutMelt lj
|
||||
shell rm -f melt.table
|
||||
pair_write 1 1 2000 rsq 0.01 2.5 lj1_lj2.table lj :pre
|
||||
|
||||
Note that it is strongly recommended to try to [delete] the potential
|
||||
table file before generating it. Since the {pair_write} command will
|
||||
always append to a table file, which pair style table will use the
|
||||
first match. Thus when changing the potential function in the python
|
||||
class, the table pair style will still read the old variant.
|
||||
|
||||
After switching the pair style to {table}, the potential tables need
|
||||
to be assigned to the LAMMPS atom types like this:
|
||||
|
||||
pair_style table linear 2000
|
||||
pair_coeff 1 1 melt.table lj :pre
|
||||
|
||||
This can also be done for more complex systems. Please see the
|
||||
{examples/python} folders for a few more examples.
|
||||
|
||||
:line
|
||||
|
||||
[Mixing, shift, table, tail correction, restart, rRESPA info]:
|
||||
|
||||
Mixing of potential parameters has to be handled inside the provided
|
||||
python module. The python pair style simply assumes that force and
|
||||
energy computation can be correctly performed for all pairs of atom
|
||||
types as they are mapped to the atom type labels inside the python
|
||||
potential class.
|
||||
|
||||
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:]
|
||||
|
||||
This pair style is part of the PYTHON package. It is only enabled if
|
||||
LAMMPS was built with that package. See the "Making
|
||||
LAMMPS"_Section_start.html#start_3 section for more info.
|
||||
|
||||
[Related commands:]
|
||||
|
||||
"pair_coeff"_pair_coeff.html, "pair_write"_pair_write.html,
|
||||
"pair style table"_pair_table.html
|
||||
|
||||
[Default:] none
|
||||
|
||||
|
||||
@ -36,7 +36,7 @@ supplemental information of the following paper:
|
||||
the most up-to-date version of ReaxFF as of summer 2010.
|
||||
|
||||
WARNING: pair style reax is now deprecated and will soon be retired. Users
|
||||
should switch to "pair_style reax/c"_pair_reax_c.html. The {reax} style
|
||||
should switch to "pair_style reax/c"_pair_reaxc.html. The {reax} style
|
||||
differs from the {reax/c} style in the lo-level implementation details.
|
||||
The {reax} style is a
|
||||
Fortran library, linked to LAMMPS. The {reax/c} style was initially
|
||||
@ -82,7 +82,7 @@ be specified.
|
||||
|
||||
Two examples using {pair_style reax} are provided in the examples/reax
|
||||
sub-directory, along with corresponding examples for
|
||||
"pair_style reax/c"_pair_reax_c.html. Note that while the energy and force
|
||||
"pair_style reax/c"_pair_reaxc.html. Note that while the energy and force
|
||||
calculated by both of these pair styles match very closely, the
|
||||
contributions due to the valence angles differ slightly due to
|
||||
the fact that with {pair_style reax/c} the default value of {thb_cutoff_sq}
|
||||
@ -201,7 +201,7 @@ appropriate units if your simulation doesn't use "real" units.
|
||||
|
||||
[Related commands:]
|
||||
|
||||
"pair_coeff"_pair_coeff.html, "pair_style reax/c"_pair_reax_c.html,
|
||||
"pair_coeff"_pair_coeff.html, "pair_style reax/c"_pair_reaxc.html,
|
||||
"fix_reax_bonds"_fix_reax_bonds.html
|
||||
|
||||
[Default:]
|
||||
|
||||
@ -17,6 +17,7 @@ cfile = NULL or name of a control file :ulb,l
|
||||
zero or more keyword/value pairs may be appended :l
|
||||
keyword = {checkqeq} or {lgvdw} or {safezone} or {mincap}
|
||||
{checkqeq} value = {yes} or {no} = whether or not to require qeq/reax fix
|
||||
{enobonds} value = {yes} or {no} = whether or not to tally energy of atoms with no bonds
|
||||
{lgvdw} value = {yes} or {no} = whether or not to use a low gradient vdW correction
|
||||
{safezone} = factor used for array allocation
|
||||
{mincap} = minimum size for array allocation :pre
|
||||
@ -127,6 +128,13 @@ recommended value for parameter {thb} is 0.01, which can be set in the
|
||||
control file. Note: Force field files are different for the original
|
||||
or lg corrected pair styles, using wrong ffield file generates an error message.
|
||||
|
||||
Using the optional keyword {enobonds} with the value {yes}, the energy
|
||||
of atoms with no bonds (i.e. isolated atoms) is included in the total
|
||||
potential energy and the per-atom energy of that atom. If the value
|
||||
{no} is specified then the energy of atoms with no bonds is set to zero.
|
||||
The latter behavior is usual not desired, as it causes discontinuities
|
||||
in the potential energy when the bonding of an atom drops to zero.
|
||||
|
||||
Optional keywords {safezone} and {mincap} are used for allocating
|
||||
reax/c arrays. Increasing these values can avoid memory problems, such
|
||||
as segmentation faults and bondchk failed errors, that could occur under
|
||||
@ -331,7 +339,7 @@ reax"_pair_reax.html
|
||||
|
||||
[Default:]
|
||||
|
||||
The keyword defaults are checkqeq = yes, lgvdw = no, safezone = 1.2,
|
||||
The keyword defaults are checkqeq = yes, enobonds = yes, lgvdw = no, safezone = 1.2,
|
||||
mincap = 50.
|
||||
|
||||
:line
|
||||
@ -134,7 +134,7 @@ respa"_run_style.html command.
|
||||
|
||||
[Restrictions:]
|
||||
|
||||
All of the lj/sdk pair styles are part of the USER-CG-CMM package.
|
||||
All of the lj/sdk pair styles are part of the USER-CGSDK package.
|
||||
The {lj/sdk/coul/long} style also requires the KSPACE package to be
|
||||
built (which is enabled by default). They are only enabled if LAMMPS
|
||||
was built with that package. See the "Making
|
||||
|
||||
@ -150,6 +150,8 @@ hybrid"_pair_hybrid.html.
|
||||
This pair style requires the "newton"_newton.html command to be {on}
|
||||
for non-bonded interactions.
|
||||
|
||||
This pair style is not compatible with "rigid body integrators"_fix_rigid.html
|
||||
|
||||
[Related commands:]
|
||||
|
||||
"pair_style hybrid"_pair_hybrid.html, "pair_coeff"_pair_coeff.html,
|
||||
|
||||
@ -18,7 +18,7 @@ pair_style tersoff/table/omp command :h3
|
||||
|
||||
pair_style style :pre
|
||||
|
||||
style = {tersoff} or {tersoff/table} or {tersoff/gpu} or {tersoff/omp} or {tersoff/table/omp}
|
||||
style = {tersoff} or {tersoff/table} or {tersoff/gpu} or {tersoff/omp} or {tersoff/table/omp} :ul
|
||||
|
||||
[Examples:]
|
||||
|
||||
|
||||
@ -35,7 +35,7 @@ cutoff.
|
||||
In contrast to "pair_style yukawa"_pair_yukawa.html, this functional
|
||||
form arises from the Coulombic interaction between two colloid
|
||||
particles, screened due to the presence of an electrolyte, see the
|
||||
book by "Safran"_#Safran for a derivation in the context of DVLO
|
||||
book by "Safran"_#Safran for a derivation in the context of DLVO
|
||||
theory. "Pair_style yukawa"_pair_yukawa.html is a screened Coulombic
|
||||
potential between two point-charges and uses no such approximation.
|
||||
|
||||
|
||||
@ -36,6 +36,7 @@ Pair Styles :h1
|
||||
pair_gayberne
|
||||
pair_gran
|
||||
pair_gromacs
|
||||
pair_gw
|
||||
pair_hbond_dreiding
|
||||
pair_hybrid
|
||||
pair_kim
|
||||
@ -68,11 +69,13 @@ Pair Styles :h1
|
||||
pair_nm
|
||||
pair_none
|
||||
pair_oxdna
|
||||
pair_oxdna2
|
||||
pair_peri
|
||||
pair_polymorphic
|
||||
pair_python
|
||||
pair_quip
|
||||
pair_reax
|
||||
pair_reax_c
|
||||
pair_reaxc
|
||||
pair_resquared
|
||||
pair_sdk
|
||||
pair_smd_hertz
|
||||
|
||||
@ -14,7 +14,7 @@ python func keyword args ... :pre
|
||||
|
||||
func = name of Python function :ulb,l
|
||||
one or more keyword/args pairs must be appended :l
|
||||
keyword = {invoke} or {input} or {return} or {format} or {length} or {file} or {here} or {exists}
|
||||
keyword = {invoke} or {input} or {return} or {format} or {length} or {file} or {here} or {exists} or {source}
|
||||
{invoke} arg = none = invoke the previously defined Python function
|
||||
{input} args = N i1 i2 ... iN
|
||||
N = # of inputs to function
|
||||
@ -36,7 +36,12 @@ keyword = {invoke} or {input} or {return} or {format} or {length} or {file} or {
|
||||
{here} arg = inline
|
||||
inline = one or more lines of Python code which defines func
|
||||
must be a single argument, typically enclosed between triple quotes
|
||||
{exists} arg = none = Python code has been loaded by previous python command :pre
|
||||
{exists} arg = none = Python code has been loaded by previous python command
|
||||
{source} arg = {filename} or {inline}
|
||||
filename = file of Python code which will be executed immediately
|
||||
inline = one or more lines of Python code which will be executed immediately
|
||||
must be a single argument, typically enclosed between triple quotes
|
||||
:pre
|
||||
:ule
|
||||
|
||||
[Examples:]
|
||||
@ -50,7 +55,7 @@ def factorial(n):
|
||||
return n * factorial(n-1)
|
||||
""" :pre
|
||||
|
||||
python loop input 1 SELF return v_value format -f here """
|
||||
python loop input 1 SELF return v_value format pf here """
|
||||
def loop(lmpptr,N,cut0):
|
||||
from lammps import lammps
|
||||
lmp = lammps(ptr=lmpptr) :pre
|
||||
@ -59,7 +64,7 @@ def loop(lmpptr,N,cut0):
|
||||
|
||||
for i in range(N):
|
||||
cut = cut0 + i*0.1
|
||||
lmp.set_variable("cut",cut) # set a variable in LAMMPS
|
||||
lmp.set_variable("cut",cut) # set a variable in LAMMPS
|
||||
lmp.command("pair_style lj/cut $\{cut\}") # LAMMPS commands
|
||||
lmp.command("pair_coeff * * 1.0 1.0")
|
||||
lmp.command("run 100")
|
||||
@ -67,12 +72,8 @@ def loop(lmpptr,N,cut0):
|
||||
|
||||
[Description:]
|
||||
|
||||
NOTE: It is not currently possible to use the "python"_python.html
|
||||
command described in this section with Python 3, only with Python 2.
|
||||
The C API changed from Python 2 to 3 and the LAMMPS code is not
|
||||
compatible with both.
|
||||
|
||||
Define a Python function or execute a previously defined function.
|
||||
Define a Python function or execute a previously defined function or
|
||||
execute some arbitrary python code.
|
||||
Arguments, including LAMMPS variables, can be passed to the function
|
||||
from the LAMMPS input script and a value returned by the Python
|
||||
function to a LAMMPS variable. The Python code for the function can
|
||||
@ -107,7 +108,8 @@ command.
|
||||
|
||||
The {func} setting specifies the name of the Python function. The
|
||||
code for the function is defined using the {file} or {here} keywords
|
||||
as explained below.
|
||||
as explained below. In case of the {source} keyword, the name of
|
||||
the function is ignored.
|
||||
|
||||
If the {invoke} keyword is used, no other keywords can be used, and a
|
||||
previous python command must have defined the Python function
|
||||
@ -116,6 +118,13 @@ previously defined arguments and return value processed as explained
|
||||
below. You can invoke the function as many times as you wish in your
|
||||
input script.
|
||||
|
||||
If the {source} keyword is used, no other keywords can be used.
|
||||
The argument can be a filename or a string with python commands,
|
||||
either on a single line enclosed in quotes, or as multiple lines
|
||||
enclosed in triple quotes. These python commands will be passed
|
||||
to the python interpreter and executed immediately without registering
|
||||
a python function for future execution.
|
||||
|
||||
The {input} keyword defines how many arguments {N} the Python function
|
||||
expects. If it takes no arguments, then the {input} keyword should
|
||||
not be used. Each argument can be specified directly as a value,
|
||||
@ -310,7 +319,7 @@ which corresponds to SELF in the python command. The first line of
|
||||
the function imports the Python module lammps.py in the python dir of
|
||||
the distribution. The second line creates a Python object "lmp" which
|
||||
wraps the instance of LAMMPS that called the function. The
|
||||
"ptr=lmpptr" argument is what makes that happen. The thrid line
|
||||
"ptr=lmpptr" argument is what makes that happen. The third line
|
||||
invokes the command() function in the LAMMPS library interface. It
|
||||
takes a single string argument which is a LAMMPS input script command
|
||||
for LAMMPS to execute, the same as if it appeared in your input
|
||||
@ -396,6 +405,9 @@ or other variables may have hidden side effects as well. In these
|
||||
cases, LAMMPS has no simple way to check that something illogical is
|
||||
being attempted.
|
||||
|
||||
The same applies to Python functions called during a simulation run at
|
||||
each time step using "fix python"_fix_python.html.
|
||||
|
||||
:line
|
||||
|
||||
If you run Python code directly on your workstation, either
|
||||
@ -477,19 +489,10 @@ python"_Section_python.html. Note that it is important that the
|
||||
stand-alone LAMMPS executable and the LAMMPS shared library be
|
||||
consistent (built from the same source code files) in order for this
|
||||
to work. If the two have been built at different times using
|
||||
different source files, problems may occur.
|
||||
|
||||
As described above, you can use the python command to invoke a Python
|
||||
function which calls back to LAMMPS through its Python-wrapped library
|
||||
interface. However you cannot do the opposite. I.e. you cannot call
|
||||
LAMMPS from Python and invoke the python command to "callback" to
|
||||
Python and execute a Python function. LAMMPS will generate an error
|
||||
if you try to do that. Note that we think there actually should be a
|
||||
way to do that, but haven't yet been able to figure out how to do it
|
||||
successfully.
|
||||
different source files, problems may occur.
|
||||
|
||||
[Related commands:]
|
||||
|
||||
"shell"_shell.html, "variable"_variable.html
|
||||
"shell"_shell.html, "variable"_variable.html, "fix python"_fix_python.html
|
||||
|
||||
[Default:] none
|
||||
|
||||
@ -15,7 +15,7 @@ rerun file1 file2 ... keyword args ... :pre
|
||||
file1,file2,... = dump file(s) to read :ulb,l
|
||||
one or more keywords may be appended, keyword {dump} must appear and be last :l
|
||||
keyword = {first} or {last} or {every} or {skip} or {start} or {stop} or {dump}
|
||||
{first} args = Nfirts
|
||||
{first} args = Nfirst
|
||||
Nfirst = dump timestep to start on
|
||||
{last} args = Nlast
|
||||
Nlast = dumptimestep to stop on
|
||||
|
||||
@ -55,7 +55,7 @@ using the generated {auto} Makefile.
|
||||
cd $LAMMPS_DIR/src :pre
|
||||
|
||||
# generate custom Makefile
|
||||
python2 Make.py -jpg -png -s ffmpeg exceptions -m mpi -a file :pre
|
||||
python Make.py -jpg -png -s ffmpeg exceptions -m mpi -a file :pre
|
||||
|
||||
# add packages if necessary
|
||||
make yes-MOLECULE :pre
|
||||
|
||||
@ -61,7 +61,7 @@ keyword/value parameters. Not all options are used by each style.
|
||||
Each option has a default as listed below.
|
||||
|
||||
The {create} style generates an ensemble of velocities using a random
|
||||
number generator with the specified seed as the specified temperature.
|
||||
number generator with the specified seed at the specified temperature.
|
||||
|
||||
The {set} style sets the velocities of all atoms in the group to the
|
||||
specified values. If any component is specified as NULL, then it is
|
||||
|
||||
@ -62,6 +62,7 @@ pair_coeff 3 3 1.0 1.5
|
||||
pair_coeff 1 4 0.0 1.0 0.5
|
||||
pair_coeff 2 4 0.0 1.0 1.0
|
||||
pair_coeff 3 4 0.0 1.0 0.75
|
||||
pair_coeff 4 4 0.0 1.0 0.0
|
||||
|
||||
delete_atoms overlap 1.0 small big
|
||||
|
||||
|
||||
@ -62,6 +62,7 @@ pair_coeff 3 3 1.0 1.5
|
||||
pair_coeff 1 4 0.0 1.0 0.5
|
||||
pair_coeff 2 4 0.0 1.0 1.0
|
||||
pair_coeff 3 4 0.0 1.0 0.75
|
||||
pair_coeff 4 4 0.0 1.0 0.0
|
||||
|
||||
delete_atoms overlap 1.0 small big
|
||||
|
||||
|
||||
@ -7,9 +7,9 @@ Input, data and log files for a DNA duplex (double-stranded DNA)
|
||||
consisiting of 5 base pairs. The duplex contains two strands with
|
||||
complementary base pairs. The topology is
|
||||
|
||||
A - A - A - A - A
|
||||
A - C - G - T - A
|
||||
| | | | |
|
||||
T - T - T - T - T
|
||||
T - G - C - A - T
|
||||
|
||||
/examples/duplex2:
|
||||
Input, data and log files for a nicked DNA duplex (double-stranded DNA)
|
||||
@ -18,9 +18,9 @@ complementary base pairs, but the backbone on one side is not continuous:
|
||||
two individual strands on one side form a duplex with a longer single
|
||||
strand on the other side. The topology is
|
||||
|
||||
A - A - A - A - A - A - A - A
|
||||
A - C - G - T - A - C - G - T
|
||||
| | | | | | | |
|
||||
T - T - T T - T - T - T - T
|
||||
T - G - C - A T - G - C - A
|
||||
|
||||
/util:
|
||||
This directory contains a simple python setup tool which creates
|
||||
|
||||
@ -1,74 +0,0 @@
|
||||
# LAMMPS data file
|
||||
10 atoms
|
||||
10 ellipsoids
|
||||
8 bonds
|
||||
|
||||
4 atom types
|
||||
1 bond types
|
||||
|
||||
# System size
|
||||
-20.000000 20.000000 xlo xhi
|
||||
-20.000000 20.000000 ylo yhi
|
||||
-20.000000 20.000000 zlo zhi
|
||||
|
||||
# Atom masses for each atom type
|
||||
Masses
|
||||
|
||||
1 3.1575
|
||||
2 3.1575
|
||||
3 3.1575
|
||||
4 3.1575
|
||||
|
||||
# Atom-ID, type, position, molecule-ID, ellipsoid flag, density
|
||||
Atoms
|
||||
|
||||
1 1 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00 1 1 1
|
||||
2 1 1.3274493266864451e-01 -4.2912827978022683e-01 3.7506163469402809e-01 1 1 1
|
||||
3 1 4.8460810659772807e-01 -7.0834970533509178e-01 7.5012326938805618e-01 1 1 1
|
||||
4 1 9.3267359196674593e-01 -7.4012419946742802e-01 1.1251849040820843e+00 1 1 1
|
||||
5 1 1.3204192238113461e+00 -5.1335201721887447e-01 1.5002465387761124e+00 1 1 1
|
||||
6 4 1.9958077618865377e-01 5.1335201721887447e-01 1.5002465387761124e+00 1 1 1
|
||||
7 4 5.8732640803325409e-01 7.4012419946742802e-01 1.1251849040820843e+00 1 1 1
|
||||
8 4 1.0353918934022719e+00 7.0834970533509178e-01 7.5012326938805618e-01 1 1 1
|
||||
9 4 1.3872550673313555e+00 4.2912827978022683e-01 3.7506163469402809e-01 1 1 1
|
||||
10 4 1.5200000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00 1 1 1
|
||||
|
||||
# Atom-ID, translational, rotational velocity
|
||||
Velocities
|
||||
|
||||
1 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00
|
||||
2 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00
|
||||
3 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00
|
||||
4 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00
|
||||
5 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00
|
||||
6 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00
|
||||
7 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00
|
||||
8 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00
|
||||
9 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00
|
||||
10 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00
|
||||
|
||||
# Atom-ID, shape, quaternion
|
||||
Ellipsoids
|
||||
|
||||
1 1.1739845031423408e+00 1.1739845031423408e+00 1.1739845031423408e+00 1.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00 0.0000000000000000e+00
|
||||
2 1.1739845031423408e+00 1.1739845031423408e+00 1.1739845031423408e+00 9.5533648912560598e-01 0.0000000000000000e+00 0.0000000000000000e+00 2.9552020666133955e-01
|
||||
3 1.1739845031423408e+00 1.1739845031423408e+00 1.1739845031423408e+00 8.2533561490967822e-01 0.0000000000000000e+00 0.0000000000000000e+00 5.6464247339503526e-01
|
||||
4 1.1739845031423408e+00 1.1739845031423408e+00 1.1739845031423408e+00 6.2160996827066439e-01 0.0000000000000000e+00 0.0000000000000000e+00 7.8332690962748319e-01
|
||||
5 1.1739845031423408e+00 1.1739845031423408e+00 1.1739845031423408e+00 3.6235775447667351e-01 0.0000000000000000e+00 0.0000000000000000e+00 9.3203908596722607e-01
|
||||
6 1.1739845031423408e+00 1.1739845031423408e+00 1.1739845031423408e+00 0.0000000000000000e+00 9.3203908596722607e-01 -3.6235775447667351e-01 0.0000000000000000e+00
|
||||
7 1.1739845031423408e+00 1.1739845031423408e+00 1.1739845031423408e+00 0.0000000000000000e+00 7.8332690962748319e-01 -6.2160996827066439e-01 0.0000000000000000e+00
|
||||
8 1.1739845031423408e+00 1.1739845031423408e+00 1.1739845031423408e+00 0.0000000000000000e+00 5.6464247339503526e-01 -8.2533561490967822e-01 0.0000000000000000e+00
|
||||
9 1.1739845031423408e+00 1.1739845031423408e+00 1.1739845031423408e+00 0.0000000000000000e+00 2.9552020666133955e-01 -9.5533648912560598e-01 0.0000000000000000e+00
|
||||
10 1.1739845031423408e+00 1.1739845031423408e+00 1.1739845031423408e+00 0.0000000000000000e+00 0.0000000000000000e+00 -1.0000000000000000e+00 0.0000000000000000e+00
|
||||
|
||||
# Bond topology
|
||||
Bonds
|
||||
|
||||
1 1 1 2
|
||||
2 1 2 3
|
||||
3 1 3 4
|
||||
4 1 4 5
|
||||
5 1 6 7
|
||||
6 1 7 8
|
||||
7 1 8 9
|
||||
8 1 9 10
|
||||
@ -1,75 +0,0 @@
|
||||
variable number equal 1
|
||||
variable ofreq equal 1000
|
||||
variable efreq equal 1000
|
||||
|
||||
units lj
|
||||
|
||||
dimension 3
|
||||
|
||||
newton off
|
||||
|
||||
boundary p p p
|
||||
|
||||
atom_style hybrid bond ellipsoid
|
||||
atom_modify sort 0 1.0
|
||||
|
||||
# Pair interactions require lists of neighbours to be calculated
|
||||
neighbor 1.0 bin
|
||||
neigh_modify every 1 delay 0 check yes
|
||||
|
||||
read_data data.duplex1
|
||||
|
||||
set atom * mass 3.1575
|
||||
|
||||
group all type 1 4
|
||||
|
||||
# oxDNA bond interactions - FENE backbone
|
||||
bond_style oxdna_fene
|
||||
bond_coeff * 2.0 0.25 0.7525
|
||||
|
||||
# oxDNA pair interactions
|
||||
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 1.61048 6.0 0.4 0.9 0.32 0.6 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 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 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 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
|
||||
|
||||
# NVE ensemble
|
||||
#fix 1 all nve/dotc/langevin 0.1 0.1 0.03 457145 angmom 10
|
||||
fix 1 all nve/dot
|
||||
|
||||
timestep 1e-5
|
||||
|
||||
#comm_style tiled
|
||||
#fix 3 all balance 10000 1.1 rcb
|
||||
|
||||
#compute mol all chunk/atom molecule
|
||||
#compute mychunk all vcm/chunk mol
|
||||
#fix 4 all ave/time 10000 1 10000 c_mychunk[1] c_mychunk[2] c_mychunk[3] file vcm.txt mode vector
|
||||
|
||||
dump pos all xyz ${ofreq} traj.${number}.xyz
|
||||
|
||||
compute quat all property/atom quatw quati quatj quatk
|
||||
dump quat all custom ${ofreq} quat.${number}.txt id c_quat[1] c_quat[2] c_quat[3] c_quat[4]
|
||||
dump_modify quat sort id
|
||||
dump_modify quat format line "%d %13.6le %13.6le %13.6le %13.6le"
|
||||
|
||||
compute erot all erotate/asphere
|
||||
compute ekin all ke
|
||||
compute epot all pe
|
||||
variable erot equal c_erot
|
||||
variable ekin equal c_ekin
|
||||
variable epot equal c_epot
|
||||
variable etot equal c_erot+c_ekin+c_epot
|
||||
fix 5 all print ${efreq} "$(step) ekin = ${ekin} | erot = ${erot} | epot = ${epot} | etot = ${etot}" screen yes
|
||||
|
||||
dump out all custom ${ofreq} out.${number}.txt id x y z vx vy vz fx fy fz tqx tqy tqz
|
||||
dump_modify out sort id
|
||||
dump_modify out format line "%d %13.6le %13.6le %13.6le %13.6le %13.6le %13.6le %13.6le %13.6le %13.6le %13.6le %13.6le %13.6le"
|
||||
|
||||
run 1000000
|
||||
|
||||
#write_restart config.${number}.*
|
||||
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
@ -1,97 +0,0 @@
|
||||
# LAMMPS data file
|
||||
16 atoms
|
||||
16 ellipsoids
|
||||
13 bonds
|
||||
|
||||
4 atom types
|
||||
1 bond types
|
||||
|
||||
# System size
|
||||
-20.0 20.0 xlo xhi
|
||||
-20.0 20.0 ylo yhi
|
||||
-20.0 20.0 zlo zhi
|
||||
|
||||
# Atom masses for each atom type
|
||||
Masses
|
||||
|
||||
1 3.1575
|
||||
2 3.1575
|
||||
3 3.1575
|
||||
4 3.1575
|
||||
|
||||
# Atom-ID, type, position, molecule-ID, ellipsoid flag, density
|
||||
Atoms
|
||||
|
||||
1 1 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 1 1 1
|
||||
2 1 1.327449326686445e-01 -4.291282797802268e-01 3.750616346940281e-01 1 1 1
|
||||
3 1 4.846081065977281e-01 -7.083497053350921e-01 7.501232693880562e-01 1 1 1
|
||||
4 1 9.326735919667459e-01 -7.401241994674285e-01 1.125184904082084e+00 1 1 1
|
||||
5 1 1.320419223811347e+00 -5.133520172188747e-01 1.500246538776112e+00 1 1 1
|
||||
6 1 1.512394297416339e+00 -1.072512061254991e-01 1.875308173470140e+00 1 1 1
|
||||
7 1 1.441536396413952e+00 3.363155369040876e-01 2.250369808164169e+00 1 1 1
|
||||
8 1 1.132598224218932e+00 6.623975870343269e-01 2.625431442858197e+00 1 1 1
|
||||
9 4 5.873264080332541e-01 7.401241994674285e-01 1.125184904082084e+00 1 1 1
|
||||
10 4 1.035391893402272e+00 7.083497053350921e-01 7.501232693880562e-01 1 1 1
|
||||
11 4 1.387255067331356e+00 4.291282797802267e-01 3.750616346940281e-01 1 1 1
|
||||
12 4 1.520000000000000e+00 1.260981291332700e-33 0.000000000000000e+00 1 1 1
|
||||
13 4 3.874017757810680e-01 -6.623975870343268e-01 2.625431442858197e+00 1 1 1
|
||||
14 4 7.846360358604798e-02 -3.363155369040874e-01 2.250369808164169e+00 1 1 1
|
||||
15 4 7.605702583661333e-03 1.072512061254995e-01 1.875308173470140e+00 1 1 1
|
||||
16 4 1.995807761886533e-01 5.133520172188748e-01 1.500246538776112e+00 1 1 1
|
||||
|
||||
# Atom-ID, translational, rotational velocity
|
||||
Velocities
|
||||
|
||||
1 0.0 0.0 0.0 0.0 0.0 0.0
|
||||
2 0.0 0.0 0.0 0.0 0.0 0.0
|
||||
3 0.0 0.0 0.0 0.0 0.0 0.0
|
||||
4 0.0 0.0 0.0 0.0 0.0 0.0
|
||||
5 0.0 0.0 0.0 0.0 0.0 0.0
|
||||
6 0.0 0.0 0.0 0.0 0.0 0.0
|
||||
7 0.0 0.0 0.0 0.0 0.0 0.0
|
||||
8 0.0 0.0 0.0 0.0 0.0 0.0
|
||||
9 0.0 0.0 0.0 0.0 0.0 0.0
|
||||
10 0.0 0.0 0.0 0.0 0.0 0.0
|
||||
11 0.0 0.0 0.0 0.0 0.0 0.0
|
||||
12 0.0 0.0 0.0 0.0 0.0 0.0
|
||||
13 0.0 0.0 0.0 0.0 0.0 0.0
|
||||
14 0.0 0.0 0.0 0.0 0.0 0.0
|
||||
15 0.0 0.0 0.0 0.0 0.0 0.0
|
||||
16 0.0 0.0 0.0 0.0 0.0 0.0
|
||||
|
||||
# Atom-ID, shape, quaternion
|
||||
Ellipsoids
|
||||
|
||||
1 1.1739845031423408 1.1739845031423408 1.1739845031423408 1.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00
|
||||
2 1.1739845031423408 1.1739845031423408 1.1739845031423408 9.553364891256060e-01 0.000000000000000e+00 0.000000000000000e+00 2.955202066613395e-01
|
||||
3 1.1739845031423408 1.1739845031423408 1.1739845031423408 8.253356149096783e-01 0.000000000000000e+00 0.000000000000000e+00 5.646424733950354e-01
|
||||
4 1.1739845031423408 1.1739845031423408 1.1739845031423408 6.216099682706646e-01 0.000000000000000e+00 0.000000000000000e+00 7.833269096274833e-01
|
||||
5 1.1739845031423408 1.1739845031423408 1.1739845031423408 3.623577544766736e-01 0.000000000000000e+00 0.000000000000000e+00 9.320390859672263e-01
|
||||
6 1.1739845031423408 1.1739845031423408 1.1739845031423408 7.073720166770291e-02 0.000000000000000e+00 0.000000000000000e+00 9.974949866040544e-01
|
||||
7 1.1739845031423408 1.1739845031423408 1.1739845031423408 -2.272020946930869e-01 -0.000000000000000e+00 0.000000000000000e+00 9.738476308781953e-01
|
||||
8 1.1739845031423408 1.1739845031423408 1.1739845031423408 -5.048461045998575e-01 -0.000000000000000e+00 0.000000000000000e+00 8.632093666488738e-01
|
||||
9 1.1739845031423408 1.1739845031423408 1.1739845031423408 4.796493962806427e-17 7.833269096274833e-01 -6.216099682706646e-01 3.806263289803786e-17
|
||||
10 1.1739845031423408 1.1739845031423408 1.1739845031423408 5.707093416549944e-17 5.646424733950354e-01 -8.253356149096784e-01 2.218801320830406e-17
|
||||
11 1.1739845031423408 1.1739845031423408 1.1739845031423408 6.107895212550935e-17 2.955202066613394e-01 -9.553364891256061e-01 4.331404380149668e-18
|
||||
12 1.1739845031423408 1.1739845031423408 1.1739845031423408 5.963096920061075e-17 0.000000000000000e+00 -1.000000000000000e+00 -1.391211590127312e-17
|
||||
13 1.1739845031423408 1.1739845031423408 1.1739845031423408 5.285632939302787e-17 8.632093666488739e-01 5.048461045998572e-01 -3.091290830301125e-17
|
||||
14 1.1739845031423408 1.1739845031423408 1.1739845031423408 4.136019110019290e-17 9.738476308781953e-01 2.272020946930868e-01 -4.515234267244800e-17
|
||||
15 1.1739845031423408 1.1739845031423408 1.1739845031423408 2.616947011741696e-17 9.974949866040544e-01 -7.073720166770313e-02 -5.535845274597425e-17
|
||||
16 1.1739845031423408 1.1739845031423408 1.1739845031423408 8.641108308308281e-18 9.320390859672264e-01 -3.623577544766736e-01 -6.061955710708163e-17
|
||||
|
||||
# Bond-ID, type, atom pairs
|
||||
Bonds
|
||||
|
||||
1 1 1 2
|
||||
2 1 2 3
|
||||
3 1 3 4
|
||||
4 1 4 5
|
||||
5 1 5 6
|
||||
6 1 6 7
|
||||
7 1 7 8
|
||||
8 1 13 14
|
||||
9 1 14 15
|
||||
10 1 15 16
|
||||
11 1 9 10
|
||||
12 1 10 11
|
||||
13 1 11 12
|
||||
@ -1,75 +0,0 @@
|
||||
variable number equal 2
|
||||
variable ofreq equal 1000
|
||||
variable efreq equal 1000
|
||||
|
||||
units lj
|
||||
|
||||
dimension 3
|
||||
|
||||
newton off
|
||||
|
||||
boundary p p p
|
||||
|
||||
atom_style hybrid bond ellipsoid
|
||||
atom_modify sort 0 1.0
|
||||
|
||||
# Pair interactions require lists of neighbours to be calculated
|
||||
neighbor 1.0 bin
|
||||
neigh_modify every 1 delay 0 check yes
|
||||
|
||||
read_data data.duplex2
|
||||
|
||||
set atom * mass 3.1575
|
||||
|
||||
group all type 1 4
|
||||
|
||||
# oxDNA bond interactions - FENE backbone
|
||||
bond_style oxdna_fene
|
||||
bond_coeff * 2.0 0.25 0.7525
|
||||
|
||||
# oxDNA pair interactions
|
||||
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 1.61048 6.0 0.4 0.9 0.32 0.6 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 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 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 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
|
||||
|
||||
# NVE ensemble
|
||||
fix 1 all nve/dotc/langevin 0.1 0.1 0.03 457145 angmom 10
|
||||
#fix 1 all nve/dot
|
||||
|
||||
timestep 1e-5
|
||||
|
||||
#comm_style tiled
|
||||
#fix 3 all balance 10000 1.1 rcb
|
||||
|
||||
#compute mol all chunk/atom molecule
|
||||
#compute mychunk all vcm/chunk mol
|
||||
#fix 4 all ave/time 10000 1 10000 c_mychunk[1] c_mychunk[2] c_mychunk[3] file vcm.txt mode vector
|
||||
|
||||
dump pos all xyz ${ofreq} traj.${number}.xyz
|
||||
|
||||
compute quat all property/atom quatw quati quatj quatk
|
||||
dump quat all custom ${ofreq} quat.${number}.txt id c_quat[1] c_quat[2] c_quat[3] c_quat[4]
|
||||
dump_modify quat sort id
|
||||
dump_modify quat format line "%d %13.6le %13.6le %13.6le %13.6le"
|
||||
|
||||
compute erot all erotate/asphere
|
||||
compute ekin all ke
|
||||
compute epot all pe
|
||||
variable erot equal c_erot
|
||||
variable ekin equal c_ekin
|
||||
variable epot equal c_epot
|
||||
variable etot equal c_erot+c_ekin+c_epot
|
||||
fix 5 all print ${efreq} "$(step) ekin = ${ekin} | erot = ${erot} | epot = ${epot} | etot = ${etot}" screen yes
|
||||
|
||||
dump out all custom ${ofreq} out.${number}.txt id x y z vx vy vz fx fy fz tqx tqy tqz
|
||||
dump_modify out sort id
|
||||
dump_modify out format line "%d %13.6le %13.6le %13.6le %13.6le %13.6le %13.6le %13.6le %13.6le %13.6le %13.6le %13.6le %13.6le"
|
||||
|
||||
run 1000000
|
||||
|
||||
#write_restart config.${number}.*
|
||||
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
73
examples/USER/cgdna/examples/oxDNA/duplex1/data.duplex1
Normal file
73
examples/USER/cgdna/examples/oxDNA/duplex1/data.duplex1
Normal file
@ -0,0 +1,73 @@
|
||||
# LAMMPS data file
|
||||
10 atoms
|
||||
10 ellipsoids
|
||||
8 bonds
|
||||
|
||||
4 atom types
|
||||
1 bond types
|
||||
|
||||
# System size
|
||||
-20.000000 20.000000 xlo xhi
|
||||
-20.000000 20.000000 ylo yhi
|
||||
-20.000000 20.000000 zlo zhi
|
||||
|
||||
Masses
|
||||
|
||||
1 3.1575
|
||||
2 3.1575
|
||||
3 3.1575
|
||||
4 3.1575
|
||||
|
||||
# Atom-ID, type, position, molecule-ID, ellipsoid flag, density
|
||||
Atoms
|
||||
|
||||
1 1 -6.000000000000001e-01 0.000000000000000e+00 0.000000000000000e+00 1 1 1
|
||||
2 2 -4.860249842674776e-01 -3.518234140414736e-01 3.897628551303122e-01 1 1 1
|
||||
3 3 -1.874009511073395e-01 -5.699832309147915e-01 7.795257102606244e-01 1 1 1
|
||||
4 4 1.824198365552941e-01 -5.715968887521518e-01 1.169288565390937e+00 1 1 1
|
||||
5 1 4.829362784135484e-01 -3.560513319622209e-01 1.559051420521249e+00 1 1 1
|
||||
6 4 -4.829362784135484e-01 3.560513319622209e-01 1.559051420521249e+00 2 1 1
|
||||
7 1 -1.824198365552941e-01 5.715968887521516e-01 1.169288565390937e+00 2 1 1
|
||||
8 2 1.874009511073395e-01 5.699832309147913e-01 7.795257102606243e-01 2 1 1
|
||||
9 3 4.860249842674775e-01 3.518234140414733e-01 3.897628551303121e-01 2 1 1
|
||||
10 4 5.999999999999996e-01 -1.332267629550188e-16 -1.110223024625157e-16 2 1 1
|
||||
|
||||
# Atom-ID, translational, rotational velocity
|
||||
Velocities
|
||||
|
||||
1 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00
|
||||
2 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00
|
||||
3 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00
|
||||
4 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00
|
||||
5 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00
|
||||
6 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00
|
||||
7 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00
|
||||
8 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00
|
||||
9 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00
|
||||
10 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00
|
||||
|
||||
# Atom-ID, shape, quaternion
|
||||
Ellipsoids
|
||||
|
||||
1 1.173984503142341e+00 1.173984503142341e+00 1.173984503142341e+00 1.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00
|
||||
2 1.173984503142341e+00 1.173984503142341e+00 1.173984503142341e+00 9.513258223252946e-01 0.000000000000000e+00 0.000000000000000e+00 3.081869234362515e-01
|
||||
3 1.173984503142341e+00 1.173984503142341e+00 1.173984503142341e+00 8.100416404457962e-01 0.000000000000000e+00 0.000000000000000e+00 5.863723567357894e-01
|
||||
4 1.173984503142341e+00 1.173984503142341e+00 1.173984503142341e+00 5.899012371043606e-01 0.000000000000000e+00 0.000000000000000e+00 8.074754054847398e-01
|
||||
5 1.173984503142341e+00 1.173984503142341e+00 1.173984503142341e+00 3.123349185122326e-01 0.000000000000000e+00 0.000000000000000e+00 9.499720515246527e-01
|
||||
6 1.173984503142341e+00 1.173984503142341e+00 1.173984503142341e+00 0.000000000000000e+00 9.499720515246527e-01 -3.123349185122326e-01 -0.000000000000000e+00
|
||||
7 1.173984503142341e+00 1.173984503142341e+00 1.173984503142341e+00 0.000000000000000e+00 8.074754054847401e-01 -5.899012371043604e-01 0.000000000000000e+00
|
||||
8 1.173984503142341e+00 1.173984503142341e+00 1.173984503142341e+00 0.000000000000000e+00 5.863723567357896e-01 -8.100416404457959e-01 0.000000000000000e+00
|
||||
9 1.173984503142341e+00 1.173984503142341e+00 1.173984503142341e+00 -0.000000000000000e+00 -3.081869234362514e-01 9.513258223252947e-01 0.000000000000000e+00
|
||||
10 1.173984503142341e+00 1.173984503142341e+00 1.173984503142341e+00 -0.000000000000000e+00 1.110223024625157e-16 1.000000000000000e+00 -0.000000000000000e+00
|
||||
|
||||
# Bond topology
|
||||
Bonds
|
||||
|
||||
1 1 1 2
|
||||
2 1 2 3
|
||||
3 1 3 4
|
||||
4 1 4 5
|
||||
5 1 6 7
|
||||
6 1 7 8
|
||||
7 1 8 9
|
||||
8 1 9 10
|
||||
77
examples/USER/cgdna/examples/oxDNA/duplex1/input.duplex1
Normal file
77
examples/USER/cgdna/examples/oxDNA/duplex1/input.duplex1
Normal file
@ -0,0 +1,77 @@
|
||||
variable number equal 1
|
||||
variable ofreq equal 1000
|
||||
variable efreq equal 1000
|
||||
|
||||
units lj
|
||||
|
||||
dimension 3
|
||||
|
||||
newton off
|
||||
|
||||
boundary p p p
|
||||
|
||||
atom_style hybrid bond ellipsoid
|
||||
atom_modify sort 0 1.0
|
||||
|
||||
# Pair interactions require lists of neighbours to be calculated
|
||||
neighbor 1.0 bin
|
||||
neigh_modify every 1 delay 0 check yes
|
||||
|
||||
read_data data.duplex1
|
||||
|
||||
set atom * mass 3.1575
|
||||
|
||||
group all type 1 4
|
||||
|
||||
# oxDNA bond interactions - FENE backbone
|
||||
bond_style oxdna/fene
|
||||
bond_coeff * 2.0 0.25 0.7525
|
||||
|
||||
# oxDNA pair interactions
|
||||
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 0.1 6.0 0.4 0.9 0.32 0.6 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 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 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 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
|
||||
|
||||
# NVE ensemble
|
||||
fix 1 all nve/dot
|
||||
#fix 1 all nve/dotc/langevin 0.1 0.1 0.03 457145 angmom 10
|
||||
#fix 1 all nve/asphere
|
||||
#fix 2 all langevin 0.1 0.1 0.03 457145 angmom 10
|
||||
|
||||
timestep 1e-5
|
||||
|
||||
#comm_style tiled
|
||||
#fix 3 all balance 10000 1.1 rcb
|
||||
|
||||
#compute mol all chunk/atom molecule
|
||||
#compute mychunk all vcm/chunk mol
|
||||
#fix 4 all ave/time 10000 1 10000 c_mychunk[1] c_mychunk[2] c_mychunk[3] file vcm.txt mode vector
|
||||
|
||||
#dump pos all xyz ${ofreq} traj.${number}.xyz
|
||||
|
||||
#compute quat all property/atom quatw quati quatj quatk
|
||||
#dump quat all custom ${ofreq} quat.${number}.txt id c_quat[1] c_quat[2] c_quat[3] c_quat[4]
|
||||
#dump_modify quat sort id
|
||||
#dump_modify quat format line "%d %13.6le %13.6le %13.6le %13.6le"
|
||||
|
||||
compute erot all erotate/asphere
|
||||
compute ekin all ke
|
||||
compute epot all pe
|
||||
variable erot equal c_erot
|
||||
variable ekin equal c_ekin
|
||||
variable epot equal c_epot
|
||||
variable etot equal c_erot+c_ekin+c_epot
|
||||
fix 5 all print ${efreq} "$(step) ekin = ${ekin} | erot = ${erot} | epot = ${epot} | etot = ${etot}" screen yes
|
||||
|
||||
#dump out all custom ${ofreq} out.${number}.txt id x y z vx vy vz fx fy fz tqx tqy tqz
|
||||
#dump_modify out sort id
|
||||
#dump_modify out format line "%d %13.6le %13.6le %13.6le %13.6le %13.6le %13.6le %13.6le %13.6le %13.6le %13.6le %13.6le %13.6le"
|
||||
|
||||
run 1000000
|
||||
|
||||
#write_restart config.${number}.*
|
||||
1161
examples/USER/cgdna/examples/oxDNA/duplex1/log.24Mar17.duplex1.g++.1
Normal file
1161
examples/USER/cgdna/examples/oxDNA/duplex1/log.24Mar17.duplex1.g++.1
Normal file
File diff suppressed because it is too large
Load Diff
1161
examples/USER/cgdna/examples/oxDNA/duplex1/log.24Mar17.duplex1.g++.4
Normal file
1161
examples/USER/cgdna/examples/oxDNA/duplex1/log.24Mar17.duplex1.g++.4
Normal file
File diff suppressed because it is too large
Load Diff
96
examples/USER/cgdna/examples/oxDNA/duplex2/data.duplex2
Normal file
96
examples/USER/cgdna/examples/oxDNA/duplex2/data.duplex2
Normal file
@ -0,0 +1,96 @@
|
||||
# LAMMPS data file
|
||||
16 atoms
|
||||
16 ellipsoids
|
||||
13 bonds
|
||||
|
||||
4 atom types
|
||||
1 bond types
|
||||
|
||||
# System size
|
||||
-20.000000 20.000000 xlo xhi
|
||||
-20.000000 20.000000 ylo yhi
|
||||
-20.000000 20.000000 zlo zhi
|
||||
|
||||
Masses
|
||||
|
||||
1 3.1575
|
||||
2 3.1575
|
||||
3 3.1575
|
||||
4 3.1575
|
||||
|
||||
# Atom-ID, type, position, molecule-ID, ellipsoid flag, density
|
||||
Atoms
|
||||
|
||||
1 1 -6.000000000000001e-01 0.000000000000000e+00 0.000000000000000e+00 1 1 1
|
||||
2 2 -4.860249842674776e-01 -3.518234140414736e-01 3.897628551303122e-01 1 1 1
|
||||
3 3 -1.874009511073395e-01 -5.699832309147915e-01 7.795257102606244e-01 1 1 1
|
||||
4 4 1.824198365552941e-01 -5.715968887521518e-01 1.169288565390937e+00 1 1 1
|
||||
5 1 4.829362784135484e-01 -3.560513319622209e-01 1.559051420521249e+00 1 1 1
|
||||
6 2 5.999771538385027e-01 -5.235921299024461e-03 1.948814275651561e+00 1 1 1
|
||||
7 3 4.890766774371325e-01 3.475687034056071e-01 2.338577130781873e+00 1 1 1
|
||||
8 4 1.923677943514057e-01 5.683261666476170e-01 2.728339985912185e+00 1 1 1
|
||||
9 1 -1.923677943514057e-01 -5.683261666476170e-01 2.728339985912185e+00 2 1 1
|
||||
10 2 -4.890766774371324e-01 -3.475687034056071e-01 2.338577130781873e+00 2 1 1
|
||||
11 3 -5.999771538385025e-01 5.235921299024461e-03 1.948814275651561e+00 2 1 1
|
||||
12 4 -4.829362784135481e-01 3.560513319622207e-01 1.559051420521249e+00 2 1 1
|
||||
13 1 -1.824198365552940e-01 5.715968887521514e-01 1.169288565390936e+00 2 1 1
|
||||
14 2 1.874009511073395e-01 5.699832309147912e-01 7.795257102606241e-01 2 1 1
|
||||
15 3 4.860249842674773e-01 3.518234140414733e-01 3.897628551303119e-01 2 1 1
|
||||
16 4 5.999999999999995e-01 -3.330669073875470e-17 -3.330669073875470e-16 2 1 1
|
||||
|
||||
# Atom-ID, translational, rotational velocity
|
||||
Velocities
|
||||
|
||||
1 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00
|
||||
2 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00
|
||||
3 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00
|
||||
4 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00
|
||||
5 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00
|
||||
6 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00
|
||||
7 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00
|
||||
8 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00
|
||||
9 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00
|
||||
10 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00
|
||||
11 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00
|
||||
12 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00
|
||||
13 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00
|
||||
14 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00
|
||||
15 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00
|
||||
16 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00
|
||||
|
||||
# Atom-ID, shape, quaternion
|
||||
Ellipsoids
|
||||
|
||||
1 1.173984503142341e+00 1.173984503142341e+00 1.173984503142341e+00 1.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00
|
||||
2 1.173984503142341e+00 1.173984503142341e+00 1.173984503142341e+00 9.513258223252946e-01 0.000000000000000e+00 0.000000000000000e+00 3.081869234362515e-01
|
||||
3 1.173984503142341e+00 1.173984503142341e+00 1.173984503142341e+00 8.100416404457962e-01 0.000000000000000e+00 0.000000000000000e+00 5.863723567357894e-01
|
||||
4 1.173984503142341e+00 1.173984503142341e+00 1.173984503142341e+00 5.899012371043606e-01 0.000000000000000e+00 0.000000000000000e+00 8.074754054847398e-01
|
||||
5 1.173984503142341e+00 1.173984503142341e+00 1.173984503142341e+00 3.123349185122326e-01 0.000000000000000e+00 0.000000000000000e+00 9.499720515246527e-01
|
||||
6 1.173984503142341e+00 1.173984503142341e+00 1.173984503142341e+00 4.363309284746654e-03 0.000000000000000e+00 0.000000000000000e+00 9.999904807207346e-01
|
||||
7 1.173984503142341e+00 1.173984503142341e+00 1.173984503142341e+00 -3.040330609254902e-01 0.000000000000000e+00 0.000000000000000e+00 9.526614812535865e-01
|
||||
8 1.173984503142341e+00 1.173984503142341e+00 1.173984503142341e+00 5.828323126827837e-01 0.000000000000000e+00 0.000000000000000e+00 -8.125924533816677e-01
|
||||
9 1.173984503142341e+00 1.173984503142341e+00 1.173984503142341e+00 0.000000000000000e+00 8.125924533816681e-01 5.828323126827832e-01 -0.000000000000000e+00
|
||||
10 1.173984503142341e+00 1.173984503142341e+00 1.173984503142341e+00 0.000000000000000e+00 9.526614812535864e-01 3.040330609254902e-01 0.000000000000000e+00
|
||||
11 1.173984503142341e+00 1.173984503142341e+00 1.173984503142341e+00 0.000000000000000e+00 9.999904807207346e-01 -4.363309284746654e-03 0.000000000000000e+00
|
||||
12 1.173984503142341e+00 1.173984503142341e+00 1.173984503142341e+00 0.000000000000000e+00 9.499720515246526e-01 -3.123349185122325e-01 0.000000000000000e+00
|
||||
13 1.173984503142341e+00 1.173984503142341e+00 1.173984503142341e+00 0.000000000000000e+00 8.074754054847402e-01 -5.899012371043603e-01 0.000000000000000e+00
|
||||
14 1.173984503142341e+00 1.173984503142341e+00 1.173984503142341e+00 0.000000000000000e+00 5.863723567357898e-01 -8.100416404457959e-01 0.000000000000000e+00
|
||||
15 1.173984503142341e+00 1.173984503142341e+00 1.173984503142341e+00 -0.000000000000000e+00 -3.081869234362514e-01 9.513258223252948e-01 0.000000000000000e+00
|
||||
16 1.173984503142341e+00 1.173984503142341e+00 1.173984503142341e+00 -0.000000000000000e+00 2.775557561562893e-17 1.000000000000000e+00 -0.000000000000000e+00
|
||||
|
||||
# Bond topology
|
||||
Bonds
|
||||
|
||||
1 1 1 2
|
||||
2 1 2 3
|
||||
3 1 3 4
|
||||
4 1 4 5
|
||||
5 1 5 6
|
||||
6 1 6 7
|
||||
7 1 7 8
|
||||
8 1 9 10
|
||||
9 1 10 11
|
||||
10 1 11 12
|
||||
11 1 13 14
|
||||
12 1 14 15
|
||||
13 1 15 16
|
||||
77
examples/USER/cgdna/examples/oxDNA/duplex2/input.duplex2
Normal file
77
examples/USER/cgdna/examples/oxDNA/duplex2/input.duplex2
Normal file
@ -0,0 +1,77 @@
|
||||
variable number equal 2
|
||||
variable ofreq equal 1000
|
||||
variable efreq equal 1000
|
||||
|
||||
units lj
|
||||
|
||||
dimension 3
|
||||
|
||||
newton off
|
||||
|
||||
boundary p p p
|
||||
|
||||
atom_style hybrid bond ellipsoid
|
||||
atom_modify sort 0 1.0
|
||||
|
||||
# Pair interactions require lists of neighbours to be calculated
|
||||
neighbor 1.0 bin
|
||||
neigh_modify every 1 delay 0 check yes
|
||||
|
||||
read_data data.duplex2
|
||||
|
||||
set atom * mass 3.1575
|
||||
|
||||
group all type 1 4
|
||||
|
||||
# oxDNA bond interactions - FENE backbone
|
||||
bond_style oxdna/fene
|
||||
bond_coeff * 2.0 0.25 0.7525
|
||||
|
||||
# oxDNA pair interactions
|
||||
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 0.1 6.0 0.4 0.9 0.32 0.6 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 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 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 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
|
||||
|
||||
# NVE ensemble
|
||||
#fix 1 all nve/dot
|
||||
fix 1 all nve/dotc/langevin 0.1 0.1 0.03 457145 angmom 10
|
||||
#fix 1 all nve/asphere
|
||||
#fix 2 all langevin 0.1 0.1 0.03 457145 angmom 10
|
||||
|
||||
timestep 1e-5
|
||||
|
||||
#comm_style tiled
|
||||
#fix 3 all balance 10000 1.1 rcb
|
||||
|
||||
#compute mol all chunk/atom molecule
|
||||
#compute mychunk all vcm/chunk mol
|
||||
#fix 4 all ave/time 10000 1 10000 c_mychunk[1] c_mychunk[2] c_mychunk[3] file vcm.txt mode vector
|
||||
|
||||
#dump pos all xyz ${ofreq} traj.${number}.xyz
|
||||
|
||||
#compute quat all property/atom quatw quati quatj quatk
|
||||
#dump quat all custom ${ofreq} quat.${number}.txt id c_quat[1] c_quat[2] c_quat[3] c_quat[4]
|
||||
#dump_modify quat sort id
|
||||
#dump_modify quat format line "%d %13.6le %13.6le %13.6le %13.6le"
|
||||
|
||||
compute erot all erotate/asphere
|
||||
compute ekin all ke
|
||||
compute epot all pe
|
||||
variable erot equal c_erot
|
||||
variable ekin equal c_ekin
|
||||
variable epot equal c_epot
|
||||
variable etot equal c_erot+c_ekin+c_epot
|
||||
fix 5 all print ${efreq} "$(step) ekin = ${ekin} | erot = ${erot} | epot = ${epot} | etot = ${etot}" screen yes
|
||||
|
||||
#dump out all custom ${ofreq} out.${number}.txt id x y z vx vy vz fx fy fz tqx tqy tqz
|
||||
#dump_modify out sort id
|
||||
#dump_modify out format line "%d %13.6le %13.6le %13.6le %13.6le %13.6le %13.6le %13.6le %13.6le %13.6le %13.6le %13.6le %13.6le"
|
||||
|
||||
run 1000000
|
||||
|
||||
#write_restart config.${number}.*
|
||||
1161
examples/USER/cgdna/examples/oxDNA/duplex2/log.24Mar17.duplex2.g++.1
Normal file
1161
examples/USER/cgdna/examples/oxDNA/duplex2/log.24Mar17.duplex2.g++.1
Normal file
File diff suppressed because it is too large
Load Diff
1161
examples/USER/cgdna/examples/oxDNA/duplex2/log.24Mar17.duplex2.g++.4
Normal file
1161
examples/USER/cgdna/examples/oxDNA/duplex2/log.24Mar17.duplex2.g++.4
Normal file
File diff suppressed because it is too large
Load Diff
73
examples/USER/cgdna/examples/oxDNA2/duplex1/data.duplex1
Normal file
73
examples/USER/cgdna/examples/oxDNA2/duplex1/data.duplex1
Normal file
@ -0,0 +1,73 @@
|
||||
# LAMMPS data file
|
||||
10 atoms
|
||||
10 ellipsoids
|
||||
8 bonds
|
||||
|
||||
4 atom types
|
||||
1 bond types
|
||||
|
||||
# System size
|
||||
-20.000000 20.000000 xlo xhi
|
||||
-20.000000 20.000000 ylo yhi
|
||||
-20.000000 20.000000 zlo zhi
|
||||
|
||||
Masses
|
||||
|
||||
1 3.1575
|
||||
2 3.1575
|
||||
3 3.1575
|
||||
4 3.1575
|
||||
|
||||
# Atom-ID, type, position, molecule-ID, ellipsoid flag, density
|
||||
Atoms
|
||||
|
||||
1 1 -6.000000000000001e-01 0.000000000000000e+00 0.000000000000000e+00 1 1 1
|
||||
2 2 -4.860249842674776e-01 -3.518234140414736e-01 3.897628551303122e-01 1 1 1
|
||||
3 3 -1.874009511073395e-01 -5.699832309147915e-01 7.795257102606244e-01 1 1 1
|
||||
4 4 1.824198365552941e-01 -5.715968887521518e-01 1.169288565390937e+00 1 1 1
|
||||
5 1 4.829362784135484e-01 -3.560513319622209e-01 1.559051420521249e+00 1 1 1
|
||||
6 4 -4.829362784135484e-01 3.560513319622209e-01 1.559051420521249e+00 2 1 1
|
||||
7 1 -1.824198365552941e-01 5.715968887521516e-01 1.169288565390937e+00 2 1 1
|
||||
8 2 1.874009511073395e-01 5.699832309147913e-01 7.795257102606243e-01 2 1 1
|
||||
9 3 4.860249842674775e-01 3.518234140414733e-01 3.897628551303121e-01 2 1 1
|
||||
10 4 5.999999999999996e-01 -1.332267629550188e-16 -1.110223024625157e-16 2 1 1
|
||||
|
||||
# Atom-ID, translational, rotational velocity
|
||||
Velocities
|
||||
|
||||
1 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00
|
||||
2 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00
|
||||
3 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00
|
||||
4 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00
|
||||
5 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00
|
||||
6 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00
|
||||
7 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00
|
||||
8 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00
|
||||
9 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00
|
||||
10 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00
|
||||
|
||||
# Atom-ID, shape, quaternion
|
||||
Ellipsoids
|
||||
|
||||
1 1.173984503142341e+00 1.173984503142341e+00 1.173984503142341e+00 1.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00
|
||||
2 1.173984503142341e+00 1.173984503142341e+00 1.173984503142341e+00 9.513258223252946e-01 0.000000000000000e+00 0.000000000000000e+00 3.081869234362515e-01
|
||||
3 1.173984503142341e+00 1.173984503142341e+00 1.173984503142341e+00 8.100416404457962e-01 0.000000000000000e+00 0.000000000000000e+00 5.863723567357894e-01
|
||||
4 1.173984503142341e+00 1.173984503142341e+00 1.173984503142341e+00 5.899012371043606e-01 0.000000000000000e+00 0.000000000000000e+00 8.074754054847398e-01
|
||||
5 1.173984503142341e+00 1.173984503142341e+00 1.173984503142341e+00 3.123349185122326e-01 0.000000000000000e+00 0.000000000000000e+00 9.499720515246527e-01
|
||||
6 1.173984503142341e+00 1.173984503142341e+00 1.173984503142341e+00 0.000000000000000e+00 9.499720515246527e-01 -3.123349185122326e-01 -0.000000000000000e+00
|
||||
7 1.173984503142341e+00 1.173984503142341e+00 1.173984503142341e+00 0.000000000000000e+00 8.074754054847401e-01 -5.899012371043604e-01 0.000000000000000e+00
|
||||
8 1.173984503142341e+00 1.173984503142341e+00 1.173984503142341e+00 0.000000000000000e+00 5.863723567357896e-01 -8.100416404457959e-01 0.000000000000000e+00
|
||||
9 1.173984503142341e+00 1.173984503142341e+00 1.173984503142341e+00 -0.000000000000000e+00 -3.081869234362514e-01 9.513258223252947e-01 0.000000000000000e+00
|
||||
10 1.173984503142341e+00 1.173984503142341e+00 1.173984503142341e+00 -0.000000000000000e+00 1.110223024625157e-16 1.000000000000000e+00 -0.000000000000000e+00
|
||||
|
||||
# Bond topology
|
||||
Bonds
|
||||
|
||||
1 1 1 2
|
||||
2 1 2 3
|
||||
3 1 3 4
|
||||
4 1 4 5
|
||||
5 1 6 7
|
||||
6 1 7 8
|
||||
7 1 8 9
|
||||
8 1 9 10
|
||||
78
examples/USER/cgdna/examples/oxDNA2/duplex1/input.duplex1
Normal file
78
examples/USER/cgdna/examples/oxDNA2/duplex1/input.duplex1
Normal file
@ -0,0 +1,78 @@
|
||||
variable number equal 1
|
||||
variable ofreq equal 1000
|
||||
variable efreq equal 1000
|
||||
|
||||
units lj
|
||||
|
||||
dimension 3
|
||||
|
||||
newton off
|
||||
|
||||
boundary p p p
|
||||
|
||||
atom_style hybrid bond ellipsoid
|
||||
atom_modify sort 0 1.0
|
||||
|
||||
# Pair interactions require lists of neighbours to be calculated
|
||||
neighbor 1.0 bin
|
||||
neigh_modify every 1 delay 0 check yes
|
||||
|
||||
read_data data.duplex1
|
||||
|
||||
set atom * mass 3.1575
|
||||
|
||||
group all type 1 4
|
||||
|
||||
# oxDNA bond interactions - FENE backbone
|
||||
bond_style oxdna2/fene
|
||||
bond_coeff * 2.0 0.25 0.7564
|
||||
|
||||
# oxDNA pair interactions
|
||||
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 0.1 6.0 0.4 0.9 0.32 0.6 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 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 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 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
|
||||
|
||||
# NVE ensemble
|
||||
fix 1 all nve/dot
|
||||
#fix 1 all nve/dotc/langevin 0.1 0.1 0.03 457145 angmom 10
|
||||
#fix 1 all nve/asphere
|
||||
#fix 2 all langevin 0.1 0.1 0.03 457145 angmom 10
|
||||
|
||||
timestep 1e-5
|
||||
|
||||
#comm_style tiled
|
||||
#fix 3 all balance 10000 1.1 rcb
|
||||
|
||||
#compute mol all chunk/atom molecule
|
||||
#compute mychunk all vcm/chunk mol
|
||||
#fix 4 all ave/time 10000 1 10000 c_mychunk[1] c_mychunk[2] c_mychunk[3] file vcm.txt mode vector
|
||||
|
||||
#dump pos all xyz ${ofreq} traj.${number}.xyz
|
||||
|
||||
#compute quat all property/atom quatw quati quatj quatk
|
||||
#dump quat all custom ${ofreq} quat.${number}.txt id c_quat[1] c_quat[2] c_quat[3] c_quat[4]
|
||||
#dump_modify quat sort id
|
||||
#dump_modify quat format line "%d %13.6le %13.6le %13.6le %13.6le"
|
||||
|
||||
compute erot all erotate/asphere
|
||||
compute ekin all ke
|
||||
compute epot all pe
|
||||
variable erot equal c_erot
|
||||
variable ekin equal c_ekin
|
||||
variable epot equal c_epot
|
||||
variable etot equal c_erot+c_ekin+c_epot
|
||||
fix 5 all print ${efreq} "$(step) ekin = ${ekin} | erot = ${erot} | epot = ${epot} | etot = ${etot}" screen yes
|
||||
|
||||
#dump out all custom ${ofreq} out.${number}.txt id x y z vx vy vz fx fy fz tqx tqy tqz
|
||||
#dump_modify out sort id
|
||||
#dump_modify out format line "%d %13.6le %13.6le %13.6le %13.6le %13.6le %13.6le %13.6le %13.6le %13.6le %13.6le %13.6le %13.6le"
|
||||
|
||||
run 1000000
|
||||
|
||||
#write_restart config.${number}.*
|
||||
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
96
examples/USER/cgdna/examples/oxDNA2/duplex2/data.duplex2
Normal file
96
examples/USER/cgdna/examples/oxDNA2/duplex2/data.duplex2
Normal file
@ -0,0 +1,96 @@
|
||||
# LAMMPS data file
|
||||
16 atoms
|
||||
16 ellipsoids
|
||||
13 bonds
|
||||
|
||||
4 atom types
|
||||
1 bond types
|
||||
|
||||
# System size
|
||||
-20.000000 20.000000 xlo xhi
|
||||
-20.000000 20.000000 ylo yhi
|
||||
-20.000000 20.000000 zlo zhi
|
||||
|
||||
Masses
|
||||
|
||||
1 3.1575
|
||||
2 3.1575
|
||||
3 3.1575
|
||||
4 3.1575
|
||||
|
||||
# Atom-ID, type, position, molecule-ID, ellipsoid flag, density
|
||||
Atoms
|
||||
|
||||
1 1 -6.000000000000001e-01 0.000000000000000e+00 0.000000000000000e+00 1 1 1
|
||||
2 2 -4.860249842674776e-01 -3.518234140414736e-01 3.897628551303122e-01 1 1 1
|
||||
3 3 -1.874009511073395e-01 -5.699832309147915e-01 7.795257102606244e-01 1 1 1
|
||||
4 4 1.824198365552941e-01 -5.715968887521518e-01 1.169288565390937e+00 1 1 1
|
||||
5 1 4.829362784135484e-01 -3.560513319622209e-01 1.559051420521249e+00 1 1 1
|
||||
6 2 5.999771538385027e-01 -5.235921299024461e-03 1.948814275651561e+00 1 1 1
|
||||
7 3 4.890766774371325e-01 3.475687034056071e-01 2.338577130781873e+00 1 1 1
|
||||
8 4 1.923677943514057e-01 5.683261666476170e-01 2.728339985912185e+00 1 1 1
|
||||
9 1 -1.923677943514057e-01 -5.683261666476170e-01 2.728339985912185e+00 2 1 1
|
||||
10 2 -4.890766774371324e-01 -3.475687034056071e-01 2.338577130781873e+00 2 1 1
|
||||
11 3 -5.999771538385025e-01 5.235921299024461e-03 1.948814275651561e+00 2 1 1
|
||||
12 4 -4.829362784135481e-01 3.560513319622207e-01 1.559051420521249e+00 2 1 1
|
||||
13 1 -1.824198365552940e-01 5.715968887521514e-01 1.169288565390936e+00 2 1 1
|
||||
14 2 1.874009511073395e-01 5.699832309147912e-01 7.795257102606241e-01 2 1 1
|
||||
15 3 4.860249842674773e-01 3.518234140414733e-01 3.897628551303119e-01 2 1 1
|
||||
16 4 5.999999999999995e-01 -3.330669073875470e-17 -3.330669073875470e-16 2 1 1
|
||||
|
||||
# Atom-ID, translational, rotational velocity
|
||||
Velocities
|
||||
|
||||
1 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00
|
||||
2 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00
|
||||
3 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00
|
||||
4 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00
|
||||
5 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00
|
||||
6 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00
|
||||
7 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00
|
||||
8 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00
|
||||
9 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00
|
||||
10 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00
|
||||
11 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00
|
||||
12 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00
|
||||
13 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00
|
||||
14 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00
|
||||
15 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00
|
||||
16 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00
|
||||
|
||||
# Atom-ID, shape, quaternion
|
||||
Ellipsoids
|
||||
|
||||
1 1.173984503142341e+00 1.173984503142341e+00 1.173984503142341e+00 1.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00
|
||||
2 1.173984503142341e+00 1.173984503142341e+00 1.173984503142341e+00 9.513258223252946e-01 0.000000000000000e+00 0.000000000000000e+00 3.081869234362515e-01
|
||||
3 1.173984503142341e+00 1.173984503142341e+00 1.173984503142341e+00 8.100416404457962e-01 0.000000000000000e+00 0.000000000000000e+00 5.863723567357894e-01
|
||||
4 1.173984503142341e+00 1.173984503142341e+00 1.173984503142341e+00 5.899012371043606e-01 0.000000000000000e+00 0.000000000000000e+00 8.074754054847398e-01
|
||||
5 1.173984503142341e+00 1.173984503142341e+00 1.173984503142341e+00 3.123349185122326e-01 0.000000000000000e+00 0.000000000000000e+00 9.499720515246527e-01
|
||||
6 1.173984503142341e+00 1.173984503142341e+00 1.173984503142341e+00 4.363309284746654e-03 0.000000000000000e+00 0.000000000000000e+00 9.999904807207346e-01
|
||||
7 1.173984503142341e+00 1.173984503142341e+00 1.173984503142341e+00 -3.040330609254902e-01 0.000000000000000e+00 0.000000000000000e+00 9.526614812535865e-01
|
||||
8 1.173984503142341e+00 1.173984503142341e+00 1.173984503142341e+00 5.828323126827837e-01 0.000000000000000e+00 0.000000000000000e+00 -8.125924533816677e-01
|
||||
9 1.173984503142341e+00 1.173984503142341e+00 1.173984503142341e+00 0.000000000000000e+00 8.125924533816681e-01 5.828323126827832e-01 -0.000000000000000e+00
|
||||
10 1.173984503142341e+00 1.173984503142341e+00 1.173984503142341e+00 0.000000000000000e+00 9.526614812535864e-01 3.040330609254902e-01 0.000000000000000e+00
|
||||
11 1.173984503142341e+00 1.173984503142341e+00 1.173984503142341e+00 0.000000000000000e+00 9.999904807207346e-01 -4.363309284746654e-03 0.000000000000000e+00
|
||||
12 1.173984503142341e+00 1.173984503142341e+00 1.173984503142341e+00 0.000000000000000e+00 9.499720515246526e-01 -3.123349185122325e-01 0.000000000000000e+00
|
||||
13 1.173984503142341e+00 1.173984503142341e+00 1.173984503142341e+00 0.000000000000000e+00 8.074754054847402e-01 -5.899012371043603e-01 0.000000000000000e+00
|
||||
14 1.173984503142341e+00 1.173984503142341e+00 1.173984503142341e+00 0.000000000000000e+00 5.863723567357898e-01 -8.100416404457959e-01 0.000000000000000e+00
|
||||
15 1.173984503142341e+00 1.173984503142341e+00 1.173984503142341e+00 -0.000000000000000e+00 -3.081869234362514e-01 9.513258223252948e-01 0.000000000000000e+00
|
||||
16 1.173984503142341e+00 1.173984503142341e+00 1.173984503142341e+00 -0.000000000000000e+00 2.775557561562893e-17 1.000000000000000e+00 -0.000000000000000e+00
|
||||
|
||||
# Bond topology
|
||||
Bonds
|
||||
|
||||
1 1 1 2
|
||||
2 1 2 3
|
||||
3 1 3 4
|
||||
4 1 4 5
|
||||
5 1 5 6
|
||||
6 1 6 7
|
||||
7 1 7 8
|
||||
8 1 9 10
|
||||
9 1 10 11
|
||||
10 1 11 12
|
||||
11 1 13 14
|
||||
12 1 14 15
|
||||
13 1 15 16
|
||||
78
examples/USER/cgdna/examples/oxDNA2/duplex2/input.duplex2
Normal file
78
examples/USER/cgdna/examples/oxDNA2/duplex2/input.duplex2
Normal file
@ -0,0 +1,78 @@
|
||||
variable number equal 2
|
||||
variable ofreq equal 1000
|
||||
variable efreq equal 1000
|
||||
|
||||
units lj
|
||||
|
||||
dimension 3
|
||||
|
||||
newton off
|
||||
|
||||
boundary p p p
|
||||
|
||||
atom_style hybrid bond ellipsoid
|
||||
atom_modify sort 0 1.0
|
||||
|
||||
# Pair interactions require lists of neighbours to be calculated
|
||||
neighbor 1.0 bin
|
||||
neigh_modify every 1 delay 0 check yes
|
||||
|
||||
read_data data.duplex2
|
||||
|
||||
set atom * mass 3.1575
|
||||
|
||||
group all type 1 4
|
||||
|
||||
# oxDNA bond interactions - FENE backbone
|
||||
bond_style oxdna2/fene
|
||||
bond_coeff * 2.0 0.25 0.7564
|
||||
|
||||
# oxDNA pair interactions
|
||||
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 0.1 6.0 0.4 0.9 0.32 0.6 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 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 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 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
|
||||
|
||||
# NVE ensemble
|
||||
#fix 1 all nve/dot
|
||||
fix 1 all nve/dotc/langevin 0.1 0.1 0.03 457145 angmom 10
|
||||
#fix 1 all nve/asphere
|
||||
#fix 2 all langevin 0.1 0.1 0.03 457145 angmom 10
|
||||
|
||||
timestep 1e-5
|
||||
|
||||
#comm_style tiled
|
||||
#fix 3 all balance 10000 1.1 rcb
|
||||
|
||||
#compute mol all chunk/atom molecule
|
||||
#compute mychunk all vcm/chunk mol
|
||||
#fix 4 all ave/time 10000 1 10000 c_mychunk[1] c_mychunk[2] c_mychunk[3] file vcm.txt mode vector
|
||||
|
||||
#dump pos all xyz ${ofreq} traj.${number}.xyz
|
||||
|
||||
#compute quat all property/atom quatw quati quatj quatk
|
||||
#dump quat all custom ${ofreq} quat.${number}.txt id c_quat[1] c_quat[2] c_quat[3] c_quat[4]
|
||||
#dump_modify quat sort id
|
||||
#dump_modify quat format line "%d %13.6le %13.6le %13.6le %13.6le"
|
||||
|
||||
compute erot all erotate/asphere
|
||||
compute ekin all ke
|
||||
compute epot all pe
|
||||
variable erot equal c_erot
|
||||
variable ekin equal c_ekin
|
||||
variable epot equal c_epot
|
||||
variable etot equal c_erot+c_ekin+c_epot
|
||||
fix 5 all print ${efreq} "$(step) ekin = ${ekin} | erot = ${erot} | epot = ${epot} | etot = ${etot}" screen yes
|
||||
|
||||
#dump out all custom ${ofreq} out.${number}.txt id x y z vx vy vz fx fy fz tqx tqy tqz
|
||||
#dump_modify out sort id
|
||||
#dump_modify out format line "%d %13.6le %13.6le %13.6le %13.6le %13.6le %13.6le %13.6le %13.6le %13.6le %13.6le %13.6le %13.6le"
|
||||
|
||||
run 1000000
|
||||
|
||||
#write_restart config.${number}.*
|
||||
File diff suppressed because it is too large
Load Diff
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user