Merge branch 'master' of github.com:lammps/lammps
This commit is contained in:
Michele Ceriotti
@ -19,33 +19,33 @@ directories for instructions on how to build the packages with
|
||||
different precisions. The GPU and USER-CUDA sub-sections of the
|
||||
doc/Section_accelerate.html file also describes this process.
|
||||
|
||||
Make.py -d ~/lammps -j 16 -p #all orig -m linux -o cpu exe
|
||||
Make.py -d ~/lammps -j 16 -p #all opt orig -m linux -o opt exe
|
||||
Make.py -d ~/lammps -j 16 -p #all omp orig -m linux -o omp exe
|
||||
Make.py -d ~/lammps -j 16 -p #all orig -m linux -o cpu -a exe
|
||||
Make.py -d ~/lammps -j 16 -p #all opt orig -m linux -o opt -a exe
|
||||
Make.py -d ~/lammps -j 16 -p #all omp orig -m linux -o omp -a exe
|
||||
Make.py -d ~/lammps -j 16 -p #all gpu orig -m linux \
|
||||
-gpu mode=double arch=20 -o gpu_double libs exe
|
||||
-gpu mode=double arch=20 -o gpu_double -a libs exe
|
||||
Make.py -d ~/lammps -j 16 -p #all gpu orig -m linux \
|
||||
-gpu mode=mixed arch=20 -o gpu_mixed libs exe
|
||||
-gpu mode=mixed arch=20 -o gpu_mixed -a libs exe
|
||||
Make.py -d ~/lammps -j 16 -p #all gpu orig -m linux \
|
||||
-gpu mode=single arch=20 -o gpu_single libs exe
|
||||
-gpu mode=single arch=20 -o gpu_single -a libs exe
|
||||
Make.py -d ~/lammps -j 16 -p #all cuda orig -m linux \
|
||||
-cuda mode=double arch=20 -o cuda_double libs exe
|
||||
-cuda mode=double arch=20 -o cuda_double -a libs exe
|
||||
Make.py -d ~/lammps -j 16 -p #all cuda orig -m linux \
|
||||
-cuda mode=mixed arch=20 -o cuda_mixed libs exe
|
||||
-cuda mode=mixed arch=20 -o cuda_mixed -a libs exe
|
||||
Make.py -d ~/lammps -j 16 -p #all cuda orig -m linux \
|
||||
-cuda mode=single arch=20 -o cuda_single libs exe
|
||||
Make.py -d ~/lammps -j 16 -p #all intel orig -m linux -o intel_cpu exe
|
||||
Make.py -d ~/lammps -j 16 -p #all kokkos orig -m linux -o kokkos_omp exe
|
||||
-cuda mode=single arch=20 -o cuda_single -a libs exe
|
||||
Make.py -d ~/lammps -j 16 -p #all intel orig -m linux -o intel_cpu -a exe
|
||||
Make.py -d ~/lammps -j 16 -p #all kokkos orig -m linux -o kokkos_omp -a exe
|
||||
Make.py -d ~/lammps -j 16 -p #all kokkos orig -kokkos cuda arch=20 \
|
||||
-m cuda -o kokkos_cuda exe
|
||||
-m cuda -o kokkos_cuda -a exe
|
||||
|
||||
Make.py -d ~/lammps -j 16 -p #all opt omp gpu cuda intel kokkos orig \
|
||||
-gpu mode=double arch=20 -cuda mode=double arch=20 -m linux \
|
||||
-o all libs exe
|
||||
-o all -a libs exe
|
||||
|
||||
Make.py -d ~/lammps -j 16 -p #all opt omp gpu cuda intel kokkos orig \
|
||||
-kokkos cuda arch=20 -gpu mode=double arch=20 \
|
||||
-cuda mode=double arch=20 -m cuda -o all_cuda libs exe
|
||||
-cuda mode=double arch=20 -m cuda -o all_cuda -a libs exe
|
||||
|
||||
------------------------------------------------------------------------
|
||||
|
||||
|
||||
@ -82,7 +82,7 @@ also leave off the "-fft fftw3" switch if you do not have the FFTW
|
||||
library will be used.
|
||||
|
||||
cd src
|
||||
Make.py -j 16 -p none molecule manybody kspace granular orig \
|
||||
Make.py -j 16 -p none molecule manybody kspace granular rigid orig \
|
||||
-cc mpi wrap=icc -fft fftw3 -a file mpi
|
||||
|
||||
----------------------------------------------------------------------
|
||||
|
||||
@ -5,7 +5,7 @@ units lj
|
||||
atom_style sphere
|
||||
boundary p p fs
|
||||
newton off
|
||||
communicate single vel yes
|
||||
comm_modify vel yes
|
||||
|
||||
read_data data.chute
|
||||
|
||||
|
||||
@ -8,7 +8,7 @@ units lj
|
||||
atom_style sphere
|
||||
boundary p p fs
|
||||
newton off
|
||||
communicate single vel yes
|
||||
comm_modify vel yes
|
||||
|
||||
read_data data.chute
|
||||
|
||||
|
||||
BIN
doc/Eqs/fix_rattle_constraints.jpg
Normal file
BIN
doc/Eqs/fix_rattle_constraints.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 4.4 KiB |
9
doc/Eqs/fix_rattle_constraints.tex
Normal file
9
doc/Eqs/fix_rattle_constraints.tex
Normal file
@ -0,0 +1,9 @@
|
||||
\documentclass[12pt]{article}
|
||||
\usepackage{amsmath}
|
||||
|
||||
\begin{document}
|
||||
\begin{align*}
|
||||
\mathbf r^{n+1}_{ij} \cdot \mathbf r^{n+1}_{ij} &= d^2_{ij} \quad \text{and} \\
|
||||
\mathbf v^{n+1}_{ij} \cdot \mathbf r^{n+1}_{ij} &= 0, \label{eq:velcon}
|
||||
\end{align*}
|
||||
\end{document}
|
||||
BIN
doc/Eqs/fix_rattle_rij.jpg
Normal file
BIN
doc/Eqs/fix_rattle_rij.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 1.8 KiB |
8
doc/Eqs/fix_rattle_rij.tex
Normal file
8
doc/Eqs/fix_rattle_rij.tex
Normal file
@ -0,0 +1,8 @@
|
||||
\documentclass[12pt]{article}
|
||||
\usepackage{amsmath}
|
||||
\begin{document}
|
||||
$$
|
||||
\mathbf r^{n+1}_{ij} = \mathbf r^n_j - \mathbf r^n_i
|
||||
$$
|
||||
\end{document}
|
||||
|
||||
BIN
doc/Eqs/fix_ttm_blast.jpg
Normal file
BIN
doc/Eqs/fix_ttm_blast.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 4.3 KiB |
13
doc/Eqs/fix_ttm_blast.tex
Normal file
13
doc/Eqs/fix_ttm_blast.tex
Normal file
@ -0,0 +1,13 @@
|
||||
\documentclass[12pt]{article}
|
||||
|
||||
\begin{document}
|
||||
|
||||
$$
|
||||
{\vec F}_i = - \partial U / \partial {\vec r}_i + {\vec F}_{langevin} - \nabla P_e/n_{ion}
|
||||
$$
|
||||
|
||||
\end{document}
|
||||
|
||||
|
||||
|
||||
|
||||
BIN
doc/Eqs/fix_ttm_blast1.jpg
Normal file
BIN
doc/Eqs/fix_ttm_blast1.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 8.5 KiB |
13
doc/Eqs/fix_ttm_blast1.tex
Normal file
13
doc/Eqs/fix_ttm_blast1.tex
Normal file
@ -0,0 +1,13 @@
|
||||
\documentclass[12pt]{article}
|
||||
|
||||
\begin{document}
|
||||
|
||||
$$
|
||||
\nabla_x P_e = \left[\frac{C_e{}T_e(x)\lambda}{(x+\lambda)^2} + \frac{x}{x+\lambda}\frac{(C_e{}T_e)_{x+\Delta x}-(C_e{}T_e)_{x}}{\Delta x} \right]
|
||||
$$
|
||||
|
||||
\end{document}
|
||||
|
||||
|
||||
|
||||
|
||||
BIN
doc/Eqs/fix_ttm_ce.jpg
Normal file
BIN
doc/Eqs/fix_ttm_ce.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 7.3 KiB |
13
doc/Eqs/fix_ttm_ce.tex
Normal file
13
doc/Eqs/fix_ttm_ce.tex
Normal file
@ -0,0 +1,13 @@
|
||||
\documentclass[12pt]{article}
|
||||
|
||||
\begin{document}
|
||||
|
||||
$$
|
||||
C_e = C_0 + (a_0 + a_1 X + a_2 X^2 + a_3 X^3 + a_4 X^4) \exp (-(AX)^2)
|
||||
$$
|
||||
|
||||
\end{document}
|
||||
|
||||
|
||||
|
||||
|
||||
BIN
doc/Eqs/fix_ttm_mod.jpg
Normal file
BIN
doc/Eqs/fix_ttm_mod.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 9.9 KiB |
15
doc/Eqs/fix_ttm_mod.tex
Normal file
15
doc/Eqs/fix_ttm_mod.tex
Normal file
@ -0,0 +1,15 @@
|
||||
\documentclass[12pt]{article}
|
||||
|
||||
\begin{document}
|
||||
|
||||
$$
|
||||
C_e \rho_e \frac{\partial T_e}{\partial t} =
|
||||
\bigtriangledown (\kappa_e \bigtriangledown T_e) -
|
||||
g_p (T_e - T_a) + g_s T_a' + \theta (x-x_{surface})I_0 \exp(-x/l_{skin})
|
||||
$$
|
||||
|
||||
\end{document}
|
||||
|
||||
|
||||
|
||||
|
||||
BIN
doc/Eqs/pair_cs.jpg
Normal file
BIN
doc/Eqs/pair_cs.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 3.4 KiB |
9
doc/Eqs/pair_cs.tex
Normal file
9
doc/Eqs/pair_cs.tex
Normal file
@ -0,0 +1,9 @@
|
||||
\documentstyle[12pt]{article}
|
||||
|
||||
\begin{document}
|
||||
|
||||
$$
|
||||
E = \frac{C q_i q_j}{\epsilon (r + r_{min})} \qquad r \rightarrow 0
|
||||
$$
|
||||
|
||||
\end{document}
|
||||
@ -1,7 +1,7 @@
|
||||
<HTML>
|
||||
<HEAD>
|
||||
<TITLE>LAMMPS Users Manual</TITLE>
|
||||
<META NAME="docnumber" CONTENT="26 Nov 2014 version">
|
||||
<META NAME="docnumber" CONTENT="6 Apr 2015 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>
|
||||
@ -22,7 +22,7 @@
|
||||
|
||||
<CENTER><H3>LAMMPS Documentation
|
||||
</H3></CENTER>
|
||||
<CENTER><H4>26 Nov 2014 version
|
||||
<CENTER><H4>6 Apr 2015 version
|
||||
</H4></CENTER>
|
||||
<H4>Version info:
|
||||
</H4>
|
||||
@ -200,6 +200,10 @@ it gives quick access to documentation for all LAMMPS commands.
|
||||
6.21 <A HREF = "Section_howto.html#howto_21">Calculating viscosity</A>
|
||||
<BR>
|
||||
6.22 <A HREF = "howto_22">Calculating a diffusion coefficient</A>
|
||||
<BR>
|
||||
6.23 <A HREF = "howto_23">Using chunks to calculate system properties</A>
|
||||
<BR>
|
||||
6.24 <A HREF = "howto_24">Setting parameters for pppm/disp</A>
|
||||
<BR></UL>
|
||||
<LI><A HREF = "Section_example.html">Example problems</A>
|
||||
|
||||
@ -241,17 +245,21 @@ it gives quick access to documentation for all LAMMPS commands.
|
||||
<BR></UL>
|
||||
<LI><A HREF = "Section_python.html">Python interface</A>
|
||||
|
||||
<UL> 11.1 <A HREF = "Section_python.html#py_1">Building LAMMPS as a shared library</A>
|
||||
<UL> 11.1 <A HREF = "Section_python.html#py_1">Overview of running LAMMPS from Python</A>
|
||||
<BR>
|
||||
11.2 <A HREF = "Section_python.html#py_2">Installing the Python wrapper into Python</A>
|
||||
11.2 <A HREF = "Section_python.html#py_2">Overview of using Python from a LAMMPS script</A>
|
||||
<BR>
|
||||
11.3 <A HREF = "Section_python.html#py_3">Extending Python with MPI to run in parallel</A>
|
||||
11.3 <A HREF = "Section_python.html#py_3">Building LAMMPS as a shared library</A>
|
||||
<BR>
|
||||
11.4 <A HREF = "Section_python.html#py_4">Testing the Python-LAMMPS interface</A>
|
||||
11.4 <A HREF = "Section_python.html#py_4">Installing the Python wrapper into Python</A>
|
||||
<BR>
|
||||
11.5 <A HREF = "Section_python.html#py_5">Using LAMMPS from Python</A>
|
||||
11.5 <A HREF = "Section_python.html#py_5">Extending Python with MPI to run in parallel</A>
|
||||
<BR>
|
||||
11.6 <A HREF = "Section_python.html#py_6">Example Python scripts that use LAMMPS</A>
|
||||
11.6 <A HREF = "Section_python.html#py_6">Testing the Python-LAMMPS interface</A>
|
||||
<BR>
|
||||
11.7 <A HREF = "py_7">Using LAMMPS from Python</A>
|
||||
<BR>
|
||||
11.8 <A HREF = "py_8">Example Python scripts that use LAMMPS</A>
|
||||
<BR></UL>
|
||||
<LI><A HREF = "Section_errors.html">Errors</A>
|
||||
|
||||
|
||||
BIN
doc/Manual.pdf
BIN
doc/Manual.pdf
Binary file not shown.
@ -1,6 +1,6 @@
|
||||
<HEAD>
|
||||
<TITLE>LAMMPS Users Manual</TITLE>
|
||||
<META NAME="docnumber" CONTENT="26 Nov 2014 version">
|
||||
<META NAME="docnumber" CONTENT="6 Apr 2015 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>
|
||||
@ -18,7 +18,7 @@
|
||||
<H1></H1>
|
||||
|
||||
LAMMPS Documentation :c,h3
|
||||
26 Nov 2014 version :c,h4
|
||||
6 Apr 2015 version :c,h4
|
||||
|
||||
Version info: :h4
|
||||
|
||||
@ -136,7 +136,9 @@ it gives quick access to documentation for all LAMMPS commands.
|
||||
6.19 "Library interface to LAMMPS"_howto_19 :b
|
||||
6.20 "Calculating thermal conductivity"_howto_20 :b
|
||||
6.21 "Calculating viscosity"_howto_21 :b
|
||||
6.22 "Calculating a diffusion coefficient"_howto_22 :ule,b
|
||||
6.22 "Calculating a diffusion coefficient"_howto_22 :b
|
||||
6.23 "Using chunks to calculate system properties"_howto_23 :b
|
||||
6.24 "Setting parameters for pppm/disp"_howto_24 :ule,b
|
||||
"Example problems"_Section_example.html :l
|
||||
"Performance & scalability"_Section_perf.html :l
|
||||
"Additional tools"_Section_tools.html :l
|
||||
@ -157,12 +159,14 @@ it gives quick access to documentation for all LAMMPS commands.
|
||||
10.14 "Variable options"_mod_14 :b
|
||||
10.15 "Submitting new features for inclusion in LAMMPS"_mod_15 :ule,b
|
||||
"Python interface"_Section_python.html :l
|
||||
11.1 "Building LAMMPS as a shared library"_py_1 :ulb,b
|
||||
11.2 "Installing the Python wrapper into Python"_py_2 :b
|
||||
11.3 "Extending Python with MPI to run in parallel"_py_3 :b
|
||||
11.4 "Testing the Python-LAMMPS interface"_py_4 :b
|
||||
11.5 "Using LAMMPS from Python"_py_5 :b
|
||||
11.6 "Example Python scripts that use LAMMPS"_py_6 :ule,b
|
||||
11.1 "Overview of running LAMMPS from Python"_py_1 :ulb,b
|
||||
11.2 "Overview of using Python from a LAMMPS script"_py_2 :b
|
||||
11.3 "Building LAMMPS as a shared library"_py_3 :b
|
||||
11.4 "Installing the Python wrapper into Python"_py_4 :b
|
||||
11.5 "Extending Python with MPI to run in parallel"_py_5 :b
|
||||
11.6 "Testing the Python-LAMMPS interface"_py_6 :b
|
||||
11.7 "Using LAMMPS from Python"_py_7 :b
|
||||
11.8 "Example Python scripts that use LAMMPS"_py_8 :ule,b
|
||||
"Errors"_Section_errors.html :l
|
||||
12.1 "Common problems"_err_1 :ulb,b
|
||||
12.2 "Reporting bugs"_err_2 :b
|
||||
|
||||
Binary file not shown.
@ -86,11 +86,12 @@ file names or user-chosen ID strings.
|
||||
</P>
|
||||
<P>Here is how each line in the input script is parsed by LAMMPS:
|
||||
</P>
|
||||
<P>(1) If the last printable character on the line is a "&" character
|
||||
(with no surrounding quotes), the command is assumed to continue on
|
||||
the next line. The next line is concatenated to the previous line by
|
||||
removing the "&" character and newline. This allows long commands to
|
||||
be continued across two or more lines.
|
||||
<P>(1) If the last printable character on the line is a "&" character,
|
||||
the command is assumed to continue on the next line. The next line is
|
||||
concatenated to the previous line by removing the "&" character and
|
||||
line break. This allows long commands to be continued across two or
|
||||
more lines. See the discussion of triple quotes in (6) for how to
|
||||
continue a command across multiple line without using "&" characters.
|
||||
</P>
|
||||
<P>(2) All characters from the first "#" character onward are treated as
|
||||
comment and discarded. See an exception in (6). Note that a
|
||||
@ -156,27 +157,38 @@ underscores, or punctuation characters.
|
||||
line are arguments.
|
||||
</P>
|
||||
<P>(6) If you want text with spaces to be treated as a single argument,
|
||||
it can be enclosed in either double or single quotes. A long single
|
||||
argument enclosed in quotes can even span multiple lines if the "&"
|
||||
character is used, as described above. E.g.
|
||||
it can be enclosed in either single or double or triple quotes. A
|
||||
long single argument enclosed in single or double quotes can span
|
||||
multiple lines if the "&" character is used, as described above. When
|
||||
the lines are concatenated together (and the "&" characters and line
|
||||
breaks removed), the text will become a single line. If you want
|
||||
multiple lines of an argument to retain their line breaks, the text
|
||||
can be enclosed in triple quotes, in which case "&" characters are not
|
||||
needed. For example:
|
||||
</P>
|
||||
<PRE>print "Volume = $v"
|
||||
print 'Volume = $v'
|
||||
if "$<I>steps</I> > 1000" then quit
|
||||
variable a string "red green blue &
|
||||
purple orange cyan"
|
||||
if "$<I>steps</I> > 1000" then quit
|
||||
print """
|
||||
System volume = $v
|
||||
System temperature = $t
|
||||
"""
|
||||
</PRE>
|
||||
<P>The quotes are removed when the single argument is stored internally.
|
||||
<P>In each case, the single, double, or triple quotes are removed when
|
||||
the single argument they enclose is stored internally.
|
||||
</P>
|
||||
<P>See the <A HREF = "dump_modify.html">dump modify format</A> or <A HREF = "print.html">print</A> or
|
||||
<A HREF = "if.html">if</A> commands for examples. A "#" or "$" character that is
|
||||
between quotes will not be treated as a comment indicator in (2) or
|
||||
substituted for as a variable in (3).
|
||||
<P>See the <A HREF = "dump_modify.html">dump modify format</A>, <A HREF = "print.html">print</A>,
|
||||
<A HREF = "if.html">if</A>, and <A HREF = "python.html">python</A> commands for examples.
|
||||
</P>
|
||||
<P>A "#" or "$" character that is between quotes will not be treated as a
|
||||
comment indicator in (2) or substituted for as a variable in (3).
|
||||
</P>
|
||||
<P>IMPORTANT NOTE: If the argument is itself a command that requires a
|
||||
quoted argument (e.g. using a <A HREF = "print.html">print</A> command as part of an
|
||||
<A HREF = "if.html">if</A> or <A HREF = "run.html">run every</A> command), then the double and
|
||||
single quotes can be nested in the usual manner. See the doc pages
|
||||
<A HREF = "if.html">if</A> or <A HREF = "run.html">run every</A> command), then single, double, or
|
||||
triple quotes can be nested in the usual manner. See the doc pages
|
||||
for those commands for examples. Only one of level of nesting is
|
||||
allowed, but that should be sufficient for most use cases.
|
||||
</P>
|
||||
@ -363,20 +375,20 @@ in the command's documentation.
|
||||
<DIV ALIGN=center><TABLE BORDER=1 >
|
||||
<TR ALIGN="center"><TD ><A HREF = "angle_coeff.html">angle_coeff</A></TD><TD ><A HREF = "angle_style.html">angle_style</A></TD><TD ><A HREF = "atom_modify.html">atom_modify</A></TD><TD ><A HREF = "atom_style.html">atom_style</A></TD><TD ><A HREF = "balance.html">balance</A></TD><TD ><A HREF = "bond_coeff.html">bond_coeff</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "bond_style.html">bond_style</A></TD><TD ><A HREF = "boundary.html">boundary</A></TD><TD ><A HREF = "box.html">box</A></TD><TD ><A HREF = "change_box.html">change_box</A></TD><TD ><A HREF = "clear.html">clear</A></TD><TD ><A HREF = "comm_modify.html">comm_modify</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "comm_style.html">comm_style</A></TD><TD ><A HREF = "compute.html">compute</A></TD><TD ><A HREF = "compute_modify.html">compute_modify</A></TD><TD ><A HREF = "create_atoms.html">create_atoms</A></TD><TD ><A HREF = "create_box.html">create_box</A></TD><TD ><A HREF = "delete_atoms.html">delete_atoms</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "delete_bonds.html">delete_bonds</A></TD><TD ><A HREF = "dielectric.html">dielectric</A></TD><TD ><A HREF = "dihedral_coeff.html">dihedral_coeff</A></TD><TD ><A HREF = "dihedral_style.html">dihedral_style</A></TD><TD ><A HREF = "dimension.html">dimension</A></TD><TD ><A HREF = "displace_atoms.html">displace_atoms</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "dump.html">dump</A></TD><TD ><A HREF = "dump_image.html">dump image</A></TD><TD ><A HREF = "dump_modify.html">dump_modify</A></TD><TD ><A HREF = "dump_image.html">dump movie</A></TD><TD ><A HREF = "echo.html">echo</A></TD><TD ><A HREF = "fix.html">fix</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "fix_modify.html">fix_modify</A></TD><TD ><A HREF = "group.html">group</A></TD><TD ><A HREF = "if.html">if</A></TD><TD ><A HREF = "improper_coeff.html">improper_coeff</A></TD><TD ><A HREF = "improper_style.html">improper_style</A></TD><TD ><A HREF = "include.html">include</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "jump.html">jump</A></TD><TD ><A HREF = "kspace_modify.html">kspace_modify</A></TD><TD ><A HREF = "kspace_style.html">kspace_style</A></TD><TD ><A HREF = "label.html">label</A></TD><TD ><A HREF = "lattice.html">lattice</A></TD><TD ><A HREF = "log.html">log</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "mass.html">mass</A></TD><TD ><A HREF = "minimize.html">minimize</A></TD><TD ><A HREF = "min_modify.html">min_modify</A></TD><TD ><A HREF = "min_style.html">min_style</A></TD><TD ><A HREF = "molecule.html">molecule</A></TD><TD ><A HREF = "neb.html">neb</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "neigh_modify.html">neigh_modify</A></TD><TD ><A HREF = "neighbor.html">neighbor</A></TD><TD ><A HREF = "newton.html">newton</A></TD><TD ><A HREF = "next.html">next</A></TD><TD ><A HREF = "package.html">package</A></TD><TD ><A HREF = "pair_coeff.html">pair_coeff</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "pair_modify.html">pair_modify</A></TD><TD ><A HREF = "pair_style.html">pair_style</A></TD><TD ><A HREF = "pair_write.html">pair_write</A></TD><TD ><A HREF = "partition.html">partition</A></TD><TD ><A HREF = "prd.html">prd</A></TD><TD ><A HREF = "print.html">print</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "processors.html">processors</A></TD><TD ><A HREF = "quit.html">quit</A></TD><TD ><A HREF = "read_data.html">read_data</A></TD><TD ><A HREF = "read_dump.html">read_dump</A></TD><TD ><A HREF = "read_restart.html">read_restart</A></TD><TD ><A HREF = "region.html">region</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "replicate.html">replicate</A></TD><TD ><A HREF = "rerun.html">rerun</A></TD><TD ><A HREF = "reset_timestep.html">reset_timestep</A></TD><TD ><A HREF = "restart.html">restart</A></TD><TD ><A HREF = "run.html">run</A></TD><TD ><A HREF = "run_style.html">run_style</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "set.html">set</A></TD><TD ><A HREF = "shell.html">shell</A></TD><TD ><A HREF = "special_bonds.html">special_bonds</A></TD><TD ><A HREF = "suffix.html">suffix</A></TD><TD ><A HREF = "tad.html">tad</A></TD><TD ><A HREF = "temper.html">temper</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "thermo.html">thermo</A></TD><TD ><A HREF = "thermo_modify.html">thermo_modify</A></TD><TD ><A HREF = "thermo_style.html">thermo_style</A></TD><TD ><A HREF = "timestep.html">timestep</A></TD><TD ><A HREF = "uncompute.html">uncompute</A></TD><TD ><A HREF = "undump.html">undump</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "unfix.html">unfix</A></TD><TD ><A HREF = "units.html">units</A></TD><TD ><A HREF = "variable.html">variable</A></TD><TD ><A HREF = "velocity.html">velocity</A></TD><TD ><A HREF = "write_data.html">write_data</A></TD><TD ><A HREF = "write_dump.html">write_dump</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "write_restart.html">write_restart</A>
|
||||
<TR ALIGN="center"><TD ><A HREF = "comm_style.html">comm_style</A></TD><TD ><A HREF = "compute.html">compute</A></TD><TD ><A HREF = "compute_modify.html">compute_modify</A></TD><TD ><A HREF = "create_atoms.html">create_atoms</A></TD><TD ><A HREF = "create_bonds.html">create_bonds</A></TD><TD ><A HREF = "create_box.html">create_box</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "delete_atoms.html">delete_atoms</A></TD><TD ><A HREF = "delete_bonds.html">delete_bonds</A></TD><TD ><A HREF = "dielectric.html">dielectric</A></TD><TD ><A HREF = "dihedral_coeff.html">dihedral_coeff</A></TD><TD ><A HREF = "dihedral_style.html">dihedral_style</A></TD><TD ><A HREF = "dimension.html">dimension</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "displace_atoms.html">displace_atoms</A></TD><TD ><A HREF = "dump.html">dump</A></TD><TD ><A HREF = "dump_image.html">dump image</A></TD><TD ><A HREF = "dump_modify.html">dump_modify</A></TD><TD ><A HREF = "dump_image.html">dump movie</A></TD><TD ><A HREF = "echo.html">echo</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "fix.html">fix</A></TD><TD ><A HREF = "fix_modify.html">fix_modify</A></TD><TD ><A HREF = "group.html">group</A></TD><TD ><A HREF = "if.html">if</A></TD><TD ><A HREF = "improper_coeff.html">improper_coeff</A></TD><TD ><A HREF = "improper_style.html">improper_style</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "include.html">include</A></TD><TD ><A HREF = "jump.html">jump</A></TD><TD ><A HREF = "kspace_modify.html">kspace_modify</A></TD><TD ><A HREF = "kspace_style.html">kspace_style</A></TD><TD ><A HREF = "label.html">label</A></TD><TD ><A HREF = "lattice.html">lattice</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "log.html">log</A></TD><TD ><A HREF = "mass.html">mass</A></TD><TD ><A HREF = "minimize.html">minimize</A></TD><TD ><A HREF = "min_modify.html">min_modify</A></TD><TD ><A HREF = "min_style.html">min_style</A></TD><TD ><A HREF = "molecule.html">molecule</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "neb.html">neb</A></TD><TD ><A HREF = "neigh_modify.html">neigh_modify</A></TD><TD ><A HREF = "neighbor.html">neighbor</A></TD><TD ><A HREF = "newton.html">newton</A></TD><TD ><A HREF = "next.html">next</A></TD><TD ><A HREF = "package.html">package</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "pair_coeff.html">pair_coeff</A></TD><TD ><A HREF = "pair_modify.html">pair_modify</A></TD><TD ><A HREF = "pair_style.html">pair_style</A></TD><TD ><A HREF = "pair_write.html">pair_write</A></TD><TD ><A HREF = "partition.html">partition</A></TD><TD ><A HREF = "prd.html">prd</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "print.html">print</A></TD><TD ><A HREF = "processors.html">processors</A></TD><TD ><A HREF = "python.html">python</A></TD><TD ><A HREF = "quit.html">quit</A></TD><TD ><A HREF = "read_data.html">read_data</A></TD><TD ><A HREF = "read_dump.html">read_dump</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "read_restart.html">read_restart</A></TD><TD ><A HREF = "region.html">region</A></TD><TD ><A HREF = "replicate.html">replicate</A></TD><TD ><A HREF = "rerun.html">rerun</A></TD><TD ><A HREF = "reset_timestep.html">reset_timestep</A></TD><TD ><A HREF = "restart.html">restart</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "run.html">run</A></TD><TD ><A HREF = "run_style.html">run_style</A></TD><TD ><A HREF = "set.html">set</A></TD><TD ><A HREF = "shell.html">shell</A></TD><TD ><A HREF = "special_bonds.html">special_bonds</A></TD><TD ><A HREF = "suffix.html">suffix</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "tad.html">tad</A></TD><TD ><A HREF = "temper.html">temper</A></TD><TD ><A HREF = "thermo.html">thermo</A></TD><TD ><A HREF = "thermo_modify.html">thermo_modify</A></TD><TD ><A HREF = "thermo_style.html">thermo_style</A></TD><TD ><A HREF = "timestep.html">timestep</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "uncompute.html">uncompute</A></TD><TD ><A HREF = "undump.html">undump</A></TD><TD ><A HREF = "unfix.html">unfix</A></TD><TD ><A HREF = "units.html">units</A></TD><TD ><A HREF = "variable.html">variable</A></TD><TD ><A HREF = "velocity.html">velocity</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "write_data.html">write_data</A></TD><TD ><A HREF = "write_dump.html">write_dump</A></TD><TD ><A HREF = "write_restart.html">write_restart</A>
|
||||
</TD></TR></TABLE></DIV>
|
||||
|
||||
<P>These are additional commands in USER packages, which can be used if
|
||||
@ -399,20 +411,20 @@ This is indicated by additional letters in parenthesis: c = USER-CUDA,
|
||||
g = GPU, i = USER-INTEL, k = KOKKOS, o = USER-OMP, t = OPT.
|
||||
</P>
|
||||
<DIV ALIGN=center><TABLE BORDER=1 >
|
||||
<TR ALIGN="center"><TD ><A HREF = "fix_adapt.html">adapt</A></TD><TD ><A HREF = "fix_addforce.html">addforce (c)</A></TD><TD ><A HREF = "fix_append_atoms.html">append/atoms</A></TD><TD ><A HREF = "fix_aveforce.html">aveforce (c)</A></TD><TD ><A HREF = "fix_ave_atom.html">ave/atom</A></TD><TD ><A HREF = "fix_ave_correlate.html">ave/correlate</A></TD><TD ><A HREF = "fix_ave_histo.html">ave/histo</A></TD><TD ><A HREF = "fix_ave_spatial.html">ave/spatial</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "fix_ave_time.html">ave/time</A></TD><TD ><A HREF = "fix_balance.html">balance</A></TD><TD ><A HREF = "fix_bond_break.html">bond/break</A></TD><TD ><A HREF = "fix_bond_create.html">bond/create</A></TD><TD ><A HREF = "fix_bond_swap.html">bond/swap</A></TD><TD ><A HREF = "fix_box_relax.html">box/relax</A></TD><TD ><A HREF = "fix_deform.html">deform</A></TD><TD ><A HREF = "fix_deposit.html">deposit</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "fix_drag.html">drag</A></TD><TD ><A HREF = "fix_dt_reset.html">dt/reset</A></TD><TD ><A HREF = "fix_efield.html">efield</A></TD><TD ><A HREF = "fix_enforce2d.html">enforce2d (c)</A></TD><TD ><A HREF = "fix_evaporate.html">evaporate</A></TD><TD ><A HREF = "fix_external.html">external</A></TD><TD ><A HREF = "fix_freeze.html">freeze (c)</A></TD><TD ><A HREF = "fix_gcmc.html">gcmc</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "fix_gld.html">gld</A></TD><TD ><A HREF = "fix_gravity.html">gravity (co)</A></TD><TD ><A HREF = "fix_heat.html">heat</A></TD><TD ><A HREF = "fix_indent.html">indent</A></TD><TD ><A HREF = "fix_langevin.html">langevin (k)</A></TD><TD ><A HREF = "fix_lineforce.html">lineforce</A></TD><TD ><A HREF = "fix_momentum.html">momentum</A></TD><TD ><A HREF = "fix_move.html">move</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "fix_msst.html">msst</A></TD><TD ><A HREF = "fix_neb.html">neb</A></TD><TD ><A HREF = "fix_nh.html">nph (o)</A></TD><TD ><A HREF = "fix_nphug.html">nphug (o)</A></TD><TD ><A HREF = "fix_nph_asphere.html">nph/asphere (o)</A></TD><TD ><A HREF = "fix_nph_sphere.html">nph/sphere (o)</A></TD><TD ><A HREF = "fix_nh.html">npt (co)</A></TD><TD ><A HREF = "fix_npt_asphere.html">npt/asphere (o)</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "fix_npt_sphere.html">npt/sphere (o)</A></TD><TD ><A HREF = "fix_nve.html">nve (cko)</A></TD><TD ><A HREF = "fix_nve_asphere.html">nve/asphere</A></TD><TD ><A HREF = "fix_nve_asphere_noforce.html">nve/asphere/noforce</A></TD><TD ><A HREF = "fix_nve_body.html">nve/body</A></TD><TD ><A HREF = "fix_nve_limit.html">nve/limit</A></TD><TD ><A HREF = "fix_nve_line.html">nve/line</A></TD><TD ><A HREF = "fix_nve_noforce.html">nve/noforce</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "fix_nve_sphere.html">nve/sphere (o)</A></TD><TD ><A HREF = "fix_nve_tri.html">nve/tri</A></TD><TD ><A HREF = "fix_nh.html">nvt (co)</A></TD><TD ><A HREF = "fix_nvt_asphere.html">nvt/asphere (o)</A></TD><TD ><A HREF = "fix_nvt_sllod.html">nvt/sllod (o)</A></TD><TD ><A HREF = "fix_nvt_sphere.html">nvt/sphere (o)</A></TD><TD ><A HREF = "fix_oneway.html">oneway</A></TD><TD ><A HREF = "fix_orient_fcc.html">orient/fcc</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "fix_planeforce.html">planeforce</A></TD><TD ><A HREF = "fix_poems.html">poems</A></TD><TD ><A HREF = "fix_pour.html">pour</A></TD><TD ><A HREF = "fix_press_berendsen.html">press/berendsen</A></TD><TD ><A HREF = "fix_print.html">print</A></TD><TD ><A HREF = "fix_property_atom.html">property/atom</A></TD><TD ><A HREF = "fix_qeq_comb.html">qeq/comb (o)</A></TD><TD ><A HREF = "fix_qeq.html">qeq/dynamic</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "fix_qeq.html">qeq/point</A></TD><TD ><A HREF = "fix_qeq.html">qeq/shielded</A></TD><TD ><A HREF = "fix_qeq.html">qeq/slater</A></TD><TD ><A HREF = "fix_reax_bonds.html">reax/bonds</A></TD><TD ><A HREF = "fix_recenter.html">recenter</A></TD><TD ><A HREF = "fix_restrain.html">restrain</A></TD><TD ><A HREF = "fix_rigid.html">rigid (o)</A></TD><TD ><A HREF = "fix_rigid.html">rigid/nph (o)</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "fix_rigid.html">rigid/npt (o)</A></TD><TD ><A HREF = "fix_rigid.html">rigid/nve (o)</A></TD><TD ><A HREF = "fix_rigid.html">rigid/nvt (o)</A></TD><TD ><A HREF = "fix_rigid.html">rigid/small (o)</A></TD><TD ><A HREF = "fix_rigid.html">rigid/small/nph</A></TD><TD ><A HREF = "fix_rigid.html">rigid/small/npt</A></TD><TD ><A HREF = "fix_rigid.html">rigid/small/nve</A></TD><TD ><A HREF = "fix_rigid.html">rigid/small/nvt</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "fix_setforce.html">setforce (c)</A></TD><TD ><A HREF = "fix_shake.html">shake (c)</A></TD><TD ><A HREF = "fix_spring.html">spring</A></TD><TD ><A HREF = "fix_spring_rg.html">spring/rg</A></TD><TD ><A HREF = "fix_spring_self.html">spring/self</A></TD><TD ><A HREF = "fix_srd.html">srd</A></TD><TD ><A HREF = "fix_store_force.html">store/force</A></TD><TD ><A HREF = "fix_store_state.html">store/state</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "fix_temp_berendsen.html">temp/berendsen (c)</A></TD><TD ><A HREF = "fix_temp_csvr.html">temp/csvr</A></TD><TD ><A HREF = "fix_temp_rescale.html">temp/rescale (c)</A></TD><TD ><A HREF = "fix_thermal_conductivity.html">thermal/conductivity</A></TD><TD ><A HREF = "fix_tmd.html">tmd</A></TD><TD ><A HREF = "fix_ttm.html">ttm</A></TD><TD ><A HREF = "fix_tune_kspace.html">tune/kspace</A></TD><TD ><A HREF = "fix_vector.html">vector</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "fix_viscosity.html">viscosity</A></TD><TD ><A HREF = "fix_viscous.html">viscous (c)</A></TD><TD ><A HREF = "fix_wall.html">wall/colloid</A></TD><TD ><A HREF = "fix_wall_gran.html">wall/gran</A></TD><TD ><A HREF = "fix_wall.html">wall/harmonic</A></TD><TD ><A HREF = "fix_wall.html">wall/lj1043</A></TD><TD ><A HREF = "fix_wall.html">wall/lj126</A></TD><TD ><A HREF = "fix_wall.html">wall/lj93</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "fix_wall_piston.html">wall/piston</A></TD><TD ><A HREF = "fix_wall_reflect.html">wall/reflect</A></TD><TD ><A HREF = "fix_wall_region.html">wall/region</A></TD><TD ><A HREF = "fix_wall_srd.html">wall/srd</A>
|
||||
<TR ALIGN="center"><TD ><A HREF = "fix_adapt.html">adapt</A></TD><TD ><A HREF = "fix_addforce.html">addforce (c)</A></TD><TD ><A HREF = "fix_append_atoms.html">append/atoms</A></TD><TD ><A HREF = "fix_atom_swap.html">atom/swap</A></TD><TD ><A HREF = "fix_aveforce.html">aveforce (c)</A></TD><TD ><A HREF = "fix_ave_atom.html">ave/atom</A></TD><TD ><A HREF = "fix_ave_chunk.html">ave/chunk</A></TD><TD ><A HREF = "fix_ave_correlate.html">ave/correlate</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "fix_ave_histo.html">ave/histo</A></TD><TD ><A HREF = "fix_ave_spatial.html">ave/spatial</A></TD><TD ><A HREF = "fix_ave_time.html">ave/time</A></TD><TD ><A HREF = "fix_balance.html">balance</A></TD><TD ><A HREF = "fix_bond_break.html">bond/break</A></TD><TD ><A HREF = "fix_bond_create.html">bond/create</A></TD><TD ><A HREF = "fix_bond_swap.html">bond/swap</A></TD><TD ><A HREF = "fix_box_relax.html">box/relax</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "fix_deform.html">deform</A></TD><TD ><A HREF = "fix_deposit.html">deposit</A></TD><TD ><A HREF = "fix_drag.html">drag</A></TD><TD ><A HREF = "fix_dt_reset.html">dt/reset</A></TD><TD ><A HREF = "fix_efield.html">efield</A></TD><TD ><A HREF = "fix_enforce2d.html">enforce2d (c)</A></TD><TD ><A HREF = "fix_evaporate.html">evaporate</A></TD><TD ><A HREF = "fix_external.html">external</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "fix_freeze.html">freeze (c)</A></TD><TD ><A HREF = "fix_gcmc.html">gcmc</A></TD><TD ><A HREF = "fix_gld.html">gld</A></TD><TD ><A HREF = "fix_gravity.html">gravity (co)</A></TD><TD ><A HREF = "fix_heat.html">heat</A></TD><TD ><A HREF = "fix_indent.html">indent</A></TD><TD ><A HREF = "fix_langevin.html">langevin (k)</A></TD><TD ><A HREF = "fix_lineforce.html">lineforce</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "fix_momentum.html">momentum</A></TD><TD ><A HREF = "fix_move.html">move</A></TD><TD ><A HREF = "fix_msst.html">msst</A></TD><TD ><A HREF = "fix_neb.html">neb</A></TD><TD ><A HREF = "fix_nh.html">nph (o)</A></TD><TD ><A HREF = "fix_nphug.html">nphug (o)</A></TD><TD ><A HREF = "fix_nph_asphere.html">nph/asphere (o)</A></TD><TD ><A HREF = "fix_nph_sphere.html">nph/sphere (o)</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "fix_nh.html">npt (co)</A></TD><TD ><A HREF = "fix_npt_asphere.html">npt/asphere (o)</A></TD><TD ><A HREF = "fix_npt_sphere.html">npt/sphere (o)</A></TD><TD ><A HREF = "fix_nve.html">nve (cko)</A></TD><TD ><A HREF = "fix_nve_asphere.html">nve/asphere</A></TD><TD ><A HREF = "fix_nve_asphere_noforce.html">nve/asphere/noforce</A></TD><TD ><A HREF = "fix_nve_body.html">nve/body</A></TD><TD ><A HREF = "fix_nve_limit.html">nve/limit</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "fix_nve_line.html">nve/line</A></TD><TD ><A HREF = "fix_nve_noforce.html">nve/noforce</A></TD><TD ><A HREF = "fix_nve_sphere.html">nve/sphere (o)</A></TD><TD ><A HREF = "fix_nve_tri.html">nve/tri</A></TD><TD ><A HREF = "fix_nh.html">nvt (co)</A></TD><TD ><A HREF = "fix_nvt_asphere.html">nvt/asphere (o)</A></TD><TD ><A HREF = "fix_nvt_sllod.html">nvt/sllod (o)</A></TD><TD ><A HREF = "fix_nvt_sphere.html">nvt/sphere (o)</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "fix_oneway.html">oneway</A></TD><TD ><A HREF = "fix_orient_fcc.html">orient/fcc</A></TD><TD ><A HREF = "fix_planeforce.html">planeforce</A></TD><TD ><A HREF = "fix_poems.html">poems</A></TD><TD ><A HREF = "fix_pour.html">pour</A></TD><TD ><A HREF = "fix_press_berendsen.html">press/berendsen</A></TD><TD ><A HREF = "fix_print.html">print</A></TD><TD ><A HREF = "fix_property_atom.html">property/atom</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "fix_qeq_comb.html">qeq/comb (o)</A></TD><TD ><A HREF = "fix_qeq.html">qeq/dynamic</A></TD><TD ><A HREF = "fix_qeq.html">qeq/point</A></TD><TD ><A HREF = "fix_qeq.html">qeq/shielded</A></TD><TD ><A HREF = "fix_qeq.html">qeq/slater</A></TD><TD ><A HREF = "fix_reax_bonds.html">reax/bonds</A></TD><TD ><A HREF = "fix_recenter.html">recenter</A></TD><TD ><A HREF = "fix_restrain.html">restrain</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "fix_rigid.html">rigid (o)</A></TD><TD ><A HREF = "fix_rigid.html">rigid/nph (o)</A></TD><TD ><A HREF = "fix_rigid.html">rigid/npt (o)</A></TD><TD ><A HREF = "fix_rigid.html">rigid/nve (o)</A></TD><TD ><A HREF = "fix_rigid.html">rigid/nvt (o)</A></TD><TD ><A HREF = "fix_rigid.html">rigid/small (o)</A></TD><TD ><A HREF = "fix_rigid.html">rigid/small/nph</A></TD><TD ><A HREF = "fix_rigid.html">rigid/small/npt</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "fix_rigid.html">rigid/small/nve</A></TD><TD ><A HREF = "fix_rigid.html">rigid/small/nvt</A></TD><TD ><A HREF = "fix_setforce.html">setforce (c)</A></TD><TD ><A HREF = "fix_shake.html">shake (c)</A></TD><TD ><A HREF = "fix_spring.html">spring</A></TD><TD ><A HREF = "fix_spring_rg.html">spring/rg</A></TD><TD ><A HREF = "fix_spring_self.html">spring/self</A></TD><TD ><A HREF = "fix_srd.html">srd</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "fix_store_force.html">store/force</A></TD><TD ><A HREF = "fix_store_state.html">store/state</A></TD><TD ><A HREF = "fix_temp_berendsen.html">temp/berendsen (c)</A></TD><TD ><A HREF = "fix_temp_csvr.html">temp/csld</A></TD><TD ><A HREF = "fix_temp_csvr.html">temp/csvr</A></TD><TD ><A HREF = "fix_temp_rescale.html">temp/rescale (c)</A></TD><TD ><A HREF = "fix_tfmc.html">tfmc</A></TD><TD ><A HREF = "fix_thermal_conductivity.html">thermal/conductivity</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "fix_tmd.html">tmd</A></TD><TD ><A HREF = "fix_ttm.html">ttm</A></TD><TD ><A HREF = "fix_tune_kspace.html">tune/kspace</A></TD><TD ><A HREF = "fix_vector.html">vector</A></TD><TD ><A HREF = "fix_viscosity.html">viscosity</A></TD><TD ><A HREF = "fix_viscous.html">viscous (c)</A></TD><TD ><A HREF = "fix_wall.html">wall/colloid</A></TD><TD ><A HREF = "fix_wall_gran.html">wall/gran</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "fix_wall.html">wall/harmonic</A></TD><TD ><A HREF = "fix_wall.html">wall/lj1043</A></TD><TD ><A HREF = "fix_wall.html">wall/lj126</A></TD><TD ><A HREF = "fix_wall.html">wall/lj93</A></TD><TD ><A HREF = "fix_wall_piston.html">wall/piston</A></TD><TD ><A HREF = "fix_wall_reflect.html">wall/reflect</A></TD><TD ><A HREF = "fix_wall_region.html">wall/region</A></TD><TD ><A HREF = "fix_wall_srd.html">wall/srd</A>
|
||||
</TD></TR></TABLE></DIV>
|
||||
|
||||
<P>These are additional fix styles in USER packages, which can be used if
|
||||
@ -425,7 +437,7 @@ package</A>.
|
||||
<TR ALIGN="center"><TD ><A HREF = "fix_lb_rigid_pc_sphere.html">lb/rigid/pc/sphere</A></TD><TD ><A HREF = "fix_lb_viscous.html">lb/viscous</A></TD><TD ><A HREF = "fix_meso.html">meso</A></TD><TD ><A HREF = "fix_meso_stationary.html">meso/stationary</A></TD><TD ><A HREF = "fix_nh_eff.html">nph/eff</A></TD><TD ><A HREF = "fix_nh_eff.html">npt/eff</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "fix_nve_eff.html">nve/eff</A></TD><TD ><A HREF = "fix_nh_eff.html">nvt/eff</A></TD><TD ><A HREF = "fix_nvt_sllod_eff.html">nvt/sllod/eff</A></TD><TD ><A HREF = "fix_phonon.html">phonon</A></TD><TD ><A HREF = "fix_pimd.html">pimd</A></TD><TD ><A HREF = "fix_qeq_reax.html">qeq/reax</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "fix_qmmm.html">qmmm</A></TD><TD ><A HREF = "fix_reax_bonds.html">reax/c/bonds</A></TD><TD ><A HREF = "fix_reaxc_species.html">reax/c/species</A></TD><TD ><A HREF = "fix_smd.html">smd</A></TD><TD ><A HREF = "fix_temp_rescale_eff.html">temp/rescale/eff</A></TD><TD ><A HREF = "fix_ti_rs.html">ti/rs</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "fix_ti_spring.html">ti/spring</A>
|
||||
<TR ALIGN="center"><TD ><A HREF = "fix_ti_spring.html">ti/spring</A></TD><TD ><A HREF = "fix_ttm.html">ttm/mod</A>
|
||||
</TD></TR></TABLE></DIV>
|
||||
|
||||
<HR>
|
||||
@ -441,17 +453,17 @@ letters in parenthesis: c = USER-CUDA, g = GPU, i = USER-INTEL, k =
|
||||
KOKKOS, o = USER-OMP, t = OPT.
|
||||
</P>
|
||||
<DIV ALIGN=center><TABLE BORDER=1 >
|
||||
<TR ALIGN="center"><TD ><A HREF = "compute_angle_local.html">angle/local</A></TD><TD ><A HREF = "compute_atom_molecule.html">atom/molecule</A></TD><TD ><A HREF = "compute_body_local.html">body/local</A></TD><TD ><A HREF = "compute_bond_local.html">bond/local</A></TD><TD ><A HREF = "compute_centro_atom.html">centro/atom</A></TD><TD ><A HREF = "compute_cluster_atom.html">cluster/atom</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "compute_cna_atom.html">cna/atom</A></TD><TD ><A HREF = "compute_com.html">com</A></TD><TD ><A HREF = "compute_com_molecule.html">com/molecule</A></TD><TD ><A HREF = "compute_contact_atom.html">contact/atom</A></TD><TD ><A HREF = "compute_coord_atom.html">coord/atom</A></TD><TD ><A HREF = "compute_damage_atom.html">damage/atom</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "compute_dihedral_local.html">dihedral/local</A></TD><TD ><A HREF = "compute_dilatation_atom.html">dilatation/atom</A></TD><TD ><A HREF = "compute_displace_atom.html">displace/atom</A></TD><TD ><A HREF = "compute_erotate_asphere.html">erotate/asphere</A></TD><TD ><A HREF = "compute_erotate_rigid.html">erotate/rigid</A></TD><TD ><A HREF = "compute_erotate_sphere.html">erotate/sphere</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "compute_erotate_sphere_atom.html">erotate/sphere/atom</A></TD><TD ><A HREF = "compute_event_displace.html">event/displace</A></TD><TD ><A HREF = "compute_group_group.html">group/group</A></TD><TD ><A HREF = "compute_gyration.html">gyration</A></TD><TD ><A HREF = "compute_gyration_molecule.html">gyration/molecule</A></TD><TD ><A HREF = "compute_heat_flux.html">heat/flux</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "compute_improper_local.html">improper/local</A></TD><TD ><A HREF = "compute_inertia_molecule.html">inertia/molecule</A></TD><TD ><A HREF = "compute_ke.html">ke</A></TD><TD ><A HREF = "compute_ke_atom.html">ke/atom</A></TD><TD ><A HREF = "compute_ke_rigid.html">ke/rigid</A></TD><TD ><A HREF = "compute_msd.html">msd</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "compute_msd_molecule.html">msd/molecule</A></TD><TD ><A HREF = "compute_msd_nongauss.html">msd/nongauss</A></TD><TD ><A HREF = "compute_pair.html">pair</A></TD><TD ><A HREF = "compute_pair_local.html">pair/local</A></TD><TD ><A HREF = "compute_pe.html">pe (c)</A></TD><TD ><A HREF = "compute_pe_atom.html">pe/atom</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "compute_plasticity_atom.html">plasticity/atom</A></TD><TD ><A HREF = "compute_pressure.html">pressure (c)</A></TD><TD ><A HREF = "compute_property_atom.html">property/atom</A></TD><TD ><A HREF = "compute_property_local.html">property/local</A></TD><TD ><A HREF = "compute_property_molecule.html">property/molecule</A></TD><TD ><A HREF = "compute_rdf.html">rdf</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "compute_reduce.html">reduce</A></TD><TD ><A HREF = "compute_reduce.html">reduce/region</A></TD><TD ><A HREF = "compute_slice.html">slice</A></TD><TD ><A HREF = "compute_sna.html">sna/atom</A></TD><TD ><A HREF = "compute_sna.html">snad/atom</A></TD><TD ><A HREF = "compute_sna.html">snav/atom</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "compute_stress_atom.html">stress/atom</A></TD><TD ><A HREF = "compute_temp.html">temp (c)</A></TD><TD ><A HREF = "compute_temp_asphere.html">temp/asphere</A></TD><TD ><A HREF = "compute_temp_com.html">temp/com</A></TD><TD ><A HREF = "compute_temp_deform.html">temp/deform</A></TD><TD ><A HREF = "compute_temp_partial.html">temp/partial (c)</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "compute_temp_profile.html">temp/profile</A></TD><TD ><A HREF = "compute_temp_ramp.html">temp/ramp</A></TD><TD ><A HREF = "compute_temp_region.html">temp/region</A></TD><TD ><A HREF = "compute_temp_sphere.html">temp/sphere</A></TD><TD ><A HREF = "compute_ti.html">ti</A></TD><TD ><A HREF = "compute_vacf.html">vacf</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "compute_vcm_molecule.html">vcm/molecule</A></TD><TD ><A HREF = "compute_voronoi_atom.html">voronoi/atom</A>
|
||||
<TR ALIGN="center"><TD ><A HREF = "compute_angle_local.html">angle/local</A></TD><TD ><A HREF = "compute_angmom_chunk.html">angmom/chunk</A></TD><TD ><A HREF = "compute_body_local.html">body/local</A></TD><TD ><A HREF = "compute_bond_local.html">bond/local</A></TD><TD ><A HREF = "compute_centro_atom.html">centro/atom</A></TD><TD ><A HREF = "compute_chunk_atom.html">chunk/atom</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "compute_cluster_atom.html">cluster/atom</A></TD><TD ><A HREF = "compute_cna_atom.html">cna/atom</A></TD><TD ><A HREF = "compute_com.html">com</A></TD><TD ><A HREF = "compute_com_chunk.html">com/chunk</A></TD><TD ><A HREF = "compute_contact_atom.html">contact/atom</A></TD><TD ><A HREF = "compute_coord_atom.html">coord/atom</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "compute_damage_atom.html">damage/atom</A></TD><TD ><A HREF = "compute_dihedral_local.html">dihedral/local</A></TD><TD ><A HREF = "compute_dilatation_atom.html">dilatation/atom</A></TD><TD ><A HREF = "compute_displace_atom.html">displace/atom</A></TD><TD ><A HREF = "compute_erotate_asphere.html">erotate/asphere</A></TD><TD ><A HREF = "compute_erotate_rigid.html">erotate/rigid</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "compute_erotate_sphere.html">erotate/sphere</A></TD><TD ><A HREF = "compute_erotate_sphere_atom.html">erotate/sphere/atom</A></TD><TD ><A HREF = "compute_event_displace.html">event/displace</A></TD><TD ><A HREF = "compute_group_group.html">group/group</A></TD><TD ><A HREF = "compute_gyration.html">gyration</A></TD><TD ><A HREF = "compute_gyration_chunk.html">gyration/chunk</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "compute_heat_flux.html">heat/flux</A></TD><TD ><A HREF = "compute_improper_local.html">improper/local</A></TD><TD ><A HREF = "compute_inertia_chunk.html">inertia/chunk</A></TD><TD ><A HREF = "compute_ke.html">ke</A></TD><TD ><A HREF = "compute_ke_atom.html">ke/atom</A></TD><TD ><A HREF = "compute_ke_rigid.html">ke/rigid</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "compute_msd.html">msd</A></TD><TD ><A HREF = "compute_msd_chunk.html">msd/chunk</A></TD><TD ><A HREF = "compute_msd_nongauss.html">msd/nongauss</A></TD><TD ><A HREF = "compute_omega_chunk.html">omega/chunk</A></TD><TD ><A HREF = "compute_pair.html">pair</A></TD><TD ><A HREF = "compute_pair_local.html">pair/local</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "compute_pe.html">pe (c)</A></TD><TD ><A HREF = "compute_pe_atom.html">pe/atom</A></TD><TD ><A HREF = "compute_plasticity_atom.html">plasticity/atom</A></TD><TD ><A HREF = "compute_pressure.html">pressure (c)</A></TD><TD ><A HREF = "compute_property_atom.html">property/atom</A></TD><TD ><A HREF = "compute_property_local.html">property/local</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "compute_property_chunk.html">property/chunk</A></TD><TD ><A HREF = "compute_rdf.html">rdf</A></TD><TD ><A HREF = "compute_reduce.html">reduce</A></TD><TD ><A HREF = "compute_reduce.html">reduce/region</A></TD><TD ><A HREF = "compute_slice.html">slice</A></TD><TD ><A HREF = "compute_sna.html">sna/atom</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "compute_sna.html">snad/atom</A></TD><TD ><A HREF = "compute_sna.html">snav/atom</A></TD><TD ><A HREF = "compute_stress_atom.html">stress/atom</A></TD><TD ><A HREF = "compute_temp.html">temp (c)</A></TD><TD ><A HREF = "compute_temp_asphere.html">temp/asphere</A></TD><TD ><A HREF = "compute_temp_com.html">temp/com</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "compute_temp_chunk.html">temp/chunk</A></TD><TD ><A HREF = "compute_temp_deform.html">temp/deform</A></TD><TD ><A HREF = "compute_temp_partial.html">temp/partial (c)</A></TD><TD ><A HREF = "compute_temp_profile.html">temp/profile</A></TD><TD ><A HREF = "compute_temp_ramp.html">temp/ramp</A></TD><TD ><A HREF = "compute_temp_region.html">temp/region</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "compute_temp_sphere.html">temp/sphere</A></TD><TD ><A HREF = "compute_ti.html">ti</A></TD><TD ><A HREF = "compute_torque_chunk.html">torque/chunk</A></TD><TD ><A HREF = "compute_vacf.html">vacf</A></TD><TD ><A HREF = "compute_vcm_chunk.html">vcm/chunk</A></TD><TD ><A HREF = "compute_voronoi_atom.html">voronoi/atom</A>
|
||||
</TD></TR></TABLE></DIV>
|
||||
|
||||
<P>These are additional compute styles in USER packages, which can be
|
||||
@ -479,29 +491,29 @@ KOKKOS, o = USER-OMP, t = OPT.
|
||||
<TR ALIGN="center"><TD ><A HREF = "pair_none.html">none</A></TD><TD ><A HREF = "pair_hybrid.html">hybrid</A></TD><TD ><A HREF = "pair_hybrid.html">hybrid/overlay</A></TD><TD ><A HREF = "pair_adp.html">adp (o)</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "pair_airebo.html">airebo (o)</A></TD><TD ><A HREF = "pair_beck.html">beck (go)</A></TD><TD ><A HREF = "pair_body.html">body</A></TD><TD ><A HREF = "pair_bop.html">bop</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "pair_born.html">born (go)</A></TD><TD ><A HREF = "pair_born.html">born/coul/long (cgo)</A></TD><TD ><A HREF = "pair_born.html">born/coul/msm (o)</A></TD><TD ><A HREF = "pair_born.html">born/coul/wolf (go)</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "pair_brownian.html">brownian (o)</A></TD><TD ><A HREF = "pair_brownian.html">brownian/poly (o)</A></TD><TD ><A HREF = "pair_buck.html">buck (cgo)</A></TD><TD ><A HREF = "pair_buck.html">buck/coul/cut (cgo)</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "pair_buck.html">buck/coul/long (cgo)</A></TD><TD ><A HREF = "pair_buck.html">buck/coul/msm (o)</A></TD><TD ><A HREF = "pair_buck_long.html">buck/long/coul/long (o)</A></TD><TD ><A HREF = "pair_colloid.html">colloid (go)</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "pair_comb.html">comb (o)</A></TD><TD ><A HREF = "pair_comb.html">comb3</A></TD><TD ><A HREF = "pair_coul.html">coul/cut (gko)</A></TD><TD ><A HREF = "pair_coul.html">coul/debye (go)</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "pair_coul.html">coul/dsf (go)</A></TD><TD ><A HREF = "pair_coul.html">coul/long (go)</A></TD><TD ><A HREF = "pair_coul.html">coul/msm</A></TD><TD ><A HREF = "pair_coul.html">coul/wolf (o)</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "pair_dpd.html">dpd (o)</A></TD><TD ><A HREF = "pair_dpd.html">dpd/tstat (o)</A></TD><TD ><A HREF = "pair_dsmc.html">dsmc</A></TD><TD ><A HREF = "pair_eam.html">eam (cgot)</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "pair_eam.html">eam/alloy (cgot)</A></TD><TD ><A HREF = "pair_eam.html">eam/fs (cgot)</A></TD><TD ><A HREF = "pair_eim.html">eim (o)</A></TD><TD ><A HREF = "pair_gauss.html">gauss (go)</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "pair_gayberne.html">gayberne (gio)</A></TD><TD ><A HREF = "pair_gran.html">gran/hertz/history (o)</A></TD><TD ><A HREF = "pair_gran.html">gran/hooke (co)</A></TD><TD ><A HREF = "pair_gran.html">gran/hooke/history (o)</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "pair_hbond_dreiding.html">hbond/dreiding/lj (o)</A></TD><TD ><A HREF = "pair_hbond_dreiding.html">hbond/dreiding/morse (o)</A></TD><TD ><A HREF = "pair_kim.html">kim</A></TD><TD ><A HREF = "pair_lcbop.html">lcbop</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "pair_line_lj.html">line/lj (o)</A></TD><TD ><A HREF = "pair_charmm.html">lj/charmm/coul/charmm (co)</A></TD><TD ><A HREF = "pair_charmm.html">lj/charmm/coul/charmm/implicit (co)</A></TD><TD ><A HREF = "pair_charmm.html">lj/charmm/coul/long (cgio)</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "pair_charmm.html">lj/charmm/coul/msm</A></TD><TD ><A HREF = "pair_class2.html">lj/class2 (cgo)</A></TD><TD ><A HREF = "pair_class2.html">lj/class2/coul/cut (co)</A></TD><TD ><A HREF = "pair_class2.html">lj/class2/coul/long (cgo)</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "pair_lj.html">lj/cut (cgikot)</A></TD><TD ><A HREF = "pair_lj.html">lj/cut/coul/cut (cgko)</A></TD><TD ><A HREF = "pair_lj.html">lj/cut/coul/debye (cgo)</A></TD><TD ><A HREF = "pair_lj.html">lj/cut/coul/dsf (go)</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "pair_lj.html">lj/cut/coul/long (cgikot)</A></TD><TD ><A HREF = "pair_lj.html">lj/cut/coul/msm (go)</A></TD><TD ><A HREF = "pair_dipole.html">lj/cut/dipole/cut (go)</A></TD><TD ><A HREF = "pair_dipole.html">lj/cut/dipole/long</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "pair_lj.html">lj/cut/tip4p/cut (o)</A></TD><TD ><A HREF = "pair_lj.html">lj/cut/tip4p/long (ot)</A></TD><TD ><A HREF = "pair_lj_expand.html">lj/expand (cgo)</A></TD><TD ><A HREF = "pair_gromacs.html">lj/gromacs (cgo)</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "pair_gromacs.html">lj/gromacs/coul/gromacs (co)</A></TD><TD ><A HREF = "pair_lj_long.html">lj/long/coul/long (o)</A></TD><TD ><A HREF = "pair_dipole.html">lj/long/dipole/long</A></TD><TD ><A HREF = "pair_lj_long.html">lj/long/tip4p/long</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "pair_lj_smooth.html">lj/smooth (co)</A></TD><TD ><A HREF = "pair_lj_smooth_linear.html">lj/smooth/linear (o)</A></TD><TD ><A HREF = "pair_lj96.html">lj96/cut (cgo)</A></TD><TD ><A HREF = "pair_lubricate.html">lubricate (o)</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "pair_lubricate.html">lubricate/poly (o)</A></TD><TD ><A HREF = "pair_lubricateU.html">lubricateU</A></TD><TD ><A HREF = "pair_lubricateU.html">lubricateU/poly</A></TD><TD ><A HREF = "pair_meam.html">meam (o)</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "pair_mie.html">mie/cut (o)</A></TD><TD ><A HREF = "pair_morse.html">morse (cgot)</A></TD><TD ><A HREF = "pair_nb3b_harmonic.html">nb3b/harmonic (o)</A></TD><TD ><A HREF = "pair_nm.html">nm/cut (o)</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "pair_nm.html">nm/cut/coul/cut (o)</A></TD><TD ><A HREF = "pair_nm.html">nm/cut/coul/long (o)</A></TD><TD ><A HREF = "pair_peri.html">peri/eps</A></TD><TD ><A HREF = "pair_peri.html">peri/lps (o)</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "pair_peri.html">peri/pmb (o)</A></TD><TD ><A HREF = "pair_peri.html">peri/ves</A></TD><TD ><A HREF = "pair_reax.html">reax</A></TD><TD ><A HREF = "pair_airebo.html">rebo (o)</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "pair_resquared.html">resquared (go)</A></TD><TD ><A HREF = "pair_snap.html">snap</A></TD><TD ><A HREF = "pair_soft.html">soft (go)</A></TD><TD ><A HREF = "pair_sw.html">sw (cgo)</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "pair_table.html">table (gko)</A></TD><TD ><A HREF = "pair_tersoff.html">tersoff (co)</A></TD><TD ><A HREF = "pair_tersoff_mod.html">tersoff/mod (o)</A></TD><TD ><A HREF = "pair_tersoff_zbl.html">tersoff/zbl (o)</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "pair_coul.html">tip4p/cut (o)</A></TD><TD ><A HREF = "pair_coul.html">tip4p/long (o)</A></TD><TD ><A HREF = "pair_tri_lj.html">tri/lj (o)</A></TD><TD ><A HREF = "pair_yukawa.html">yukawa (go)</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "pair_yukawa_colloid.html">yukawa/colloid (go)</A></TD><TD ><A HREF = "pair_zbl.html">zbl (o)</A>
|
||||
<TR ALIGN="center"><TD ><A HREF = "pair_brownian.html">brownian (o)</A></TD><TD ><A HREF = "pair_brownian.html">brownian/poly (o)</A></TD><TD ><A HREF = "pair_buck.html">buck (cgko)</A></TD><TD ><A HREF = "pair_buck.html">buck/coul/cut (cgko)</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "pair_buck.html">buck/coul/long (cgko)</A></TD><TD ><A HREF = "pair_buck.html">buck/coul/msm (o)</A></TD><TD ><A HREF = "pair_buck_long.html">buck/long/coul/long (o)</A></TD><TD ><A HREF = "pair_colloid.html">colloid (go)</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "pair_comb.html">comb (o)</A></TD><TD ><A HREF = "pair_comb.html">comb3</A></TD><TD ><A HREF = "pair_coul.html">coul/cut (gko)</A></TD><TD ><A HREF = "pair_coul.html">coul/debye (gko)</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "pair_coul.html">coul/dsf (gko)</A></TD><TD ><A HREF = "pair_coul.html">coul/long (gko)</A></TD><TD ><A HREF = "pair_coul.html">coul/msm</A></TD><TD ><A HREF = "pair_coul.html">coul/streitz</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "pair_coul.html">coul/wolf (ko)</A></TD><TD ><A HREF = "pair_dpd.html">dpd (o)</A></TD><TD ><A HREF = "pair_dpd.html">dpd/tstat (o)</A></TD><TD ><A HREF = "pair_dsmc.html">dsmc</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "pair_eam.html">eam (cgkot)</A></TD><TD ><A HREF = "pair_eam.html">eam/alloy (cgot)</A></TD><TD ><A HREF = "pair_eam.html">eam/fs (cgot)</A></TD><TD ><A HREF = "pair_eim.html">eim (o)</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "pair_gauss.html">gauss (go)</A></TD><TD ><A HREF = "pair_gayberne.html">gayberne (gio)</A></TD><TD ><A HREF = "pair_gran.html">gran/hertz/history (o)</A></TD><TD ><A HREF = "pair_gran.html">gran/hooke (co)</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "pair_gran.html">gran/hooke/history (o)</A></TD><TD ><A HREF = "pair_hbond_dreiding.html">hbond/dreiding/lj (o)</A></TD><TD ><A HREF = "pair_hbond_dreiding.html">hbond/dreiding/morse (o)</A></TD><TD ><A HREF = "pair_kim.html">kim</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "pair_lcbop.html">lcbop</A></TD><TD ><A HREF = "pair_line_lj.html">line/lj (o)</A></TD><TD ><A HREF = "pair_charmm.html">lj/charmm/coul/charmm (cko)</A></TD><TD ><A HREF = "pair_charmm.html">lj/charmm/coul/charmm/implicit (cko)</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "pair_charmm.html">lj/charmm/coul/long (cgiko)</A></TD><TD ><A HREF = "pair_charmm.html">lj/charmm/coul/msm</A></TD><TD ><A HREF = "pair_class2.html">lj/class2 (cgko)</A></TD><TD ><A HREF = "pair_class2.html">lj/class2/coul/cut (cko)</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "pair_class2.html">lj/class2/coul/long (cgko)</A></TD><TD ><A HREF = "pair_lj.html">lj/cut (cgikot)</A></TD><TD ><A HREF = "pair_lj.html">lj/cut/coul/cut (cgko)</A></TD><TD ><A HREF = "pair_lj.html">lj/cut/coul/debye (cgko)</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "pair_lj.html">lj/cut/coul/dsf (gko)</A></TD><TD ><A HREF = "pair_lj.html">lj/cut/coul/long (cgikot)</A></TD><TD ><A HREF = "pair_lj.html">lj/cut/coul/msm (go)</A></TD><TD ><A HREF = "pair_dipole.html">lj/cut/dipole/cut (go)</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "pair_dipole.html">lj/cut/dipole/long</A></TD><TD ><A HREF = "pair_lj.html">lj/cut/tip4p/cut (o)</A></TD><TD ><A HREF = "pair_lj.html">lj/cut/tip4p/long (ot)</A></TD><TD ><A HREF = "pair_lj_expand.html">lj/expand (cgko)</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "pair_gromacs.html">lj/gromacs (cgko)</A></TD><TD ><A HREF = "pair_gromacs.html">lj/gromacs/coul/gromacs (cko)</A></TD><TD ><A HREF = "pair_lj_long.html">lj/long/coul/long (o)</A></TD><TD ><A HREF = "pair_dipole.html">lj/long/dipole/long</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "pair_lj_long.html">lj/long/tip4p/long</A></TD><TD ><A HREF = "pair_lj_smooth.html">lj/smooth (co)</A></TD><TD ><A HREF = "pair_lj_smooth_linear.html">lj/smooth/linear (o)</A></TD><TD ><A HREF = "pair_lj96.html">lj96/cut (cgo)</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "pair_lubricate.html">lubricate (o)</A></TD><TD ><A HREF = "pair_lubricate.html">lubricate/poly (o)</A></TD><TD ><A HREF = "pair_lubricateU.html">lubricateU</A></TD><TD ><A HREF = "pair_lubricateU.html">lubricateU/poly</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "pair_meam.html">meam (o)</A></TD><TD ><A HREF = "pair_mie.html">mie/cut (o)</A></TD><TD ><A HREF = "pair_morse.html">morse (cgot)</A></TD><TD ><A HREF = "pair_nb3b_harmonic.html">nb3b/harmonic (o)</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "pair_nm.html">nm/cut (o)</A></TD><TD ><A HREF = "pair_nm.html">nm/cut/coul/cut (o)</A></TD><TD ><A HREF = "pair_nm.html">nm/cut/coul/long (o)</A></TD><TD ><A HREF = "pair_peri.html">peri/eps</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "pair_peri.html">peri/lps (o)</A></TD><TD ><A HREF = "pair_peri.html">peri/pmb (o)</A></TD><TD ><A HREF = "pair_peri.html">peri/ves</A></TD><TD ><A HREF = "pair_reax.html">reax</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "pair_airebo.html">rebo (o)</A></TD><TD ><A HREF = "pair_resquared.html">resquared (go)</A></TD><TD ><A HREF = "pair_snap.html">snap</A></TD><TD ><A HREF = "pair_soft.html">soft (go)</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "pair_sw.html">sw (cgo)</A></TD><TD ><A HREF = "pair_table.html">table (gko)</A></TD><TD ><A HREF = "pair_tersoff.html">tersoff (co)</A></TD><TD ><A HREF = "pair_tersoff_mod.html">tersoff/mod (o)</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "pair_tersoff_zbl.html">tersoff/zbl (o)</A></TD><TD ><A HREF = "pair_coul.html">tip4p/cut (o)</A></TD><TD ><A HREF = "pair_coul.html">tip4p/long (o)</A></TD><TD ><A HREF = "pair_tri_lj.html">tri/lj (o)</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "pair_yukawa.html">yukawa (go)</A></TD><TD ><A HREF = "pair_yukawa_colloid.html">yukawa/colloid (go)</A></TD><TD ><A HREF = "pair_zbl.html">zbl (o)</A>
|
||||
</TD></TR></TABLE></DIV>
|
||||
|
||||
<P>These are additional pair styles in USER packages, which can be used
|
||||
@ -512,11 +524,11 @@ package</A>.
|
||||
<TR ALIGN="center"><TD ><A HREF = "pair_awpmd.html">awpmd/cut</A></TD><TD ><A HREF = "pair_lj_soft.html">coul/cut/soft (o)</A></TD><TD ><A HREF = "pair_coul_diel.html">coul/diel (o)</A></TD><TD ><A HREF = "pair_lj_soft.html">coul/long/soft (o)</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "pair_eam.html">eam/cd (o)</A></TD><TD ><A HREF = "pair_edip.html">edip (o)</A></TD><TD ><A HREF = "pair_eff.html">eff/cut</A></TD><TD ><A HREF = "pair_gauss.html">gauss/cut</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "pair_list.html">list</A></TD><TD ><A HREF = "pair_charmm.html">lj/charmm/coul/long/soft (o)</A></TD><TD ><A HREF = "pair_lj_soft.html">lj/cut/coul/cut/soft (o)</A></TD><TD ><A HREF = "pair_lj_soft.html">lj/cut/coul/long/soft (o)</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "pair_dipole.html">lj/cut/dipole/sf (go)</A></TD><TD ><A HREF = "pair_lj_soft.html">lj/cut/soft (o)</A></TD><TD ><A HREF = "pair_lj_soft.html">lj/cut/tip4p/long/soft (o)</A></TD><TD ><A HREF = "pair_sdk.html">lj/sdk (go)</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "pair_dipole.html">lj/cut/dipole/sf (go)</A></TD><TD ><A HREF = "pair_lj_soft.html">lj/cut/soft (o)</A></TD><TD ><A HREF = "pair_lj_soft.html">lj/cut/tip4p/long/soft (o)</A></TD><TD ><A HREF = "pair_sdk.html">lj/sdk (gko)</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "pair_sdk.html">lj/sdk/coul/long (go)</A></TD><TD ><A HREF = "pair_sdk.html">lj/sdk/coul/msm (o)</A></TD><TD ><A HREF = "pair_lj_sf.html">lj/sf (o)</A></TD><TD ><A HREF = "pair_meam_spline.html">meam/spline</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "pair_meam_sw_spline.html">meam/sw/spline</A></TD><TD ><A HREF = "pair_reax_c.html">reax/c</A></TD><TD ><A HREF = "pair_sph_heatconduction.html">sph/heatconduction</A></TD><TD ><A HREF = "pair_sph_idealgas.html">sph/idealgas</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "pair_sph_lj.html">sph/lj</A></TD><TD ><A HREF = "pair_sph_rhosum.html">sph/rhosum</A></TD><TD ><A HREF = "pair_sph_taitwater.html">sph/taitwater</A></TD><TD ><A HREF = "pair_sph_taitwater_morris.html">sph/taitwater/morris</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "pair_srp.html">srp</A></TD><TD ><A HREF = "pair_tersoff.html">tersoff/table (o)</A></TD><TD ><A HREF = "pair_lj_soft.html">tip4p/long/soft (o)</A>
|
||||
<TR ALIGN="center"><TD ><A HREF = "pair_meam_sw_spline.html">meam/sw/spline</A></TD><TD ><A HREF = "pair_quip.html">quip</A></TD><TD ><A HREF = "pair_reax_c.html">reax/c</A></TD><TD ><A HREF = "pair_sph_heatconduction.html">sph/heatconduction</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "pair_sph_idealgas.html">sph/idealgas</A></TD><TD ><A HREF = "pair_sph_lj.html">sph/lj</A></TD><TD ><A HREF = "pair_sph_rhosum.html">sph/rhosum</A></TD><TD ><A HREF = "pair_sph_taitwater.html">sph/taitwater</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "pair_sph_taitwater_morris.html">sph/taitwater/morris</A></TD><TD ><A HREF = "pair_srp.html">srp</A></TD><TD ><A HREF = "pair_tersoff.html">tersoff/table (o)</A></TD><TD ><A HREF = "pair_lj_soft.html">tip4p/long/soft (o)</A>
|
||||
</TD></TR></TABLE></DIV>
|
||||
|
||||
<HR>
|
||||
@ -532,8 +544,8 @@ letters in parenthesis: c = USER-CUDA, g = GPU, i = USER-INTEL, k =
|
||||
KOKKOS, o = USER-OMP, t = OPT.
|
||||
</P>
|
||||
<DIV ALIGN=center><TABLE BORDER=1 >
|
||||
<TR ALIGN="center"><TD ><A HREF = "bond_none.html">none</A></TD><TD ><A HREF = "bond_hybrid.html">hybrid</A></TD><TD ><A HREF = "bond_class2.html">class2 (o)</A></TD><TD ><A HREF = "bond_fene.html">fene (o)</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "bond_fene_expand.html">fene/expand (o)</A></TD><TD ><A HREF = "bond_harmonic.html">harmonic (o)</A></TD><TD ><A HREF = "bond_morse.html">morse (o)</A></TD><TD ><A HREF = "bond_nonlinear.html">nonlinear (o)</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "bond_none.html">none</A></TD><TD ><A HREF = "bond_hybrid.html">hybrid</A></TD><TD ><A HREF = "bond_class2.html">class2 (o)</A></TD><TD ><A HREF = "bond_fene.html">fene (ko)</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "bond_fene_expand.html">fene/expand (o)</A></TD><TD ><A HREF = "bond_harmonic.html">harmonic (ko)</A></TD><TD ><A HREF = "bond_morse.html">morse (o)</A></TD><TD ><A HREF = "bond_nonlinear.html">nonlinear (o)</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "bond_quartic.html">quartic (o)</A></TD><TD ><A HREF = "bond_table.html">table (o)</A>
|
||||
</TD></TR></TABLE></DIV>
|
||||
|
||||
@ -558,9 +570,9 @@ letters in parenthesis: c = USER-CUDA, g = GPU, i = USER-INTEL, k =
|
||||
KOKKOS, o = USER-OMP, t = OPT.
|
||||
</P>
|
||||
<DIV ALIGN=center><TABLE BORDER=1 >
|
||||
<TR ALIGN="center"><TD ><A HREF = "angle_none.html">none</A></TD><TD ><A HREF = "angle_hybrid.html">hybrid</A></TD><TD ><A HREF = "angle_charmm.html">charmm (o)</A></TD><TD ><A HREF = "angle_class2.html">class2 (o)</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "angle_none.html">none</A></TD><TD ><A HREF = "angle_hybrid.html">hybrid</A></TD><TD ><A HREF = "angle_charmm.html">charmm (ko)</A></TD><TD ><A HREF = "angle_class2.html">class2 (o)</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "angle_cosine.html">cosine (o)</A></TD><TD ><A HREF = "angle_cosine_delta.html">cosine/delta (o)</A></TD><TD ><A HREF = "angle_cosine_periodic.html">cosine/periodic (o)</A></TD><TD ><A HREF = "angle_cosine_squared.html">cosine/squared (o)</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "angle_harmonic.html">harmonic (o)</A></TD><TD ><A HREF = "angle_table.html">table (o)</A>
|
||||
<TR ALIGN="center"><TD ><A HREF = "angle_harmonic.html">harmonic (ko)</A></TD><TD ><A HREF = "angle_table.html">table (o)</A>
|
||||
</TD></TR></TABLE></DIV>
|
||||
|
||||
<P>These are additional angle styles in USER packages, which can be used
|
||||
@ -585,8 +597,8 @@ letters in parenthesis: c = USER-CUDA, g = GPU, i = USER-INTEL, k =
|
||||
KOKKOS, o = USER-OMP, t = OPT.
|
||||
</P>
|
||||
<DIV ALIGN=center><TABLE BORDER=1 >
|
||||
<TR ALIGN="center"><TD ><A HREF = "dihedral_none.html">none</A></TD><TD ><A HREF = "dihedral_hybrid.html">hybrid</A></TD><TD ><A HREF = "dihedral_charmm.html">charmm (o)</A></TD><TD ><A HREF = "dihedral_class2.html">class2 (o)</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "dihedral_harmonic.html">harmonic (o)</A></TD><TD ><A HREF = "dihedral_helix.html">helix (o)</A></TD><TD ><A HREF = "dihedral_multi_harmonic.html">multi/harmonic (o)</A></TD><TD ><A HREF = "dihedral_opls.html">opls (o)</A>
|
||||
<TR ALIGN="center"><TD ><A HREF = "dihedral_none.html">none</A></TD><TD ><A HREF = "dihedral_hybrid.html">hybrid</A></TD><TD ><A HREF = "dihedral_charmm.html">charmm (ko)</A></TD><TD ><A HREF = "dihedral_class2.html">class2 (o)</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "dihedral_harmonic.html">harmonic (o)</A></TD><TD ><A HREF = "dihedral_helix.html">helix (o)</A></TD><TD ><A HREF = "dihedral_multi_harmonic.html">multi/harmonic (o)</A></TD><TD ><A HREF = "dihedral_opls.html">opls (ko)</A>
|
||||
</TD></TR></TABLE></DIV>
|
||||
|
||||
<P>These are additional dihedral styles in USER packages, which can be
|
||||
@ -612,7 +624,7 @@ KOKKOS, o = USER-OMP, t = OPT.
|
||||
</P>
|
||||
<DIV ALIGN=center><TABLE BORDER=1 >
|
||||
<TR ALIGN="center"><TD ><A HREF = "improper_none.html">none</A></TD><TD ><A HREF = "improper_hybrid.html">hybrid</A></TD><TD ><A HREF = "improper_class2.html">class2 (o)</A></TD><TD ><A HREF = "improper_cvff.html">cvff (o)</A></TD></TR>
|
||||
<TR ALIGN="center"><TD ><A HREF = "improper_harmonic.html">harmonic (o)</A></TD><TD ><A HREF = "improper_umbrella.html">umbrella (o)</A>
|
||||
<TR ALIGN="center"><TD ><A HREF = "improper_harmonic.html">harmonic (ko)</A></TD><TD ><A HREF = "improper_umbrella.html">umbrella (o)</A>
|
||||
</TD></TR></TABLE></DIV>
|
||||
|
||||
<P>These are additional improper styles in USER packages, which can be
|
||||
|
||||
@ -82,11 +82,12 @@ file names or user-chosen ID strings.
|
||||
|
||||
Here is how each line in the input script is parsed by LAMMPS:
|
||||
|
||||
(1) If the last printable character on the line is a "&" character
|
||||
(with no surrounding quotes), the command is assumed to continue on
|
||||
the next line. The next line is concatenated to the previous line by
|
||||
removing the "&" character and newline. This allows long commands to
|
||||
be continued across two or more lines.
|
||||
(1) If the last printable character on the line is a "&" character,
|
||||
the command is assumed to continue on the next line. The next line is
|
||||
concatenated to the previous line by removing the "&" character and
|
||||
line break. This allows long commands to be continued across two or
|
||||
more lines. See the discussion of triple quotes in (6) for how to
|
||||
continue a command across multiple line without using "&" characters.
|
||||
|
||||
(2) All characters from the first "#" character onward are treated as
|
||||
comment and discarded. See an exception in (6). Note that a
|
||||
@ -152,27 +153,38 @@ underscores, or punctuation characters.
|
||||
line are arguments.
|
||||
|
||||
(6) If you want text with spaces to be treated as a single argument,
|
||||
it can be enclosed in either double or single quotes. A long single
|
||||
argument enclosed in quotes can even span multiple lines if the "&"
|
||||
character is used, as described above. E.g.
|
||||
it can be enclosed in either single or double or triple quotes. A
|
||||
long single argument enclosed in single or double quotes can span
|
||||
multiple lines if the "&" character is used, as described above. When
|
||||
the lines are concatenated together (and the "&" characters and line
|
||||
breaks removed), the text will become a single line. If you want
|
||||
multiple lines of an argument to retain their line breaks, the text
|
||||
can be enclosed in triple quotes, in which case "&" characters are not
|
||||
needed. For example:
|
||||
|
||||
print "Volume = $v"
|
||||
print 'Volume = $v'
|
||||
if "${steps} > 1000" then quit
|
||||
variable a string "red green blue &
|
||||
purple orange cyan"
|
||||
if "${steps} > 1000" then quit :pre
|
||||
print """
|
||||
System volume = $v
|
||||
System temperature = $t
|
||||
""" :pre
|
||||
|
||||
The quotes are removed when the single argument is stored internally.
|
||||
In each case, the single, double, or triple quotes are removed when
|
||||
the single argument they enclose is stored internally.
|
||||
|
||||
See the "dump modify format"_dump_modify.html or "print"_print.html or
|
||||
"if"_if.html commands for examples. A "#" or "$" character that is
|
||||
between quotes will not be treated as a comment indicator in (2) or
|
||||
substituted for as a variable in (3).
|
||||
See the "dump modify format"_dump_modify.html, "print"_print.html,
|
||||
"if"_if.html, and "python"_python.html commands for examples.
|
||||
|
||||
A "#" or "$" character that is between quotes will not be treated as a
|
||||
comment indicator in (2) or substituted for as a variable in (3).
|
||||
|
||||
IMPORTANT NOTE: If the argument is itself a command that requires a
|
||||
quoted argument (e.g. using a "print"_print.html command as part of an
|
||||
"if"_if.html or "run every"_run.html command), then the double and
|
||||
single quotes can be nested in the usual manner. See the doc pages
|
||||
"if"_if.html or "run every"_run.html command), then single, double, or
|
||||
triple quotes can be nested in the usual manner. See the doc pages
|
||||
for those commands for examples. Only one of level of nesting is
|
||||
allowed, but that should be sufficient for most use cases.
|
||||
|
||||
@ -372,6 +384,7 @@ in the command's documentation.
|
||||
"compute"_compute.html,
|
||||
"compute_modify"_compute_modify.html,
|
||||
"create_atoms"_create_atoms.html,
|
||||
"create_bonds"_create_bonds.html,
|
||||
"create_box"_create_box.html,
|
||||
"delete_atoms"_delete_atoms.html,
|
||||
"delete_bonds"_delete_bonds.html,
|
||||
@ -417,6 +430,7 @@ in the command's documentation.
|
||||
"prd"_prd.html,
|
||||
"print"_print.html,
|
||||
"processors"_processors.html,
|
||||
"python"_python.html,
|
||||
"quit"_quit.html,
|
||||
"read_data"_read_data.html,
|
||||
"read_dump"_read_dump.html,
|
||||
@ -468,8 +482,10 @@ g = GPU, i = USER-INTEL, k = KOKKOS, o = USER-OMP, t = OPT.
|
||||
"adapt"_fix_adapt.html,
|
||||
"addforce (c)"_fix_addforce.html,
|
||||
"append/atoms"_fix_append_atoms.html,
|
||||
"atom/swap"_fix_atom_swap.html,
|
||||
"aveforce (c)"_fix_aveforce.html,
|
||||
"ave/atom"_fix_ave_atom.html,
|
||||
"ave/chunk"_fix_ave_chunk.html,
|
||||
"ave/correlate"_fix_ave_correlate.html,
|
||||
"ave/histo"_fix_ave_histo.html,
|
||||
"ave/spatial"_fix_ave_spatial.html,
|
||||
@ -554,8 +570,10 @@ g = GPU, i = USER-INTEL, k = KOKKOS, o = USER-OMP, t = OPT.
|
||||
"store/force"_fix_store_force.html,
|
||||
"store/state"_fix_store_state.html,
|
||||
"temp/berendsen (c)"_fix_temp_berendsen.html,
|
||||
"temp/csld"_fix_temp_csvr.html,
|
||||
"temp/csvr"_fix_temp_csvr.html,
|
||||
"temp/rescale (c)"_fix_temp_rescale.html,
|
||||
"tfmc"_fix_tfmc.html,
|
||||
"thermal/conductivity"_fix_thermal_conductivity.html,
|
||||
"tmd"_fix_tmd.html,
|
||||
"ttm"_fix_ttm.html,
|
||||
@ -608,7 +626,8 @@ package"_Section_start.html#start_3.
|
||||
"smd"_fix_smd.html,
|
||||
"temp/rescale/eff"_fix_temp_rescale_eff.html,
|
||||
"ti/rs"_fix_ti_rs.html,
|
||||
"ti/spring"_fix_ti_spring.html :tb(c=6,ea=c)
|
||||
"ti/spring"_fix_ti_spring.html,
|
||||
"ttm/mod"_fix_ttm.html :tb(c=6,ea=c)
|
||||
|
||||
:line
|
||||
|
||||
@ -623,14 +642,15 @@ letters in parenthesis: c = USER-CUDA, g = GPU, i = USER-INTEL, k =
|
||||
KOKKOS, o = USER-OMP, t = OPT.
|
||||
|
||||
"angle/local"_compute_angle_local.html,
|
||||
"atom/molecule"_compute_atom_molecule.html,
|
||||
"angmom/chunk"_compute_angmom_chunk.html,
|
||||
"body/local"_compute_body_local.html,
|
||||
"bond/local"_compute_bond_local.html,
|
||||
"centro/atom"_compute_centro_atom.html,
|
||||
"chunk/atom"_compute_chunk_atom.html,
|
||||
"cluster/atom"_compute_cluster_atom.html,
|
||||
"cna/atom"_compute_cna_atom.html,
|
||||
"com"_compute_com.html,
|
||||
"com/molecule"_compute_com_molecule.html,
|
||||
"com/chunk"_compute_com_chunk.html,
|
||||
"contact/atom"_compute_contact_atom.html,
|
||||
"coord/atom"_compute_coord_atom.html,
|
||||
"damage/atom"_compute_damage_atom.html,
|
||||
@ -644,16 +664,17 @@ KOKKOS, o = USER-OMP, t = OPT.
|
||||
"event/displace"_compute_event_displace.html,
|
||||
"group/group"_compute_group_group.html,
|
||||
"gyration"_compute_gyration.html,
|
||||
"gyration/molecule"_compute_gyration_molecule.html,
|
||||
"gyration/chunk"_compute_gyration_chunk.html,
|
||||
"heat/flux"_compute_heat_flux.html,
|
||||
"improper/local"_compute_improper_local.html,
|
||||
"inertia/molecule"_compute_inertia_molecule.html,
|
||||
"inertia/chunk"_compute_inertia_chunk.html,
|
||||
"ke"_compute_ke.html,
|
||||
"ke/atom"_compute_ke_atom.html,
|
||||
"ke/rigid"_compute_ke_rigid.html,
|
||||
"msd"_compute_msd.html,
|
||||
"msd/molecule"_compute_msd_molecule.html,
|
||||
"msd/chunk"_compute_msd_chunk.html,
|
||||
"msd/nongauss"_compute_msd_nongauss.html,
|
||||
"omega/chunk"_compute_omega_chunk.html,
|
||||
"pair"_compute_pair.html,
|
||||
"pair/local"_compute_pair_local.html,
|
||||
"pe (c)"_compute_pe.html,
|
||||
@ -662,7 +683,7 @@ KOKKOS, o = USER-OMP, t = OPT.
|
||||
"pressure (c)"_compute_pressure.html,
|
||||
"property/atom"_compute_property_atom.html,
|
||||
"property/local"_compute_property_local.html,
|
||||
"property/molecule"_compute_property_molecule.html,
|
||||
"property/chunk"_compute_property_chunk.html,
|
||||
"rdf"_compute_rdf.html,
|
||||
"reduce"_compute_reduce.html,
|
||||
"reduce/region"_compute_reduce.html,
|
||||
@ -674,6 +695,7 @@ KOKKOS, o = USER-OMP, t = OPT.
|
||||
"temp (c)"_compute_temp.html,
|
||||
"temp/asphere"_compute_temp_asphere.html,
|
||||
"temp/com"_compute_temp_com.html,
|
||||
"temp/chunk"_compute_temp_chunk.html,
|
||||
"temp/deform"_compute_temp_deform.html,
|
||||
"temp/partial (c)"_compute_temp_partial.html,
|
||||
"temp/profile"_compute_temp_profile.html,
|
||||
@ -681,8 +703,9 @@ KOKKOS, o = USER-OMP, t = OPT.
|
||||
"temp/region"_compute_temp_region.html,
|
||||
"temp/sphere"_compute_temp_sphere.html,
|
||||
"ti"_compute_ti.html,
|
||||
"torque/chunk"_compute_torque_chunk.html,
|
||||
"vacf"_compute_vacf.html,
|
||||
"vcm/molecule"_compute_vcm_molecule.html,
|
||||
"vcm/chunk"_compute_vcm_chunk.html,
|
||||
"voronoi/atom"_compute_voronoi_atom.html :tb(c=6,ea=c)
|
||||
|
||||
These are additional compute styles in USER packages, which can be
|
||||
@ -728,24 +751,25 @@ KOKKOS, o = USER-OMP, t = OPT.
|
||||
"born/coul/wolf (go)"_pair_born.html,
|
||||
"brownian (o)"_pair_brownian.html,
|
||||
"brownian/poly (o)"_pair_brownian.html,
|
||||
"buck (cgo)"_pair_buck.html,
|
||||
"buck/coul/cut (cgo)"_pair_buck.html,
|
||||
"buck/coul/long (cgo)"_pair_buck.html,
|
||||
"buck (cgko)"_pair_buck.html,
|
||||
"buck/coul/cut (cgko)"_pair_buck.html,
|
||||
"buck/coul/long (cgko)"_pair_buck.html,
|
||||
"buck/coul/msm (o)"_pair_buck.html,
|
||||
"buck/long/coul/long (o)"_pair_buck_long.html,
|
||||
"colloid (go)"_pair_colloid.html,
|
||||
"comb (o)"_pair_comb.html,
|
||||
"comb3"_pair_comb.html,
|
||||
"coul/cut (gko)"_pair_coul.html,
|
||||
"coul/debye (go)"_pair_coul.html,
|
||||
"coul/dsf (go)"_pair_coul.html,
|
||||
"coul/long (go)"_pair_coul.html,
|
||||
"coul/debye (gko)"_pair_coul.html,
|
||||
"coul/dsf (gko)"_pair_coul.html,
|
||||
"coul/long (gko)"_pair_coul.html,
|
||||
"coul/msm"_pair_coul.html,
|
||||
"coul/wolf (o)"_pair_coul.html,
|
||||
"coul/streitz"_pair_coul.html,
|
||||
"coul/wolf (ko)"_pair_coul.html,
|
||||
"dpd (o)"_pair_dpd.html,
|
||||
"dpd/tstat (o)"_pair_dpd.html,
|
||||
"dsmc"_pair_dsmc.html,
|
||||
"eam (cgot)"_pair_eam.html,
|
||||
"eam (cgkot)"_pair_eam.html,
|
||||
"eam/alloy (cgot)"_pair_eam.html,
|
||||
"eam/fs (cgot)"_pair_eam.html,
|
||||
"eim (o)"_pair_eim.html,
|
||||
@ -759,26 +783,26 @@ KOKKOS, o = USER-OMP, t = OPT.
|
||||
"kim"_pair_kim.html,
|
||||
"lcbop"_pair_lcbop.html,
|
||||
"line/lj (o)"_pair_line_lj.html,
|
||||
"lj/charmm/coul/charmm (co)"_pair_charmm.html,
|
||||
"lj/charmm/coul/charmm/implicit (co)"_pair_charmm.html,
|
||||
"lj/charmm/coul/long (cgio)"_pair_charmm.html,
|
||||
"lj/charmm/coul/charmm (cko)"_pair_charmm.html,
|
||||
"lj/charmm/coul/charmm/implicit (cko)"_pair_charmm.html,
|
||||
"lj/charmm/coul/long (cgiko)"_pair_charmm.html,
|
||||
"lj/charmm/coul/msm"_pair_charmm.html,
|
||||
"lj/class2 (cgo)"_pair_class2.html,
|
||||
"lj/class2/coul/cut (co)"_pair_class2.html,
|
||||
"lj/class2/coul/long (cgo)"_pair_class2.html,
|
||||
"lj/class2 (cgko)"_pair_class2.html,
|
||||
"lj/class2/coul/cut (cko)"_pair_class2.html,
|
||||
"lj/class2/coul/long (cgko)"_pair_class2.html,
|
||||
"lj/cut (cgikot)"_pair_lj.html,
|
||||
"lj/cut/coul/cut (cgko)"_pair_lj.html,
|
||||
"lj/cut/coul/debye (cgo)"_pair_lj.html,
|
||||
"lj/cut/coul/dsf (go)"_pair_lj.html,
|
||||
"lj/cut/coul/debye (cgko)"_pair_lj.html,
|
||||
"lj/cut/coul/dsf (gko)"_pair_lj.html,
|
||||
"lj/cut/coul/long (cgikot)"_pair_lj.html,
|
||||
"lj/cut/coul/msm (go)"_pair_lj.html,
|
||||
"lj/cut/dipole/cut (go)"_pair_dipole.html,
|
||||
"lj/cut/dipole/long"_pair_dipole.html,
|
||||
"lj/cut/tip4p/cut (o)"_pair_lj.html,
|
||||
"lj/cut/tip4p/long (ot)"_pair_lj.html,
|
||||
"lj/expand (cgo)"_pair_lj_expand.html,
|
||||
"lj/gromacs (cgo)"_pair_gromacs.html,
|
||||
"lj/gromacs/coul/gromacs (co)"_pair_gromacs.html,
|
||||
"lj/expand (cgko)"_pair_lj_expand.html,
|
||||
"lj/gromacs (cgko)"_pair_gromacs.html,
|
||||
"lj/gromacs/coul/gromacs (cko)"_pair_gromacs.html,
|
||||
"lj/long/coul/long (o)"_pair_lj_long.html,
|
||||
"lj/long/dipole/long"_pair_dipole.html,
|
||||
"lj/long/tip4p/long"_pair_lj_long.html,
|
||||
@ -836,12 +860,13 @@ package"_Section_start.html#start_3.
|
||||
"lj/cut/dipole/sf (go)"_pair_dipole.html,
|
||||
"lj/cut/soft (o)"_pair_lj_soft.html,
|
||||
"lj/cut/tip4p/long/soft (o)"_pair_lj_soft.html,
|
||||
"lj/sdk (go)"_pair_sdk.html,
|
||||
"lj/sdk (gko)"_pair_sdk.html,
|
||||
"lj/sdk/coul/long (go)"_pair_sdk.html,
|
||||
"lj/sdk/coul/msm (o)"_pair_sdk.html,
|
||||
"lj/sf (o)"_pair_lj_sf.html,
|
||||
"meam/spline"_pair_meam_spline.html,
|
||||
"meam/sw/spline"_pair_meam_sw_spline.html,
|
||||
"quip"_pair_quip.html,
|
||||
"reax/c"_pair_reax_c.html,
|
||||
"sph/heatconduction"_pair_sph_heatconduction.html,
|
||||
"sph/idealgas"_pair_sph_idealgas.html,
|
||||
@ -868,9 +893,9 @@ KOKKOS, o = USER-OMP, t = OPT.
|
||||
"none"_bond_none.html,
|
||||
"hybrid"_bond_hybrid.html,
|
||||
"class2 (o)"_bond_class2.html,
|
||||
"fene (o)"_bond_fene.html,
|
||||
"fene (ko)"_bond_fene.html,
|
||||
"fene/expand (o)"_bond_fene_expand.html,
|
||||
"harmonic (o)"_bond_harmonic.html,
|
||||
"harmonic (ko)"_bond_harmonic.html,
|
||||
"morse (o)"_bond_morse.html,
|
||||
"nonlinear (o)"_bond_nonlinear.html,
|
||||
"quartic (o)"_bond_quartic.html,
|
||||
@ -897,13 +922,13 @@ KOKKOS, o = USER-OMP, t = OPT.
|
||||
|
||||
"none"_angle_none.html,
|
||||
"hybrid"_angle_hybrid.html,
|
||||
"charmm (o)"_angle_charmm.html,
|
||||
"charmm (ko)"_angle_charmm.html,
|
||||
"class2 (o)"_angle_class2.html,
|
||||
"cosine (o)"_angle_cosine.html,
|
||||
"cosine/delta (o)"_angle_cosine_delta.html,
|
||||
"cosine/periodic (o)"_angle_cosine_periodic.html,
|
||||
"cosine/squared (o)"_angle_cosine_squared.html,
|
||||
"harmonic (o)"_angle_harmonic.html,
|
||||
"harmonic (ko)"_angle_harmonic.html,
|
||||
"table (o)"_angle_table.html :tb(c=4,ea=c)
|
||||
|
||||
These are additional angle styles in USER packages, which can be used
|
||||
@ -932,12 +957,12 @@ KOKKOS, o = USER-OMP, t = OPT.
|
||||
|
||||
"none"_dihedral_none.html,
|
||||
"hybrid"_dihedral_hybrid.html,
|
||||
"charmm (o)"_dihedral_charmm.html,
|
||||
"charmm (ko)"_dihedral_charmm.html,
|
||||
"class2 (o)"_dihedral_class2.html,
|
||||
"harmonic (o)"_dihedral_harmonic.html,
|
||||
"helix (o)"_dihedral_helix.html,
|
||||
"multi/harmonic (o)"_dihedral_multi_harmonic.html,
|
||||
"opls (o)"_dihedral_opls.html :tb(c=4,ea=c)
|
||||
"opls (ko)"_dihedral_opls.html :tb(c=4,ea=c)
|
||||
|
||||
These are additional dihedral styles in USER packages, which can be
|
||||
used if "LAMMPS is built with the appropriate
|
||||
@ -965,7 +990,7 @@ KOKKOS, o = USER-OMP, t = OPT.
|
||||
"hybrid"_improper_hybrid.html,
|
||||
"class2 (o)"_improper_class2.html,
|
||||
"cvff (o)"_improper_cvff.html,
|
||||
"harmonic (o)"_improper_harmonic.html,
|
||||
"harmonic (ko)"_improper_harmonic.html,
|
||||
"umbrella (o)"_improper_umbrella.html :tb(c=4,ea=c)
|
||||
|
||||
These are additional improper styles in USER packages, which can be
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
@ -34,7 +34,10 @@
|
||||
6.19 <A HREF = "#howto_19">Library interface to LAMMPS</A><BR>
|
||||
6.20 <A HREF = "#howto_20">Calculating thermal conductivity</A><BR>
|
||||
6.21 <A HREF = "#howto_21">Calculating viscosity</A><BR>
|
||||
6.22 <A HREF = "#howto_22">Calculating a diffusion coefficient</A> <BR>
|
||||
6.22 <A HREF = "#howto_22">Calculating a diffusion coefficient</A><BR>
|
||||
6.23 <A HREF = "#howto_23">Using chunks to calculate system properties</A><BR>
|
||||
6.24 <A HREF = "#howto_24">Setting parameters for the kspace_style pppm/disp command</A><BR>
|
||||
6.25 <A HREF = "#howto_25">Adiabatic core/shell model</A> <BR>
|
||||
|
||||
<P>The example input scripts included in the LAMMPS distribution and
|
||||
highlighted in <A HREF = "Section_example.html">Section_example</A> also show how to
|
||||
@ -1616,15 +1619,15 @@ pressure</A> command calculates pressure.
|
||||
<LI><A HREF = "compute_temp_ramp.html">compute temp/ramp</A>
|
||||
<LI><A HREF = "compute_temp_region.html">compute temp/region</A>
|
||||
</UL>
|
||||
<P>All but the first 3 calculate velocity biases (i.e. advection
|
||||
<P>All but the first 3 calculate velocity biases directly (e.g. advection
|
||||
velocities) that are removed when computing the thermal temperature.
|
||||
<A HREF = "compute_temp_sphere.html">Compute temp/sphere</A> and <A HREF = "compute_temp_asphere.html">compute
|
||||
temp/asphere</A> compute kinetic energy for
|
||||
finite-size particles that includes rotational degrees of freedom.
|
||||
They both allow, as an extra argument, which is another temperature
|
||||
compute that subtracts a velocity bias. This allows the translational
|
||||
velocity of spherical or aspherical particles to be adjusted in
|
||||
prescribed ways.
|
||||
They both allow for velocity biases indirectly, via an optional extra
|
||||
argument, another temperature compute that subtracts a velocity bias.
|
||||
This allows the translational velocity of spherical or aspherical
|
||||
particles to be adjusted in prescribed ways.
|
||||
</P>
|
||||
<P>Thermostatting in LAMMPS is performed by <A HREF = "fix.html">fixes</A>, or in one
|
||||
case by a pair style. Several thermostatting fixes are available:
|
||||
@ -1657,15 +1660,21 @@ to the per-particle thermostatting of <A HREF = "fix_langevin.html">fix
|
||||
langevin</A>.
|
||||
</P>
|
||||
<P>Any of the thermostatting fixes can use temperature computes that
|
||||
remove bias for two purposes: (a) computing the current temperature to
|
||||
compare to the requested target temperature, and (b) adjusting only
|
||||
the thermal temperature component of the particle's velocities. See
|
||||
the doc pages for the individual fixes and for the
|
||||
remove bias which has two effects. First, the current calculated
|
||||
temperature, which is compared to the requested target temperature, is
|
||||
caluclated with the velocity bias removed. Second, the thermostat
|
||||
adjusts only the thermal temperature component of the particle's
|
||||
velocities, which are the velocities with the bias removed. The
|
||||
removed bias is then added back to the adjusted velocities. See the
|
||||
doc pages for the individual fixes and for the
|
||||
<A HREF = "fix_modify.html">fix_modify</A> command for instructions on how to assign
|
||||
a temperature compute to a thermostatting fix. For example, you can
|
||||
apply a thermostat to only the x and z components of velocity by using
|
||||
it in conjunction with <A HREF = "compute_temp_partial.html">compute
|
||||
temp/partial</A>.
|
||||
temp/partial</A>. Of you could thermostat only
|
||||
the thermal temperature of a streaming flow of particles without
|
||||
affecting the streaming velocity, by using <A HREF = "compute_temp_profile.html">compute
|
||||
temp/profile</A>.
|
||||
</P>
|
||||
<P>IMPORTANT NOTE: Only the nvt fixes perform time integration, meaning
|
||||
they update the velocities and positions of particles due to forces
|
||||
@ -1905,15 +1914,18 @@ void *lammps_extract_atom(void *, char *)
|
||||
void *lammps_extract_compute(void *, char *, int, int)
|
||||
void *lammps_extract_fix(void *, char *, int, int, int, int)
|
||||
void *lammps_extract_variable(void *, char *, char *)
|
||||
int lammps_set_variable(void *, char *, char *)
|
||||
int lammps_get_natoms(void *)
|
||||
void lammps_get_coords(void *, double *)
|
||||
void lammps_put_coords(void *, double *)
|
||||
</PRE>
|
||||
<P>These can extract various global or per-atom quantities from LAMMPS as
|
||||
well as values calculated by a compute, fix, or variable. The "get"
|
||||
and "put" operations can retrieve and reset atom coordinates.
|
||||
See the library.cpp file and its associated header file library.h for
|
||||
details.
|
||||
well as values calculated by a compute, fix, or variable. The
|
||||
"set_variable" function can set an existing string-style variable to a
|
||||
new value, so that subsequent LAMMPS commands can access the variable.
|
||||
The "get" and "put" operations can retrieve and reset atom
|
||||
coordinates. See the library.cpp file and its associated header file
|
||||
library.h for details.
|
||||
</P>
|
||||
<P>The key idea of the library interface is that you can write any
|
||||
functions you wish to define how your code talks to LAMMPS and add
|
||||
@ -2146,6 +2158,455 @@ and thus extract D.
|
||||
</P>
|
||||
<HR>
|
||||
|
||||
<A NAME = "howto_23"></A><H4>6.23 Using chunks to calculate system properties
|
||||
</H4>
|
||||
<P>In LAMMS, "chunks" are collections of atoms, as defined by the
|
||||
<A HREF = "compute_chunk_atom.html">compute chunk/atom</A> command, which assigns
|
||||
each atom to a chunk ID (or to no chunk at all). The number of chunks
|
||||
and the assignment of chunk IDs to atoms can be static or change over
|
||||
time. Examples of "chunks" are molecules or spatial bins or atoms
|
||||
with similar values (e.g. coordination number or potential energy).
|
||||
</P>
|
||||
<P>The per-atom chunk IDs can be used as input to two other kinds of
|
||||
commands, to calculate various properties of a system:
|
||||
</P>
|
||||
<UL><LI><A HREF = "fix_ave_chunk.html">fix ave/chunk</A>
|
||||
<LI>any of the <A HREF = "compute.html">compute */chunk</A> commands
|
||||
</UL>
|
||||
<P>Here, each of the 3 kinds of chunk-related commands is briefly
|
||||
overviewed. Then some examples are given of how to compute different
|
||||
properties with chunk commands.
|
||||
</P>
|
||||
<H5>Compute chunk/atom command:
|
||||
</H5>
|
||||
<P>This compute can assign atoms to chunks of various styles. Only atoms
|
||||
in the specified group and optional specified region are assigned to a
|
||||
chunk. Here are some possible chunk definitions:
|
||||
</P>
|
||||
<DIV ALIGN=center><TABLE BORDER=1 >
|
||||
<TR><TD >atoms in same molecule </TD><TD > chunk ID = molecule ID </TD></TR>
|
||||
<TR><TD >atoms of same atom type </TD><TD > chunk ID = atom type </TD></TR>
|
||||
<TR><TD >all atoms with same atom property (charge, radius, etc) </TD><TD > chunk ID = output of compute property/atom </TD></TR>
|
||||
<TR><TD >atoms in same cluster </TD><TD > chunk ID = output of <A HREF = "compute_cluster_atom.html">compute cluster/atom</A> command </TD></TR>
|
||||
<TR><TD >atoms in same spatial bin </TD><TD > chunk ID = bin ID </TD></TR>
|
||||
<TR><TD >atoms in same rigid body </TD><TD > chunk ID = molecule ID used to define rigid bodies </TD></TR>
|
||||
<TR><TD >atoms with similar potential energy </TD><TD > chunk ID = output of <A HREF = "compute_pe_atom.html">compute pe/atom</A> </TD></TR>
|
||||
<TR><TD >atoms with same local defect structure </TD><TD > chunk ID = output of <A HREF = "compute_centro_atom.html">compute centro/atom</A> or <A HREF = "compute_coord_atom.html">compute coord/atom</A> command
|
||||
</TD></TR></TABLE></DIV>
|
||||
|
||||
<P>Note that chunk IDs are integer values, so for atom properties or
|
||||
computes that produce a floating point value, they will be truncated
|
||||
to an integer. You could also use the compute in a variable that
|
||||
scales the floating point value to spread it across multiple intergers.
|
||||
</P>
|
||||
<P>Spatial bins can be of various kinds, e.g. 1d bins = slabs, 2d bins =
|
||||
pencils, 3d bins = boxes, spherical bins, cylindrical bins.
|
||||
</P>
|
||||
<P>This compute also calculates the number of chunks <I>Nchunk</I>, which is
|
||||
used by other commands to tally per-chunk data. <I>Nchunk</I> can be a
|
||||
static value or change over time (e.g. the number of clusters). The
|
||||
chunk ID for an individual atom can also be static (e.g. a molecule
|
||||
ID), or dynamic (e.g. what spatial bin an atom is in as it moves).
|
||||
</P>
|
||||
<P>Note that this compute allows the per-atom output of other
|
||||
<A HREF = "compute.html">computes</A>, <A HREF = "fix.html">fixes</A>, and
|
||||
<A HREF = "variable.html">variables</A> to be used to define chunk IDs for each
|
||||
atom. This means you can write your own compute or fix to output a
|
||||
per-atom quantity to use as chunk ID. See
|
||||
<A HREF = "Section_modify.html">Section_modify</A> of the documentation for how to
|
||||
do this. You can also define a <A HREF = "variable.html">per-atom variable</A> in
|
||||
the input script that uses a formula to generate a chunk ID for each
|
||||
atom.
|
||||
</P>
|
||||
<H5>Fix ave/chunk command:
|
||||
</H5>
|
||||
<P>This fix takes the ID of a <A HREF = "compute_chunk_atom.html">compute
|
||||
chunk/atom</A> command as input. For each chunk,
|
||||
it then sums one or more specified per-atom values over the atoms in
|
||||
each chunk. The per-atom values can be any atom property, such as
|
||||
velocity, force, charge, potential energy, kinetic energy, stress,
|
||||
etc. Additional keywords are defined for per-chunk properties like
|
||||
density and temperature. More generally any per-atom value generated
|
||||
by other <A HREF = "compute.html">computes</A>, <A HREF = "fix.html">fixes</A>, and <A HREF = "variable.html">per-atom
|
||||
variables</A>, can be summed over atoms in each chunk.
|
||||
</P>
|
||||
<P>Similar to other averaging fixes, this fix allows the summed per-chunk
|
||||
values to be time-averaged in various ways, and output to a file. The
|
||||
fix produces a global array as output with one row of values per
|
||||
chunk.
|
||||
</P>
|
||||
<H5>Compute */chunk commands:
|
||||
</H5>
|
||||
<P>Currently the following computes operate on chunks of atoms to produce
|
||||
per-chunk values.
|
||||
</P>
|
||||
<UL><LI><A HREF = "compute_com_chunk.html">compute com/chunk</A>
|
||||
<LI><A HREF = "compute_gyration_chunk.html">compute gyration/chunk</A>
|
||||
<LI><A HREF = "compute_inertia_chunk.html">compute inertia/chunk</A>
|
||||
<LI><A HREF = "compute_msd_chunk.html">compute msd/chunk</A>
|
||||
<LI><A HREF = "compute_property_chunk.html">compute property/chunk</A>
|
||||
<LI><A HREF = "compute_temp_chunk.html">compute temp/chunk</A>
|
||||
<LI><A HREF = "compute_vcm_chunk.html">compute torque/chunk</A>
|
||||
<LI><A HREF = "compute_vcm_chunk.html">compute vcm/chunk</A>
|
||||
</UL>
|
||||
<P>They each take the ID of a <A HREF = "compute_chunk_atom.html">compute
|
||||
chunk/atom</A> command as input. As their names
|
||||
indicate, they calculate the center-of-mass, radius of gyration,
|
||||
moments of inertia, mean-squared displacement, temperature, torque,
|
||||
and velocity of center-of-mass for each chunk of atoms. The <A HREF = "compute_property_chunk.html">compute
|
||||
property/chunk</A> command can tally the
|
||||
count of atoms in each chunk and extract other per-chunk properties.
|
||||
</P>
|
||||
<P>The reason these various calculations are not part of the <A HREF = "fix_ave_chunk.html">fix
|
||||
ave/chunk command</A>, is that each requires a more
|
||||
complicated operation than simply summing and averaging over per-atom
|
||||
values in each chunk. For example, many of them require calculation
|
||||
of a center of mass, which requires summing mass*position over the
|
||||
atoms and then dividing by summed mass.
|
||||
</P>
|
||||
<P>All of these computes produce a global vector or global array as
|
||||
output, wih one or more values per chunk. They can be used
|
||||
in various ways:
|
||||
</P>
|
||||
<UL><LI>As input to the <A HREF = "fix_ave_time.html">fix ave/time</A> command, which can
|
||||
write the values to a file and optionally time average them.
|
||||
|
||||
<LI>As input to the <A HREF = "fix_ave_histo.html">fix ave/histo</A> command to
|
||||
histogram values across chunks. E.g. a histogram of cluster sizes or
|
||||
molecule diffusion rates.
|
||||
|
||||
<LI>As input to special functions of <A HREF = "variable.html">equal-style
|
||||
variables</A>, like sum() and max(). E.g. to find the
|
||||
largest cluster or fastest diffusing molecule.
|
||||
</UL>
|
||||
<H5>Example calculations with chunks
|
||||
</H5>
|
||||
<P>Here are eaxmples using chunk commands to calculate various
|
||||
properties:
|
||||
</P>
|
||||
<P>(1) Average velocity in each of 1000 2d spatial bins:
|
||||
</P>
|
||||
<PRE>compute cc1 all chunk/atom bin/2d x 0.0 0.1 y lower 0.01 units reduced
|
||||
fix 1 all ave/chunk 100 10 1000 cc1 vx vy file tmp.out
|
||||
</PRE>
|
||||
<P>(2) Temperature in each spatial bin, after subtracting a flow
|
||||
velocity:
|
||||
</P>
|
||||
<PRE>compute cc1 all chunk/atom bin/2d x 0.0 0.1 y lower 0.1 units reduced
|
||||
compute vbias all temp/profile 1 0 0 y 10
|
||||
fix 1 all ave/chunk 100 10 1000 cc1 temp bias vbias file tmp.out
|
||||
</PRE>
|
||||
<P>(3) Center of mass of each molecule:
|
||||
</P>
|
||||
<PRE>compute cc1 all chunk/atom molecule
|
||||
compute myChunk all com/chunk cc1
|
||||
fix 1 all ave/time 100 1 100 c_myChunk file tmp.out mode vector
|
||||
</PRE>
|
||||
<P>(4) Total force on each molecule and ave/max across all molecules:
|
||||
</P>
|
||||
<PRE>compute cc1 all chunk/atom molecule
|
||||
fix 1 all ave/chunk 1000 1 1000 cc1 fx fy fz file tmp.out
|
||||
variable xave equal ave(f_1<B>2</B>)
|
||||
variable xmax equal max(f_1<B>2</B>)
|
||||
thermo 1000
|
||||
thermo_style custom step temp v_xave v_xmax
|
||||
</PRE>
|
||||
<P>(5) Histogram of cluster sizes:
|
||||
</P>
|
||||
<PRE>compute cluster all cluster/atom 1.0
|
||||
compute cc1 all chunk/atom c_cluster compress yes
|
||||
compute size all property/chunk cc1 count
|
||||
fix 1 all ave/histo 100 1 100 0 20 20 c_size mode vector ave running beyond ignore file tmp.histo
|
||||
</PRE>
|
||||
<HR>
|
||||
|
||||
<A NAME = "howto_24"></A><H4>6.24 Setting parameters for the <A HREF = "kspace_style.html">kspace_style pppm/disp</A> command
|
||||
</H4>
|
||||
<P>The PPPM method computes interactions by splitting the pair potential
|
||||
into two parts, one of which is computed in a normal pairwise fashion,
|
||||
the so-called real-space part, and one of which is computed using the
|
||||
Fourier transform, the so called reciprocal-space or kspace part. For
|
||||
both parts, the potential is not computed exactly but is approximated.
|
||||
Thus, there is an error in both parts of the computation, the
|
||||
real-space and the kspace error. The just mentioned facts are true
|
||||
both for the PPPM for Coulomb as well as dispersion interactions. The
|
||||
deciding difference - and also the reason why the parameters for
|
||||
pppm/disp have to be selected with more care - is the impact of the
|
||||
errors on the results: The kspace error of the PPPM for Coulomb and
|
||||
dispersion interaction and the real-space error of the PPPM for
|
||||
Coulomb interaction have the character of noise. In contrast, the
|
||||
real-space error of the PPPM for dispersion has a clear physical
|
||||
interpretation: the underprediction of cohesion. As a consequence, the
|
||||
real-space error has a much stronger effect than the kspace error on
|
||||
simulation results for pppm/disp. Parameters must thus be chosen in a
|
||||
way that this error is much smaller than the kspace error.
|
||||
</P>
|
||||
<P>When using pppm/disp and not making any specifications on the PPPM
|
||||
parameters via the kspace modify command, parameters will be tuned
|
||||
such that the real-space error and the kspace error are equal. This
|
||||
will result in simulations that are either inaccurate or slow, both of
|
||||
which is not desirable. For selecting parameters for the pppm/disp
|
||||
that provide fast and accurate simulations, there are two approaches,
|
||||
which both have their up- and downsides.
|
||||
</P>
|
||||
<P>The first approach is to set desired real-space an kspace accuracies
|
||||
via the <I>kspace_modify force/disp/real</I> and <I>kspace_modify
|
||||
force/disp/kspace</I> commands. Note that the accuracies have to be
|
||||
specified in force units and are thus dependend on the chosen unit
|
||||
settings. For real units, 0.0001 and 0.002 seem to provide reasonable
|
||||
accurate and efficient computations for the real-space and kspace
|
||||
accuracies. 0.002 and 0.05 work well for most systems using lj
|
||||
units. PPPM parameters will be generated based on the desired
|
||||
accuracies. The upside of this approach is that it usually provides a
|
||||
good set of parameters and will work for both the <I>kspace_modify diff
|
||||
ad</I> and <I>kspace_modify diff ik</I> options. The downside of the method
|
||||
is that setting the PPPM parameters will take some time during the
|
||||
initialization of the simulation.
|
||||
</P>
|
||||
<P>The second approach is to set the parameters for the pppm/disp
|
||||
explicitly using the <I>kspace_modify mesh/disp</I>, <I>kspace_modify
|
||||
order/disp</I>, and <I>kspace_modify gewald/disp</I> commands. This approach
|
||||
requires a more experienced user who understands well the impact of
|
||||
the choice of parameters on the simulation accuracy and
|
||||
performance. This approach provides a fast initialization of the
|
||||
simulation. However, it is sensitive to errors: A combination of
|
||||
parameters that will perform well for one system might result in
|
||||
far-from-optimal conditions for other simulations. For example,
|
||||
parametes that provide accurate and fast computations for
|
||||
all-atomistic force fields can provide insufficient accuracy or
|
||||
united-atomistic force fields (which is related to that the latter
|
||||
typically have larger dispersion coefficients).
|
||||
</P>
|
||||
<P>To avoid inaccurate or inefficient simulations, the pppm/disp stops
|
||||
simulations with an error message if no action is taken to control the
|
||||
PPPM parameters. If the automatic parameter generation is desired and
|
||||
real-space and kspace accuracies are desired to be equal, this error
|
||||
message can be suppressed using the <I>kspace_modify disp/auto yes</I>
|
||||
command.
|
||||
</P>
|
||||
<P>A reasonable approach that combines the upsides of both methods is to
|
||||
make the first run using the <I>kspace_modify force/disp/real</I> and
|
||||
<I>kspace_modify force/disp/kspace</I> commands, write down the PPPM
|
||||
parameters from the outut, and specify these parameters using the
|
||||
second approach in subsequent runs (which have the same composition,
|
||||
force field, and approximately the same volume).
|
||||
</P>
|
||||
<P>Concerning the performance of the pppm/disp there are two more things
|
||||
to consider. The first is that when using the pppm/disp, the cutoff
|
||||
parameter does no longer affect the accuracy of the simulation
|
||||
(subject to that gewald/disp is adjusted when changing the cutoff).
|
||||
The performance can thus be increased by examining different values
|
||||
for the cutoff parameter. A lower bound for the cutoff is only set by
|
||||
the truncation error of the repulsive term of pair potentials.
|
||||
</P>
|
||||
<P>The second is that the mixing rule of the pair style has an impact on
|
||||
the computation time when using the pppm/disp. Fastest computations
|
||||
are achieved when using the geometric mixing rule. Using the
|
||||
arithmetic mixing rule substantially increases the computational cost.
|
||||
The computational overhead can be reduced using the <I>kspace_modify
|
||||
mix/disp geom</I> and <I>kspace_modify splittol</I> commands. The first
|
||||
command simply enforces geometric mixing of the dispersion
|
||||
coeffiecients in kspace computations. This introduces some error in
|
||||
the computations but will also significantly speed-up the
|
||||
simulations. The second keyword sets the accuracy with which the
|
||||
dispersion coefficients are approximated using a matrix factorization
|
||||
approach. This may result in better accuracy then using the first
|
||||
command, but will usually also not provide an equally good increase of
|
||||
efficiency.
|
||||
</P>
|
||||
<P>Finally, pppm/disp can also be used when no mixing rules apply.
|
||||
This can be achieved using the <I>kspace_modify mix/disp none</I> command.
|
||||
Note that the code does not check automatically whether any mixing
|
||||
rule is fulfilled. If mixing rules do not apply, the user will have
|
||||
to specify this command explicitly.
|
||||
</P>
|
||||
<HR>
|
||||
|
||||
<A NAME = "howto_25"></A><H4>6.25 Adiabatic core/shell model
|
||||
</H4>
|
||||
<P>The adiabatic core-shell model by <A HREF = "#MitchellFinchham">Mitchell and
|
||||
Finchham</A> is a simple method for adding
|
||||
polarizability to a system. In order to mimic the electron shell of
|
||||
an ion, a ghost atom is attached to it. This way the ions are split
|
||||
into a core and a shell where the latter is meant to react to the
|
||||
electrostatic environment inducing polarizability.
|
||||
</P>
|
||||
<P>Technically, shells are attached to the cores by a spring force f =
|
||||
k*r where k is a parametrized spring constant and r is the distance
|
||||
between the core and the shell. The charges of the core and the shell
|
||||
add up to the ion charge, thus q(ion) = q(core) + q(shell). In a
|
||||
similar fashion the mass of the ion is distributed on the core and the
|
||||
shell with the core having the larger mass.
|
||||
</P>
|
||||
<P>To run this model in LAMMPS, <A HREF = "atom_style.html">atom_style</A> <I>full</I> can
|
||||
be used since atom charge and bonds are needed. Each kind of
|
||||
core/shell pair requires two atom types and a bond type. The core and
|
||||
shell of a core/shell pair should be bonded to each other with a
|
||||
harmonic bond that provides the spring force. For example, a data file
|
||||
for NaCl, as found in examples/coreshell, has this format:
|
||||
</P>
|
||||
<PRE>432 atoms # core and shell atoms
|
||||
216 bonds # number of core/shell springs
|
||||
</PRE>
|
||||
<PRE>4 atom types # 2 cores and 2 shells for Na and Cl
|
||||
2 bond types
|
||||
</PRE>
|
||||
<PRE>0.0 24.09597 xlo xhi
|
||||
0.0 24.09597 ylo yhi
|
||||
0.0 24.09597 zlo zhi
|
||||
</PRE>
|
||||
<PRE>Masses # core/shell mass ratio = 0.1
|
||||
</PRE>
|
||||
<PRE>1 20.690784 # Na core
|
||||
2 31.90500 # Cl core
|
||||
3 2.298976 # Na shell
|
||||
4 3.54500 # Cl shell
|
||||
</PRE>
|
||||
<PRE>Atoms
|
||||
</PRE>
|
||||
<PRE>1 1 2 1.5005 0.00000000 0.00000000 0.00000000 # core of core/shell pair 1
|
||||
2 1 4 -2.5005 0.00000000 0.00000000 0.00000000 # shell of core/shell pair 1
|
||||
3 2 1 1.5056 4.01599500 4.01599500 4.01599500 # core of core/shell pair 2
|
||||
4 2 3 -0.5056 4.01599500 4.01599500 4.01599500 # shell of core/shell pair 2
|
||||
(...)
|
||||
</PRE>
|
||||
<PRE>Bonds # Bond topology for spring forces
|
||||
</PRE>
|
||||
<PRE>1 2 1 2 # spring for core/shell pair 1
|
||||
2 2 3 4 # spring for core/shell pair 2
|
||||
(...)
|
||||
</PRE>
|
||||
<P>Non-Coulombic (e.g. Lennard-Jones) pairwise interactions are only
|
||||
defined between the shells. Coulombic interactions are defined
|
||||
between all cores and shells. If desired, additional bonds can be
|
||||
specified between cores.
|
||||
</P>
|
||||
<P>The <A HREF = "special_bonds.html">special_bonds</A> command should be used to
|
||||
turn-off the Coulombic interaction within core/shell pairs, since that
|
||||
interaction is set by the bond spring. This is done using the
|
||||
<A HREF = "special_bonds.html">special_bonds</A> command with a 1-2 weight = 0.0,
|
||||
which is the default value.
|
||||
</P>
|
||||
<P>Since the core/shell model permits distances of r = 0.0 between the
|
||||
core and shell, a pair style with a "cs" suffix needs to be used to
|
||||
implement a valid long-range Coulombic correction. Several such pair
|
||||
styles are provided in the CORESHELL package. See <A HREF = "pair_cs.html">this doc
|
||||
page</A> for details. All of the core/shell enabled pair
|
||||
styles require the use of a long-range Coulombic solver, as specified
|
||||
by the <A HREF = "kspace_style.html">kspace_style</A> command. Either the PPPM or
|
||||
Ewald solvers can be used.
|
||||
</P>
|
||||
<P>For the NaCL example problem, these pair style and bond style settings
|
||||
are used:
|
||||
</P>
|
||||
<PRE>pair_style born/coul/long/cs 20.0 20.0
|
||||
pair_coeff * * 0.0 1.000 0.00 0.00 0.00
|
||||
pair_coeff 3 3 487.0 0.23768 0.00 1.05 0.50 #Na-Na
|
||||
pair_coeff 3 4 145134.0 0.23768 0.00 6.99 8.70 #Na-Cl
|
||||
pair_coeff 4 4 405774.0 0.23768 0.00 72.40 145.40 #Cl-Cl
|
||||
</PRE>
|
||||
<PRE>bond_style harmonic
|
||||
bond_coeff 1 63.014 0.0
|
||||
bond_coeff 2 25.724 0.0
|
||||
</PRE>
|
||||
<P>When running dynamics with the adiabatic core/shell model, the
|
||||
following issues should be considered. Since the relative motion of
|
||||
the core and shell particles corresponds to the polarization, typical
|
||||
thermostats can alter the polarization behaviour, meaining the shell
|
||||
will not react freely to its electrostatic environment. Therefore
|
||||
it's typically desirable to decouple the relative motion of the
|
||||
core/shell pair, which is an imaginary degree of freedom, from the
|
||||
real physical system. To do that, the <A HREF = "compute_temp_cs.html">compute
|
||||
temp/cs</A> command can be used, in conjunction with
|
||||
any of the thermostat fixes, such as <A HREF = "fix_nh.html">fix nvt</A> or <A HREF = "fix_langevin">fix
|
||||
langevin</A>. This compute uses the center-of-mass velocity
|
||||
of the core/shell pairs to calculate a temperature, and insures that
|
||||
velocity is what is rescaled for thermostatting purposes. The
|
||||
<A HREF = "compute_temp_cs.html">compute temp/cs</A> command requires input of two
|
||||
groups, one for the core atoms, another for the shell atoms. These
|
||||
can be defined using the <A HREF = "group.html">group <I>type</I></A> command. Note that
|
||||
to perform thermostatting using this definition of temperature, the
|
||||
<A HREF = "fix_modify.html">fix modify temp</A> command should be used to assign the
|
||||
comptue to the thermostat fix. Likewise the <A HREF = "thermo_modify.html">thermo_modify
|
||||
temp</A> command can be used to make this temperature
|
||||
be output for the overall system.
|
||||
</P>
|
||||
<P>For the NaCl example, this can be done as follows:
|
||||
</P>
|
||||
<PRE>group cores type 1 2
|
||||
group shells type 3 4
|
||||
compute CSequ all temp/cs cores shells
|
||||
fix thermoberendsen all temp/berendsen 1427 1427 0.4 # thermostat for the true physical system
|
||||
fix thermostatequ all nve # integrator as needed for the berendsen thermostat
|
||||
fix_modify thermoberendsen temp CSequ
|
||||
thermo_modify temp CSequ # output of center-of-mass derived temperature
|
||||
</PRE>
|
||||
<P>When intializing the velocities of a system with core/shell pairs, it
|
||||
is also desirable to not introduce energy into the relative motion of
|
||||
the core/shell particles, but only assign a center-of-mass velocity to
|
||||
the pairs. This can be done by using the <I>bias</I> keyword of the
|
||||
<A HREF = "velocity.html">velocity create</A> command and assigning the <A HREF = "compute_temp_cs.html">compute
|
||||
temp/cs</A> command to the <I>temp</I> keyword of the
|
||||
<A HREF = "velocity.html">velocity</A> commmand, e.g.
|
||||
</P>
|
||||
<PRE>velocity all create 1427 134 bias yes temp CSequ
|
||||
velocity all scale 1427 temp CSequ
|
||||
</PRE>
|
||||
<P>It is important to note that the polarizability of the core/shell
|
||||
pairs is based on their relative motion. Therefore the choice of
|
||||
spring force and mass ratio need to ensure much faster relative motion
|
||||
of the 2 atoms within the core/shell pair than their center-of-mass
|
||||
velocity. This allow the shells to effectively react instantaneously
|
||||
to the electrostatic environment. This fast movement also limits the
|
||||
timestep size that can be used.
|
||||
</P>
|
||||
<P>Additionally, the mass mismatch of the core and shell particles means
|
||||
that only a small amount of energy is transfered to the decoupled
|
||||
imaginary degrees of freedom. However, this transfer will typically
|
||||
lead to a a small drift in total energy over time. This internal
|
||||
energy can be monitored using the <A HREF = "compute_chunk_atom.html">compute
|
||||
chunk/atom</A> and <A HREF = "compute_temp_chunk.html">compute
|
||||
temp/chunk</A> commands. The internal kinetic
|
||||
energies of each core/shell pair can then be summed using the sum()
|
||||
special functino of the <A HREF = "variable.html">variable</A> command. Or they can
|
||||
be time/averaged and output using the <A HREF = "fix_ave_time.html">fix ave/time</A>
|
||||
command. To use these commands, each core/shell pair must be defined
|
||||
as a "chunk". If each core/shell pair is defined as its own molecule,
|
||||
the molecule ID can be used to define the chunks. If cores are bonded
|
||||
to each other to form larger molecules, then another way to define the
|
||||
chunks is to use the <A HREF = "fix_property_atom.html">fix property/atom</A> to
|
||||
assign a core/shell ID to each atom via a special field in the data
|
||||
file read by the <A HREF = "read_data.html">read_data</A> command. This field can
|
||||
then be accessed by the <A HREF = "compute_property_atom.html">compute
|
||||
property/atom</A> command, to use as input to
|
||||
the <A HREF = "compute_chunk_atom.html">compute chunk/atom</A> command to define the
|
||||
core/shell pairs as chunks.
|
||||
</P>
|
||||
<P>For example,
|
||||
</P>
|
||||
<PRE>fix csinfo all property/atom i_CSID # property/atom command
|
||||
read_data NaCl_CS_x0.1_prop.data fix csinfo NULL CS-Info # atom property added in the data-file
|
||||
compute prop all property/atom i_CSID
|
||||
compute cs_chunk all chunk/atom c_prop
|
||||
compute cstherm all temp/chunk cs_chunk temp internal com yes cdof 3.0 # note the chosen degrees of freedom for the core/shell pairs
|
||||
fix ave_chunk all ave/time 10 1 10 c_cstherm file chunk.dump mode vector
|
||||
</PRE>
|
||||
<P>The additional section in the date file would be formatted like this:
|
||||
</P>
|
||||
<PRE>CS-Info # header of additional section
|
||||
</PRE>
|
||||
<PRE>1 1 # column 1 = atom ID, column 2 = core/shell ID
|
||||
2 1
|
||||
3 2
|
||||
4 2
|
||||
5 3
|
||||
6 3
|
||||
7 4
|
||||
8 4
|
||||
(...)
|
||||
</PRE>
|
||||
<HR>
|
||||
|
||||
<HR>
|
||||
|
||||
<A NAME = "Berendsen"></A>
|
||||
@ -2191,4 +2652,9 @@ Phys, 79, 926 (1983).
|
||||
|
||||
<P><B>(Shinoda)</B> Shinoda, Shiga, and Mikami, Phys Rev B, 69, 134103 (2004).
|
||||
</P>
|
||||
<A NAME = "MitchellFinchham"></A>
|
||||
|
||||
<P><B>(Mitchell and Finchham)</B> Mitchell, Finchham, J Phys Condensed Matter,
|
||||
5, 1031-1038 (1993).
|
||||
</P>
|
||||
</HTML>
|
||||
|
||||
@ -31,7 +31,10 @@ This section describes how to perform common tasks using LAMMPS.
|
||||
6.19 "Library interface to LAMMPS"_#howto_19
|
||||
6.20 "Calculating thermal conductivity"_#howto_20
|
||||
6.21 "Calculating viscosity"_#howto_21
|
||||
6.22 "Calculating a diffusion coefficient"_#howto_22 :all(b)
|
||||
6.22 "Calculating a diffusion coefficient"_#howto_22
|
||||
6.23 "Using chunks to calculate system properties"_#howto_23
|
||||
6.24 "Setting parameters for the kspace_style pppm/disp command"_#howto_24
|
||||
6.25 "Adiabatic core/shell model"_#howto_25 :all(b)
|
||||
|
||||
The example input scripts included in the LAMMPS distribution and
|
||||
highlighted in "Section_example"_Section_example.html also show how to
|
||||
@ -1603,15 +1606,15 @@ pressure"_compute_pressure.html command calculates pressure.
|
||||
"compute temp/ramp"_compute_temp_ramp.html
|
||||
"compute temp/region"_compute_temp_region.html :ul
|
||||
|
||||
All but the first 3 calculate velocity biases (i.e. advection
|
||||
All but the first 3 calculate velocity biases directly (e.g. advection
|
||||
velocities) that are removed when computing the thermal temperature.
|
||||
"Compute temp/sphere"_compute_temp_sphere.html and "compute
|
||||
temp/asphere"_compute_temp_asphere.html compute kinetic energy for
|
||||
finite-size particles that includes rotational degrees of freedom.
|
||||
They both allow, as an extra argument, which is another temperature
|
||||
compute that subtracts a velocity bias. This allows the translational
|
||||
velocity of spherical or aspherical particles to be adjusted in
|
||||
prescribed ways.
|
||||
They both allow for velocity biases indirectly, via an optional extra
|
||||
argument, another temperature compute that subtracts a velocity bias.
|
||||
This allows the translational velocity of spherical or aspherical
|
||||
particles to be adjusted in prescribed ways.
|
||||
|
||||
Thermostatting in LAMMPS is performed by "fixes"_fix.html, or in one
|
||||
case by a pair style. Several thermostatting fixes are available:
|
||||
@ -1644,15 +1647,21 @@ to the per-particle thermostatting of "fix
|
||||
langevin"_fix_langevin.html.
|
||||
|
||||
Any of the thermostatting fixes can use temperature computes that
|
||||
remove bias for two purposes: (a) computing the current temperature to
|
||||
compare to the requested target temperature, and (b) adjusting only
|
||||
the thermal temperature component of the particle's velocities. See
|
||||
the doc pages for the individual fixes and for the
|
||||
remove bias which has two effects. First, the current calculated
|
||||
temperature, which is compared to the requested target temperature, is
|
||||
caluclated with the velocity bias removed. Second, the thermostat
|
||||
adjusts only the thermal temperature component of the particle's
|
||||
velocities, which are the velocities with the bias removed. The
|
||||
removed bias is then added back to the adjusted velocities. See the
|
||||
doc pages for the individual fixes and for the
|
||||
"fix_modify"_fix_modify.html command for instructions on how to assign
|
||||
a temperature compute to a thermostatting fix. For example, you can
|
||||
apply a thermostat to only the x and z components of velocity by using
|
||||
it in conjunction with "compute
|
||||
temp/partial"_compute_temp_partial.html.
|
||||
temp/partial"_compute_temp_partial.html. Of you could thermostat only
|
||||
the thermal temperature of a streaming flow of particles without
|
||||
affecting the streaming velocity, by using "compute
|
||||
temp/profile"_compute_temp_profile.html.
|
||||
|
||||
IMPORTANT NOTE: Only the nvt fixes perform time integration, meaning
|
||||
they update the velocities and positions of particles due to forces
|
||||
@ -1892,15 +1901,18 @@ void *lammps_extract_atom(void *, char *)
|
||||
void *lammps_extract_compute(void *, char *, int, int)
|
||||
void *lammps_extract_fix(void *, char *, int, int, int, int)
|
||||
void *lammps_extract_variable(void *, char *, char *)
|
||||
int lammps_set_variable(void *, char *, char *)
|
||||
int lammps_get_natoms(void *)
|
||||
void lammps_get_coords(void *, double *)
|
||||
void lammps_put_coords(void *, double *) :pre
|
||||
|
||||
These can extract various global or per-atom quantities from LAMMPS as
|
||||
well as values calculated by a compute, fix, or variable. The "get"
|
||||
and "put" operations can retrieve and reset atom coordinates.
|
||||
See the library.cpp file and its associated header file library.h for
|
||||
details.
|
||||
well as values calculated by a compute, fix, or variable. The
|
||||
"set_variable" function can set an existing string-style variable to a
|
||||
new value, so that subsequent LAMMPS commands can access the variable.
|
||||
The "get" and "put" operations can retrieve and reset atom
|
||||
coordinates. See the library.cpp file and its associated header file
|
||||
library.h for details.
|
||||
|
||||
The key idea of the library interface is that you can write any
|
||||
functions you wish to define how your code talks to LAMMPS and add
|
||||
@ -2131,6 +2143,453 @@ accumulated in a vector via the "fix vector"_fix_vector.html command,
|
||||
and time integrated via the "variable trap"_variable.html function,
|
||||
and thus extract D.
|
||||
|
||||
:line
|
||||
|
||||
6.23 Using chunks to calculate system properties :link(howto_23),h4
|
||||
|
||||
In LAMMS, "chunks" are collections of atoms, as defined by the
|
||||
"compute chunk/atom"_compute_chunk_atom.html command, which assigns
|
||||
each atom to a chunk ID (or to no chunk at all). The number of chunks
|
||||
and the assignment of chunk IDs to atoms can be static or change over
|
||||
time. Examples of "chunks" are molecules or spatial bins or atoms
|
||||
with similar values (e.g. coordination number or potential energy).
|
||||
|
||||
The per-atom chunk IDs can be used as input to two other kinds of
|
||||
commands, to calculate various properties of a system:
|
||||
|
||||
"fix ave/chunk"_fix_ave_chunk.html
|
||||
any of the "compute */chunk"_compute.html commands :ul
|
||||
|
||||
Here, each of the 3 kinds of chunk-related commands is briefly
|
||||
overviewed. Then some examples are given of how to compute different
|
||||
properties with chunk commands.
|
||||
|
||||
Compute chunk/atom command: :h5
|
||||
|
||||
This compute can assign atoms to chunks of various styles. Only atoms
|
||||
in the specified group and optional specified region are assigned to a
|
||||
chunk. Here are some possible chunk definitions:
|
||||
|
||||
atoms in same molecule | chunk ID = molecule ID |
|
||||
atoms of same atom type | chunk ID = atom type |
|
||||
all atoms with same atom property (charge, radius, etc) | chunk ID = output of compute property/atom |
|
||||
atoms in same cluster | chunk ID = output of "compute cluster/atom"_compute_cluster_atom.html command |
|
||||
atoms in same spatial bin | chunk ID = bin ID |
|
||||
atoms in same rigid body | chunk ID = molecule ID used to define rigid bodies |
|
||||
atoms with similar potential energy | chunk ID = output of "compute pe/atom"_compute_pe_atom.html |
|
||||
atoms with same local defect structure | chunk ID = output of "compute centro/atom"_compute_centro_atom.html or "compute coord/atom"_compute_coord_atom.html command :tb(s=|,c=2)
|
||||
|
||||
Note that chunk IDs are integer values, so for atom properties or
|
||||
computes that produce a floating point value, they will be truncated
|
||||
to an integer. You could also use the compute in a variable that
|
||||
scales the floating point value to spread it across multiple intergers.
|
||||
|
||||
Spatial bins can be of various kinds, e.g. 1d bins = slabs, 2d bins =
|
||||
pencils, 3d bins = boxes, spherical bins, cylindrical bins.
|
||||
|
||||
This compute also calculates the number of chunks {Nchunk}, which is
|
||||
used by other commands to tally per-chunk data. {Nchunk} can be a
|
||||
static value or change over time (e.g. the number of clusters). The
|
||||
chunk ID for an individual atom can also be static (e.g. a molecule
|
||||
ID), or dynamic (e.g. what spatial bin an atom is in as it moves).
|
||||
|
||||
Note that this compute allows the per-atom output of other
|
||||
"computes"_compute.html, "fixes"_fix.html, and
|
||||
"variables"_variable.html to be used to define chunk IDs for each
|
||||
atom. This means you can write your own compute or fix to output a
|
||||
per-atom quantity to use as chunk ID. See
|
||||
"Section_modify"_Section_modify.html of the documentation for how to
|
||||
do this. You can also define a "per-atom variable"_variable.html in
|
||||
the input script that uses a formula to generate a chunk ID for each
|
||||
atom.
|
||||
|
||||
Fix ave/chunk command: :h5
|
||||
|
||||
This fix takes the ID of a "compute
|
||||
chunk/atom"_compute_chunk_atom.html command as input. For each chunk,
|
||||
it then sums one or more specified per-atom values over the atoms in
|
||||
each chunk. The per-atom values can be any atom property, such as
|
||||
velocity, force, charge, potential energy, kinetic energy, stress,
|
||||
etc. Additional keywords are defined for per-chunk properties like
|
||||
density and temperature. More generally any per-atom value generated
|
||||
by other "computes"_compute.html, "fixes"_fix.html, and "per-atom
|
||||
variables"_variable.html, can be summed over atoms in each chunk.
|
||||
|
||||
Similar to other averaging fixes, this fix allows the summed per-chunk
|
||||
values to be time-averaged in various ways, and output to a file. The
|
||||
fix produces a global array as output with one row of values per
|
||||
chunk.
|
||||
|
||||
Compute */chunk commands: :h5
|
||||
|
||||
Currently the following computes operate on chunks of atoms to produce
|
||||
per-chunk values.
|
||||
|
||||
"compute com/chunk"_compute_com_chunk.html
|
||||
"compute gyration/chunk"_compute_gyration_chunk.html
|
||||
"compute inertia/chunk"_compute_inertia_chunk.html
|
||||
"compute msd/chunk"_compute_msd_chunk.html
|
||||
"compute property/chunk"_compute_property_chunk.html
|
||||
"compute temp/chunk"_compute_temp_chunk.html
|
||||
"compute torque/chunk"_compute_vcm_chunk.html
|
||||
"compute vcm/chunk"_compute_vcm_chunk.html :ul
|
||||
|
||||
They each take the ID of a "compute
|
||||
chunk/atom"_compute_chunk_atom.html command as input. As their names
|
||||
indicate, they calculate the center-of-mass, radius of gyration,
|
||||
moments of inertia, mean-squared displacement, temperature, torque,
|
||||
and velocity of center-of-mass for each chunk of atoms. The "compute
|
||||
property/chunk"_compute_property_chunk.html command can tally the
|
||||
count of atoms in each chunk and extract other per-chunk properties.
|
||||
|
||||
The reason these various calculations are not part of the "fix
|
||||
ave/chunk command"_fix_ave_chunk.html, is that each requires a more
|
||||
complicated operation than simply summing and averaging over per-atom
|
||||
values in each chunk. For example, many of them require calculation
|
||||
of a center of mass, which requires summing mass*position over the
|
||||
atoms and then dividing by summed mass.
|
||||
|
||||
All of these computes produce a global vector or global array as
|
||||
output, wih one or more values per chunk. They can be used
|
||||
in various ways:
|
||||
|
||||
As input to the "fix ave/time"_fix_ave_time.html command, which can
|
||||
write the values to a file and optionally time average them. :ulb,l
|
||||
|
||||
As input to the "fix ave/histo"_fix_ave_histo.html command to
|
||||
histogram values across chunks. E.g. a histogram of cluster sizes or
|
||||
molecule diffusion rates. :l
|
||||
|
||||
As input to special functions of "equal-style
|
||||
variables"_variable.html, like sum() and max(). E.g. to find the
|
||||
largest cluster or fastest diffusing molecule. :l,ule
|
||||
|
||||
Example calculations with chunks :h5
|
||||
|
||||
Here are eaxmples using chunk commands to calculate various
|
||||
properties:
|
||||
|
||||
(1) Average velocity in each of 1000 2d spatial bins:
|
||||
|
||||
compute cc1 all chunk/atom bin/2d x 0.0 0.1 y lower 0.01 units reduced
|
||||
fix 1 all ave/chunk 100 10 1000 cc1 vx vy file tmp.out :pre
|
||||
|
||||
(2) Temperature in each spatial bin, after subtracting a flow
|
||||
velocity:
|
||||
|
||||
compute cc1 all chunk/atom bin/2d x 0.0 0.1 y lower 0.1 units reduced
|
||||
compute vbias all temp/profile 1 0 0 y 10
|
||||
fix 1 all ave/chunk 100 10 1000 cc1 temp bias vbias file tmp.out :pre
|
||||
|
||||
(3) Center of mass of each molecule:
|
||||
|
||||
compute cc1 all chunk/atom molecule
|
||||
compute myChunk all com/chunk cc1
|
||||
fix 1 all ave/time 100 1 100 c_myChunk file tmp.out mode vector :pre
|
||||
|
||||
(4) Total force on each molecule and ave/max across all molecules:
|
||||
|
||||
compute cc1 all chunk/atom molecule
|
||||
fix 1 all ave/chunk 1000 1 1000 cc1 fx fy fz file tmp.out
|
||||
variable xave equal ave(f_1[2])
|
||||
variable xmax equal max(f_1[2])
|
||||
thermo 1000
|
||||
thermo_style custom step temp v_xave v_xmax :pre
|
||||
|
||||
(5) Histogram of cluster sizes:
|
||||
|
||||
compute cluster all cluster/atom 1.0
|
||||
compute cc1 all chunk/atom c_cluster compress yes
|
||||
compute size all property/chunk cc1 count
|
||||
fix 1 all ave/histo 100 1 100 0 20 20 c_size mode vector ave running beyond ignore file tmp.histo :pre
|
||||
|
||||
:line
|
||||
|
||||
6.24 Setting parameters for the "kspace_style pppm/disp"_kspace_style.html command :link(howto_24),h4
|
||||
|
||||
The PPPM method computes interactions by splitting the pair potential
|
||||
into two parts, one of which is computed in a normal pairwise fashion,
|
||||
the so-called real-space part, and one of which is computed using the
|
||||
Fourier transform, the so called reciprocal-space or kspace part. For
|
||||
both parts, the potential is not computed exactly but is approximated.
|
||||
Thus, there is an error in both parts of the computation, the
|
||||
real-space and the kspace error. The just mentioned facts are true
|
||||
both for the PPPM for Coulomb as well as dispersion interactions. The
|
||||
deciding difference - and also the reason why the parameters for
|
||||
pppm/disp have to be selected with more care - is the impact of the
|
||||
errors on the results: The kspace error of the PPPM for Coulomb and
|
||||
dispersion interaction and the real-space error of the PPPM for
|
||||
Coulomb interaction have the character of noise. In contrast, the
|
||||
real-space error of the PPPM for dispersion has a clear physical
|
||||
interpretation: the underprediction of cohesion. As a consequence, the
|
||||
real-space error has a much stronger effect than the kspace error on
|
||||
simulation results for pppm/disp. Parameters must thus be chosen in a
|
||||
way that this error is much smaller than the kspace error.
|
||||
|
||||
When using pppm/disp and not making any specifications on the PPPM
|
||||
parameters via the kspace modify command, parameters will be tuned
|
||||
such that the real-space error and the kspace error are equal. This
|
||||
will result in simulations that are either inaccurate or slow, both of
|
||||
which is not desirable. For selecting parameters for the pppm/disp
|
||||
that provide fast and accurate simulations, there are two approaches,
|
||||
which both have their up- and downsides.
|
||||
|
||||
The first approach is to set desired real-space an kspace accuracies
|
||||
via the {kspace_modify force/disp/real} and {kspace_modify
|
||||
force/disp/kspace} commands. Note that the accuracies have to be
|
||||
specified in force units and are thus dependend on the chosen unit
|
||||
settings. For real units, 0.0001 and 0.002 seem to provide reasonable
|
||||
accurate and efficient computations for the real-space and kspace
|
||||
accuracies. 0.002 and 0.05 work well for most systems using lj
|
||||
units. PPPM parameters will be generated based on the desired
|
||||
accuracies. The upside of this approach is that it usually provides a
|
||||
good set of parameters and will work for both the {kspace_modify diff
|
||||
ad} and {kspace_modify diff ik} options. The downside of the method
|
||||
is that setting the PPPM parameters will take some time during the
|
||||
initialization of the simulation.
|
||||
|
||||
The second approach is to set the parameters for the pppm/disp
|
||||
explicitly using the {kspace_modify mesh/disp}, {kspace_modify
|
||||
order/disp}, and {kspace_modify gewald/disp} commands. This approach
|
||||
requires a more experienced user who understands well the impact of
|
||||
the choice of parameters on the simulation accuracy and
|
||||
performance. This approach provides a fast initialization of the
|
||||
simulation. However, it is sensitive to errors: A combination of
|
||||
parameters that will perform well for one system might result in
|
||||
far-from-optimal conditions for other simulations. For example,
|
||||
parametes that provide accurate and fast computations for
|
||||
all-atomistic force fields can provide insufficient accuracy or
|
||||
united-atomistic force fields (which is related to that the latter
|
||||
typically have larger dispersion coefficients).
|
||||
|
||||
To avoid inaccurate or inefficient simulations, the pppm/disp stops
|
||||
simulations with an error message if no action is taken to control the
|
||||
PPPM parameters. If the automatic parameter generation is desired and
|
||||
real-space and kspace accuracies are desired to be equal, this error
|
||||
message can be suppressed using the {kspace_modify disp/auto yes}
|
||||
command.
|
||||
|
||||
A reasonable approach that combines the upsides of both methods is to
|
||||
make the first run using the {kspace_modify force/disp/real} and
|
||||
{kspace_modify force/disp/kspace} commands, write down the PPPM
|
||||
parameters from the outut, and specify these parameters using the
|
||||
second approach in subsequent runs (which have the same composition,
|
||||
force field, and approximately the same volume).
|
||||
|
||||
Concerning the performance of the pppm/disp there are two more things
|
||||
to consider. The first is that when using the pppm/disp, the cutoff
|
||||
parameter does no longer affect the accuracy of the simulation
|
||||
(subject to that gewald/disp is adjusted when changing the cutoff).
|
||||
The performance can thus be increased by examining different values
|
||||
for the cutoff parameter. A lower bound for the cutoff is only set by
|
||||
the truncation error of the repulsive term of pair potentials.
|
||||
|
||||
The second is that the mixing rule of the pair style has an impact on
|
||||
the computation time when using the pppm/disp. Fastest computations
|
||||
are achieved when using the geometric mixing rule. Using the
|
||||
arithmetic mixing rule substantially increases the computational cost.
|
||||
The computational overhead can be reduced using the {kspace_modify
|
||||
mix/disp geom} and {kspace_modify splittol} commands. The first
|
||||
command simply enforces geometric mixing of the dispersion
|
||||
coeffiecients in kspace computations. This introduces some error in
|
||||
the computations but will also significantly speed-up the
|
||||
simulations. The second keyword sets the accuracy with which the
|
||||
dispersion coefficients are approximated using a matrix factorization
|
||||
approach. This may result in better accuracy then using the first
|
||||
command, but will usually also not provide an equally good increase of
|
||||
efficiency.
|
||||
|
||||
Finally, pppm/disp can also be used when no mixing rules apply.
|
||||
This can be achieved using the {kspace_modify mix/disp none} command.
|
||||
Note that the code does not check automatically whether any mixing
|
||||
rule is fulfilled. If mixing rules do not apply, the user will have
|
||||
to specify this command explicitly.
|
||||
|
||||
:line
|
||||
|
||||
6.25 Adiabatic core/shell model :link(howto_25),h4
|
||||
|
||||
The adiabatic core-shell model by "Mitchell and
|
||||
Finchham"_#MitchellFinchham is a simple method for adding
|
||||
polarizability to a system. In order to mimic the electron shell of
|
||||
an ion, a ghost atom is attached to it. This way the ions are split
|
||||
into a core and a shell where the latter is meant to react to the
|
||||
electrostatic environment inducing polarizability.
|
||||
|
||||
Technically, shells are attached to the cores by a spring force f =
|
||||
k*r where k is a parametrized spring constant and r is the distance
|
||||
between the core and the shell. The charges of the core and the shell
|
||||
add up to the ion charge, thus q(ion) = q(core) + q(shell). In a
|
||||
similar fashion the mass of the ion is distributed on the core and the
|
||||
shell with the core having the larger mass.
|
||||
|
||||
To run this model in LAMMPS, "atom_style"_atom_style.html {full} can
|
||||
be used since atom charge and bonds are needed. Each kind of
|
||||
core/shell pair requires two atom types and a bond type. The core and
|
||||
shell of a core/shell pair should be bonded to each other with a
|
||||
harmonic bond that provides the spring force. For example, a data file
|
||||
for NaCl, as found in examples/coreshell, has this format:
|
||||
|
||||
432 atoms # core and shell atoms
|
||||
216 bonds # number of core/shell springs :pre
|
||||
|
||||
4 atom types # 2 cores and 2 shells for Na and Cl
|
||||
2 bond types :pre
|
||||
|
||||
0.0 24.09597 xlo xhi
|
||||
0.0 24.09597 ylo yhi
|
||||
0.0 24.09597 zlo zhi :pre
|
||||
|
||||
Masses # core/shell mass ratio = 0.1 :pre
|
||||
|
||||
1 20.690784 # Na core
|
||||
2 31.90500 # Cl core
|
||||
3 2.298976 # Na shell
|
||||
4 3.54500 # Cl shell :pre
|
||||
|
||||
Atoms :pre
|
||||
|
||||
1 1 2 1.5005 0.00000000 0.00000000 0.00000000 # core of core/shell pair 1
|
||||
2 1 4 -2.5005 0.00000000 0.00000000 0.00000000 # shell of core/shell pair 1
|
||||
3 2 1 1.5056 4.01599500 4.01599500 4.01599500 # core of core/shell pair 2
|
||||
4 2 3 -0.5056 4.01599500 4.01599500 4.01599500 # shell of core/shell pair 2
|
||||
(...) :pre
|
||||
|
||||
Bonds # Bond topology for spring forces :pre
|
||||
|
||||
1 2 1 2 # spring for core/shell pair 1
|
||||
2 2 3 4 # spring for core/shell pair 2
|
||||
(...) :pre
|
||||
|
||||
Non-Coulombic (e.g. Lennard-Jones) pairwise interactions are only
|
||||
defined between the shells. Coulombic interactions are defined
|
||||
between all cores and shells. If desired, additional bonds can be
|
||||
specified between cores.
|
||||
|
||||
The "special_bonds"_special_bonds.html command should be used to
|
||||
turn-off the Coulombic interaction within core/shell pairs, since that
|
||||
interaction is set by the bond spring. This is done using the
|
||||
"special_bonds"_special_bonds.html command with a 1-2 weight = 0.0,
|
||||
which is the default value.
|
||||
|
||||
Since the core/shell model permits distances of r = 0.0 between the
|
||||
core and shell, a pair style with a "cs" suffix needs to be used to
|
||||
implement a valid long-range Coulombic correction. Several such pair
|
||||
styles are provided in the CORESHELL package. See "this doc
|
||||
page"_pair_cs.html for details. All of the core/shell enabled pair
|
||||
styles require the use of a long-range Coulombic solver, as specified
|
||||
by the "kspace_style"_kspace_style.html command. Either the PPPM or
|
||||
Ewald solvers can be used.
|
||||
|
||||
For the NaCL example problem, these pair style and bond style settings
|
||||
are used:
|
||||
|
||||
pair_style born/coul/long/cs 20.0 20.0
|
||||
pair_coeff * * 0.0 1.000 0.00 0.00 0.00
|
||||
pair_coeff 3 3 487.0 0.23768 0.00 1.05 0.50 #Na-Na
|
||||
pair_coeff 3 4 145134.0 0.23768 0.00 6.99 8.70 #Na-Cl
|
||||
pair_coeff 4 4 405774.0 0.23768 0.00 72.40 145.40 #Cl-Cl :pre
|
||||
|
||||
bond_style harmonic
|
||||
bond_coeff 1 63.014 0.0
|
||||
bond_coeff 2 25.724 0.0 :pre
|
||||
|
||||
When running dynamics with the adiabatic core/shell model, the
|
||||
following issues should be considered. Since the relative motion of
|
||||
the core and shell particles corresponds to the polarization, typical
|
||||
thermostats can alter the polarization behaviour, meaining the shell
|
||||
will not react freely to its electrostatic environment. Therefore
|
||||
it's typically desirable to decouple the relative motion of the
|
||||
core/shell pair, which is an imaginary degree of freedom, from the
|
||||
real physical system. To do that, the "compute
|
||||
temp/cs"_compute_temp_cs.html command can be used, in conjunction with
|
||||
any of the thermostat fixes, such as "fix nvt"_fix_nh.html or "fix
|
||||
langevin"_fix_langevin. This compute uses the center-of-mass velocity
|
||||
of the core/shell pairs to calculate a temperature, and insures that
|
||||
velocity is what is rescaled for thermostatting purposes. The
|
||||
"compute temp/cs"_compute_temp_cs.html command requires input of two
|
||||
groups, one for the core atoms, another for the shell atoms. These
|
||||
can be defined using the "group {type}"_group.html command. Note that
|
||||
to perform thermostatting using this definition of temperature, the
|
||||
"fix modify temp"_fix_modify.html command should be used to assign the
|
||||
comptue to the thermostat fix. Likewise the "thermo_modify
|
||||
temp"_thermo_modify.html command can be used to make this temperature
|
||||
be output for the overall system.
|
||||
|
||||
For the NaCl example, this can be done as follows:
|
||||
|
||||
group cores type 1 2
|
||||
group shells type 3 4
|
||||
compute CSequ all temp/cs cores shells
|
||||
fix thermoberendsen all temp/berendsen 1427 1427 0.4 # thermostat for the true physical system
|
||||
fix thermostatequ all nve # integrator as needed for the berendsen thermostat
|
||||
fix_modify thermoberendsen temp CSequ
|
||||
thermo_modify temp CSequ # output of center-of-mass derived temperature :pre
|
||||
|
||||
When intializing the velocities of a system with core/shell pairs, it
|
||||
is also desirable to not introduce energy into the relative motion of
|
||||
the core/shell particles, but only assign a center-of-mass velocity to
|
||||
the pairs. This can be done by using the {bias} keyword of the
|
||||
"velocity create"_velocity.html command and assigning the "compute
|
||||
temp/cs"_compute_temp_cs.html command to the {temp} keyword of the
|
||||
"velocity"_velocity.html commmand, e.g.
|
||||
|
||||
velocity all create 1427 134 bias yes temp CSequ
|
||||
velocity all scale 1427 temp CSequ :pre
|
||||
|
||||
It is important to note that the polarizability of the core/shell
|
||||
pairs is based on their relative motion. Therefore the choice of
|
||||
spring force and mass ratio need to ensure much faster relative motion
|
||||
of the 2 atoms within the core/shell pair than their center-of-mass
|
||||
velocity. This allow the shells to effectively react instantaneously
|
||||
to the electrostatic environment. This fast movement also limits the
|
||||
timestep size that can be used.
|
||||
|
||||
Additionally, the mass mismatch of the core and shell particles means
|
||||
that only a small amount of energy is transfered to the decoupled
|
||||
imaginary degrees of freedom. However, this transfer will typically
|
||||
lead to a a small drift in total energy over time. This internal
|
||||
energy can be monitored using the "compute
|
||||
chunk/atom"_compute_chunk_atom.html and "compute
|
||||
temp/chunk"_compute_temp_chunk.html commands. The internal kinetic
|
||||
energies of each core/shell pair can then be summed using the sum()
|
||||
special functino of the "variable"_variable.html command. Or they can
|
||||
be time/averaged and output using the "fix ave/time"_fix_ave_time.html
|
||||
command. To use these commands, each core/shell pair must be defined
|
||||
as a "chunk". If each core/shell pair is defined as its own molecule,
|
||||
the molecule ID can be used to define the chunks. If cores are bonded
|
||||
to each other to form larger molecules, then another way to define the
|
||||
chunks is to use the "fix property/atom"_fix_property_atom.html to
|
||||
assign a core/shell ID to each atom via a special field in the data
|
||||
file read by the "read_data"_read_data.html command. This field can
|
||||
then be accessed by the "compute
|
||||
property/atom"_compute_property_atom.html command, to use as input to
|
||||
the "compute chunk/atom"_compute_chunk_atom.html command to define the
|
||||
core/shell pairs as chunks.
|
||||
|
||||
For example,
|
||||
|
||||
fix csinfo all property/atom i_CSID # property/atom command
|
||||
read_data NaCl_CS_x0.1_prop.data fix csinfo NULL CS-Info # atom property added in the data-file
|
||||
compute prop all property/atom i_CSID
|
||||
compute cs_chunk all chunk/atom c_prop
|
||||
compute cstherm all temp/chunk cs_chunk temp internal com yes cdof 3.0 # note the chosen degrees of freedom for the core/shell pairs
|
||||
fix ave_chunk all ave/time 10 1 10 c_cstherm file chunk.dump mode vector :pre
|
||||
|
||||
The additional section in the date file would be formatted like this:
|
||||
|
||||
CS-Info # header of additional section :pre
|
||||
|
||||
1 1 # column 1 = atom ID, column 2 = core/shell ID
|
||||
2 1
|
||||
3 2
|
||||
4 2
|
||||
5 3
|
||||
6 3
|
||||
7 4
|
||||
8 4
|
||||
(...) :pre
|
||||
|
||||
:line
|
||||
:line
|
||||
|
||||
@ -2167,3 +2626,7 @@ Phys, 79, 926 (1983).
|
||||
|
||||
:link(Shinoda)
|
||||
[(Shinoda)] Shinoda, Shiga, and Mikami, Phys Rev B, 69, 134103 (2004).
|
||||
|
||||
:link(MitchellFinchham)
|
||||
[(Mitchell and Finchham)] Mitchell, Finchham, J Phys Condensed Matter,
|
||||
5, 1031-1038 (1993).
|
||||
|
||||
@ -144,7 +144,7 @@ commands)
|
||||
</P>
|
||||
<UL><LI> pairwise potentials: Lennard-Jones, Buckingham, Morse, Born-Mayer-Huggins, Yukawa, soft, class 2 (COMPASS), hydrogen bond, tabulated
|
||||
<LI> charged pairwise potentials: Coulombic, point-dipole
|
||||
<LI> manybody potentials: EAM, Finnis/Sinclair EAM, modified EAM (MEAM), embedded ion method (EIM), EDIP, ADP, Stillinger-Weber, Tersoff, REBO, AIREBO, ReaxFF, COMB, SNAP
|
||||
<LI> manybody potentials: EAM, Finnis/Sinclair EAM, modified EAM (MEAM), embedded ion method (EIM), EDIP, ADP, Stillinger-Weber, Tersoff, REBO, AIREBO, ReaxFF, COMB, SNAP, Streitz-Mintmire
|
||||
<LI> charge equilibration (QEq via dynamic, point, shielded, Slater methods)
|
||||
<LI> electron force field (eFF, AWPMD)
|
||||
<LI> coarse-grained potentials: DPD, GayBerne, REsquared, colloidal, DLVO
|
||||
@ -188,7 +188,8 @@ commands)
|
||||
<LI> harmonic (umbrella) constraint forces
|
||||
<LI> rigid body constraints
|
||||
<LI> SHAKE bond and angle constraints
|
||||
<LI> bond breaking, formation, swapping
|
||||
<LI> Monte Carlo bond breaking, formation, swapping
|
||||
<LI> atom/molecule insertion and deletion
|
||||
<LI> walls of various kinds
|
||||
<LI> non-equilibrium molecular dynamics (NEMD)
|
||||
<LI> variety of additional boundary conditions and constraints
|
||||
@ -256,8 +257,8 @@ molecular dynamics options:
|
||||
<LI><A HREF = "fix_atc.html">atom-to-continuum coupling</A> with finite elements
|
||||
<LI>coupled rigid body integration via the <A HREF = "fix_poems.html">POEMS</A> library
|
||||
<LI><A HREF = "fix_qmmm.html">QM/MM coupling</A>
|
||||
<LI><A HREF = "fix_ipi.html">path-integral molecular dynamics (PIMD)</A>
|
||||
<LI><A HREF = "fix_gcmc.html">grand canonical Monte Carlo</A> insertions/deletions
|
||||
<LI><A HREF = "fix_ipi.html">path-integral molecular dynamics (PIMD)</A> and <A HREF = "fix_pimd.html">this as well</A>
|
||||
<LI>Monte Carlo via <A HREF = "fix_gcmc.html">GCMC</A> and <A HREF = "fix_tfmc.html">tfMC</A> and <A HREF = "fix_swap.html">atom swapping</A>
|
||||
<LI><A HREF = "pair_dsmc.html">Direct Simulation Monte Carlo</A> for low-density fluids
|
||||
<LI><A HREF = "pair_peri.html">Peridynamics mesoscale modeling</A>
|
||||
<LI><A HREF = "fix_lb_fluid.html">Lattice Boltzmann fluid</A>
|
||||
|
||||
@ -141,7 +141,7 @@ commands)
|
||||
charged pairwise potentials: Coulombic, point-dipole
|
||||
manybody potentials: EAM, Finnis/Sinclair EAM, modified EAM (MEAM), \
|
||||
embedded ion method (EIM), EDIP, ADP, Stillinger-Weber, Tersoff, \
|
||||
REBO, AIREBO, ReaxFF, COMB, SNAP
|
||||
REBO, AIREBO, ReaxFF, COMB, SNAP, Streitz-Mintmire
|
||||
charge equilibration (QEq via dynamic, point, shielded, Slater methods)
|
||||
electron force field (eFF, AWPMD)
|
||||
coarse-grained potentials: DPD, GayBerne, REsquared, colloidal, DLVO
|
||||
@ -189,7 +189,8 @@ Ensembles, constraints, and boundary conditions :h4
|
||||
harmonic (umbrella) constraint forces
|
||||
rigid body constraints
|
||||
SHAKE bond and angle constraints
|
||||
bond breaking, formation, swapping
|
||||
Monte Carlo bond breaking, formation, swapping
|
||||
atom/molecule insertion and deletion
|
||||
walls of various kinds
|
||||
non-equilibrium molecular dynamics (NEMD)
|
||||
variety of additional boundary conditions and constraints :ul
|
||||
@ -254,8 +255,8 @@ molecular dynamics options:
|
||||
"atom-to-continuum coupling"_fix_atc.html with finite elements
|
||||
coupled rigid body integration via the "POEMS"_fix_poems.html library
|
||||
"QM/MM coupling"_fix_qmmm.html
|
||||
"path-integral molecular dynamics (PIMD)"_fix_ipi.html
|
||||
"grand canonical Monte Carlo"_fix_gcmc.html insertions/deletions
|
||||
"path-integral molecular dynamics (PIMD)"_fix_ipi.html and "this as well"_fix_pimd.html
|
||||
Monte Carlo via "GCMC"_fix_gcmc.html and "tfMC"_fix_tfmc.html and "atom swapping"_fix_swap.html
|
||||
"Direct Simulation Monte Carlo"_pair_dsmc.html for low-density fluids
|
||||
"Peridynamics mesoscale modeling"_pair_peri.html
|
||||
"Lattice Boltzmann fluid"_fix_lb_fluid.html
|
||||
|
||||
@ -44,26 +44,28 @@ packages, more details are provided.
|
||||
</P>
|
||||
<DIV ALIGN=center><TABLE BORDER=1 >
|
||||
<TR ALIGN="center"><TD >Package</TD><TD > Description</TD><TD > Author(s)</TD><TD > Doc page</TD><TD > Example</TD><TD > Library</TD></TR>
|
||||
<TR ALIGN="center"><TD >ASPHERE</TD><TD > aspherical particles</TD><TD > -</TD><TD > <A HREF = "Section_howto.html#howto_14">Section_howto</A></TD><TD > ellipse</TD><TD > -</TD></TR>
|
||||
<TR ALIGN="center"><TD >ASPHERE</TD><TD > aspherical particles</TD><TD > -</TD><TD > <A HREF = "Section_howto.html#howto_14">Section_howto 6.14</A></TD><TD > ellipse</TD><TD > -</TD></TR>
|
||||
<TR ALIGN="center"><TD >BODY</TD><TD > body-style particles</TD><TD > -</TD><TD > <A HREF = "body.html">body</A></TD><TD > body</TD><TD > -</TD></TR>
|
||||
<TR ALIGN="center"><TD >CLASS2</TD><TD > class 2 force fields</TD><TD > -</TD><TD > <A HREF = "pair_class2.html">pair_style lj/class2</A></TD><TD > -</TD><TD > -</TD></TR>
|
||||
<TR ALIGN="center"><TD >COLLOID</TD><TD > colloidal particles</TD><TD > -</TD><TD > <A HREF = "atom_style.html">atom_style colloid</A></TD><TD > colloid</TD><TD > -</TD></TR>
|
||||
<TR ALIGN="center"><TD >CORESHELL</TD><TD > adiabatic core/shell model</TD><TD > Hendrik Heenen (Technical U of Munich)</TD><TD > <A HREF = "Section_howto.html#howto_25">Section_howto 6.25</A></TD><TD > coreshell</TD><TD > -</TD></TR>
|
||||
<TR ALIGN="center"><TD >DIPOLE</TD><TD > point dipole particles</TD><TD > -</TD><TD > <A HREF = "pair_dipole.html">pair_style dipole/cut</A></TD><TD > dipole</TD><TD > -</TD></TR>
|
||||
<TR ALIGN="center"><TD >FLD</TD><TD > Fast Lubrication Dynamics</TD><TD > Kumar & Bybee & Higdon (1)</TD><TD > <A HREF = "pair_lubricateU.html">pair_style lubricateU</A></TD><TD > -</TD><TD > -</TD></TR>
|
||||
<TR ALIGN="center"><TD >GPU</TD><TD > GPU-enabled styles</TD><TD > Mike Brown (ORNL)</TD><TD > <A HREF = "Section_accelerate.html#acc_6">Section accelerate</A></TD><TD > gpu</TD><TD > lib/gpu</TD></TR>
|
||||
<TR ALIGN="center"><TD >GRANULAR</TD><TD > granular systems</TD><TD > -</TD><TD > <A HREF = "Section_howto.html#howto_6">Section_howto</A></TD><TD > pour</TD><TD > -</TD></TR>
|
||||
<TR ALIGN="center"><TD >GPU</TD><TD > GPU-enabled styles</TD><TD > Mike Brown (ORNL)</TD><TD > <A HREF = "accelerate_gpu.html">Section accelerate</A></TD><TD > gpu</TD><TD > lib/gpu</TD></TR>
|
||||
<TR ALIGN="center"><TD >GRANULAR</TD><TD > granular systems</TD><TD > -</TD><TD > <A HREF = "Section_howto.html#howto_6">Section_howto 6.6</A></TD><TD > pour</TD><TD > -</TD></TR>
|
||||
<TR ALIGN="center"><TD >KIM</TD><TD > openKIM potentials</TD><TD > Smirichinski & Elliot & Tadmor (3)</TD><TD > <A HREF = "pair_kim.html">pair_style kim</A></TD><TD > kim</TD><TD > KIM</TD></TR>
|
||||
<TR ALIGN="center"><TD >KOKKOS</TD><TD > Kokkos-enabled styles</TD><TD > Trott & Edwards (4)</TD><TD > <A HREF = "Section_accelerate.html#acc_8">Section_accelerate</A></TD><TD > kokkos</TD><TD > lib/kokkos</TD></TR>
|
||||
<TR ALIGN="center"><TD >KOKKOS</TD><TD > Kokkos-enabled styles</TD><TD > Trott & Edwards (4)</TD><TD > <A HREF = "accelerate_kokkos.html">Section_accelerate</A></TD><TD > kokkos</TD><TD > lib/kokkos</TD></TR>
|
||||
<TR ALIGN="center"><TD >KSPACE</TD><TD > long-range Coulombic solvers</TD><TD > -</TD><TD > <A HREF = "kspace_style.html">kspace_style</A></TD><TD > peptide</TD><TD > -</TD></TR>
|
||||
<TR ALIGN="center"><TD >MANYBODY</TD><TD > many-body potentials</TD><TD > -</TD><TD > <A HREF = "pair_tersoff.html">pair_style tersoff</A></TD><TD > shear</TD><TD > -</TD></TR>
|
||||
<TR ALIGN="center"><TD >MEAM</TD><TD > modified EAM potential</TD><TD > Greg Wagner (Sandia)</TD><TD > <A HREF = "pair_meam.html">pair_style meam</A></TD><TD > meam</TD><TD > lib/meam</TD></TR>
|
||||
<TR ALIGN="center"><TD >MC</TD><TD > Monte Carlo options</TD><TD > -</TD><TD > <A HREF = "fix_gcmc.html">fix gcmc</A></TD><TD > -</TD><TD > -</TD></TR>
|
||||
<TR ALIGN="center"><TD >MOLECULE</TD><TD > molecular system force fields</TD><TD > -</TD><TD > <A HREF = "Section_howto.html#howto_3">Section_howto</A></TD><TD > peptide</TD><TD > -</TD></TR>
|
||||
<TR ALIGN="center"><TD >OPT</TD><TD > optimized pair styles</TD><TD > Fischer & Richie & Natoli (2)</TD><TD > <A HREF = "Section_accelerate.html#acc_4">Section accelerate</A></TD><TD > -</TD><TD > -</TD></TR>
|
||||
<TR ALIGN="center"><TD >MOLECULE</TD><TD > molecular system force fields</TD><TD > -</TD><TD > <A HREF = "Section_howto.html#howto_3">Section_howto 6.3</A></TD><TD > peptide</TD><TD > -</TD></TR>
|
||||
<TR ALIGN="center"><TD >OPT</TD><TD > optimized pair styles</TD><TD > Fischer & Richie & Natoli (2)</TD><TD > <A HREF = "accelerate_opt.html">Section accelerate</A></TD><TD > -</TD><TD > -</TD></TR>
|
||||
<TR ALIGN="center"><TD >PERI</TD><TD > Peridynamics models</TD><TD > Mike Parks (Sandia)</TD><TD > <A HREF = "pair_peri.html">pair_style peri</A></TD><TD > peri</TD><TD > -</TD></TR>
|
||||
<TR ALIGN="center"><TD >POEMS</TD><TD > coupled rigid body motion</TD><TD > Rudra Mukherjee (JPL)</TD><TD > <A HREF = "fix_poems.html">fix poems</A></TD><TD > rigid</TD><TD > lib/poems</TD></TR>
|
||||
<TR ALIGN="center"><TD >PYTHON</TD><TD > embed Python code in an input script</TD><TD > -</TD><TD > <A HREF = "python.html">python</A></TD><TD > python</TD><TD > lib/python</TD></TR>
|
||||
<TR ALIGN="center"><TD >REAX</TD><TD > ReaxFF potential</TD><TD > Aidan Thompson (Sandia)</TD><TD > <A HREF = "pair_reax.html">pair_style reax</A></TD><TD > reax</TD><TD > lib/reax</TD></TR>
|
||||
<TR ALIGN="center"><TD >REPLICA</TD><TD > multi-replica methods</TD><TD > -</TD><TD > <A HREF = "Section_howto.html#howto_5">Section_howto</A></TD><TD > tad</TD><TD > -</TD></TR>
|
||||
<TR ALIGN="center"><TD >REPLICA</TD><TD > multi-replica methods</TD><TD > -</TD><TD > <A HREF = "Section_howto.html#howto_5">Section_howto 6.5</A></TD><TD > tad</TD><TD > -</TD></TR>
|
||||
<TR ALIGN="center"><TD >RIGID</TD><TD > rigid bodies</TD><TD > -</TD><TD > <A HREF = "fix_rigid.html">fix rigid</A></TD><TD > rigid</TD><TD > -</TD></TR>
|
||||
<TR ALIGN="center"><TD >SHOCK</TD><TD > shock loading methods</TD><TD > -</TD><TD > <A HREF = "fix_msst.html">fix msst</A></TD><TD > -</TD><TD > -</TD></TR>
|
||||
<TR ALIGN="center"><TD >SNAP</TD><TD > quantum-fit potential</TD><TD > Aidan Thompson (Sandia)</TD><TD > <A HREF = "pair_snap.html">pair snap</A></TD><TD > snap</TD><TD > -</TD></TR>
|
||||
@ -123,16 +125,17 @@ on how to build LAMMPS with both kinds of auxiliary libraries.
|
||||
<TR ALIGN="center"><TD >USER-AWPMD</TD><TD > wave-packet MD</TD><TD > Ilya Valuev (JIHT)</TD><TD > <A HREF = "pair_awpmd.html">pair_style awpmd/cut</A></TD><TD > USER/awpmd</TD><TD > -</TD><TD > lib/awpmd</TD></TR>
|
||||
<TR ALIGN="center"><TD >USER-CG-CMM</TD><TD > coarse-graining model</TD><TD > Axel Kohlmeyer (Temple U)</TD><TD > <A HREF = "pair_sdk.html">pair_style lj/sdk</A></TD><TD > USER/cg-cmm</TD><TD > <A HREF = "http://lammps.sandia.gov/pictures.html#cg">cg</A></TD><TD > -</TD></TR>
|
||||
<TR ALIGN="center"><TD >USER-COLVARS</TD><TD > collective variables</TD><TD > Fiorin & Henin & Kohlmeyer (3)</TD><TD > <A HREF = "fix_colvars.html">fix colvars</A></TD><TD > USER/colvars</TD><TD > <A HREF = "colvars">colvars</A></TD><TD > lib/colvars</TD></TR>
|
||||
<TR ALIGN="center"><TD >USER-CUDA</TD><TD > NVIDIA GPU styles</TD><TD > Christian Trott (U Tech Ilmenau)</TD><TD > <A HREF = "Section_accelerate.html#acc_7">Section accelerate</A></TD><TD > USER/cuda</TD><TD > -</TD><TD > lib/cuda</TD></TR>
|
||||
<TR ALIGN="center"><TD >USER-CUDA</TD><TD > NVIDIA GPU styles</TD><TD > Christian Trott (U Tech Ilmenau)</TD><TD > <A HREF = "accelerate_cuda.html">Section accelerate</A></TD><TD > USER/cuda</TD><TD > -</TD><TD > lib/cuda</TD></TR>
|
||||
<TR ALIGN="center"><TD >USER-EFF</TD><TD > electron force field</TD><TD > Andres Jaramillo-Botero (Caltech)</TD><TD > <A HREF = "pair_eff.html">pair_style eff/cut</A></TD><TD > USER/eff</TD><TD > <A HREF = "http://lammps.sandia.gov/movies.html#eff">eff</A></TD><TD > -</TD></TR>
|
||||
<TR ALIGN="center"><TD >USER-FEP</TD><TD > free energy perturbation</TD><TD > Agilio Padua (U Blaise Pascal Clermont-Ferrand)</TD><TD > <A HREF = "fix_adapt.html">fix adapt/fep</A></TD><TD > USER/fep</TD><TD > -</TD><TD > -</TD></TR>
|
||||
<TR ALIGN="center"><TD >USER-INTEL</TD><TD > Vectorized CPU and Intel(R) coprocessor styles</TD><TD > W. Michael Brown (Intel)</TD><TD > <A HREF = "Section_accelerate.html#acc_9">Section accelerate</A></TD><TD > examples/intel</TD><TD > -</TD><TD > -</TD></TR>
|
||||
<TR ALIGN="center"><TD >USER-INTEL</TD><TD > Vectorized CPU and Intel(R) coprocessor styles</TD><TD > W. Michael Brown (Intel)</TD><TD > <A HREF = "accelerate_intel.html">Section accelerate</A></TD><TD > examples/intel</TD><TD > -</TD><TD > -</TD></TR>
|
||||
<TR ALIGN="center"><TD >USER-LB</TD><TD > Lattice Boltzmann fluid</TD><TD > Colin Denniston (U Western Ontario)</TD><TD > <A HREF = "fix_lb_fluid.html">fix lb/fluid</A></TD><TD > USER/lb</TD><TD > -</TD><TD > -</TD></TR>
|
||||
<TR ALIGN="center"><TD >USER-MISC</TD><TD > single-file contributions</TD><TD > USER-MISC/README</TD><TD > USER-MISC/README</TD><TD > -</TD><TD > -</TD><TD > -</TD></TR>
|
||||
<TR ALIGN="center"><TD >USER-MOLFILE</TD><TD > <A HREF = "http://www.ks.uiuc.edu/Research/vmd">VMD</A> molfile plug-ins</TD><TD > Axel Kohlmeyer (Temple U)</TD><TD > <A HREF = "dump_molfile.html">dump molfile</A></TD><TD > -</TD><TD > -</TD><TD > VMD-MOLFILE</TD></TR>
|
||||
<TR ALIGN="center"><TD >USER-OMP</TD><TD > OpenMP threaded styles</TD><TD > Axel Kohlmeyer (Temple U)</TD><TD > <A HREF = "Section_accelerate.html#acc_5">Section accelerate</A></TD><TD > -</TD><TD > -</TD><TD > -</TD></TR>
|
||||
<TR ALIGN="center"><TD >USER-OMP</TD><TD > OpenMP threaded styles</TD><TD > Axel Kohlmeyer (Temple U)</TD><TD > <A HREF = "accelerate_omp.html">Section accelerate</A></TD><TD > -</TD><TD > -</TD><TD > -</TD></TR>
|
||||
<TR ALIGN="center"><TD >USER-PHONON</TD><TD > phonon dynamical matrix</TD><TD > Ling-Ti Kong (Shanghai Jiao Tong U)</TD><TD > <A HREF = "fix_phonon.html">fix phonon</A></TD><TD > USER/phonon</TD><TD > -</TD><TD > -</TD></TR>
|
||||
<TR ALIGN="center"><TD >USER-QMMM</TD><TD > QM/MM coupling</TD><TD > Axel Kohlmeyer (Temple U)</TD><TD > <A HREF = "fix_qmmm.html">fix qmmm</A></TD><TD > lib/qmmm/example1</TD><TD > -</TD><TD > lib/qmmm</TD></TR>
|
||||
<TR ALIGN="center"><TD >USER-QMMM</TD><TD > QM/MM coupling</TD><TD > Axel Kohlmeyer (Temple U)</TD><TD > <A HREF = "fix_qmmm.html">fix qmmm</A></TD><TD > USER/qmmm</TD><TD > -</TD><TD > lib/qmmm</TD></TR>
|
||||
<TR ALIGN="center"><TD >USER-QUIP</TD><TD > QM/MM coupling</TD><TD > Albert Bartok-Partay (U Cambridge)</TD><TD > <A HREF = "fix_quip.html">fix quip</A></TD><TD > USER/quip</TD><TD > -</TD><TD > lib/quip</TD></TR>
|
||||
<TR ALIGN="center"><TD >USER-REAXC</TD><TD > C version of ReaxFF</TD><TD > Metin Aktulga (LBNL)</TD><TD > <A HREF = "pair_reax_c.html">pair_style reaxc</A></TD><TD > reax</TD><TD > -</TD><TD > -</TD></TR>
|
||||
<TR ALIGN="center"><TD >USER-SPH</TD><TD > smoothed particle hydrodynamics</TD><TD > Georg Ganzenmuller (EMI)</TD><TD > <A HREF = "USER/sph/SPH_LAMMPS_userguide.pdf">userguide.pdf</A></TD><TD > USER/sph</TD><TD > <A HREF = "http://lammps.sandia.gov/movies.html#sph">sph</A></TD><TD > -</TD></TR>
|
||||
<TR ALIGN="center"><TD >
|
||||
|
||||
@ -39,26 +39,28 @@ packages, more details are provided.
|
||||
The current list of standard packages is as follows:
|
||||
|
||||
Package, Description, Author(s), Doc page, Example, Library
|
||||
ASPHERE, aspherical particles, -, "Section_howto"_Section_howto.html#howto_14, ellipse, -
|
||||
ASPHERE, aspherical particles, -, "Section_howto 6.14"_Section_howto.html#howto_14, ellipse, -
|
||||
BODY, body-style particles, -, "body"_body.html, body, -
|
||||
CLASS2, class 2 force fields, -, "pair_style lj/class2"_pair_class2.html, -, -
|
||||
COLLOID, colloidal particles, -, "atom_style colloid"_atom_style.html, colloid, -
|
||||
CORESHELL, adiabatic core/shell model, Hendrik Heenen (Technical U of Munich), "Section_howto 6.25"_Section_howto.html#howto_25, coreshell, -
|
||||
DIPOLE, point dipole particles, -, "pair_style dipole/cut"_pair_dipole.html, dipole, -
|
||||
FLD, Fast Lubrication Dynamics, Kumar & Bybee & Higdon (1), "pair_style lubricateU"_pair_lubricateU.html, -, -
|
||||
GPU, GPU-enabled styles, Mike Brown (ORNL), "Section accelerate"_Section_accelerate.html#acc_6, gpu, lib/gpu
|
||||
GRANULAR, granular systems, -, "Section_howto"_Section_howto.html#howto_6, pour, -
|
||||
GPU, GPU-enabled styles, Mike Brown (ORNL), "Section accelerate"_accelerate_gpu.html, gpu, lib/gpu
|
||||
GRANULAR, granular systems, -, "Section_howto 6.6"_Section_howto.html#howto_6, pour, -
|
||||
KIM, openKIM potentials, Smirichinski & Elliot & Tadmor (3), "pair_style kim"_pair_kim.html, kim, KIM
|
||||
KOKKOS, Kokkos-enabled styles, Trott & Edwards (4), "Section_accelerate"_Section_accelerate.html#acc_8, kokkos, lib/kokkos
|
||||
KOKKOS, Kokkos-enabled styles, Trott & Edwards (4), "Section_accelerate"_accelerate_kokkos.html, kokkos, lib/kokkos
|
||||
KSPACE, long-range Coulombic solvers, -, "kspace_style"_kspace_style.html, peptide, -
|
||||
MANYBODY, many-body potentials, -, "pair_style tersoff"_pair_tersoff.html, shear, -
|
||||
MEAM, modified EAM potential, Greg Wagner (Sandia), "pair_style meam"_pair_meam.html, meam, lib/meam
|
||||
MC, Monte Carlo options, -, "fix gcmc"_fix_gcmc.html, -, -
|
||||
MOLECULE, molecular system force fields, -, "Section_howto"_Section_howto.html#howto_3, peptide, -
|
||||
OPT, optimized pair styles, Fischer & Richie & Natoli (2), "Section accelerate"_Section_accelerate.html#acc_4, -, -
|
||||
MOLECULE, molecular system force fields, -, "Section_howto 6.3"_Section_howto.html#howto_3, peptide, -
|
||||
OPT, optimized pair styles, Fischer & Richie & Natoli (2), "Section accelerate"_accelerate_opt.html, -, -
|
||||
PERI, Peridynamics models, Mike Parks (Sandia), "pair_style peri"_pair_peri.html, peri, -
|
||||
POEMS, coupled rigid body motion, Rudra Mukherjee (JPL), "fix poems"_fix_poems.html, rigid, lib/poems
|
||||
PYTHON, embed Python code in an input script, -, "python"_python.html, python, lib/python
|
||||
REAX, ReaxFF potential, Aidan Thompson (Sandia), "pair_style reax"_pair_reax.html, reax, lib/reax
|
||||
REPLICA, multi-replica methods, -, "Section_howto"_Section_howto.html#howto_5, tad, -
|
||||
REPLICA, multi-replica methods, -, "Section_howto 6.5"_Section_howto.html#howto_5, tad, -
|
||||
RIGID, rigid bodies, -, "fix rigid"_fix_rigid.html, rigid, -
|
||||
SHOCK, shock loading methods, -, "fix msst"_fix_msst.html, -, -
|
||||
SNAP, quantum-fit potential, Aidan Thompson (Sandia), "pair snap"_pair_snap.html, snap, -
|
||||
@ -115,16 +117,17 @@ USER-ATC, atom-to-continuum coupling, Jones & Templeton & Zimmerman (2), "fix at
|
||||
USER-AWPMD, wave-packet MD, Ilya Valuev (JIHT), "pair_style awpmd/cut"_pair_awpmd.html, USER/awpmd, -, lib/awpmd
|
||||
USER-CG-CMM, coarse-graining model, Axel Kohlmeyer (Temple U), "pair_style lj/sdk"_pair_sdk.html, USER/cg-cmm, "cg"_cg, -
|
||||
USER-COLVARS, collective variables, Fiorin & Henin & Kohlmeyer (3), "fix colvars"_fix_colvars.html, USER/colvars, "colvars"_colvars, lib/colvars
|
||||
USER-CUDA, NVIDIA GPU styles, Christian Trott (U Tech Ilmenau), "Section accelerate"_Section_accelerate.html#acc_7, USER/cuda, -, lib/cuda
|
||||
USER-CUDA, NVIDIA GPU styles, Christian Trott (U Tech Ilmenau), "Section accelerate"_accelerate_cuda.html, USER/cuda, -, lib/cuda
|
||||
USER-EFF, electron force field, Andres Jaramillo-Botero (Caltech), "pair_style eff/cut"_pair_eff.html, USER/eff, "eff"_eff, -
|
||||
USER-FEP, free energy perturbation, Agilio Padua (U Blaise Pascal Clermont-Ferrand), "fix adapt/fep"_fix_adapt.html, USER/fep, -, -
|
||||
USER-INTEL, Vectorized CPU and Intel(R) coprocessor styles, W. Michael Brown (Intel), "Section accelerate"_Section_accelerate.html#acc_9, examples/intel, -, -
|
||||
USER-INTEL, Vectorized CPU and Intel(R) coprocessor styles, W. Michael Brown (Intel), "Section accelerate"_accelerate_intel.html, examples/intel, -, -
|
||||
USER-LB, Lattice Boltzmann fluid, Colin Denniston (U Western Ontario), "fix lb/fluid"_fix_lb_fluid.html, USER/lb, -, -
|
||||
USER-MISC, single-file contributions, USER-MISC/README, USER-MISC/README, -, -, -
|
||||
USER-MOLFILE, "VMD"_VMD molfile plug-ins, Axel Kohlmeyer (Temple U), "dump molfile"_dump_molfile.html, -, -, VMD-MOLFILE
|
||||
USER-OMP, OpenMP threaded styles, Axel Kohlmeyer (Temple U), "Section accelerate"_Section_accelerate.html#acc_5, -, -, -
|
||||
USER-OMP, OpenMP threaded styles, Axel Kohlmeyer (Temple U), "Section accelerate"_accelerate_omp.html, -, -, -
|
||||
USER-PHONON, phonon dynamical matrix, Ling-Ti Kong (Shanghai Jiao Tong U), "fix phonon"_fix_phonon.html, USER/phonon, -, -
|
||||
USER-QMMM, QM/MM coupling, Axel Kohlmeyer (Temple U), "fix qmmm"_fix_qmmm.html, lib/qmmm/example1, -, lib/qmmm
|
||||
USER-QMMM, QM/MM coupling, Axel Kohlmeyer (Temple U), "fix qmmm"_fix_qmmm.html, USER/qmmm, -, lib/qmmm
|
||||
USER-QUIP, QM/MM coupling, Albert Bartok-Partay (U Cambridge), "fix quip"_fix_quip.html, USER/quip, -, lib/quip
|
||||
USER-REAXC, C version of ReaxFF, Metin Aktulga (LBNL), "pair_style reaxc"_pair_reax_c.html, reax, -, -
|
||||
USER-SPH, smoothed particle hydrodynamics, Georg Ganzenmuller (EMI), "userguide.pdf"_USER/sph/SPH_LAMMPS_userguide.pdf, USER/sph, "sph"_sph, -
|
||||
:tb(ea=c)
|
||||
|
||||
@ -11,61 +11,98 @@
|
||||
|
||||
<H3>11. Python interface to LAMMPS
|
||||
</H3>
|
||||
<P>This section describes how to build and use LAMMPS via a Python
|
||||
interface.
|
||||
<P>LAMMPS can work together with Python in two ways. First, Python can
|
||||
wrap LAMMPS through the <A HREF = "Section_howto.html#howto_19">LAMMPS library
|
||||
interface</A>, so that a Python script can
|
||||
create one or more instances of LAMMPS and launch one or more
|
||||
simulations. In Python lingo, this is "extending" Python with LAMMPS.
|
||||
</P>
|
||||
<UL><LI>11.1 <A HREF = "#py_1">Building LAMMPS as a shared library</A>
|
||||
<LI>11.2 <A HREF = "#py_2">Installing the Python wrapper into Python</A>
|
||||
<LI>11.3 <A HREF = "#py_3">Extending Python with MPI to run in parallel</A>
|
||||
<LI>11.4 <A HREF = "#py_4">Testing the Python-LAMMPS interface</A>
|
||||
<LI>11.5 <A HREF = "#py_5">Using LAMMPS from Python</A>
|
||||
<LI>11.6 <A HREF = "#py_6">Example Python scripts that use LAMMPS</A>
|
||||
<P>Second, LAMMPS can use the Python interpreter, so that a LAMMPS input
|
||||
script can invoke Python code, and pass information back-and-forth
|
||||
between the input script and Python functions you write. The Python
|
||||
code can also callback to LAMMPS to query or change its attributes.
|
||||
In Python lingo, this is "embedding" Python in LAMMPS.
|
||||
</P>
|
||||
<P>This section describes how to do both.
|
||||
</P>
|
||||
<UL><LI>11.1 <A HREF = "#py_1">Overview of running LAMMPS from Python</A>
|
||||
<LI>11.2 <A HREF = "#py_2">Overview of using Python from a LAMMPS script</A>
|
||||
<LI>11.3 <A HREF = "#py_3">Building LAMMPS as a shared library</A>
|
||||
<LI>11.4 <A HREF = "#py_4">Installing the Python wrapper into Python</A>
|
||||
<LI>11.5 <A HREF = "#py_5">Extending Python with MPI to run in parallel</A>
|
||||
<LI>11.6 <A HREF = "#py_6">Testing the Python-LAMMPS interface</A>
|
||||
<LI>11.7 <A HREF = "#py_7">Using LAMMPS from Python</A>
|
||||
<LI>11.8 <A HREF = "#py_8">Example Python scripts that use LAMMPS</A>
|
||||
</UL>
|
||||
<P>The LAMMPS distribution includes the file python/lammps.py which wraps
|
||||
the library interface to LAMMPS. This file makes it is possible to
|
||||
run LAMMPS, invoke LAMMPS commands or give it an input script, extract
|
||||
LAMMPS results, an modify internal LAMMPS variables, either from a
|
||||
Python script or interactively from a Python prompt. You can do the
|
||||
former in serial or parallel. Running Python interactively in
|
||||
parallel does not generally work, unless you have a package installed
|
||||
that extends your Python to enable multiple instances of Python to
|
||||
read what you type.
|
||||
<P>If you are not familiar with it, <A HREF = "http://www.python.org">Python</A> is a
|
||||
powerful scripting and programming language which can essentially do
|
||||
anything that faster, lower-level languages like C or C++ can do, but
|
||||
typically with much fewer lines of code. When used in embedded mode,
|
||||
Python can perform operations that the simplistic LAMMPS input script
|
||||
syntax cannot. Python can be also be used as a "glue" language to
|
||||
drive a program through its library interface, or to hook multiple
|
||||
pieces of software together, such as a simulation package plus a
|
||||
visualization package, or to run a coupled multiscale or multiphysics
|
||||
model.
|
||||
</P>
|
||||
<P><A HREF = "http://www.python.org">Python</A> is a powerful scripting and programming
|
||||
language which can be used to wrap software like LAMMPS and other
|
||||
packages. It can be used to glue multiple pieces of software
|
||||
together, e.g. to run a coupled or multiscale model. See <A HREF = "Section_howto.html#howto_10">Section
|
||||
section</A> of the manual and the couple
|
||||
directory of the distribution for more ideas about coupling LAMMPS to
|
||||
other codes. See <A HREF = "Section_start.html#start_5">Section_start 4</A> about
|
||||
how to build LAMMPS as a library, and <A HREF = "Section_howto.html#howto_19">Section_howto
|
||||
19</A> for a description of the library
|
||||
interface provided in src/library.cpp and src/library.h and how to
|
||||
extend it for your needs. As described below, that interface is what
|
||||
is exposed to Python. It is designed to be easy to add functions to.
|
||||
This can easily extend the Python inteface as well. See details
|
||||
below.
|
||||
<P>See <A HREF = "Section_howto.html#howto_10">Section_howto 10</A> of the manual and
|
||||
the couple directory of the distribution for more ideas about coupling
|
||||
LAMMPS to other codes. See <A HREF = "Section_howto.html#howto_19">Section_howto
|
||||
19</A> for a description of the LAMMPS
|
||||
library interface provided in src/library.cpp and src/library.h, and
|
||||
how to extend it for your needs. As described below, that interface
|
||||
is what is exposed to Python either when calling LAMMPS from Python or
|
||||
when calling Python from a LAMMPS input script and then calling back
|
||||
to LAMMPS from Python code. The library interface is designed to be
|
||||
easy to add functions to. Thus the Python interface to LAMMPS is also
|
||||
easy to extend as well.
|
||||
</P>
|
||||
<P>By using the Python interface, LAMMPS can also be coupled with a GUI
|
||||
or other visualization tools that display graphs or animations in real
|
||||
time as LAMMPS runs. Examples of such scripts are inlcluded in the
|
||||
python directory.
|
||||
<P>If you create interesting Python scripts that run LAMMPS or
|
||||
interesting Python functions that can be called from a LAMMPS input
|
||||
script, that you think would be useful to other users, please <A HREF = "http://lammps.sandia.gov/authors.html">email
|
||||
them to the developers</A>. We can
|
||||
include them in the LAMMPS distribution.
|
||||
</P>
|
||||
<P>Two advantages of using Python are how concise the language is, and
|
||||
that it can be run interactively, enabling rapid development and
|
||||
debugging of programs. If you use it to mostly invoke costly
|
||||
operations within LAMMPS, such as running a simulation for a
|
||||
<HR>
|
||||
|
||||
<HR>
|
||||
|
||||
<A NAME = "py_1"></A><H4>11.1 Overview of running LAMMPS from Python
|
||||
</H4>
|
||||
<P>The LAMMPS distribution includes a python directory with all you need
|
||||
to run LAMMPS from Python. The python/lammps.py file wraps the LAMMPS
|
||||
library interface, with one wrapper function per LAMMPS library
|
||||
function. This file makes it is possible to do the following either
|
||||
from a Python script, or interactively from a Python prompt: create
|
||||
one or more instances of LAMMPS, invoke LAMMPS commands or give it an
|
||||
input script, run LAMMPS incrementally, extract LAMMPS results, an
|
||||
modify internal LAMMPS variables. From a Python script you can do
|
||||
this in serial or parallel. Running Python interactively in parallel
|
||||
does not generally work, unless you have a version of Python that
|
||||
extends standard Python to enable multiple instances of Python to read
|
||||
what you type.
|
||||
</P>
|
||||
<P>To do all of this, you must first build LAMMPS as a shared library,
|
||||
then insure that your Python can find the python/lammps.py file and
|
||||
the shared library. These steps are explained in subsequent sections
|
||||
11.3 and 11.4. Sections 11.5 and 11.6 discuss using MPI from a
|
||||
parallel Python program and how to test that you are ready to use
|
||||
LAMMPS from Python. Section 11.7 lists all the functions in the
|
||||
current LAMMPS library interface and how to call them from Python.
|
||||
</P>
|
||||
<P>Section 11.8 gives some examples of coupling LAMMPS to other tools via
|
||||
Python. For example, LAMMPS can easily be coupled to a GUI or other
|
||||
visualization tools that display graphs or animations in real time as
|
||||
LAMMPS runs. Examples of such scripts are inlcluded in the python
|
||||
directory.
|
||||
</P>
|
||||
<P>Two advantages of using Python to run LAMMPS are how concise the
|
||||
language is, and that it can be run interactively, enabling rapid
|
||||
development and debugging of programs. If you use it to mostly invoke
|
||||
costly operations within LAMMPS, such as running a simulation for a
|
||||
reasonable number of timesteps, then the overhead cost of invoking
|
||||
LAMMPS thru Python will be negligible.
|
||||
</P>
|
||||
<P>Before using LAMMPS from a Python script, you need to do two things.
|
||||
You need to build LAMMPS as a dynamic shared library, so it can be
|
||||
loaded by Python. And you need to tell Python how to find the library
|
||||
and the Python wrapper file python/lammps.py. Both these steps are
|
||||
discussed below. If you wish to run LAMMPS in parallel from Python,
|
||||
you also need to extend your Python with MPI. This is also discussed
|
||||
below.
|
||||
</P>
|
||||
<P>The Python wrapper for LAMMPS uses the amazing and magical (to me)
|
||||
"ctypes" package in Python, which auto-generates the interface code
|
||||
needed between Python and a set of C interface routines for a library.
|
||||
@ -75,19 +112,84 @@ check which version of Python you have installed, by simply typing
|
||||
</P>
|
||||
<HR>
|
||||
|
||||
<A NAME = "py_2"></A><H4>11.2 Overview of using Python from a LAMMPS script
|
||||
</H4>
|
||||
<P>IMPORTANT NOTE: It is not currently possible to use the
|
||||
<A HREF = "python.html">python</A> 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.
|
||||
</P>
|
||||
<P>LAMMPS has a <A HREF = "python.html">python</A> 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 <A HREF = "variable.html">variable</A> 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.
|
||||
</P>
|
||||
<P>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
|
||||
are mapped to LAMMPS variables (also defined in the input script) and
|
||||
it can return a value to a LAMMPS variable. This is thus a mechanism
|
||||
for your input script to pass information to a piece of Python code,
|
||||
ask Python to execute the code, and return information to your input
|
||||
script.
|
||||
</P>
|
||||
<P>Note that a Python function can be arbitrarily complex. It can import
|
||||
other Python modules, instantiate Python classes, call other Python
|
||||
functions, etc. The Python code that you provide can contain more
|
||||
code than the single function. It can contain other functions or
|
||||
Python classes, as well as global variables or other mechanisms for
|
||||
storing state between calls from LAMMPS to the function.
|
||||
</P>
|
||||
<P>The Python function you provide can consist of "pure" Python code that
|
||||
only performs operations provided by standard Python. However, the
|
||||
Python function can also "call back" to LAMMPS through its
|
||||
Python-wrapped library interface, in the manner described in the
|
||||
previous section 11.1. This means it can issue LAMMPS input script
|
||||
commands or query and set internal LAMMPS state. As an example, this
|
||||
can be useful in an input script to create a more complex loop with
|
||||
branching logic, than can be created using the simple looping and
|
||||
brancing logic enabled by the <A HREF = "next_html">next</A> and <A HREF = "if.html">if</A>
|
||||
commands.
|
||||
</P>
|
||||
<P>See the <A HREF = "python.html">python</A> doc page and the <A HREF = "variable.html">variable</A>
|
||||
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.
|
||||
</P>
|
||||
<P>To run pure Python code from LAMMPS, you only need to build LAMMPS
|
||||
with the PYTHON package installed:
|
||||
</P>
|
||||
<P>make yes-python
|
||||
make machine
|
||||
</P>
|
||||
<P>Note that this will link LAMMPS with the Python library on your
|
||||
system, which typically requires several auxiliary system libraries to
|
||||
also be linked. The list of these libraries and the paths to find
|
||||
them are specified in the lib/python/Makefile.lammps file. You need
|
||||
to insure that file contains the correct information for your version
|
||||
of Python and your machine to successfully build LAMMPS. See the
|
||||
lib/python/README file for more info.
|
||||
</P>
|
||||
<P>If you want to write Python code with callbacks to LAMMPS, then you
|
||||
must also follow the steps overviewed in the preceeding section (11.1)
|
||||
for running LAMMPS from Python. I.e. you must build LAMMPS as a
|
||||
shared library and insure that Python can find the python/lammps.py
|
||||
file and the shared library.
|
||||
</P>
|
||||
<HR>
|
||||
|
||||
<A NAME = "py_1"></A><H4>11.1 Building LAMMPS as a shared library
|
||||
<A NAME = "py_3"></A><H4>11.3 Building LAMMPS as a shared library
|
||||
</H4>
|
||||
<P>Instructions on how to build LAMMPS as a shared library are given in
|
||||
<A HREF = "Section_start.html#start_5">Section_start 5</A>. A shared library is one
|
||||
that is dynamically loadable, which is what Python requires. On Linux
|
||||
this is a library file that ends in ".so", not ".a".
|
||||
that is dynamically loadable, which is what Python requires to wrap
|
||||
LAMMPS. On Linux this is a library file that ends in ".so", not ".a".
|
||||
</P>
|
||||
<P>From the src directory, type
|
||||
<P>>From the src directory, type
|
||||
</P>
|
||||
<PRE>make makeshlib
|
||||
make -f Makefile.shlib foo
|
||||
<PRE>make foo mode=shlib
|
||||
</PRE>
|
||||
<P>where foo is the machine target name, such as linux or g++ or serial.
|
||||
This should create the file liblammps_foo.so in the src directory, as
|
||||
@ -103,7 +205,7 @@ system.
|
||||
</P>
|
||||
<HR>
|
||||
|
||||
<A NAME = "py_2"></A><H4>11.2 Installing the Python wrapper into Python
|
||||
<A NAME = "py_4"></A><H4>11.4 Installing the Python wrapper into Python
|
||||
</H4>
|
||||
<P>For Python to invoke LAMMPS, there are 2 files it needs to know about:
|
||||
</P>
|
||||
@ -171,7 +273,7 @@ environment variable as described above.
|
||||
</P>
|
||||
<HR>
|
||||
|
||||
<A NAME = "py_3"></A><H4>11.3 Extending Python with MPI to run in parallel
|
||||
<A NAME = "py_5"></A><H4>11.5 Extending Python with MPI to run in parallel
|
||||
</H4>
|
||||
<P>If you wish to run LAMMPS in parallel from Python, you need to extend
|
||||
your Python with an interface to MPI. This also allows you to
|
||||
@ -198,11 +300,12 @@ believe) creates a new alternate executable (in place of "python"
|
||||
itself) as a result.
|
||||
</P>
|
||||
<P>In principle any of these Python/MPI packages should work to invoke
|
||||
LAMMPS in parallel and MPI calls themselves from a Python script which
|
||||
is itself running in parallel. However, when I downloaded and looked
|
||||
at a few of them, their documentation was incomplete and I had trouble
|
||||
with their installation. It's not clear if some of the packages are
|
||||
still being actively developed and supported.
|
||||
LAMMPS in parallel and to make MPI calls themselves from a Python
|
||||
script which is itself running in parallel. However, when I
|
||||
downloaded and looked at a few of them, their documentation was
|
||||
incomplete and I had trouble with their installation. It's not clear
|
||||
if some of the packages are still being actively developed and
|
||||
supported.
|
||||
</P>
|
||||
<P>The one I recommend, since I have successfully used it with LAMMPS, is
|
||||
Pypar. Pypar requires the ubiquitous <A HREF = "http://numpy.scipy.org">Numpy
|
||||
@ -262,7 +365,7 @@ the right one.
|
||||
</P>
|
||||
<HR>
|
||||
|
||||
<A NAME = "py_4"></A><H4>11.4 Testing the Python-LAMMPS interface
|
||||
<A NAME = "py_6"></A><H4>11.6 Testing the Python-LAMMPS interface
|
||||
</H4>
|
||||
<P>To test if LAMMPS is callable from Python, launch Python interactively
|
||||
and type:
|
||||
@ -376,22 +479,24 @@ Python on a single processor, not in parallel.
|
||||
|
||||
<HR>
|
||||
|
||||
<A NAME = "py_5"></A><H4>11.5 Using LAMMPS from Python
|
||||
<A NAME = "py_7"></A><H4>11.7 Using LAMMPS from Python
|
||||
</H4>
|
||||
<P>The Python interface to LAMMPS consists of a Python "lammps" module,
|
||||
the source code for which is in python/lammps.py, which creates a
|
||||
"lammps" object, with a set of methods that can be invoked on that
|
||||
object. The sample Python code below assumes you have first imported
|
||||
the "lammps" module in your Python script, as follows:
|
||||
<P>As described above, the Python interface to LAMMPS consists of a
|
||||
Python "lammps" module, the source code for which is in
|
||||
python/lammps.py, which creates a "lammps" object, with a set of
|
||||
methods that can be invoked on that object. The sample Python code
|
||||
below assumes you have first imported the "lammps" module in your
|
||||
Python script, as follows:
|
||||
</P>
|
||||
<PRE>from lammps import lammps
|
||||
</PRE>
|
||||
<P>These are the methods defined by the lammps module. If you look
|
||||
at the file src/library.cpp you will see that they correspond
|
||||
one-to-one with calls you can make to the LAMMPS library from a C++ or
|
||||
C or Fortran program.
|
||||
<P>These are the methods defined by the lammps module. If you look at
|
||||
the files src/library.cpp and src/library.h you will see that they
|
||||
correspond one-to-one with calls you can make to the LAMMPS library
|
||||
from a C++ or C or Fortran program.
|
||||
</P>
|
||||
<PRE>lmp = lammps() # create a LAMMPS object using the default liblammps.so library
|
||||
lmp = lammps(ptr=lmpptr) # ditto, but use lmpptr as previously created LAMMPS object
|
||||
lmp = lammps("g++") # create a LAMMPS object using the liblammps_g++.so library
|
||||
lmp = lammps("",list) # ditto, with command-line args, e.g. list = ["-echo","screen"]
|
||||
lmp = lammps("g++",list)
|
||||
@ -430,7 +535,8 @@ v3 = lmp.extract_fix(id,style,type,i,j) # extract value(s) from a fix
|
||||
# flag = 0 = equal-style variable
|
||||
# 1 = atom-style variable
|
||||
</PRE>
|
||||
<PRE>natoms = lmp.get_natoms() # total # of atoms as int
|
||||
<PRE>flag = lmp.set_variable(name,value) # set existing named string-style variable to value, flag = 0 if successful
|
||||
natoms = lmp.get_natoms() # total # of atoms as int
|
||||
data = lmp.gather_atoms(name,type,count) # return atom attribute of all atoms gathered into data, ordered by atom ID
|
||||
# name = "x", "charge", "type", etc
|
||||
# count = # of per-atom values, 1 or 3, etc
|
||||
@ -449,6 +555,33 @@ processors. If someone figures out how to do this with one or more of
|
||||
the Python wrappers for MPI, like Pypar, please let us know and we
|
||||
will amend these doc pages.
|
||||
</P>
|
||||
<P>The lines
|
||||
</P>
|
||||
<PRE>from lammps import lammps
|
||||
lmp = lammps()
|
||||
</PRE>
|
||||
<P>create an instance of LAMMPS, wrapped in a Python class by the lammps
|
||||
Python module, and return an instance of the Python class as lmp. It
|
||||
is used to make all subequent calls to the LAMMPS library.
|
||||
</P>
|
||||
<P>Additional arguments can be used to tell Python the name of the shared
|
||||
library to load or to pass arguments to the LAMMPS instance, the same
|
||||
as if LAMMPS were launched from a command-line prompt.
|
||||
</P>
|
||||
<P>If the ptr argument is set like this:
|
||||
</P>
|
||||
<PRE>lmp = lammps(ptr=lmpptr)
|
||||
</PRE>
|
||||
<P>then lmpptr must be an argument passed to Python via the LAMMPS
|
||||
<A HREF = "python.html">python</A> command, when it is used to define a Python
|
||||
function that is invoked by the LAMMPS input script. This mode of
|
||||
using Python with LAMMPS is described above in 11.2. The variable
|
||||
lmpptr refers to the instance of LAMMPS that called the embedded
|
||||
Python interpreter. Using it as an argument to lammps() allows the
|
||||
returned Python class instance "lmp" to make calls to that instance of
|
||||
LAMMPS. See the <A HREF = "python.html">python</A> command doc page for examples
|
||||
using this syntax.
|
||||
</P>
|
||||
<P>Note that you can create multiple LAMMPS objects in your Python
|
||||
script, and coordinate and run multiple simulations, e.g.
|
||||
</P>
|
||||
@ -578,7 +711,7 @@ Python script. Isn't ctypes amazing?
|
||||
|
||||
<HR>
|
||||
|
||||
<A NAME = "py_6"></A><H4>11.6 Example Python scripts that use LAMMPS
|
||||
<A NAME = "py_8"></A><H4>11.8 Example Python scripts that use LAMMPS
|
||||
</H4>
|
||||
<P>These are the Python scripts included as demos in the python/examples
|
||||
directory of the LAMMPS distribution, to illustrate the kinds of
|
||||
|
||||
@ -8,61 +8,97 @@
|
||||
|
||||
11. Python interface to LAMMPS :h3
|
||||
|
||||
This section describes how to build and use LAMMPS via a Python
|
||||
interface.
|
||||
LAMMPS can work together with Python in two ways. First, Python can
|
||||
wrap LAMMPS through the "LAMMPS library
|
||||
interface"_Section_howto.html#howto_19, so that a Python script can
|
||||
create one or more instances of LAMMPS and launch one or more
|
||||
simulations. In Python lingo, this is "extending" Python with LAMMPS.
|
||||
|
||||
11.1 "Building LAMMPS as a shared library"_#py_1
|
||||
11.2 "Installing the Python wrapper into Python"_#py_2
|
||||
11.3 "Extending Python with MPI to run in parallel"_#py_3
|
||||
11.4 "Testing the Python-LAMMPS interface"_#py_4
|
||||
11.5 "Using LAMMPS from Python"_#py_5
|
||||
11.6 "Example Python scripts that use LAMMPS"_#py_6 :ul
|
||||
Second, LAMMPS can use the Python interpreter, so that a LAMMPS input
|
||||
script can invoke Python code, and pass information back-and-forth
|
||||
between the input script and Python functions you write. The Python
|
||||
code can also callback to LAMMPS to query or change its attributes.
|
||||
In Python lingo, this is "embedding" Python in LAMMPS.
|
||||
|
||||
The LAMMPS distribution includes the file python/lammps.py which wraps
|
||||
the library interface to LAMMPS. This file makes it is possible to
|
||||
run LAMMPS, invoke LAMMPS commands or give it an input script, extract
|
||||
LAMMPS results, an modify internal LAMMPS variables, either from a
|
||||
Python script or interactively from a Python prompt. You can do the
|
||||
former in serial or parallel. Running Python interactively in
|
||||
parallel does not generally work, unless you have a package installed
|
||||
that extends your Python to enable multiple instances of Python to
|
||||
read what you type.
|
||||
This section describes how to do both.
|
||||
|
||||
"Python"_http://www.python.org is a powerful scripting and programming
|
||||
language which can be used to wrap software like LAMMPS and other
|
||||
packages. It can be used to glue multiple pieces of software
|
||||
together, e.g. to run a coupled or multiscale model. See "Section
|
||||
section"_Section_howto.html#howto_10 of the manual and the couple
|
||||
directory of the distribution for more ideas about coupling LAMMPS to
|
||||
other codes. See "Section_start 4"_Section_start.html#start_5 about
|
||||
how to build LAMMPS as a library, and "Section_howto
|
||||
19"_Section_howto.html#howto_19 for a description of the library
|
||||
interface provided in src/library.cpp and src/library.h and how to
|
||||
extend it for your needs. As described below, that interface is what
|
||||
is exposed to Python. It is designed to be easy to add functions to.
|
||||
This can easily extend the Python inteface as well. See details
|
||||
below.
|
||||
11.1 "Overview of running LAMMPS from Python"_#py_1
|
||||
11.2 "Overview of using Python from a LAMMPS script"_#py_2
|
||||
11.3 "Building LAMMPS as a shared library"_#py_3
|
||||
11.4 "Installing the Python wrapper into Python"_#py_4
|
||||
11.5 "Extending Python with MPI to run in parallel"_#py_5
|
||||
11.6 "Testing the Python-LAMMPS interface"_#py_6
|
||||
11.7 "Using LAMMPS from Python"_#py_7
|
||||
11.8 "Example Python scripts that use LAMMPS"_#py_8 :ul
|
||||
|
||||
By using the Python interface, LAMMPS can also be coupled with a GUI
|
||||
or other visualization tools that display graphs or animations in real
|
||||
time as LAMMPS runs. Examples of such scripts are inlcluded in the
|
||||
python directory.
|
||||
If you are not familiar with it, "Python"_http://www.python.org is a
|
||||
powerful scripting and programming language which can essentially do
|
||||
anything that faster, lower-level languages like C or C++ can do, but
|
||||
typically with much fewer lines of code. When used in embedded mode,
|
||||
Python can perform operations that the simplistic LAMMPS input script
|
||||
syntax cannot. Python can be also be used as a "glue" language to
|
||||
drive a program through its library interface, or to hook multiple
|
||||
pieces of software together, such as a simulation package plus a
|
||||
visualization package, or to run a coupled multiscale or multiphysics
|
||||
model.
|
||||
|
||||
Two advantages of using Python are how concise the language is, and
|
||||
that it can be run interactively, enabling rapid development and
|
||||
debugging of programs. If you use it to mostly invoke costly
|
||||
operations within LAMMPS, such as running a simulation for a
|
||||
See "Section_howto 10"_Section_howto.html#howto_10 of the manual and
|
||||
the couple directory of the distribution for more ideas about coupling
|
||||
LAMMPS to other codes. See "Section_howto
|
||||
19"_Section_howto.html#howto_19 for a description of the LAMMPS
|
||||
library interface provided in src/library.cpp and src/library.h, and
|
||||
how to extend it for your needs. As described below, that interface
|
||||
is what is exposed to Python either when calling LAMMPS from Python or
|
||||
when calling Python from a LAMMPS input script and then calling back
|
||||
to LAMMPS from Python code. The library interface is designed to be
|
||||
easy to add functions to. Thus the Python interface to LAMMPS is also
|
||||
easy to extend as well.
|
||||
|
||||
If you create interesting Python scripts that run LAMMPS or
|
||||
interesting Python functions that can be called from a LAMMPS input
|
||||
script, that you think would be useful to other users, please "email
|
||||
them to the developers"_http://lammps.sandia.gov/authors.html. We can
|
||||
include them in the LAMMPS distribution.
|
||||
|
||||
:line
|
||||
:line
|
||||
|
||||
11.1 Overview of running LAMMPS from Python :link(py_1),h4
|
||||
|
||||
The LAMMPS distribution includes a python directory with all you need
|
||||
to run LAMMPS from Python. The python/lammps.py file wraps the LAMMPS
|
||||
library interface, with one wrapper function per LAMMPS library
|
||||
function. This file makes it is possible to do the following either
|
||||
from a Python script, or interactively from a Python prompt: create
|
||||
one or more instances of LAMMPS, invoke LAMMPS commands or give it an
|
||||
input script, run LAMMPS incrementally, extract LAMMPS results, an
|
||||
modify internal LAMMPS variables. From a Python script you can do
|
||||
this in serial or parallel. Running Python interactively in parallel
|
||||
does not generally work, unless you have a version of Python that
|
||||
extends standard Python to enable multiple instances of Python to read
|
||||
what you type.
|
||||
|
||||
To do all of this, you must first build LAMMPS as a shared library,
|
||||
then insure that your Python can find the python/lammps.py file and
|
||||
the shared library. These steps are explained in subsequent sections
|
||||
11.3 and 11.4. Sections 11.5 and 11.6 discuss using MPI from a
|
||||
parallel Python program and how to test that you are ready to use
|
||||
LAMMPS from Python. Section 11.7 lists all the functions in the
|
||||
current LAMMPS library interface and how to call them from Python.
|
||||
|
||||
Section 11.8 gives some examples of coupling LAMMPS to other tools via
|
||||
Python. For example, LAMMPS can easily be coupled to a GUI or other
|
||||
visualization tools that display graphs or animations in real time as
|
||||
LAMMPS runs. Examples of such scripts are inlcluded in the python
|
||||
directory.
|
||||
|
||||
Two advantages of using Python to run LAMMPS are how concise the
|
||||
language is, and that it can be run interactively, enabling rapid
|
||||
development and debugging of programs. If you use it to mostly invoke
|
||||
costly operations within LAMMPS, such as running a simulation for a
|
||||
reasonable number of timesteps, then the overhead cost of invoking
|
||||
LAMMPS thru Python will be negligible.
|
||||
|
||||
Before using LAMMPS from a Python script, you need to do two things.
|
||||
You need to build LAMMPS as a dynamic shared library, so it can be
|
||||
loaded by Python. And you need to tell Python how to find the library
|
||||
and the Python wrapper file python/lammps.py. Both these steps are
|
||||
discussed below. If you wish to run LAMMPS in parallel from Python,
|
||||
you also need to extend your Python with MPI. This is also discussed
|
||||
below.
|
||||
|
||||
The Python wrapper for LAMMPS uses the amazing and magical (to me)
|
||||
"ctypes" package in Python, which auto-generates the interface code
|
||||
needed between Python and a set of C interface routines for a library.
|
||||
@ -71,19 +107,85 @@ check which version of Python you have installed, by simply typing
|
||||
"python" at a shell prompt.
|
||||
|
||||
:line
|
||||
|
||||
11.2 Overview of using Python from a LAMMPS script :link(py_2),h4
|
||||
|
||||
IMPORTANT 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 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.
|
||||
|
||||
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
|
||||
are mapped to LAMMPS variables (also defined in the input script) and
|
||||
it can return a value to a LAMMPS variable. This is thus a mechanism
|
||||
for your input script to pass information to a piece of Python code,
|
||||
ask Python to execute the code, and return information to your input
|
||||
script.
|
||||
|
||||
Note that a Python function can be arbitrarily complex. It can import
|
||||
other Python modules, instantiate Python classes, call other Python
|
||||
functions, etc. The Python code that you provide can contain more
|
||||
code than the single function. It can contain other functions or
|
||||
Python classes, as well as global variables or other mechanisms for
|
||||
storing state between calls from LAMMPS to the function.
|
||||
|
||||
The Python function you provide can consist of "pure" Python code that
|
||||
only performs operations provided by standard Python. However, the
|
||||
Python function can also "call back" to LAMMPS through its
|
||||
Python-wrapped library interface, in the manner described in the
|
||||
previous section 11.1. This means it can issue LAMMPS input script
|
||||
commands or query and set internal LAMMPS state. As an example, this
|
||||
can be useful in an input script to create a more complex loop with
|
||||
branching logic, than can be created using the simple looping and
|
||||
brancing logic enabled by the "next"_next_html and "if"_if.html
|
||||
commands.
|
||||
|
||||
See the "python"_python.html doc page and the "variable"_variable.html
|
||||
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:
|
||||
|
||||
make yes-python
|
||||
make machine
|
||||
|
||||
Note that this will link LAMMPS with the Python library on your
|
||||
system, which typically requires several auxiliary system libraries to
|
||||
also be linked. The list of these libraries and the paths to find
|
||||
them are specified in the lib/python/Makefile.lammps file. You need
|
||||
to insure that file contains the correct information for your version
|
||||
of Python and your machine to successfully build LAMMPS. See the
|
||||
lib/python/README file for more info.
|
||||
|
||||
If you want to write Python code with callbacks to LAMMPS, then you
|
||||
must also follow the steps overviewed in the preceeding section (11.1)
|
||||
for running LAMMPS from Python. I.e. you must build LAMMPS as a
|
||||
shared library and insure that Python can find the python/lammps.py
|
||||
file and the shared library.
|
||||
|
||||
:line
|
||||
|
||||
11.1 Building LAMMPS as a shared library :link(py_1),h4
|
||||
11.3 Building LAMMPS as a shared library :link(py_3),h4
|
||||
|
||||
Instructions on how to build LAMMPS as a shared library are given in
|
||||
"Section_start 5"_Section_start.html#start_5. A shared library is one
|
||||
that is dynamically loadable, which is what Python requires. On Linux
|
||||
this is a library file that ends in ".so", not ".a".
|
||||
that is dynamically loadable, which is what Python requires to wrap
|
||||
LAMMPS. On Linux this is a library file that ends in ".so", not ".a".
|
||||
|
||||
From the src directory, type
|
||||
>From the src directory, type
|
||||
|
||||
make makeshlib
|
||||
make -f Makefile.shlib foo :pre
|
||||
make foo mode=shlib :pre
|
||||
|
||||
where foo is the machine target name, such as linux or g++ or serial.
|
||||
This should create the file liblammps_foo.so in the src directory, as
|
||||
@ -99,7 +201,7 @@ system.
|
||||
|
||||
:line
|
||||
|
||||
11.2 Installing the Python wrapper into Python :link(py_2),h4
|
||||
11.4 Installing the Python wrapper into Python :link(py_4),h4
|
||||
|
||||
For Python to invoke LAMMPS, there are 2 files it needs to know about:
|
||||
|
||||
@ -167,7 +269,7 @@ environment variable as described above.
|
||||
|
||||
:line
|
||||
|
||||
11.3 Extending Python with MPI to run in parallel :link(py_3),h4
|
||||
11.5 Extending Python with MPI to run in parallel :link(py_5),h4
|
||||
|
||||
If you wish to run LAMMPS in parallel from Python, you need to extend
|
||||
your Python with an interface to MPI. This also allows you to
|
||||
@ -194,11 +296,12 @@ believe) creates a new alternate executable (in place of "python"
|
||||
itself) as a result.
|
||||
|
||||
In principle any of these Python/MPI packages should work to invoke
|
||||
LAMMPS in parallel and MPI calls themselves from a Python script which
|
||||
is itself running in parallel. However, when I downloaded and looked
|
||||
at a few of them, their documentation was incomplete and I had trouble
|
||||
with their installation. It's not clear if some of the packages are
|
||||
still being actively developed and supported.
|
||||
LAMMPS in parallel and to make MPI calls themselves from a Python
|
||||
script which is itself running in parallel. However, when I
|
||||
downloaded and looked at a few of them, their documentation was
|
||||
incomplete and I had trouble with their installation. It's not clear
|
||||
if some of the packages are still being actively developed and
|
||||
supported.
|
||||
|
||||
The one I recommend, since I have successfully used it with LAMMPS, is
|
||||
Pypar. Pypar requires the ubiquitous "Numpy
|
||||
@ -258,7 +361,7 @@ the right one.
|
||||
|
||||
:line
|
||||
|
||||
11.4 Testing the Python-LAMMPS interface :link(py_4),h4
|
||||
11.6 Testing the Python-LAMMPS interface :link(py_6),h4
|
||||
|
||||
To test if LAMMPS is callable from Python, launch Python interactively
|
||||
and type:
|
||||
@ -371,22 +474,24 @@ Python on a single processor, not in parallel.
|
||||
:line
|
||||
:line
|
||||
|
||||
11.5 Using LAMMPS from Python :link(py_5),h4
|
||||
11.7 Using LAMMPS from Python :link(py_7),h4
|
||||
|
||||
The Python interface to LAMMPS consists of a Python "lammps" module,
|
||||
the source code for which is in python/lammps.py, which creates a
|
||||
"lammps" object, with a set of methods that can be invoked on that
|
||||
object. The sample Python code below assumes you have first imported
|
||||
the "lammps" module in your Python script, as follows:
|
||||
As described above, the Python interface to LAMMPS consists of a
|
||||
Python "lammps" module, the source code for which is in
|
||||
python/lammps.py, which creates a "lammps" object, with a set of
|
||||
methods that can be invoked on that object. The sample Python code
|
||||
below assumes you have first imported the "lammps" module in your
|
||||
Python script, as follows:
|
||||
|
||||
from lammps import lammps :pre
|
||||
|
||||
These are the methods defined by the lammps module. If you look
|
||||
at the file src/library.cpp you will see that they correspond
|
||||
one-to-one with calls you can make to the LAMMPS library from a C++ or
|
||||
C or Fortran program.
|
||||
These are the methods defined by the lammps module. If you look at
|
||||
the files src/library.cpp and src/library.h you will see that they
|
||||
correspond one-to-one with calls you can make to the LAMMPS library
|
||||
from a C++ or C or Fortran program.
|
||||
|
||||
lmp = lammps() # create a LAMMPS object using the default liblammps.so library
|
||||
lmp = lammps(ptr=lmpptr) # ditto, but use lmpptr as previously created LAMMPS object
|
||||
lmp = lammps("g++") # create a LAMMPS object using the liblammps_g++.so library
|
||||
lmp = lammps("",list) # ditto, with command-line args, e.g. list = \["-echo","screen"\]
|
||||
lmp = lammps("g++",list) :pre
|
||||
@ -425,6 +530,7 @@ var = lmp.extract_variable(name,group,flag) # extract value(s) from a variable
|
||||
# flag = 0 = equal-style variable
|
||||
# 1 = atom-style variable :pre
|
||||
|
||||
flag = lmp.set_variable(name,value) # set existing named string-style variable to value, flag = 0 if successful
|
||||
natoms = lmp.get_natoms() # total # of atoms as int
|
||||
data = lmp.gather_atoms(name,type,count) # return atom attribute of all atoms gathered into data, ordered by atom ID
|
||||
# name = "x", "charge", "type", etc
|
||||
@ -444,6 +550,33 @@ processors. If someone figures out how to do this with one or more of
|
||||
the Python wrappers for MPI, like Pypar, please let us know and we
|
||||
will amend these doc pages.
|
||||
|
||||
The lines
|
||||
|
||||
from lammps import lammps
|
||||
lmp = lammps() :pre
|
||||
|
||||
create an instance of LAMMPS, wrapped in a Python class by the lammps
|
||||
Python module, and return an instance of the Python class as lmp. It
|
||||
is used to make all subequent calls to the LAMMPS library.
|
||||
|
||||
Additional arguments can be used to tell Python the name of the shared
|
||||
library to load or to pass arguments to the LAMMPS instance, the same
|
||||
as if LAMMPS were launched from a command-line prompt.
|
||||
|
||||
If the ptr argument is set like this:
|
||||
|
||||
lmp = lammps(ptr=lmpptr) :pre
|
||||
|
||||
then lmpptr must be an argument passed to Python via the LAMMPS
|
||||
"python"_python.html command, when it is used to define a Python
|
||||
function that is invoked by the LAMMPS input script. This mode of
|
||||
using Python with LAMMPS is described above in 11.2. The variable
|
||||
lmpptr refers to the instance of LAMMPS that called the embedded
|
||||
Python interpreter. Using it as an argument to lammps() allows the
|
||||
returned Python class instance "lmp" to make calls to that instance of
|
||||
LAMMPS. See the "python"_python.html command doc page for examples
|
||||
using this syntax.
|
||||
|
||||
Note that you can create multiple LAMMPS objects in your Python
|
||||
script, and coordinate and run multiple simulations, e.g.
|
||||
|
||||
@ -572,7 +705,7 @@ Python script. Isn't ctypes amazing? :l,ule
|
||||
:line
|
||||
:line
|
||||
|
||||
11.6 Example Python scripts that use LAMMPS :link(py_6),h4
|
||||
11.8 Example Python scripts that use LAMMPS :link(py_8),h4
|
||||
|
||||
These are the Python scripts included as demos in the python/examples
|
||||
directory of the LAMMPS distribution, to illustrate the kinds of
|
||||
|
||||
@ -171,7 +171,7 @@ all good starting points if you find you need to change them for your
|
||||
machine. Put any file you edit into the src/MAKE/MINE directory and
|
||||
it will be never be touched by any LAMMPS updates.
|
||||
</P>
|
||||
<P>From within the src directory, type "make" or "gmake". You should see
|
||||
<P>>From within the src directory, type "make" or "gmake". You should see
|
||||
a list of available choices from src/MAKE and all of its
|
||||
sub-directories. If one of those has the options you want or is the
|
||||
machine you want, you can type a command like:
|
||||
@ -304,15 +304,24 @@ if your platform does have its own XDR files available. See the
|
||||
Restrictions section of the <A HREF = "dump.html">dump</A> command for details.
|
||||
</P>
|
||||
<P>Use at most one of the -DLAMMPS_SMALLBIG, -DLAMMPS_BIGBIG, -D-
|
||||
DLAMMPS_SMALLSMALL settings. The default is -DLAMMPS_SMALLBIG. These
|
||||
DLAMMPS_SMALLSMALL settings. The default is -DLAMMPS_SMALLBIG. These
|
||||
settings refer to use of 4-byte (small) vs 8-byte (big) integers
|
||||
within LAMMPS, as specified in src/lmptype.h. The only reason to use
|
||||
the BIGBIG setting is to enable simulation of huge molecular systems
|
||||
(which store bond topology info) with more than 2 billion atoms, or to
|
||||
track the image flags of moving atoms that wrap around a periodic box
|
||||
more than 512 times. The only reason to use the SMALLSMALL setting is
|
||||
if your machine does not support 64-bit integers. See the <A HREF = "#start_2_4">Additional
|
||||
build tips</A> section below for more details.
|
||||
more than 512 times. Normally, the only reason to use SMALLSMALL is
|
||||
if your machine does not support 64-bit integers, though you can use
|
||||
SMALLSMALL setting if you are running in serial or on a desktop
|
||||
machine or small cluster where you will never run large systems or for
|
||||
long time (more than 2 billion atoms, more than 2 billion timesteps).
|
||||
See the <A HREF = "#start_2_4">Additional build tips</A> section below for more
|
||||
details on these settings.
|
||||
</P>
|
||||
<P>Note that two packages, USER-ATC and USER-CUDA are not currently
|
||||
compatible with -DLAMMPS_BIGBIG. Also the GPU package requires the
|
||||
lib/gpu library to be compiled with the same setting, or the link will
|
||||
fail.
|
||||
</P>
|
||||
<P>The -DLAMMPS_LONGLONG_TO_LONG setting may be needed if your system or
|
||||
MPI version does not recognize "long long" data types. In this case a
|
||||
@ -368,10 +377,11 @@ need to build the STUBS library for your platform before making LAMMPS
|
||||
itself. Note that if you are building with src/MAKE/Makefile.serial,
|
||||
e.g. by typing "make serial", then the STUBS library is built for you.
|
||||
</P>
|
||||
<P>To build the STUBS library from the src directory, type "make stubs",
|
||||
or from the src/STUBS dir, type "make". This should create a
|
||||
libmpi_stubs.a file suitable for linking to LAMMPS. If the build
|
||||
fails, you will need to edit the STUBS/Makefile for your platform.
|
||||
<P>To build the STUBS library from the src directory, type "make
|
||||
mpi-stubs", or from the src/STUBS dir, type "make". This should
|
||||
create a libmpi_stubs.a file suitable for linking to LAMMPS. If the
|
||||
build fails, you will need to edit the STUBS/Makefile for your
|
||||
platform.
|
||||
</P>
|
||||
<P>The file STUBS/mpi.c provides a CPU timer function called MPI_Wtime()
|
||||
that calls gettimeofday() . If your system doesn't support
|
||||
@ -762,20 +772,33 @@ options.
|
||||
<A NAME = "start_3_3"></A><B><I>Packages that require extra libraries:</I></B>
|
||||
|
||||
<P>A few of the standard and user packages require additional auxiliary
|
||||
libraries. They must be compiled first, before LAMMPS is built. If
|
||||
you get a LAMMPS build error about a missing library, this is likely
|
||||
the reason. See the <A HREF = "Section_packages.html">Section_packages</A> doc page
|
||||
for a list of packages that have auxiliary libraries.
|
||||
libraries. Most 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
|
||||
<A HREF = "Section_packages.html">Section_packages</A> doc page for a list of
|
||||
packages that have these kinds of auxiliary libraries.
|
||||
</P>
|
||||
<P>Code for most of these auxiliary libraries is included in the LAMMPS
|
||||
distribution under the lib directory. Examples are the USER-ATC and
|
||||
MEAM packages. A few auxiliary libraries are NOT included with
|
||||
LAMMPS; to use the associated package you must download and install
|
||||
the auxiliary library yourself. Examples are the KIM and VORONOI and
|
||||
USER-MOLFILE packages.
|
||||
<P>The lib directory in the distribution has sub-directories with package
|
||||
names that correspond to the needed auxiliary libs, e.g. lib/reax.
|
||||
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.
|
||||
</P>
|
||||
<P>For provided libraries, each lib directory has a README file
|
||||
(e.g. lib/reax/README) with instructions on how to build that library.
|
||||
<P>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 and VORONOI and USER-MOLFILE packages.
|
||||
</P>
|
||||
<P>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 already available on your system. However, the Makefile.lammps
|
||||
file is needed to tell the LAMMPS build which libs to use and where to
|
||||
find them.
|
||||
</P>
|
||||
<P>For libraries with provided code, the sub-directory README file
|
||||
(e.g. lib/reax/README) has instructions on how to build that library.
|
||||
Typically this is done by typing something like:
|
||||
</P>
|
||||
<PRE>make -f Makefile.g++
|
||||
@ -808,20 +831,22 @@ 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.
|
||||
</P>
|
||||
<P>For libraries without provided source code, the file
|
||||
src/package/README has information on where to find the library and
|
||||
how to build it, e.g. src/VORONOI/README. There is also a
|
||||
Makefile.lammps file in the src/package directory. E.g. files
|
||||
src/KIM/Makefile.lammps or src/VORONOI/Makefile.lammps or
|
||||
src/UESR-MOLFILE/Makefile.lammps. These files serve the same purpose
|
||||
as the lib/package/Makefile.lammps files described above. The files
|
||||
have settings needed when LAMMPS is built to link with the
|
||||
corresponding auxiliary library.
|
||||
<P>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. 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.
|
||||
</P>
|
||||
<P>Again, you must insure that the settings in
|
||||
src/package/Makefile.lammps are appropriate for your system and where
|
||||
you installed the auxiliary library. If they are not, the LAMMPS
|
||||
build will typically fail.
|
||||
<P>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.
|
||||
</P>
|
||||
<P>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.
|
||||
</P>
|
||||
<HR>
|
||||
|
||||
@ -912,6 +937,13 @@ 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.
|
||||
</P>
|
||||
<P>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.
|
||||
</P>
|
||||
<P>You can run Make.py from the src directory by typing either:
|
||||
</P>
|
||||
<PRE>Make.py -h
|
||||
@ -927,13 +959,13 @@ Python. And you may need to insure the script is executable:
|
||||
</P>
|
||||
<DIV ALIGN=center><TABLE BORDER=1 >
|
||||
<TR><TD >Install/uninstall packages</TD><TD > Make.py -p no-lib kokkos omp intel</TD></TR>
|
||||
<TR><TD >Build specific auxiliary libs</TD><TD > Make.py lib-atc lib-meam</TD></TR>
|
||||
<TR><TD >Build libs for all installed packages</TD><TD > Make.py -p cuda gpu -gpu mode=double arch=31 lib-all</TD></TR>
|
||||
<TR><TD >Create a Makefile from scratch with compiler and MPI settings</TD><TD > Make.py -m none -cc g++ -mpi mpich file</TD></TR>
|
||||
<TR><TD >Augment Makefile.serial with settings for installed packages</TD><TD > Make.py -p intel -intel cpu -m serial file</TD></TR>
|
||||
<TR><TD >Add JPG and FFTW support to Makefile.mpi</TD><TD > Make.py -m mpi -jpg -fft fftw file</TD></TR>
|
||||
<TR><TD >Build LAMMPS with a parallel make using Makefile.mpi</TD><TD > Make.py -j 16 -m mpi exe</TD></TR>
|
||||
<TR><TD >Build LAMMPS and libs it needs using Makefile.serial with accelerator settings</TD><TD > Make.py -p gpu intel -intel cpu lib-all file serial
|
||||
<TR><TD >Build specific auxiliary libs</TD><TD > Make.py -a lib-atc lib-meam</TD></TR>
|
||||
<TR><TD >Build libs for all installed packages</TD><TD > Make.py -p cuda gpu -gpu mode=double arch=31 -a lib-all</TD></TR>
|
||||
<TR><TD >Create a Makefile from scratch with compiler and MPI settings</TD><TD > Make.py -m none -cc g++ -mpi mpich -a file</TD></TR>
|
||||
<TR><TD >Augment Makefile.serial with settings for installed packages</TD><TD > Make.py -p intel -intel cpu -m serial -a file</TD></TR>
|
||||
<TR><TD >Add JPG and FFTW support to Makefile.mpi</TD><TD > Make.py -m mpi -jpg -fft fftw -a file</TD></TR>
|
||||
<TR><TD >Build LAMMPS with a parallel make using Makefile.mpi</TD><TD > Make.py -j 16 -m mpi -a exe</TD></TR>
|
||||
<TR><TD >Build LAMMPS and libs it needs using Makefile.serial with accelerator settings</TD><TD > Make.py -p gpu intel -intel cpu -a lib-all file serial
|
||||
</TD></TR></TABLE></DIV>
|
||||
|
||||
<P>The bench and examples directories give Make.py commands that can be
|
||||
@ -954,11 +986,15 @@ the "-h" switch.
|
||||
</P>
|
||||
<P>E.g. typing "Make.py -h" gives
|
||||
</P>
|
||||
<PRE>Syntax: Make.py switch args ... <I>action1</I> <I>action2</I> ...
|
||||
actions:
|
||||
lib-all, lib-dir, clean, file, exe or machine
|
||||
zero or more actions, in any order (machine must be last)
|
||||
switches:
|
||||
<PRE>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:
|
||||
@ -1022,51 +1058,58 @@ more info on wrapping and running LAMMPS from Python.
|
||||
</H5>
|
||||
<P>To build LAMMPS as a static library (*.a file on Linux), type
|
||||
</P>
|
||||
<PRE>make makelib
|
||||
make -f Makefile.lib foo
|
||||
<PRE>make foo mode=lib
|
||||
</PRE>
|
||||
<P>where foo is the machine name. This kind of library is typically used
|
||||
to statically link a driver application to LAMMPS, so that you can
|
||||
insure all dependencies are satisfied at compile time. Note that
|
||||
inclusion or exclusion of any desired optional packages should be done
|
||||
before typing "make makelib". The first "make" command will create a
|
||||
current Makefile.lib with all the file names in your src dir. The
|
||||
second "make" command will use it to build LAMMPS as a static library,
|
||||
using the ARCHIVE and ARFLAGS settings in src/MAKE/Makefile.foo. The
|
||||
build will create the file liblammps_foo.a which another application can
|
||||
link to.
|
||||
insure all dependencies are satisfied at compile time. This will use
|
||||
the ARCHIVE and ARFLAGS settings in src/MAKE/Makefile.foo. The build
|
||||
will create the file liblammps_foo.a which another application can
|
||||
link to. It will also create a soft link liblammps.a, which will
|
||||
point to the most recently built static library.
|
||||
</P>
|
||||
<H5><B>Shared library:</B>
|
||||
</H5>
|
||||
<P>To build LAMMPS as a shared library (*.so file on Linux), which can be
|
||||
dynamically loaded, e.g. from Python, type
|
||||
</P>
|
||||
<PRE>make makeshlib
|
||||
make -f Makefile.shlib foo
|
||||
<PRE>make foo mode=shlib
|
||||
</PRE>
|
||||
<P>where foo is the machine name. This kind of library is required when
|
||||
wrapping LAMMPS with Python; see <A HREF = "Section_python.html">Section_python</A>
|
||||
for details. Again, note that inclusion or exclusion of any desired
|
||||
optional packages should be done before typing "make makelib". The
|
||||
first "make" command will create a current Makefile.shlib with all the
|
||||
file names in your src dir. The second "make" command will use it to
|
||||
build LAMMPS as a shared library, using the SHFLAGS and SHLIBFLAGS
|
||||
settings in src/MAKE/Makefile.foo. The build will create the file
|
||||
liblammps_foo.so which another application can link to dyamically. It
|
||||
will also create a soft link liblammps.so, which the Python wrapper uses
|
||||
by default.
|
||||
for details. This will use the SHFLAGS and SHLIBFLAGS settings in
|
||||
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 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.
|
||||
</P>
|
||||
<P>Note that for a shared library to be usable by a calling program, all
|
||||
the auxiliary libraries it depends on must also exist as shared
|
||||
libraries. This will be the case for libraries included with LAMMPS,
|
||||
such as the dummy MPI library in src/STUBS or any package libraries in
|
||||
lib/packges, since they are always built as shared libraries with the
|
||||
-fPIC switch. However, if a library like MPI or FFTW does not exist
|
||||
as a shared library, the second make command will generate an error.
|
||||
This means you will need to install a shared library version of the
|
||||
package. The build instructions for the library should tell you how
|
||||
to do this.
|
||||
lib/packages, since they are always built as shared libraries using
|
||||
the -fPIC switch. However, if a library like MPI or FFTW does not
|
||||
exist as a shared library, the shared library build will generate an
|
||||
error. This means you will need to install a shared library version
|
||||
of the auxiliary library. The build instructions for the library
|
||||
should tell you how to do this.
|
||||
</P>
|
||||
<P>Here is an example of such errors when the system FFTW or provided
|
||||
lib/colvars library have not been built as shared libraries:
|
||||
</P>
|
||||
<PRE>/usr/bin/ld: /usr/local/lib/libfftw3.a(mapflags.o): relocation
|
||||
R_X86_64_32 against `.rodata' can not be used when making a shared
|
||||
object; recompile with -fPIC
|
||||
/usr/local/lib/libfftw3.a: could not read symbols: Bad value
|
||||
</PRE>
|
||||
<PRE>/usr/bin/ld: ../../lib/colvars/libcolvars.a(colvarmodule.o):
|
||||
relocation R_X86_64_32 against `__pthread_key_create' can not be used
|
||||
when making a shared object; recompile with -fPIC
|
||||
../../lib/colvars/libcolvars.a: error adding symbols: Bad value
|
||||
</PRE>
|
||||
<P>As an example, here is how to build and install the <A HREF = "http://www-unix.mcs.anl.gov/mpi">MPICH
|
||||
library</A>, a popular open-source version of MPI, distributed by
|
||||
Argonne National Labs, as a shared library in the default
|
||||
|
||||
@ -165,7 +165,7 @@ all good starting points if you find you need to change them for your
|
||||
machine. Put any file you edit into the src/MAKE/MINE directory and
|
||||
it will be never be touched by any LAMMPS updates.
|
||||
|
||||
From within the src directory, type "make" or "gmake". You should see
|
||||
>From within the src directory, type "make" or "gmake". You should see
|
||||
a list of available choices from src/MAKE and all of its
|
||||
sub-directories. If one of those has the options you want or is the
|
||||
machine you want, you can type a command like:
|
||||
@ -298,15 +298,24 @@ if your platform does have its own XDR files available. See the
|
||||
Restrictions section of the "dump"_dump.html command for details.
|
||||
|
||||
Use at most one of the -DLAMMPS_SMALLBIG, -DLAMMPS_BIGBIG, -D-
|
||||
DLAMMPS_SMALLSMALL settings. The default is -DLAMMPS_SMALLBIG. These
|
||||
DLAMMPS_SMALLSMALL settings. The default is -DLAMMPS_SMALLBIG. These
|
||||
settings refer to use of 4-byte (small) vs 8-byte (big) integers
|
||||
within LAMMPS, as specified in src/lmptype.h. The only reason to use
|
||||
the BIGBIG setting is to enable simulation of huge molecular systems
|
||||
(which store bond topology info) with more than 2 billion atoms, or to
|
||||
track the image flags of moving atoms that wrap around a periodic box
|
||||
more than 512 times. The only reason to use the SMALLSMALL setting is
|
||||
if your machine does not support 64-bit integers. See the "Additional
|
||||
build tips"_#start_2_4 section below for more details.
|
||||
more than 512 times. Normally, the only reason to use SMALLSMALL is
|
||||
if your machine does not support 64-bit integers, though you can use
|
||||
SMALLSMALL setting if you are running in serial or on a desktop
|
||||
machine or small cluster where you will never run large systems or for
|
||||
long time (more than 2 billion atoms, more than 2 billion timesteps).
|
||||
See the "Additional build tips"_#start_2_4 section below for more
|
||||
details on these settings.
|
||||
|
||||
Note that two packages, USER-ATC and USER-CUDA are not currently
|
||||
compatible with -DLAMMPS_BIGBIG. Also the GPU package requires the
|
||||
lib/gpu library to be compiled with the same setting, or the link will
|
||||
fail.
|
||||
|
||||
The -DLAMMPS_LONGLONG_TO_LONG setting may be needed if your system or
|
||||
MPI version does not recognize "long long" data types. In this case a
|
||||
@ -362,10 +371,11 @@ need to build the STUBS library for your platform before making LAMMPS
|
||||
itself. Note that if you are building with src/MAKE/Makefile.serial,
|
||||
e.g. by typing "make serial", then the STUBS library is built for you.
|
||||
|
||||
To build the STUBS library from the src directory, type "make stubs",
|
||||
or from the src/STUBS dir, type "make". This should create a
|
||||
libmpi_stubs.a file suitable for linking to LAMMPS. If the build
|
||||
fails, you will need to edit the STUBS/Makefile for your platform.
|
||||
To build the STUBS library from the src directory, type "make
|
||||
mpi-stubs", or from the src/STUBS dir, type "make". This should
|
||||
create a libmpi_stubs.a file suitable for linking to LAMMPS. If the
|
||||
build fails, you will need to edit the STUBS/Makefile for your
|
||||
platform.
|
||||
|
||||
The file STUBS/mpi.c provides a CPU timer function called MPI_Wtime()
|
||||
that calls gettimeofday() . If your system doesn't support
|
||||
@ -756,20 +766,33 @@ options.
|
||||
[{Packages that require extra libraries:}] :link(start_3_3)
|
||||
|
||||
A few of the standard and user packages require additional auxiliary
|
||||
libraries. They must be compiled first, before LAMMPS is built. If
|
||||
you get a LAMMPS build error about a missing library, this is likely
|
||||
the reason. See the "Section_packages"_Section_packages.html doc page
|
||||
for a list of packages that have auxiliary libraries.
|
||||
libraries. Most 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_packages"_Section_packages.html doc page for a list of
|
||||
packages that have these kinds of auxiliary libraries.
|
||||
|
||||
Code for most of these auxiliary libraries is included in the LAMMPS
|
||||
distribution under the lib directory. Examples are the USER-ATC and
|
||||
MEAM packages. A few auxiliary libraries are NOT included with
|
||||
LAMMPS; to use the associated package you must download and install
|
||||
the auxiliary library yourself. Examples are the KIM and VORONOI and
|
||||
USER-MOLFILE packages.
|
||||
The lib directory in the distribution has sub-directories with package
|
||||
names that correspond to the needed auxiliary libs, e.g. lib/reax.
|
||||
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.
|
||||
|
||||
For provided libraries, each lib directory has a README file
|
||||
(e.g. lib/reax/README) with instructions on how to build that library.
|
||||
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 and VORONOI and USER-MOLFILE packages.
|
||||
|
||||
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 already available on your system. However, the Makefile.lammps
|
||||
file is needed to tell the LAMMPS build which libs to use and where to
|
||||
find them.
|
||||
|
||||
For libraries with provided code, the sub-directory README file
|
||||
(e.g. lib/reax/README) has instructions on how to build that library.
|
||||
Typically this is done by typing something like:
|
||||
|
||||
make -f Makefile.g++ :pre
|
||||
@ -802,20 +825,22 @@ 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.
|
||||
|
||||
For libraries without provided source code, the file
|
||||
src/package/README has information on where to find the library and
|
||||
how to build it, e.g. src/VORONOI/README. There is also a
|
||||
Makefile.lammps file in the src/package directory. E.g. files
|
||||
src/KIM/Makefile.lammps or src/VORONOI/Makefile.lammps or
|
||||
src/UESR-MOLFILE/Makefile.lammps. These files serve the same purpose
|
||||
as the lib/package/Makefile.lammps files described above. The files
|
||||
have settings needed when LAMMPS is built to link with the
|
||||
corresponding auxiliary library.
|
||||
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. 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.
|
||||
|
||||
Again, you must insure that the settings in
|
||||
src/package/Makefile.lammps are appropriate for your system and where
|
||||
you installed the auxiliary library. If they are not, the LAMMPS
|
||||
build will typically fail.
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
:line
|
||||
|
||||
@ -906,6 +931,13 @@ 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
|
||||
@ -920,13 +952,13 @@ 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 lib-atc lib-meam
|
||||
Build libs for all installed packages: Make.py -p cuda gpu -gpu mode=double arch=31 lib-all
|
||||
Create a Makefile from scratch with compiler and MPI settings: Make.py -m none -cc g++ -mpi mpich file
|
||||
Augment Makefile.serial with settings for installed packages: Make.py -p intel -intel cpu -m serial file
|
||||
Add JPG and FFTW support to Makefile.mpi: Make.py -m mpi -jpg -fft fftw file
|
||||
Build LAMMPS with a parallel make using Makefile.mpi: Make.py -j 16 -m mpi exe
|
||||
Build LAMMPS and libs it needs using Makefile.serial with accelerator settings: Make.py -p gpu intel -intel cpu lib-all file serial :tb(s=:)
|
||||
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
|
||||
@ -946,11 +978,15 @@ the "-h" switch.
|
||||
|
||||
E.g. typing "Make.py -h" gives
|
||||
|
||||
Syntax: Make.py switch args ... {action1} {action2} ...
|
||||
actions:
|
||||
lib-all, lib-dir, clean, file, exe or machine
|
||||
zero or more actions, in any order (machine must be last)
|
||||
switches:
|
||||
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:
|
||||
@ -1014,50 +1050,57 @@ more info on wrapping and running LAMMPS from Python.
|
||||
|
||||
To build LAMMPS as a static library (*.a file on Linux), type
|
||||
|
||||
make makelib
|
||||
make -f Makefile.lib foo :pre
|
||||
make foo mode=lib :pre
|
||||
|
||||
where foo is the machine name. This kind of library is typically used
|
||||
to statically link a driver application to LAMMPS, so that you can
|
||||
insure all dependencies are satisfied at compile time. Note that
|
||||
inclusion or exclusion of any desired optional packages should be done
|
||||
before typing "make makelib". The first "make" command will create a
|
||||
current Makefile.lib with all the file names in your src dir. The
|
||||
second "make" command will use it to build LAMMPS as a static library,
|
||||
using the ARCHIVE and ARFLAGS settings in src/MAKE/Makefile.foo. The
|
||||
build will create the file liblammps_foo.a which another application can
|
||||
link to.
|
||||
insure all dependencies are satisfied at compile time. This will use
|
||||
the ARCHIVE and ARFLAGS settings in src/MAKE/Makefile.foo. The build
|
||||
will create the file liblammps_foo.a which another application can
|
||||
link to. It will also create a soft link liblammps.a, which will
|
||||
point to the most recently built static library.
|
||||
|
||||
[Shared library:] :h5
|
||||
|
||||
To build LAMMPS as a shared library (*.so file on Linux), which can be
|
||||
dynamically loaded, e.g. from Python, type
|
||||
|
||||
make makeshlib
|
||||
make -f Makefile.shlib foo :pre
|
||||
make foo mode=shlib :pre
|
||||
|
||||
where foo is the machine name. This kind of library is required when
|
||||
wrapping LAMMPS with Python; see "Section_python"_Section_python.html
|
||||
for details. Again, note that inclusion or exclusion of any desired
|
||||
optional packages should be done before typing "make makelib". The
|
||||
first "make" command will create a current Makefile.shlib with all the
|
||||
file names in your src dir. The second "make" command will use it to
|
||||
build LAMMPS as a shared library, using the SHFLAGS and SHLIBFLAGS
|
||||
settings in src/MAKE/Makefile.foo. The build will create the file
|
||||
liblammps_foo.so which another application can link to dyamically. It
|
||||
will also create a soft link liblammps.so, which the Python wrapper uses
|
||||
by default.
|
||||
for details. This will use the SHFLAGS and SHLIBFLAGS settings in
|
||||
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 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.
|
||||
|
||||
Note that for a shared library to be usable by a calling program, all
|
||||
the auxiliary libraries it depends on must also exist as shared
|
||||
libraries. This will be the case for libraries included with LAMMPS,
|
||||
such as the dummy MPI library in src/STUBS or any package libraries in
|
||||
lib/packges, since they are always built as shared libraries with the
|
||||
-fPIC switch. However, if a library like MPI or FFTW does not exist
|
||||
as a shared library, the second make command will generate an error.
|
||||
This means you will need to install a shared library version of the
|
||||
package. The build instructions for the library should tell you how
|
||||
to do this.
|
||||
lib/packages, since they are always built as shared libraries using
|
||||
the -fPIC switch. However, if a library like MPI or FFTW does not
|
||||
exist as a shared library, the shared library build will generate an
|
||||
error. This means you will need to install a shared library version
|
||||
of the auxiliary library. The build instructions for the library
|
||||
should tell you how to do this.
|
||||
|
||||
Here is an example of such errors when the system FFTW or provided
|
||||
lib/colvars library have not been built as shared libraries:
|
||||
|
||||
/usr/bin/ld: /usr/local/lib/libfftw3.a(mapflags.o): relocation
|
||||
R_X86_64_32 against `.rodata' can not be used when making a shared
|
||||
object; recompile with -fPIC
|
||||
/usr/local/lib/libfftw3.a: could not read symbols: Bad value :pre
|
||||
|
||||
/usr/bin/ld: ../../lib/colvars/libcolvars.a(colvarmodule.o):
|
||||
relocation R_X86_64_32 against `__pthread_key_create' can not be used
|
||||
when making a shared object; recompile with -fPIC
|
||||
../../lib/colvars/libcolvars.a: error adding symbols: Bad value :pre
|
||||
|
||||
As an example, here is how to build and install the "MPICH
|
||||
library"_mpich, a popular open-source version of MPI, distributed by
|
||||
|
||||
@ -62,8 +62,7 @@ Xeon Phi(TM) coprocessor is the same except for these additional
|
||||
steps:
|
||||
</P>
|
||||
<UL><LI>add the flag -DLMP_INTEL_OFFLOAD to CCFLAGS in your Makefile.machine
|
||||
<LI>add the flag -offload to LINKFLAGS in your Makefile.machine
|
||||
<LI>specify how many coprocessor threads per MPI task to use
|
||||
<LI>add the flag -offload to LINKFLAGS in your Makefile.machine
|
||||
</UL>
|
||||
<P>The latter two steps in the first case and the last step in the
|
||||
coprocessor case can be done using the "-pk intel" and "-sf intel"
|
||||
@ -75,7 +74,7 @@ commands respectively to your input script.
|
||||
<P><B>Required hardware/software:</B>
|
||||
</P>
|
||||
<P>To use the offload option, you must have one or more Intel(R) Xeon
|
||||
Phi(TM) coprocessors.
|
||||
Phi(TM) coprocessors and use an Intel(R) C++ compiler.
|
||||
</P>
|
||||
<P>Optimizations for vectorization have only been tested with the
|
||||
Intel(R) compiler. Use of other compilers may not result in
|
||||
@ -85,10 +84,18 @@ vectorization or give poor performance.
|
||||
g++ will not recognize some of the settings, so they cannot be used).
|
||||
The compiler must support the OpenMP interface.
|
||||
</P>
|
||||
<P>The recommended version of the Intel(R) compiler is 14.0.1.106.
|
||||
Versions 15.0.1.133 and later are also supported. If using Intel(R)
|
||||
MPI, versions 15.0.2.044 and later are recommended.
|
||||
</P>
|
||||
<P><B>Building LAMMPS with the USER-INTEL package:</B>
|
||||
</P>
|
||||
<P>You must choose at build time whether to build for CPU acceleration or
|
||||
to use the Xeon Phi in offload mode.
|
||||
<P>You can choose to build with or without support for offload to a
|
||||
Intel(R) Xeon Phi(TM) coprocessor. If you build with support for a
|
||||
coprocessor, the same binary can be used on nodes with and without
|
||||
coprocessors installed. However, if you do not have coprocessors
|
||||
on your system, building without offload support will produce a
|
||||
smaller binary.
|
||||
</P>
|
||||
<P>You can do either in one line, using the src/Make.py script, described
|
||||
in <A HREF = "Section_start.html#start_4">Section 2.4</A> of the manual. Type
|
||||
@ -119,7 +126,9 @@ both the CCFLAGS and LINKFLAGS variables. You also need to add
|
||||
</P>
|
||||
<P>If you are compiling on the same architecture that will be used for
|
||||
the runs, adding the flag <I>-xHost</I> to CCFLAGS will enable
|
||||
vectorization with the Intel(R) compiler.
|
||||
vectorization with the Intel(R) compiler. Otherwise, you must
|
||||
provide the correct compute node architecture to the -x option
|
||||
(e.g. -xAVX).
|
||||
</P>
|
||||
<P>In order to build with support for an Intel(R) Xeon Phi(TM)
|
||||
coprocessor, the flag <I>-offload</I> should be added to the LINKFLAGS line
|
||||
@ -130,10 +139,20 @@ included in the src/MAKE/OPTIONS directory with settings that perform
|
||||
well with the Intel(R) compiler. The latter file has support for
|
||||
offload to coprocessors; the former does not.
|
||||
</P>
|
||||
<P>If using an Intel compiler, it is recommended that Intel(R) Compiler
|
||||
2013 SP1 update 1 be used. Newer versions have some performance
|
||||
issues that are being addressed. If using Intel(R) MPI, version 5 or
|
||||
higher is recommended.
|
||||
<P><B>Notes on CPU and core affinity:</B>
|
||||
</P>
|
||||
<P>Setting core affinity is often used to pin MPI tasks and OpenMP
|
||||
threads to a core or group of cores so that memory access can be
|
||||
uniform. Unless disabled at build time, affinity for MPI tasks and
|
||||
OpenMP threads on the host will be set by default on the host
|
||||
when using offload to a coprocessor. In this case, it is unnecessary
|
||||
to use other methods to control affinity (e.g. taskset, numactl,
|
||||
I_MPI_PIN_DOMAIN, etc.). This can be disabled in an input script
|
||||
with the <I>no_affinity</I> option to the <A HREF = "package.html">package intel</A>
|
||||
command or by disabling the option at build time (by adding
|
||||
-DINTEL_OFFLOAD_NOAFFINITY to the CCFLAGS line of your Makefile).
|
||||
Disabling this option is not recommended, especially when running
|
||||
on a machine with hyperthreading disabled.
|
||||
</P>
|
||||
<P><B>Running with the USER-INTEL package from the command line:</B>
|
||||
</P>
|
||||
|
||||
@ -59,8 +59,7 @@ Xeon Phi(TM) coprocessor is the same except for these additional
|
||||
steps:
|
||||
|
||||
add the flag -DLMP_INTEL_OFFLOAD to CCFLAGS in your Makefile.machine
|
||||
add the flag -offload to LINKFLAGS in your Makefile.machine
|
||||
specify how many coprocessor threads per MPI task to use :ul
|
||||
add the flag -offload to LINKFLAGS in your Makefile.machine :ul
|
||||
|
||||
The latter two steps in the first case and the last step in the
|
||||
coprocessor case can be done using the "-pk intel" and "-sf intel"
|
||||
@ -72,7 +71,7 @@ commands respectively to your input script.
|
||||
[Required hardware/software:]
|
||||
|
||||
To use the offload option, you must have one or more Intel(R) Xeon
|
||||
Phi(TM) coprocessors.
|
||||
Phi(TM) coprocessors and use an Intel(R) C++ compiler.
|
||||
|
||||
Optimizations for vectorization have only been tested with the
|
||||
Intel(R) compiler. Use of other compilers may not result in
|
||||
@ -82,10 +81,18 @@ Use of an Intel C++ compiler is recommended, but not required (though
|
||||
g++ will not recognize some of the settings, so they cannot be used).
|
||||
The compiler must support the OpenMP interface.
|
||||
|
||||
The recommended version of the Intel(R) compiler is 14.0.1.106.
|
||||
Versions 15.0.1.133 and later are also supported. If using Intel(R)
|
||||
MPI, versions 15.0.2.044 and later are recommended.
|
||||
|
||||
[Building LAMMPS with the USER-INTEL package:]
|
||||
|
||||
You must choose at build time whether to build for CPU acceleration or
|
||||
to use the Xeon Phi in offload mode.
|
||||
You can choose to build with or without support for offload to a
|
||||
Intel(R) Xeon Phi(TM) coprocessor. If you build with support for a
|
||||
coprocessor, the same binary can be used on nodes with and without
|
||||
coprocessors installed. However, if you do not have coprocessors
|
||||
on your system, building without offload support will produce a
|
||||
smaller binary.
|
||||
|
||||
You can do either in one line, using the src/Make.py script, described
|
||||
in "Section 2.4"_Section_start.html#start_4 of the manual. Type
|
||||
@ -116,7 +123,9 @@ both the CCFLAGS and LINKFLAGS variables. You also need to add
|
||||
|
||||
If you are compiling on the same architecture that will be used for
|
||||
the runs, adding the flag {-xHost} to CCFLAGS will enable
|
||||
vectorization with the Intel(R) compiler.
|
||||
vectorization with the Intel(R) compiler. Otherwise, you must
|
||||
provide the correct compute node architecture to the -x option
|
||||
(e.g. -xAVX).
|
||||
|
||||
In order to build with support for an Intel(R) Xeon Phi(TM)
|
||||
coprocessor, the flag {-offload} should be added to the LINKFLAGS line
|
||||
@ -127,10 +136,20 @@ included in the src/MAKE/OPTIONS directory with settings that perform
|
||||
well with the Intel(R) compiler. The latter file has support for
|
||||
offload to coprocessors; the former does not.
|
||||
|
||||
If using an Intel compiler, it is recommended that Intel(R) Compiler
|
||||
2013 SP1 update 1 be used. Newer versions have some performance
|
||||
issues that are being addressed. If using Intel(R) MPI, version 5 or
|
||||
higher is recommended.
|
||||
[Notes on CPU and core affinity:]
|
||||
|
||||
Setting core affinity is often used to pin MPI tasks and OpenMP
|
||||
threads to a core or group of cores so that memory access can be
|
||||
uniform. Unless disabled at build time, affinity for MPI tasks and
|
||||
OpenMP threads on the host will be set by default on the host
|
||||
when using offload to a coprocessor. In this case, it is unnecessary
|
||||
to use other methods to control affinity (e.g. taskset, numactl,
|
||||
I_MPI_PIN_DOMAIN, etc.). This can be disabled in an input script
|
||||
with the {no_affinity} option to the "package intel"_package.html
|
||||
command or by disabling the option at build time (by adding
|
||||
-DINTEL_OFFLOAD_NOAFFINITY to the CCFLAGS line of your Makefile).
|
||||
Disabling this option is not recommended, especially when running
|
||||
on a machine with hyperthreading disabled.
|
||||
|
||||
[Running with the USER-INTEL package from the command line:]
|
||||
|
||||
|
||||
@ -508,4 +508,7 @@ available backend programming models. Specifically, Kokkos requires
|
||||
extensive C++ support from the Kernel language. This is expected to
|
||||
change in the future.
|
||||
</P>
|
||||
<P>Kokkos must be built with a C++11 compatible compiler. For example,
|
||||
gcc 4.7.2 or later.
|
||||
</P>
|
||||
</HTML>
|
||||
|
||||
@ -504,3 +504,6 @@ Currently Kokkos does not support AMD GPUs due to limits in the
|
||||
available backend programming models. Specifically, Kokkos requires
|
||||
extensive C++ support from the Kernel language. This is expected to
|
||||
change in the future.
|
||||
|
||||
Kokkos must be built with a C++11 compatible compiler. For example,
|
||||
gcc 4.7.2 or later.
|
||||
|
||||
@ -11,6 +11,8 @@
|
||||
|
||||
<H3>angle_style charmm command
|
||||
</H3>
|
||||
<H3>angle_style charmm/kk command
|
||||
</H3>
|
||||
<H3>angle_style charmm/omp command
|
||||
</H3>
|
||||
<P><B>Syntax:</B>
|
||||
@ -76,7 +78,7 @@ more instructions on how to use the accelerated styles effectively.
|
||||
<P><B>Restrictions:</B>
|
||||
</P>
|
||||
<P>This angle style can only be used if LAMMPS was built with the
|
||||
MOLECULAR package (which it is by default). See the <A HREF = "Section_start.html#start_3">Making
|
||||
MOLECULE package (which it is by default). See the <A HREF = "Section_start.html#start_3">Making
|
||||
LAMMPS</A> section for more info on packages.
|
||||
</P>
|
||||
<P><B>Related commands:</B>
|
||||
|
||||
@ -7,6 +7,7 @@
|
||||
:line
|
||||
|
||||
angle_style charmm command :h3
|
||||
angle_style charmm/kk command :h3
|
||||
angle_style charmm/omp command :h3
|
||||
|
||||
[Syntax:]
|
||||
@ -72,7 +73,7 @@ more instructions on how to use the accelerated styles effectively.
|
||||
[Restrictions:]
|
||||
|
||||
This angle style can only be used if LAMMPS was built with the
|
||||
MOLECULAR package (which it is by default). See the "Making
|
||||
MOLECULE package (which it is by default). See the "Making
|
||||
LAMMPS"_Section_start.html#start_3 section for more info on packages.
|
||||
|
||||
[Related commands:]
|
||||
|
||||
@ -65,7 +65,7 @@ more instructions on how to use the accelerated styles effectively.
|
||||
<P><B>Restrictions:</B>
|
||||
</P>
|
||||
<P>This angle style can only be used if LAMMPS was built with the
|
||||
MOLECULAR package (which it is by default). See the <A HREF = "Section_start.html#start_3">Making
|
||||
MOLECULE package (which it is by default). See the <A HREF = "Section_start.html#start_3">Making
|
||||
LAMMPS</A> section for more info on packages.
|
||||
</P>
|
||||
<P><B>Related commands:</B>
|
||||
|
||||
@ -61,7 +61,7 @@ more instructions on how to use the accelerated styles effectively.
|
||||
[Restrictions:]
|
||||
|
||||
This angle style can only be used if LAMMPS was built with the
|
||||
MOLECULAR package (which it is by default). See the "Making
|
||||
MOLECULE package (which it is by default). See the "Making
|
||||
LAMMPS"_Section_start.html#start_3 section for more info on packages.
|
||||
|
||||
[Related commands:]
|
||||
|
||||
@ -70,7 +70,7 @@ more instructions on how to use the accelerated styles effectively.
|
||||
<P><B>Restrictions:</B>
|
||||
</P>
|
||||
<P>This angle style can only be used if LAMMPS was built with the
|
||||
MOLECULAR package (which it is by default). See the <A HREF = "Section_start.html#start_3">Making
|
||||
MOLECULE package (which it is by default). See the <A HREF = "Section_start.html#start_3">Making
|
||||
LAMMPS</A> section for more info on packages.
|
||||
</P>
|
||||
<P><B>Related commands:</B>
|
||||
|
||||
@ -66,7 +66,7 @@ more instructions on how to use the accelerated styles effectively.
|
||||
[Restrictions:]
|
||||
|
||||
This angle style can only be used if LAMMPS was built with the
|
||||
MOLECULAR package (which it is by default). See the "Making
|
||||
MOLECULE package (which it is by default). See the "Making
|
||||
LAMMPS"_Section_start.html#start_3 section for more info on packages.
|
||||
|
||||
[Related commands:]
|
||||
|
||||
@ -78,7 +78,7 @@ more instructions on how to use the accelerated styles effectively.
|
||||
<P><B>Restrictions:</B>
|
||||
</P>
|
||||
<P>This angle style can only be used if LAMMPS was built with the
|
||||
MOLECULAR package (which it is by default). See the <A HREF = "Section_start.html#start_3">Making
|
||||
MOLECULE package (which it is by default). See the <A HREF = "Section_start.html#start_3">Making
|
||||
LAMMPS</A> section for more info on packages.
|
||||
</P>
|
||||
<P><B>Related commands:</B>
|
||||
|
||||
@ -74,7 +74,7 @@ more instructions on how to use the accelerated styles effectively.
|
||||
[Restrictions:]
|
||||
|
||||
This angle style can only be used if LAMMPS was built with the
|
||||
MOLECULAR package (which it is by default). See the "Making
|
||||
MOLECULE package (which it is by default). See the "Making
|
||||
LAMMPS"_Section_start.html#start_3 section for more info on packages.
|
||||
|
||||
[Related commands:]
|
||||
|
||||
@ -70,7 +70,7 @@ more instructions on how to use the accelerated styles effectively.
|
||||
<P><B>Restrictions:</B>
|
||||
</P>
|
||||
<P>This angle style can only be used if LAMMPS was built with the
|
||||
MOLECULAR package (which it is by default). See the <A HREF = "Section_start.html#start_3">Making
|
||||
MOLECULE package (which it is by default). See the <A HREF = "Section_start.html#start_3">Making
|
||||
LAMMPS</A> section for more info on packages.
|
||||
</P>
|
||||
<P><B>Related commands:</B>
|
||||
|
||||
@ -66,7 +66,7 @@ more instructions on how to use the accelerated styles effectively.
|
||||
[Restrictions:]
|
||||
|
||||
This angle style can only be used if LAMMPS was built with the
|
||||
MOLECULAR package (which it is by default). See the "Making
|
||||
MOLECULE package (which it is by default). See the "Making
|
||||
LAMMPS"_Section_start.html#start_3 section for more info on packages.
|
||||
|
||||
[Related commands:]
|
||||
|
||||
@ -11,6 +11,8 @@
|
||||
|
||||
<H3>angle_style harmonic command
|
||||
</H3>
|
||||
<H3>angle_style harmonic/kk command
|
||||
</H3>
|
||||
<H3>angle_style harmonic/omp command
|
||||
</H3>
|
||||
<P><B>Syntax:</B>
|
||||
@ -70,7 +72,7 @@ more instructions on how to use the accelerated styles effectively.
|
||||
<P><B>Restrictions:</B> none
|
||||
</P>
|
||||
<P>This angle style can only be used if LAMMPS was built with the
|
||||
MOLECULAR package (which it is by default). See the <A HREF = "Section_start.html#start_3">Making
|
||||
MOLECULE package (which it is by default). See the <A HREF = "Section_start.html#start_3">Making
|
||||
LAMMPS</A> section for more info on packages.
|
||||
</P>
|
||||
<P><B>Related commands:</B>
|
||||
|
||||
@ -7,6 +7,7 @@
|
||||
:line
|
||||
|
||||
angle_style harmonic command :h3
|
||||
angle_style harmonic/kk command :h3
|
||||
angle_style harmonic/omp command :h3
|
||||
|
||||
[Syntax:]
|
||||
@ -66,7 +67,7 @@ more instructions on how to use the accelerated styles effectively.
|
||||
[Restrictions:] none
|
||||
|
||||
This angle style can only be used if LAMMPS was built with the
|
||||
MOLECULAR package (which it is by default). See the "Making
|
||||
MOLECULE package (which it is by default). See the "Making
|
||||
LAMMPS"_Section_start.html#start_3 section for more info on packages.
|
||||
|
||||
[Related commands:]
|
||||
|
||||
@ -79,7 +79,7 @@ for specific angle types.
|
||||
<P><B>Restrictions:</B>
|
||||
</P>
|
||||
<P>This angle style can only be used if LAMMPS was built with the
|
||||
MOLECULAR package (which it is by default). See the <A HREF = "Section_start.html#start_3">Making
|
||||
MOLECULE package (which it is by default). See the <A HREF = "Section_start.html#start_3">Making
|
||||
LAMMPS</A> section for more info on packages.
|
||||
</P>
|
||||
<P>Unlike other angle styles, the hybrid angle style does not store angle
|
||||
|
||||
@ -76,7 +76,7 @@ for specific angle types.
|
||||
[Restrictions:]
|
||||
|
||||
This angle style can only be used if LAMMPS was built with the
|
||||
MOLECULAR package (which it is by default). See the "Making
|
||||
MOLECULE package (which it is by default). See the "Making
|
||||
LAMMPS"_Section_start.html#start_3 section for more info on packages.
|
||||
|
||||
Unlike other angle styles, the hybrid angle style does not store angle
|
||||
|
||||
@ -83,7 +83,7 @@ page</A>.
|
||||
<P>Angle styles can only be set for atom_styles that allow angles to be
|
||||
defined.
|
||||
</P>
|
||||
<P>Most angle styles are part of the MOLECULAR package. They are only
|
||||
<P>Most angle styles are part of the MOLECULE package. They are only
|
||||
enabled if LAMMPS was built with that package. See the <A HREF = "Section_start.html#start_3">Making
|
||||
LAMMPS</A> section for more info on packages.
|
||||
The doc pages for individual bond potentials tell if it is part of a
|
||||
|
||||
@ -81,7 +81,7 @@ page"_Section_commands.html#cmd_5.
|
||||
Angle styles can only be set for atom_styles that allow angles to be
|
||||
defined.
|
||||
|
||||
Most angle styles are part of the MOLECULAR package. They are only
|
||||
Most angle styles are part of the MOLECULE 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 on packages.
|
||||
The doc pages for individual bond potentials tell if it is part of a
|
||||
|
||||
@ -151,7 +151,7 @@ more instructions on how to use the accelerated styles effectively.
|
||||
<P><B>Restrictions:</B>
|
||||
</P>
|
||||
<P>This angle style can only be used if LAMMPS was built with the
|
||||
MOLECULAR package (which it is by default). See the <A HREF = "Section_start.html#start_3">Making
|
||||
MOLECULE package (which it is by default). See the <A HREF = "Section_start.html#start_3">Making
|
||||
LAMMPS</A> section for more info on packages.
|
||||
</P>
|
||||
<P><B>Related commands:</B>
|
||||
|
||||
@ -147,7 +147,7 @@ more instructions on how to use the accelerated styles effectively.
|
||||
[Restrictions:]
|
||||
|
||||
This angle style can only be used if LAMMPS was built with the
|
||||
MOLECULAR package (which it is by default). See the "Making
|
||||
MOLECULE package (which it is by default). See the "Making
|
||||
LAMMPS"_Section_start.html#start_3 section for more info on packages.
|
||||
|
||||
[Related commands:]
|
||||
|
||||
@ -26,7 +26,7 @@
|
||||
template-ID = ID of molecule template specified in a separate <A HREF = "molecule.html">molecule</A> command
|
||||
<I>hybrid</I> args = list of one or more sub-styles, each with their args
|
||||
</PRE>
|
||||
<LI>accelerated styles (with same args) = <I>angle/cuda</I> or <I>angle/kokkos</I> or <I>atomic/cuda</I> or <I>atomic/kokkos</I> or <I>bond/kokkos</I> or <I>charge/cuda</I> or <I>charge/kokkos</I> or <I>full/cuda</I> or <I>full/kokkos</I> or <I>molecular/kokkos</I>
|
||||
<LI>accelerated styles (with same args) = <I>angle/cuda</I> or <I>angle/kk</I> or <I>atomic/cuda</I> or <I>atomic/kk</I> or <I>bond/kk</I> or <I>charge/cuda</I> or <I>charge/kk</I> or <I>full/cuda</I> or <I>full/kk</I> or <I>molecular/kk</I>
|
||||
|
||||
|
||||
</UL>
|
||||
@ -237,7 +237,7 @@ more instructions on how to use the accelerated styles effectively.
|
||||
<A HREF = "read_data.html">read_data</A> or <A HREF = "create_box.html">create_box</A> command.
|
||||
</P>
|
||||
<P>The <I>angle</I>, <I>bond</I>, <I>full</I>, <I>molecular</I>, and <I>template</I> styles are
|
||||
part of the MOLECULAR package. The <I>line</I> and <I>tri</I> styles are part
|
||||
part of the MOLECULE package. The <I>line</I> and <I>tri</I> styles are part
|
||||
of the ASPHERE pacakge. The <I>body</I> style is part of the BODY package.
|
||||
The <I>dipole</I> style is part of the DIPOLE package. The <I>peri</I> style is
|
||||
part of the PERI package for Peridynamics. The <I>electron</I> style is
|
||||
|
||||
@ -24,7 +24,7 @@ style = {angle} or {atomic} or {body} or {bond} or {charge} or {dipole} or \
|
||||
template-ID = ID of molecule template specified in a separate "molecule"_molecule.html command
|
||||
{hybrid} args = list of one or more sub-styles, each with their args :pre
|
||||
|
||||
accelerated styles (with same args) = {angle/cuda} or {angle/kokkos} or {atomic/cuda} or {atomic/kokkos} or {bond/kokkos} or {charge/cuda} or {charge/kokkos} or {full/cuda} or {full/kokkos} or {molecular/kokkos} :l
|
||||
accelerated styles (with same args) = {angle/cuda} or {angle/kk} or {atomic/cuda} or {atomic/kk} or {bond/kk} or {charge/cuda} or {charge/kk} or {full/cuda} or {full/kk} or {molecular/kk} :l
|
||||
:ule
|
||||
|
||||
[Examples:]
|
||||
@ -232,7 +232,7 @@ This command cannot be used after the simulation box is defined by a
|
||||
"read_data"_read_data.html or "create_box"_create_box.html command.
|
||||
|
||||
The {angle}, {bond}, {full}, {molecular}, and {template} styles are
|
||||
part of the MOLECULAR package. The {line} and {tri} styles are part
|
||||
part of the MOLECULE package. The {line} and {tri} styles are part
|
||||
of the ASPHERE pacakge. The {body} style is part of the BODY package.
|
||||
The {dipole} style is part of the DIPOLE package. The {peri} style is
|
||||
part of the PERI package for Peridynamics. The {electron} style is
|
||||
|
||||
@ -11,6 +11,8 @@
|
||||
|
||||
<H3>bond_style fene command
|
||||
</H3>
|
||||
<H3>bond_style fene/kk command
|
||||
</H3>
|
||||
<H3>bond_style fene/omp command
|
||||
</H3>
|
||||
<P><B>Syntax:</B>
|
||||
@ -72,7 +74,7 @@ more instructions on how to use the accelerated styles effectively.
|
||||
<P><B>Restrictions:</B>
|
||||
</P>
|
||||
<P>This bond style can only be used if LAMMPS was built with the
|
||||
MOLECULAR package (which it is by default). See the <A HREF = "Section_start.html#start_3">Making
|
||||
MOLECULE package (which it is by default). See the <A HREF = "Section_start.html#start_3">Making
|
||||
LAMMPS</A> section for more info on packages.
|
||||
</P>
|
||||
<P>You typically should specify <A HREF = "special_bonds.html"">special_bonds fene</A>
|
||||
|
||||
@ -7,6 +7,7 @@
|
||||
:line
|
||||
|
||||
bond_style fene command :h3
|
||||
bond_style fene/kk command :h3
|
||||
bond_style fene/omp command :h3
|
||||
|
||||
[Syntax:]
|
||||
@ -68,7 +69,7 @@ more instructions on how to use the accelerated styles effectively.
|
||||
[Restrictions:]
|
||||
|
||||
This bond style can only be used if LAMMPS was built with the
|
||||
MOLECULAR package (which it is by default). See the "Making
|
||||
MOLECULE package (which it is by default). See the "Making
|
||||
LAMMPS"_Section_start.html#start_3 section for more info on packages.
|
||||
|
||||
You typically should specify "special_bonds fene"_special_bonds.html"
|
||||
|
||||
@ -77,7 +77,7 @@ more instructions on how to use the accelerated styles effectively.
|
||||
<P><B>Restrictions:</B>
|
||||
</P>
|
||||
<P>This bond style can only be used if LAMMPS was built with the
|
||||
MOLECULAR package (which it is by default). See the <A HREF = "Section_start.html#start_3">Making
|
||||
MOLECULE package (which it is by default). See the <A HREF = "Section_start.html#start_3">Making
|
||||
LAMMPS</A> section for more info on packages.
|
||||
</P>
|
||||
<P>You typically should specify <A HREF = "special_bonds.html"">special_bonds fene</A>
|
||||
|
||||
@ -73,7 +73,7 @@ more instructions on how to use the accelerated styles effectively.
|
||||
[Restrictions:]
|
||||
|
||||
This bond style can only be used if LAMMPS was built with the
|
||||
MOLECULAR package (which it is by default). See the "Making
|
||||
MOLECULE package (which it is by default). See the "Making
|
||||
LAMMPS"_Section_start.html#start_3 section for more info on packages.
|
||||
|
||||
You typically should specify "special_bonds fene"_special_bonds.html"
|
||||
|
||||
@ -11,6 +11,8 @@
|
||||
|
||||
<H3>bond_style harmonic command
|
||||
</H3>
|
||||
<H3>bond_style harmonic/kk command
|
||||
</H3>
|
||||
<H3>bond_style harmonic/omp command
|
||||
</H3>
|
||||
<P><B>Syntax:</B>
|
||||
@ -67,7 +69,7 @@ more instructions on how to use the accelerated styles effectively.
|
||||
<P><B>Restrictions:</B>
|
||||
</P>
|
||||
<P>This bond style can only be used if LAMMPS was built with the
|
||||
MOLECULAR package (which it is by default). See the <A HREF = "Section_start.html#start_3">Making
|
||||
MOLECULE package (which it is by default). See the <A HREF = "Section_start.html#start_3">Making
|
||||
LAMMPS</A> section for more info on packages.
|
||||
</P>
|
||||
<P><B>Related commands:</B>
|
||||
|
||||
@ -7,6 +7,7 @@
|
||||
:line
|
||||
|
||||
bond_style harmonic command :h3
|
||||
bond_style harmonic/kk command :h3
|
||||
bond_style harmonic/omp command :h3
|
||||
|
||||
[Syntax:]
|
||||
@ -63,7 +64,7 @@ more instructions on how to use the accelerated styles effectively.
|
||||
[Restrictions:]
|
||||
|
||||
This bond style can only be used if LAMMPS was built with the
|
||||
MOLECULAR package (which it is by default). See the "Making
|
||||
MOLECULE package (which it is by default). See the "Making
|
||||
LAMMPS"_Section_start.html#start_3 section for more info on packages.
|
||||
|
||||
[Related commands:]
|
||||
|
||||
@ -62,7 +62,7 @@ bond types.
|
||||
<P><B>Restrictions:</B>
|
||||
</P>
|
||||
<P>This bond style can only be used if LAMMPS was built with the
|
||||
MOLECULAR package (which it is by default). See the <A HREF = "Section_start.html#start_3">Making
|
||||
MOLECULE package (which it is by default). See the <A HREF = "Section_start.html#start_3">Making
|
||||
LAMMPS</A> section for more info on packages.
|
||||
</P>
|
||||
<P>Unlike other bond styles, the hybrid bond style does not store bond
|
||||
|
||||
@ -59,7 +59,7 @@ bond types.
|
||||
[Restrictions:]
|
||||
|
||||
This bond style can only be used if LAMMPS was built with the
|
||||
MOLECULAR package (which it is by default). See the "Making
|
||||
MOLECULE package (which it is by default). See the "Making
|
||||
LAMMPS"_Section_start.html#start_3 section for more info on packages.
|
||||
|
||||
Unlike other bond styles, the hybrid bond style does not store bond
|
||||
|
||||
@ -68,7 +68,7 @@ more instructions on how to use the accelerated styles effectively.
|
||||
<P><B>Restrictions:</B>
|
||||
</P>
|
||||
<P>This bond style can only be used if LAMMPS was built with the
|
||||
MOLECULAR package (which it is by default). See the <A HREF = "Section_start.html#start_3">Making
|
||||
MOLECULE package (which it is by default). See the <A HREF = "Section_start.html#start_3">Making
|
||||
LAMMPS</A> section for more info on packages.
|
||||
</P>
|
||||
<P><B>Related commands:</B>
|
||||
|
||||
@ -64,7 +64,7 @@ more instructions on how to use the accelerated styles effectively.
|
||||
[Restrictions:]
|
||||
|
||||
This bond style can only be used if LAMMPS was built with the
|
||||
MOLECULAR package (which it is by default). See the "Making
|
||||
MOLECULE package (which it is by default). See the "Making
|
||||
LAMMPS"_Section_start.html#start_3 section for more info on packages.
|
||||
|
||||
[Related commands:]
|
||||
|
||||
@ -68,7 +68,7 @@ more instructions on how to use the accelerated styles effectively.
|
||||
<P><B>Restrictions:</B>
|
||||
</P>
|
||||
<P>This bond style can only be used if LAMMPS was built with the
|
||||
MOLECULAR package (which it is by default). See the <A HREF = "Section_start.html#start_3">Making
|
||||
MOLECULE package (which it is by default). See the <A HREF = "Section_start.html#start_3">Making
|
||||
LAMMPS</A> section for more info on packages.
|
||||
</P>
|
||||
<P><B>Related commands:</B>
|
||||
|
||||
@ -64,7 +64,7 @@ more instructions on how to use the accelerated styles effectively.
|
||||
[Restrictions:]
|
||||
|
||||
This bond style can only be used if LAMMPS was built with the
|
||||
MOLECULAR package (which it is by default). See the "Making
|
||||
MOLECULE package (which it is by default). See the "Making
|
||||
LAMMPS"_Section_start.html#start_3 section for more info on packages.
|
||||
|
||||
[Related commands:]
|
||||
|
||||
@ -103,7 +103,7 @@ more instructions on how to use the accelerated styles effectively.
|
||||
<P><B>Restrictions:</B>
|
||||
</P>
|
||||
<P>This bond style can only be used if LAMMPS was built with the
|
||||
MOLECULAR package (which it is by default). See the <A HREF = "Section_start.html#start_3">Making
|
||||
MOLECULE package (which it is by default). See the <A HREF = "Section_start.html#start_3">Making
|
||||
LAMMPS</A> section for more info on packages.
|
||||
</P>
|
||||
<P>The <I>quartic</I> style requires that <A HREF = "special_bonds.html">special_bonds</A>
|
||||
|
||||
@ -99,7 +99,7 @@ more instructions on how to use the accelerated styles effectively.
|
||||
[Restrictions:]
|
||||
|
||||
This bond style can only be used if LAMMPS was built with the
|
||||
MOLECULAR package (which it is by default). See the "Making
|
||||
MOLECULE package (which it is by default). See the "Making
|
||||
LAMMPS"_Section_start.html#start_3 section for more info on packages.
|
||||
|
||||
The {quartic} style requires that "special_bonds"_special_bonds.html
|
||||
|
||||
@ -92,7 +92,7 @@ page</A>.
|
||||
<P>Bond styles can only be set for atom styles that allow bonds to be
|
||||
defined.
|
||||
</P>
|
||||
<P>Most bond styles are part of the MOLECULAR package. They are only
|
||||
<P>Most bond styles are part of the MOLECULE package. They are only
|
||||
enabled if LAMMPS was built with that package. See the <A HREF = "Section_start.html#start_3">Making
|
||||
LAMMPS</A> section for more info on packages.
|
||||
The doc pages for individual bond potentials tell if it is part of a
|
||||
|
||||
@ -89,7 +89,7 @@ page"_Section_commands.html#cmd_5.
|
||||
Bond styles can only be set for atom styles that allow bonds to be
|
||||
defined.
|
||||
|
||||
Most bond styles are part of the MOLECULAR package. They are only
|
||||
Most bond styles are part of the MOLECULE 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 on packages.
|
||||
The doc pages for individual bond potentials tell if it is part of a
|
||||
|
||||
@ -148,7 +148,7 @@ more instructions on how to use the accelerated styles effectively.
|
||||
<P><B>Restrictions:</B>
|
||||
</P>
|
||||
<P>This bond style can only be used if LAMMPS was built with the
|
||||
MOLECULAR package (which it is by default). See the <A HREF = "Section_start.html#start_3">Making
|
||||
MOLECULE package (which it is by default). See the <A HREF = "Section_start.html#start_3">Making
|
||||
LAMMPS</A> section for more info on packages.
|
||||
</P>
|
||||
<P><B>Related commands:</B>
|
||||
|
||||
@ -144,7 +144,7 @@ more instructions on how to use the accelerated styles effectively.
|
||||
[Restrictions:]
|
||||
|
||||
This bond style can only be used if LAMMPS was built with the
|
||||
MOLECULAR package (which it is by default). See the "Making
|
||||
MOLECULE package (which it is by default). See the "Making
|
||||
LAMMPS"_Section_start.html#start_3 section for more info on packages.
|
||||
|
||||
[Related commands:]
|
||||
|
||||
@ -180,14 +180,13 @@ are given in the compute section of <A HREF = "Section_commands.html#cmd_5">this
|
||||
page</A>.
|
||||
</P>
|
||||
<UL><LI><A HREF = "compute_bond_local.html">angle/local</A> - theta and energy of each angle
|
||||
<LI><A HREF = "compute_atom_molecule.html">atom/molecule</A> - sum per-atom properties for each molecule
|
||||
<LI><A HREF = "compute_body_local.html">body/local</A> - attributes of body sub-particles
|
||||
<LI><A HREF = "compute_bond_local.html">bond/local</A> - distance and energy of each bond
|
||||
<LI><A HREF = "compute_centro_atom.html">centro/atom</A> - centro-symmetry parameter for each atom
|
||||
<LI><A HREF = "compute_cluster_atom.html">cluster/atom</A> - cluster ID for each atom
|
||||
<LI><A HREF = "compute_cna_atom.html">cna/atom</A> - common neighbor analysis (CNA) for each atom
|
||||
<LI><A HREF = "compute_com.html">com</A> - center-of-mass of group of atoms
|
||||
<LI><A HREF = "compute_com_molecule.html">com/molecule</A> - center-of-mass for each molecule
|
||||
<LI><A HREF = "compute_com_chunk.html">com/chunk</A> - center-of-mass for each chunk
|
||||
<LI><A HREF = "compute_contact_atom.html">contact/atom</A> - contact count for each spherical particle
|
||||
<LI><A HREF = "compute_coord_atom.html">coord/atom</A> - coordination number for each atom
|
||||
<LI><A HREF = "compute_damage_atom.html">damage/atom</A> - Peridynamic damage for each atom
|
||||
@ -201,15 +200,15 @@ page</A>.
|
||||
<LI><A HREF = "compute_event_displace.html">event/displace</A> - detect event on atom displacement
|
||||
<LI><A HREF = "compute_group_group.html">group/group</A> - energy/force between two groups of atoms
|
||||
<LI><A HREF = "compute_gyration.html">gyration</A> - radius of gyration of group of atoms
|
||||
<LI><A HREF = "compute_gyration_molecule.html">gyration/molecule</A> - radius of gyration for each molecule
|
||||
<LI><A HREF = "compute_gyration_chunk.html">gyration/chunk</A> - radius of gyration for each chunk
|
||||
<LI><A HREF = "compute_heat_flux.html">heat/flux</A> - heat flux through a group of atoms
|
||||
<LI><A HREF = "compute_improper_local.html">improper/local</A> - angle of each improper
|
||||
<LI><A HREF = "compute_inertia_molecule.html">inertia/molecule</A> - inertia tensor for each molecule
|
||||
<LI><A HREF = "compute_inertia_chunk.html">inertia/chunk</A> - inertia tensor for each chunk
|
||||
<LI><A HREF = "compute_ke.html">ke</A> - translational kinetic energy
|
||||
<LI><A HREF = "compute_ke_atom.html">ke/atom</A> - kinetic energy for each atom
|
||||
<LI><A HREF = "compute_ke_rigid.html">ke/rigid</A> - translational kinetic energy of rigid bodies
|
||||
<LI><A HREF = "compute_msd.html">msd</A> - mean-squared displacement of group of atoms
|
||||
<LI><A HREF = "compute_msd_molecule.html">msd/molecule</A> - mean-squared displacement for each molecule
|
||||
<LI><A HREF = "compute_msd_chunk.html">msd/chunk</A> - mean-squared displacement for each chunk
|
||||
<LI><A HREF = "compute_msd_nongauss.html">msd/nongauss</A> - MSD and non-Gaussian parameter of group of atoms
|
||||
<LI><A HREF = "compute_pair.html">pair</A> - values computed by a pair style
|
||||
<LI><A HREF = "compute_pair_local.html">pair/local</A> - distance/energy/force of each pairwise interaction
|
||||
@ -219,7 +218,7 @@ page</A>.
|
||||
<LI><A HREF = "compute_pressure.html">pressure</A> - total pressure and pressure tensor
|
||||
<LI><A HREF = "compute_property_atom.html">property/atom</A> - convert atom attributes to per-atom vectors/arrays
|
||||
<LI><A HREF = "compute_property_local.html">property/local</A> - convert local attributes to localvectors/arrays
|
||||
<LI><A HREF = "compute_property_molecule.html">property/molecule</A> - convert molecule attributes to localvectors/arrays
|
||||
<LI><A HREF = "compute_property_chunk.html">property/chunk</A> - extract various per-chunk attributes
|
||||
<LI><A HREF = "compute_rdf.html">rdf</A> - radial distribution function g(r) histogram of group of atoms
|
||||
<LI><A HREF = "compute_reduce.html">reduce</A> - combine per-atom quantities into a single global value
|
||||
<LI><A HREF = "compute_reduce.html">reduce/region</A> - same as compute reduce, within a region
|
||||
@ -230,6 +229,7 @@ page</A>.
|
||||
<LI><A HREF = "compute_stress_atom.html">stress/atom</A> - stress tensor for each atom
|
||||
<LI><A HREF = "compute_temp.html">temp</A> - temperature of group of atoms
|
||||
<LI><A HREF = "compute_temp_asphere.html">temp/asphere</A> - temperature of aspherical particles
|
||||
<LI><A HREF = "compute_temp_chunk.html">temp/chunk</A> - temperature of each chunk
|
||||
<LI><A HREF = "compute_temp_com.html">temp/com</A> - temperature after subtracting center-of-mass velocity
|
||||
<LI><A HREF = "compute_temp_deform.html">temp/deform</A> - temperature excluding box deformation velocity
|
||||
<LI><A HREF = "compute_temp_partial.html">temp/partial</A> - temperature excluding one or more dimensions of velocity
|
||||
@ -238,7 +238,9 @@ page</A>.
|
||||
<LI><A HREF = "compute_temp_region.html">temp/region</A> - temperature of a region of atoms
|
||||
<LI><A HREF = "compute_temp_sphere.html">temp/sphere</A> - temperature of spherical particles
|
||||
<LI><A HREF = "compute_ti.html">ti</A> - thermodyanmic integration free energy values
|
||||
<LI><A HREF = "compute_torque_chunk.html">torque/chunk</A> - torque applied on each chunk
|
||||
<LI><A HREF = "compute_vacf.html">vacf</A> - velocity-autocorrelation function of group of atoms
|
||||
<LI><A HREF = "compute_vcm_chunk.html">vcm/chunk</A> - velocity of center-of-mass for each chunk
|
||||
<LI><A HREF = "compute_voronoi_atom.html">voronoi/atom</A> - Voronoi volume and neighbors for each atom
|
||||
</UL>
|
||||
<P>There are also additional compute styles submitted by users which are
|
||||
|
||||
@ -175,14 +175,13 @@ are given in the compute section of "this
|
||||
page"_Section_commands.html#cmd_5.
|
||||
|
||||
"angle/local"_compute_bond_local.html - theta and energy of each angle
|
||||
"atom/molecule"_compute_atom_molecule.html - sum per-atom properties for each molecule
|
||||
"body/local"_compute_body_local.html - attributes of body sub-particles
|
||||
"bond/local"_compute_bond_local.html - distance and energy of each bond
|
||||
"centro/atom"_compute_centro_atom.html - centro-symmetry parameter for each atom
|
||||
"cluster/atom"_compute_cluster_atom.html - cluster ID for each atom
|
||||
"cna/atom"_compute_cna_atom.html - common neighbor analysis (CNA) for each atom
|
||||
"com"_compute_com.html - center-of-mass of group of atoms
|
||||
"com/molecule"_compute_com_molecule.html - center-of-mass for each molecule
|
||||
"com/chunk"_compute_com_chunk.html - center-of-mass for each chunk
|
||||
"contact/atom"_compute_contact_atom.html - contact count for each spherical particle
|
||||
"coord/atom"_compute_coord_atom.html - coordination number for each atom
|
||||
"damage/atom"_compute_damage_atom.html - Peridynamic damage for each atom
|
||||
@ -196,15 +195,15 @@ page"_Section_commands.html#cmd_5.
|
||||
"event/displace"_compute_event_displace.html - detect event on atom displacement
|
||||
"group/group"_compute_group_group.html - energy/force between two groups of atoms
|
||||
"gyration"_compute_gyration.html - radius of gyration of group of atoms
|
||||
"gyration/molecule"_compute_gyration_molecule.html - radius of gyration for each molecule
|
||||
"gyration/chunk"_compute_gyration_chunk.html - radius of gyration for each chunk
|
||||
"heat/flux"_compute_heat_flux.html - heat flux through a group of atoms
|
||||
"improper/local"_compute_improper_local.html - angle of each improper
|
||||
"inertia/molecule"_compute_inertia_molecule.html - inertia tensor for each molecule
|
||||
"inertia/chunk"_compute_inertia_chunk.html - inertia tensor for each chunk
|
||||
"ke"_compute_ke.html - translational kinetic energy
|
||||
"ke/atom"_compute_ke_atom.html - kinetic energy for each atom
|
||||
"ke/rigid"_compute_ke_rigid.html - translational kinetic energy of rigid bodies
|
||||
"msd"_compute_msd.html - mean-squared displacement of group of atoms
|
||||
"msd/molecule"_compute_msd_molecule.html - mean-squared displacement for each molecule
|
||||
"msd/chunk"_compute_msd_chunk.html - mean-squared displacement for each chunk
|
||||
"msd/nongauss"_compute_msd_nongauss.html - MSD and non-Gaussian parameter of group of atoms
|
||||
"pair"_compute_pair.html - values computed by a pair style
|
||||
"pair/local"_compute_pair_local.html - distance/energy/force of each pairwise interaction
|
||||
@ -214,7 +213,7 @@ page"_Section_commands.html#cmd_5.
|
||||
"pressure"_compute_pressure.html - total pressure and pressure tensor
|
||||
"property/atom"_compute_property_atom.html - convert atom attributes to per-atom vectors/arrays
|
||||
"property/local"_compute_property_local.html - convert local attributes to localvectors/arrays
|
||||
"property/molecule"_compute_property_molecule.html - convert molecule attributes to localvectors/arrays
|
||||
"property/chunk"_compute_property_chunk.html - extract various per-chunk attributes
|
||||
"rdf"_compute_rdf.html - radial distribution function g(r) histogram of group of atoms
|
||||
"reduce"_compute_reduce.html - combine per-atom quantities into a single global value
|
||||
"reduce/region"_compute_reduce.html - same as compute reduce, within a region
|
||||
@ -225,6 +224,7 @@ page"_Section_commands.html#cmd_5.
|
||||
"stress/atom"_compute_stress_atom.html - stress tensor for each atom
|
||||
"temp"_compute_temp.html - temperature of group of atoms
|
||||
"temp/asphere"_compute_temp_asphere.html - temperature of aspherical particles
|
||||
"temp/chunk"_compute_temp_chunk.html - temperature of each chunk
|
||||
"temp/com"_compute_temp_com.html - temperature after subtracting center-of-mass velocity
|
||||
"temp/deform"_compute_temp_deform.html - temperature excluding box deformation velocity
|
||||
"temp/partial"_compute_temp_partial.html - temperature excluding one or more dimensions of velocity
|
||||
@ -233,7 +233,9 @@ page"_Section_commands.html#cmd_5.
|
||||
"temp/region"_compute_temp_region.html - temperature of a region of atoms
|
||||
"temp/sphere"_compute_temp_sphere.html - temperature of spherical particles
|
||||
"ti"_compute_ti.html - thermodyanmic integration free energy values
|
||||
"torque/chunk"_compute_torque_chunk.html - torque applied on each chunk
|
||||
"vacf"_compute_vacf.html - velocity-autocorrelation function of group of atoms
|
||||
"vcm/chunk"_compute_vcm_chunk.html - velocity of center-of-mass for each chunk
|
||||
"voronoi/atom"_compute_voronoi_atom.html - Voronoi volume and neighbors for each atom :ul
|
||||
|
||||
There are also additional compute styles submitted by users which are
|
||||
|
||||
94
doc/compute_angmom_chunk.html
Normal file
94
doc/compute_angmom_chunk.html
Normal file
@ -0,0 +1,94 @@
|
||||
<HTML>
|
||||
<CENTER><A HREF = "http://lammps.sandia.gov">LAMMPS WWW Site</A> - <A HREF = "Manual.html">LAMMPS Documentation</A> - <A HREF = "Section_commands.html#comm">LAMMPS Commands</A>
|
||||
</CENTER>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<HR>
|
||||
|
||||
<H3>compute angmom/chunk command
|
||||
</H3>
|
||||
<P><B>Syntax:</B>
|
||||
</P>
|
||||
<PRE>compute ID group-ID angmom/chunk chunkID
|
||||
</PRE>
|
||||
<UL><LI>ID, group-ID are documented in <A HREF = "compute.html">compute</A> command
|
||||
<LI>angmom/molecule = style name of this compute command
|
||||
<LI>chunkID = ID of <A HREF = "compute_chunk_atom.html">compute chunk/atom</A> command
|
||||
</UL>
|
||||
<P><B>Examples:</B>
|
||||
</P>
|
||||
<PRE>compute 1 fluid angmom/chunk molchunk
|
||||
</PRE>
|
||||
<P><B>Description:</B>
|
||||
</P>
|
||||
<P>Define a computation that calculates the angular momemtum of multiple
|
||||
chunks of atoms.
|
||||
</P>
|
||||
<P>In LAMMPS, chunks are collections of atoms defined by a <A HREF = "compute_chunk_atom.html">compute
|
||||
chunk/atom</A> command, which assigns each atom
|
||||
to a single chunk (or no chunk). The ID for this command is specified
|
||||
as chunkID. For example, a single chunk could be the atoms in a
|
||||
molecule or atoms in a spatial bin. See the <A HREF = "compute_chunk_atom.html">compute
|
||||
chunk/atom</A> doc page and "<A HREF = "Section_howto.html#howto_23">Section_howto
|
||||
23</A> for details of how chunks can be
|
||||
defined and examples of how they can be used to measure properties of
|
||||
a system.
|
||||
</P>
|
||||
<P>This compute calculates the 3 components of the angular momentum
|
||||
vector for each chunk, due to the velocity/momentum of the individual
|
||||
atoms in the chunk around the center-of-mass of the chunk. The
|
||||
calculation includes all effects due to atoms passing thru periodic
|
||||
boundaries.
|
||||
</P>
|
||||
<P>Note that only atoms in the specified group contribute to the
|
||||
calculation. The <A HREF = "compute_chunk_atom.html">compute chunk/atom</A> command
|
||||
defines its own group; atoms will have a chunk ID = 0 if they are not
|
||||
in that group, signifying they are not assigned to a chunk, and will
|
||||
thus also not contribute to this calculation. You can specify the
|
||||
"all" group for this command if you simply want to include atoms with
|
||||
non-zero chunk IDs.
|
||||
</P>
|
||||
<P>IMPORTANT NOTE: The coordinates of an atom contribute to the chunk's
|
||||
angular momentum in "unwrapped" form, by using the image flags
|
||||
associated with each atom. See the <A HREF = "dump.html">dump custom</A> command
|
||||
for a discussion of "unwrapped" coordinates. See the Atoms section of
|
||||
the <A HREF = "read_data.html">read_data</A> command for a discussion of image flags
|
||||
and how they are set for each atom. You can reset the image flags
|
||||
(e.g. to 0) before invoking this compute by using the <A HREF = "set.html">set
|
||||
image</A> command.
|
||||
</P>
|
||||
<P>The simplest way to output the results of the compute angmom/chunk
|
||||
calculation to a file is to use the <A HREF = "fix_ave_time.html">fix ave/time</A>
|
||||
command, for example:
|
||||
</P>
|
||||
<PRE>compute cc1 all chunk/atom molecule
|
||||
compute myChunk all angmom/chunk cc1
|
||||
fix 1 all ave/time 100 1 100 c_myChunk file tmp.out mode vector
|
||||
</PRE>
|
||||
<P><B>Output info:</B>
|
||||
</P>
|
||||
<P>This compute calculates a global array where the number of rows = the
|
||||
number of chunks <I>Nchunk</I> as calculated by the specified <A HREF = "compute_chunk_atom.html">compute
|
||||
chunk/atom</A> command. The number of columns =
|
||||
3 for the 3 xyz components of the angular momentum for each chunk.
|
||||
These values can be accessed by any command that uses global array
|
||||
values from a compute as input. See <A HREF = "Section_howto.html#howto_15">Section_howto
|
||||
15</A> for an overview of LAMMPS output
|
||||
options.
|
||||
</P>
|
||||
<P>The array values are "intensive". The array values will be in
|
||||
mass-velocity-distance <A HREF = "units.html">units</A>.
|
||||
</P>
|
||||
<P><B>Restrictions:</B> none
|
||||
</P>
|
||||
<P><B>Related commands:</B>
|
||||
</P>
|
||||
<P><A HREF = "variable.html">variable angmom() function</A>
|
||||
</P>
|
||||
<P><B>Default:</B> none
|
||||
</P>
|
||||
</HTML>
|
||||
89
doc/compute_angmom_chunk.txt
Normal file
89
doc/compute_angmom_chunk.txt
Normal file
@ -0,0 +1,89 @@
|
||||
"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
|
||||
|
||||
compute angmom/chunk command :h3
|
||||
|
||||
[Syntax:]
|
||||
|
||||
compute ID group-ID angmom/chunk chunkID :pre
|
||||
|
||||
ID, group-ID are documented in "compute"_compute.html command
|
||||
angmom/molecule = style name of this compute command
|
||||
chunkID = ID of "compute chunk/atom"_compute_chunk_atom.html command :ul
|
||||
|
||||
[Examples:]
|
||||
|
||||
compute 1 fluid angmom/chunk molchunk :pre
|
||||
|
||||
[Description:]
|
||||
|
||||
Define a computation that calculates the angular momemtum of multiple
|
||||
chunks of atoms.
|
||||
|
||||
In LAMMPS, chunks are collections of atoms defined by a "compute
|
||||
chunk/atom"_compute_chunk_atom.html command, which assigns each atom
|
||||
to a single chunk (or no chunk). The ID for this command is specified
|
||||
as chunkID. For example, a single chunk could be the atoms in a
|
||||
molecule or atoms in a spatial bin. See the "compute
|
||||
chunk/atom"_compute_chunk_atom.html doc page and ""Section_howto
|
||||
23"_Section_howto.html#howto_23 for details of how chunks can be
|
||||
defined and examples of how they can be used to measure properties of
|
||||
a system.
|
||||
|
||||
This compute calculates the 3 components of the angular momentum
|
||||
vector for each chunk, due to the velocity/momentum of the individual
|
||||
atoms in the chunk around the center-of-mass of the chunk. The
|
||||
calculation includes all effects due to atoms passing thru periodic
|
||||
boundaries.
|
||||
|
||||
Note that only atoms in the specified group contribute to the
|
||||
calculation. The "compute chunk/atom"_compute_chunk_atom.html command
|
||||
defines its own group; atoms will have a chunk ID = 0 if they are not
|
||||
in that group, signifying they are not assigned to a chunk, and will
|
||||
thus also not contribute to this calculation. You can specify the
|
||||
"all" group for this command if you simply want to include atoms with
|
||||
non-zero chunk IDs.
|
||||
|
||||
IMPORTANT NOTE: The coordinates of an atom contribute to the chunk's
|
||||
angular momentum in "unwrapped" form, by using the image flags
|
||||
associated with each atom. See the "dump custom"_dump.html command
|
||||
for a discussion of "unwrapped" coordinates. See the Atoms section of
|
||||
the "read_data"_read_data.html command for a discussion of image flags
|
||||
and how they are set for each atom. You can reset the image flags
|
||||
(e.g. to 0) before invoking this compute by using the "set
|
||||
image"_set.html command.
|
||||
|
||||
The simplest way to output the results of the compute angmom/chunk
|
||||
calculation to a file is to use the "fix ave/time"_fix_ave_time.html
|
||||
command, for example:
|
||||
|
||||
compute cc1 all chunk/atom molecule
|
||||
compute myChunk all angmom/chunk cc1
|
||||
fix 1 all ave/time 100 1 100 c_myChunk file tmp.out mode vector :pre
|
||||
|
||||
[Output info:]
|
||||
|
||||
This compute calculates a global array where the number of rows = the
|
||||
number of chunks {Nchunk} as calculated by the specified "compute
|
||||
chunk/atom"_compute_chunk_atom.html command. The number of columns =
|
||||
3 for the 3 xyz components of the angular momentum for each chunk.
|
||||
These values can be accessed by any command that uses global array
|
||||
values from a compute as input. See "Section_howto
|
||||
15"_Section_howto.html#howto_15 for an overview of LAMMPS output
|
||||
options.
|
||||
|
||||
The array values are "intensive". The array values will be in
|
||||
mass-velocity-distance "units"_units.html.
|
||||
|
||||
[Restrictions:] none
|
||||
|
||||
[Related commands:]
|
||||
|
||||
"variable angmom() function"_variable.html
|
||||
|
||||
[Default:] none
|
||||
@ -1,128 +0,0 @@
|
||||
<HTML>
|
||||
<CENTER><A HREF = "http://lammps.sandia.gov">LAMMPS WWW Site</A> - <A HREF = "Manual.html">LAMMPS Documentation</A> - <A HREF = "Section_commands.html#comm">LAMMPS Commands</A>
|
||||
</CENTER>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<HR>
|
||||
|
||||
<H3>compute atom/molecule command
|
||||
</H3>
|
||||
<P><B>Syntax:</B>
|
||||
</P>
|
||||
<PRE>compute ID group-ID atom/molecule input1 input2 ...
|
||||
</PRE>
|
||||
<UL><LI>ID, group-ID are documented in <A HREF = "compute.html">compute</A> command
|
||||
|
||||
<LI>atom/molecule = style name of this compute command
|
||||
|
||||
<LI>one or more inputs can be listed
|
||||
|
||||
<LI>input = c_ID, c_ID[N], f_ID, f_ID[N], v_name
|
||||
|
||||
<PRE> c_ID = per-atom vector calculated by a compute with ID
|
||||
c_ID[I] = Ith column of per-atom array calculated by a compute with ID
|
||||
f_ID = per-atom vector calculated by a fix with ID
|
||||
f_ID[I] = Ith column of per-atom array calculated by a fix with ID
|
||||
v_name = per-atom vector calculated by an atom-style variable with name
|
||||
</PRE>
|
||||
|
||||
</UL>
|
||||
<P><B>Examples:</B>
|
||||
</P>
|
||||
<PRE>compute 1 all atom/molecule c_ke c_pe
|
||||
compute 1 top atom/molecule v_myFormula c_stress[3]
|
||||
</PRE>
|
||||
<P><B>Description:</B>
|
||||
</P>
|
||||
<P>Define a calculation that sums per-atom values on a per-molecule
|
||||
basis, one per listed input. The inputs can <A HREF = "compute.html">computes</A>,
|
||||
<A HREF = "fix.html">fixes</A>, or <A HREF = "variable.html">variables</A> that generate per-atom
|
||||
quantities. Note that attributes stored by atoms, such as mass or
|
||||
force, can also be summed on a per-molecule basis, by accessing these
|
||||
quantities via the <A HREF = "compute_property_atom.html">compute property/atom</A>
|
||||
command.
|
||||
</P>
|
||||
<P>Each listed input is operated on independently. Only atoms within the
|
||||
specified group contribute to the per-molecule sum. Note that compute
|
||||
or fix inputs define their own group which may affect the quantities
|
||||
they return. For example, if a compute is used as an input which
|
||||
generates a per-atom vector, it will generate values of 0.0 for atoms
|
||||
that are not in the group specified for that compute.
|
||||
</P>
|
||||
<P>The ordering of per-molecule quantities produced by this compute is
|
||||
consistent with the ordering produced by other compute commands that
|
||||
generate per-molecule datums. Conceptually, them molecule IDs will be
|
||||
in ascending order for any molecule with one or more of its atoms in
|
||||
the specified group.
|
||||
</P>
|
||||
<P>If an input begins with "c_", a compute ID must follow which has been
|
||||
previously defined in the input script and which generates per-atom
|
||||
quantities. See the individual <A HREF = "compute.html">compute</A> doc page for
|
||||
details. If no bracketed integer is appended, the vector calculated
|
||||
by the compute is used. If a bracketed integer is appended, the Ith
|
||||
column of the array calculated by the compute is used. Users can also
|
||||
write code for their own compute styles and <A HREF = "Section_modify.html">add them to
|
||||
LAMMPS</A>.
|
||||
</P>
|
||||
<P>If an input begins with "f_", a fix ID must follow which has been
|
||||
previously defined in the input script and which generates per-atom
|
||||
quantities. See the individual <A HREF = "fix.html">fix</A> doc page for details.
|
||||
Note that some fixes only produce their values on certain timesteps,
|
||||
which must be compatible with when compute atom/molecule references
|
||||
the values, else an error results. If no bracketed integer is
|
||||
appended, the vector calculated by the fix is used. If a bracketed
|
||||
integer is appended, the Ith column of the array calculated by the fix
|
||||
is used. Users can also write code for their own fix style and <A HREF = "Section_modify.html">add
|
||||
them to LAMMPS</A>.
|
||||
</P>
|
||||
<P>If an input begins with "v_", a variable name must follow which has
|
||||
been previously defined in the input script. It must be an
|
||||
<A HREF = "variable.html">atom-style variable</A>. Atom-style variables can
|
||||
reference thermodynamic keywords and various per-atom attributes, or
|
||||
invoke other computes, fixes, or variables when they are evaluated, so
|
||||
this is a very general means of generating per-atom quantities to sum
|
||||
on a per-molecule basis.
|
||||
</P>
|
||||
<P>Here is an example of using this command to sum up the components of
|
||||
total force on each molecule and print them to a file every 1000
|
||||
timesteps. The printed values could also be time-averaged by the fix
|
||||
ave/time command if desired, by changing "1000 1 1000" to "10 100
|
||||
1000" (for example):
|
||||
</P>
|
||||
<PRE>compute 1 all property/atom fx fy fz
|
||||
compute 2 all atom/molecule c_1[1] c_1[2] c_1[3]
|
||||
fix 1 all ave/time 1000 1 1000 c_2 mode vector file tmp.molecule.force
|
||||
</PRE>
|
||||
<HR>
|
||||
|
||||
<P><B>Output info:</B>
|
||||
</P>
|
||||
<P>This compute calculates a global vector or global array depending on
|
||||
the number of input values. The length of the vector or number of
|
||||
rows in the array is the number of molecules. If a single input is
|
||||
specified, a global vector is produced. If two or more inputs are
|
||||
specified, a global array is produced where the number of columns =
|
||||
the number of inputs. The vector or array can be accessed by any
|
||||
command that uses global values from a compute as input. See <A HREF = "Section_howto.html#howto_15">this
|
||||
section</A> for an overview of LAMMPS output
|
||||
options.
|
||||
</P>
|
||||
<P>All the vector or array values calculated by this compute are
|
||||
"extensive".
|
||||
</P>
|
||||
<P>The vector or array values will be in whatever <A HREF = "units.html">units</A> the
|
||||
input quantities are in.
|
||||
</P>
|
||||
<P><B>Restrictions:</B> none
|
||||
</P>
|
||||
<P><B>Related commands:</B>
|
||||
</P>
|
||||
<P><A HREF = "compute.html">compute</A>, <A HREF = "fix.html">fix</A>, <A HREF = "variable.html">variable</A>
|
||||
</P>
|
||||
<P><B>Default:</B> none
|
||||
</P>
|
||||
</HTML>
|
||||
@ -1,118 +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
|
||||
|
||||
compute atom/molecule command :h3
|
||||
|
||||
[Syntax:]
|
||||
|
||||
compute ID group-ID atom/molecule input1 input2 ... :pre
|
||||
|
||||
ID, group-ID are documented in "compute"_compute.html command :ulb,l
|
||||
atom/molecule = style name of this compute command :l
|
||||
one or more inputs can be listed :l
|
||||
input = c_ID, c_ID\[N\], f_ID, f_ID\[N\], v_name :l
|
||||
c_ID = per-atom vector calculated by a compute with ID
|
||||
c_ID\[I\] = Ith column of per-atom array calculated by a compute with ID
|
||||
f_ID = per-atom vector calculated by a fix with ID
|
||||
f_ID\[I\] = Ith column of per-atom array calculated by a fix with ID
|
||||
v_name = per-atom vector calculated by an atom-style variable with name :pre
|
||||
:ule
|
||||
|
||||
[Examples:]
|
||||
|
||||
compute 1 all atom/molecule c_ke c_pe
|
||||
compute 1 top atom/molecule v_myFormula c_stress\[3\] :pre
|
||||
|
||||
[Description:]
|
||||
|
||||
Define a calculation that sums per-atom values on a per-molecule
|
||||
basis, one per listed input. The inputs can "computes"_compute.html,
|
||||
"fixes"_fix.html, or "variables"_variable.html that generate per-atom
|
||||
quantities. Note that attributes stored by atoms, such as mass or
|
||||
force, can also be summed on a per-molecule basis, by accessing these
|
||||
quantities via the "compute property/atom"_compute_property_atom.html
|
||||
command.
|
||||
|
||||
Each listed input is operated on independently. Only atoms within the
|
||||
specified group contribute to the per-molecule sum. Note that compute
|
||||
or fix inputs define their own group which may affect the quantities
|
||||
they return. For example, if a compute is used as an input which
|
||||
generates a per-atom vector, it will generate values of 0.0 for atoms
|
||||
that are not in the group specified for that compute.
|
||||
|
||||
The ordering of per-molecule quantities produced by this compute is
|
||||
consistent with the ordering produced by other compute commands that
|
||||
generate per-molecule datums. Conceptually, them molecule IDs will be
|
||||
in ascending order for any molecule with one or more of its atoms in
|
||||
the specified group.
|
||||
|
||||
If an input begins with "c_", a compute ID must follow which has been
|
||||
previously defined in the input script and which generates per-atom
|
||||
quantities. See the individual "compute"_compute.html doc page for
|
||||
details. If no bracketed integer is appended, the vector calculated
|
||||
by the compute is used. If a bracketed integer is appended, the Ith
|
||||
column of the array calculated by the compute is used. Users can also
|
||||
write code for their own compute styles and "add them to
|
||||
LAMMPS"_Section_modify.html.
|
||||
|
||||
If an input begins with "f_", a fix ID must follow which has been
|
||||
previously defined in the input script and which generates per-atom
|
||||
quantities. See the individual "fix"_fix.html doc page for details.
|
||||
Note that some fixes only produce their values on certain timesteps,
|
||||
which must be compatible with when compute atom/molecule references
|
||||
the values, else an error results. If no bracketed integer is
|
||||
appended, the vector calculated by the fix is used. If a bracketed
|
||||
integer is appended, the Ith column of the array calculated by the fix
|
||||
is used. Users can also write code for their own fix style and "add
|
||||
them to LAMMPS"_Section_modify.html.
|
||||
|
||||
If an input begins with "v_", a variable name must follow which has
|
||||
been previously defined in the input script. It must be an
|
||||
"atom-style variable"_variable.html. Atom-style variables can
|
||||
reference thermodynamic keywords and various per-atom attributes, or
|
||||
invoke other computes, fixes, or variables when they are evaluated, so
|
||||
this is a very general means of generating per-atom quantities to sum
|
||||
on a per-molecule basis.
|
||||
|
||||
Here is an example of using this command to sum up the components of
|
||||
total force on each molecule and print them to a file every 1000
|
||||
timesteps. The printed values could also be time-averaged by the fix
|
||||
ave/time command if desired, by changing "1000 1 1000" to "10 100
|
||||
1000" (for example):
|
||||
|
||||
compute 1 all property/atom fx fy fz
|
||||
compute 2 all atom/molecule c_1\[1\] c_1\[2\] c_1\[3\]
|
||||
fix 1 all ave/time 1000 1 1000 c_2 mode vector file tmp.molecule.force :pre
|
||||
|
||||
:line
|
||||
|
||||
[Output info:]
|
||||
|
||||
This compute calculates a global vector or global array depending on
|
||||
the number of input values. The length of the vector or number of
|
||||
rows in the array is the number of molecules. If a single input is
|
||||
specified, a global vector is produced. If two or more inputs are
|
||||
specified, a global array is produced where the number of columns =
|
||||
the number of inputs. The vector or array can be accessed by any
|
||||
command that uses global values from a compute as input. See "this
|
||||
section"_Section_howto.html#howto_15 for an overview of LAMMPS output
|
||||
options.
|
||||
|
||||
All the vector or array values calculated by this compute are
|
||||
"extensive".
|
||||
|
||||
The vector or array values will be in whatever "units"_units.html the
|
||||
input quantities are in.
|
||||
|
||||
[Restrictions:] none
|
||||
|
||||
[Related commands:]
|
||||
|
||||
"compute"_compute.html, "fix"_fix.html, "variable"_variable.html
|
||||
|
||||
[Default:] none
|
||||
568
doc/compute_chunk_atom.html
Normal file
568
doc/compute_chunk_atom.html
Normal file
@ -0,0 +1,568 @@
|
||||
<HTML>
|
||||
<CENTER><A HREF = "http://lammps.sandia.gov">LAMMPS WWW Site</A> - <A HREF = "Manual.html">LAMMPS Documentation</A> - <A HREF = "Section_commands.html#comm">LAMMPS Commands</A>
|
||||
</CENTER>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<HR>
|
||||
|
||||
<H3>compute chunk/atom command
|
||||
</H3>
|
||||
<P><B>Syntax:</B>
|
||||
</P>
|
||||
<PRE>compute ID group-ID chunk/atom style args keyword values ...
|
||||
</PRE>
|
||||
<UL><LI>ID, group-ID are documented in <A HREF = "compute.html">compute</A> command
|
||||
|
||||
<LI>chunk/atom = style name of this compute command
|
||||
|
||||
<PRE>style = <I>bin/1d</I> or <I>bin/2d</I> or <I>bin/3d</I> or <I>type</I> or <I>molecule</I> or <I>compute/fix/variable</I>
|
||||
<I>bin/1d</I> args = dim origin delta
|
||||
dim = <I>x</I> or <I>y</I> or <I>z</I>
|
||||
origin = <I>lower</I> or <I>center</I> or <I>upper</I> or coordinate value (distance units)
|
||||
delta = thickness of spatial bins in dim (distance units)
|
||||
<I>bin/2d</I> args = dim origin delta dim origin delta
|
||||
dim = <I>x</I> or <I>y</I> or <I>z</I>
|
||||
origin = <I>lower</I> or <I>center</I> or <I>upper</I> or coordinate value (distance units)
|
||||
delta = thickness of spatial bins in dim (distance units)
|
||||
<I>bin/3d</I> args = dim origin delta dim origin delta dim origin delta
|
||||
dim = <I>x</I> or <I>y</I> or <I>z</I>
|
||||
origin = <I>lower</I> or <I>center</I> or <I>upper</I> or coordinate value (distance units)
|
||||
delta = thickness of spatial bins in dim (distance units)
|
||||
<I>type</I> args = none
|
||||
<I>molecule</I> args = none
|
||||
<I>compute/fix/variable</I> = c_ID, c_ID[I], f_ID, f_ID[I], v_name with no args
|
||||
c_ID = per-atom vector calculated by a compute with ID
|
||||
c_ID[I] = Ith column of per-atom array calculated by a compute with ID
|
||||
f_ID = per-atom vector calculated by a fix with ID
|
||||
f_ID[I] = Ith column of per-atom array calculated by a fix with ID
|
||||
v_name = per-atom vector calculated by an atom-style variable with name
|
||||
</PRE>
|
||||
<LI>zero or more keyword/values pairs may be appended
|
||||
|
||||
<LI>keyword = <I>region</I> or <I>nchunk</I> or <I>static</I> or <I>compress</I> or <I>bound</I> or <I>discard</I> or <I>units</I>
|
||||
|
||||
<PRE> <I>region</I> value = region-ID
|
||||
region-ID = ID of region atoms must be in to be part of a chunk
|
||||
<I>nchunk</I> value = <I>once</I> or <I>every</I>
|
||||
once = only compute the number of chunks once
|
||||
every = re-compute the number of chunks whenever invoked
|
||||
<I>limit</I> values = 0 or Nc max or Nc exact
|
||||
0 = no limit on the number of chunks
|
||||
Nc max = limit number of chunks to be <= Nc
|
||||
Nc exact = set number of chunks to exactly Nc
|
||||
<I>ids</I> value = <I>once</I> or <I>nfreq</I> or <I>every</I>
|
||||
once = assign chunk IDs to atoms only once, they persist thereafter
|
||||
nfreq = assign chunk IDs to atoms only once every Nfreq steps (if invoked by <A HREF = "fix_ave_chunk.html">fix ave/chunk</A> which sets Nfreq)
|
||||
every = assign chunk IDs to atoms whenever invoked
|
||||
<I>compress</I> value = <I>yes</I> or <I>no</I>
|
||||
yes = compress chunk IDs to eliminate IDs with no atoms
|
||||
no = do not compress chunk IDs even if some IDs have no atoms
|
||||
<I>discard</I> value = <I>yes</I> or <I>no</I> or <I>mixed</I>
|
||||
yes = discard atoms with out-of-range chunk IDs by assigning a chunk ID = 0
|
||||
no = keep atoms with out-of-range chunk IDs by assigning a valid chunk ID
|
||||
mixed = keep or discard such atoms according to spatial binning rule
|
||||
<I>bound</I> values = x/y/z lo hi
|
||||
x/y/z = <I>x</I> or <I>y</I> or <I>z</I> to bound sptial bins in this dimension
|
||||
lo = <I>lower</I> or coordinate value (distance units)
|
||||
hi = <I>upper</I> or coordinate value (distance units)
|
||||
<I>units</I> value = <I>box</I> or <I>lattice</I> or <I>reduced</I>
|
||||
</PRE>
|
||||
|
||||
</UL>
|
||||
<P><B>Examples:</B>
|
||||
</P>
|
||||
<PRE>compute 1 all chunk/atom type
|
||||
compute 1 all chunk/atom bin/1d z lower 0.02 units reduced
|
||||
compute 1 all chunk/atom bin/2d z lower 1.0 y 0.0 2.5
|
||||
compute 1 all chunk/atom molecule region sphere nchunk once ids once compress yes
|
||||
</PRE>
|
||||
<P><B>Description:</B>
|
||||
</P>
|
||||
<P>Define a computation that calculates an integer chunk ID from 1 to
|
||||
Nchunk for each atom in the group. Values of chunk IDs are determined
|
||||
by the <I>style</I> of chunk, which can be based on atom type or molecule
|
||||
ID or spatial binning or a per-atom property or value calculated by
|
||||
another <A HREF = "compute.html">compute</A>, <A HREF = "fix.html">fix</A>, or <A HREF = "variable.html">atom-style
|
||||
variable</A>. Per-atom chunk IDs can be used by other
|
||||
computes with "chunk" in their style name, such as <A HREF = "compute_com_chunk.html">compute
|
||||
com/chunk</A> or <A HREF = "compute_msd_chunk.html">compute
|
||||
msd/chunk</A>. Or they can be used by the <A HREF = "fix_ave_chunk.html">fix
|
||||
ave/chunk</A> command to sum and time average a
|
||||
variety of per-atom properties over the atoms in each chunk. Or they
|
||||
can simply be accessed by any command that uses per-atom values from a
|
||||
compute as input, as discussed in <A HREF = "Section_howto.html#howto_15">Section_howto
|
||||
15</A>.
|
||||
</P>
|
||||
<P>See <A HREF = "Section_howto.html#howto_23">Section_howto 23</A> for an overview of
|
||||
how this compute can be used with a variety of other commands to
|
||||
tabulate properties of a simulation. The howto section gives several
|
||||
examples of input script commands that can be used to calculate
|
||||
interesting properties.
|
||||
</P>
|
||||
<P>Conceptually it is important to realize that this compute does two
|
||||
simple things. First, it sets the value of <I>Nchunk</I> = the number of
|
||||
chunks, which can be a constant value or change over time. Second, it
|
||||
assigns each atom to a chunk via a chunk ID. Chunk IDs range from 1
|
||||
to <I>Nchunk</I> inclusive; some chunks may have no atoms assigned to them.
|
||||
Atoms that do not belong to any chunk are assigned a value of 0. Note
|
||||
that the two operations are not always performed together. For
|
||||
example, spatial bins can be setup once (which sets <I>Nchunk</I>), and
|
||||
atoms assigned to those bins many times thereafter (setting their
|
||||
chunk IDs).
|
||||
</P>
|
||||
<P>All other commands in LAMMPS that use chunk IDs assume there are
|
||||
<I>Nchunk</I> number of chunks, and that every atom is assigned to one of
|
||||
those chunks, or not assigned to any chunk.
|
||||
</P>
|
||||
<P>There are many options for specifying for how and when <I>Nchunk</I> is
|
||||
calculated, and how and when chunk IDs are assigned to atoms. The
|
||||
details depend on the chunk <I>style</I> and its <I>args</I>, as well as
|
||||
optional keyword settings. They can also depend on whether a <A HREF = "fix_ave_chunk.html">fix
|
||||
ave/chunk</A> command is using this compute, since
|
||||
that command requires <I>Nchunk</I> to remain static across windows of
|
||||
timesteps it specifies, while it accumulates per-chunk averages.
|
||||
</P>
|
||||
<P>The details are described below.
|
||||
</P>
|
||||
<HR>
|
||||
|
||||
<HR>
|
||||
|
||||
<P>The different chunk styles operate as follows. For each style, how it
|
||||
calculates <I>Nchunk</I> and assigns chunk IDs to atoms is explained. Note
|
||||
that using the optional keywords can change both of those actions, as
|
||||
described further below where the keywords are discussed.
|
||||
</P>
|
||||
<HR>
|
||||
|
||||
<P>The <I>binning</I> styles perform a spatial binning of atoms, and assign an
|
||||
atom the chunk ID corresponding to the bin number it is in. <I>Nchunk</I>
|
||||
is set to the number of bins, which can change if the simulation box
|
||||
size changes.
|
||||
</P>
|
||||
<P>The <I>bin/1d</I>, <I>bin/2d</I>, and <I>bin/3d</I> styles define bins as 1d layers
|
||||
(slabs), 2d pencils, or 3d boxes. The <I>dim</I>, <I>origin</I>, and <I>delta</I>
|
||||
settings are specified 1, 2, or 3 times. For 2d or 3d bins, there is
|
||||
no restriction on specifying dim = x before dim = y or z, or dim = y
|
||||
before dim = z. Bins in a particular <I>dim</I> have a bin size in that
|
||||
dimension given by <I>delta</I>. In each dimension, bins are defined
|
||||
relative to a specified <I>origin</I>, which may be the lower/upper edge of
|
||||
the simulation box (in that dimension), or its center point, or a
|
||||
specified coordinate value. Starting at the origin, sufficient bins
|
||||
are created in both directions to completely span the simulation box
|
||||
or the bounds specified by the optional <I>bounds</I> keyword.
|
||||
</P>
|
||||
<P>For orthogonal simulation boxes, the bins are layers, pencils, or
|
||||
boxes aligned with the xyz coordinate axes. For triclinic
|
||||
(non-orthogonal) simulation boxes, the bin faces are parallel to the
|
||||
tilted faces of the simulation box. See <A HREF = "Section_howto.html#howto_12">this
|
||||
section</A> of the manual for a discussion of
|
||||
the geometry of triclinic boxes in LAMMPS. As described there, a
|
||||
tilted simulation box has edge vectors a,b,c. In that nomenclature,
|
||||
bins in the x dimension have faces with normals in the "b" cross "c"
|
||||
direction. Bins in y have faces normal to the "a" cross "c"
|
||||
direction. And bins in z have faces normal to the "a" cross "b"
|
||||
direction. Note that in order to define the size and position of
|
||||
these bins in an unambiguous fashion, the <I>units</I> option must be set
|
||||
to <I>reduced</I> when using a triclinic simulation box, as noted below.
|
||||
</P>
|
||||
<P>The meaning of <I>origin</I> and <I>delta</I> for triclinic boxes is as follows.
|
||||
Consider a triclinic box with bins that are 1d layers or slabs in the
|
||||
x dimension. No matter how the box is tilted, an <I>origin</I> of 0.0
|
||||
means start layers at the lower "b" cross "c" plane of the simulation
|
||||
box and an <I>origin</I> of 1.0 means to start layers at the upper "b"
|
||||
cross "c" face of the box. A <I>delta</I> value of 0.1 in <I>reduced</I> units
|
||||
means there will be 10 layers from 0.0 to 1.0, regardless of the
|
||||
current size or shape of the simulation box.
|
||||
</P>
|
||||
<P>The created bins (and hence the chunk IDs) are numbered consecutively
|
||||
from 1 to the number of bins = <I>Nchunk</I>. For 2d and 3d bins, the
|
||||
numbering varies most rapidly in the first dimension (which could be
|
||||
x, y, or z), next rapidly in the 2nd dimension, and most slowly in the
|
||||
3rd dimension.
|
||||
</P>
|
||||
<P>Each time this compute is invoked, each atom is mapped to a bin based
|
||||
on its current position. Note that between reneighboring timesteps,
|
||||
atoms can move outside the current simulation box. If the box is
|
||||
periodic (in that dimension) the atom is remapping into the periodic
|
||||
box for purposes of binning. If the box in not periodic, the atom may
|
||||
have moved outside the bounds of all bins. If an atom is not inside
|
||||
any bin, the <I>discard</I> keyword is used to determine how a chunk ID is
|
||||
assigned to the atom.
|
||||
</P>
|
||||
<HR>
|
||||
|
||||
<P>The <I>type</I> style uses the atom type as the chunk ID. <I>Nchunk</I> is set
|
||||
to the number of atom types defined for the simulation, e.g. via the
|
||||
<A HREF = "create_box.html">create_box</A> or <A HREF = "read_data.html">read_data</A> commands.
|
||||
</P>
|
||||
<HR>
|
||||
|
||||
<P>The <I>molecule</I> style uses the molecule ID of each atom as its chunk
|
||||
ID. <I>Nchunk</I> is set to the largest chunk ID. Note that this excludes
|
||||
molecule IDs for atoms which are not in the specified group or
|
||||
optional region.
|
||||
</P>
|
||||
<P>There is no requirement that all atoms in a particular molecule are
|
||||
assigned the same chunk ID (zero or non-zero), though you probably
|
||||
want that to be the case, if you wish to compute a per-molecule
|
||||
property. LAMMPS will issue a warning if that is not the case, but
|
||||
only the first time that <I>Nchunk</I> is calculated.
|
||||
</P>
|
||||
<P>Note that atoms with a molecule ID = 0, which may be non-molecular
|
||||
solvent atoms, have an out-of-range chunk ID. These atoms are
|
||||
discarded (not assigned to any chunk) or assigned to <I>Nchunk</I>,
|
||||
depending on the value of the <I>discard</I> keyword.
|
||||
</P>
|
||||
<HR>
|
||||
|
||||
<P>The <I>compute/fix/variable</I> styles set the chunk ID of each atom based
|
||||
on a quantity calculated and stored by a compute, fix, or variable.
|
||||
In each case, it must be a per-atom quantity. In each case the
|
||||
referenced floating point values are converted to an integer chunk ID
|
||||
as follows. The floating point value is truncated (rounded down) to
|
||||
an integer value. If the integer value is <= 0, then a chunk ID of 0
|
||||
is assigned to the atom. If the integer value is > 0, it becomes the
|
||||
chunk ID to the atom. <I>Nchunk</I> is set to the largest chunk ID. Note
|
||||
that this excludes atoms which are not in the specified group or
|
||||
optional region.
|
||||
</P>
|
||||
<P>If the style begins with "c_", a compute ID must follow which has been
|
||||
previously defined in the input script. If no bracketed integer is
|
||||
appended, the per-atom vector calculated by the compute is used. If a
|
||||
bracketed integer is appended, the Ith column of the per-atom array
|
||||
calculated by the compute is used. Users can also write code for
|
||||
their own compute styles and <A HREF = "Section_modify.html">add them to LAMMPS</A>.
|
||||
</P>
|
||||
<P>If the style begins with "f_", a fix ID must follow which has been
|
||||
previously defined in the input script. If no bracketed integer is
|
||||
appended, the per-atom vector calculated by the fix is used. If a
|
||||
bracketed integer is appended, the Ith column of the per-atom array
|
||||
calculated by the fix is used. Note that some fixes only produce
|
||||
their values on certain timesteps, which must be compatible with the
|
||||
timestep on which this compute accesses the fix, else an error
|
||||
results. Users can also write code for their own fix styles and <A HREF = "Section_modify.html">add
|
||||
them to LAMMPS</A>.
|
||||
</P>
|
||||
<P>If a value begins with "v_", a variable name for an <I>atom</I> or
|
||||
<I>atomfile</I> style <A HREF = "variable.html">variable</A> must follow which has been
|
||||
previously defined in the input script. Variables of style <I>atom</I> can
|
||||
reference thermodynamic keywords and various per-atom attributes, or
|
||||
invoke other computes, fixes, or variables when they are evaluated, so
|
||||
this is a very general means of generating per-atom quantities to
|
||||
treat as a chunk ID.
|
||||
</P>
|
||||
<HR>
|
||||
|
||||
<HR>
|
||||
|
||||
<P>Normally, <I>Nchunk</I> = the number of chunks, is re-calculated every time
|
||||
this fix is invoked, though the value may or may not change. As
|
||||
explained below, the <I>nchunk</I> keyword can be set to <I>once</I> which means
|
||||
<I>Nchunk</I> will never change.
|
||||
</P>
|
||||
<P>If a <A HREF = "fix_ave_chunk.html">fix ave/chunk</A> command uses this compute, it
|
||||
can also turn off the re-calculation of <I>Nchunk</I> for one or more
|
||||
windows of timesteps. The extent of the windows, during which Nchunk
|
||||
is held constant, are determined by the <I>Nevery</I>, <I>Nrepeat</I>, <I>Nfreq</I>
|
||||
values and the <I>ave</I> keyword setting that are used by the <A HREF = "fix_ave_chunk.html">fix
|
||||
ave/chunk</A> command.
|
||||
</P>
|
||||
<P>Specifically, if <I>ave</I> = <I>one</I>, then for each span of <I>Nfreq</I>
|
||||
timesteps, <I>Nchunk</I> is held constant between the first timestep when
|
||||
averaging is done (within the Nfreq-length window), and the last
|
||||
timestep when averaging is done (multiple of Nfreq). If <I>ave</I> =
|
||||
<I>running</I> or <I>window</I>, then <I>Nchunk</I> is held constant forever,
|
||||
starting on the first timestep when the <A HREF = "fix_ave_chunk.html">fix
|
||||
ave/chunk</A> command invokes this compute.
|
||||
</P>
|
||||
<P>Note that multiple <A HREF = "fix_ave_chunk.html">fix ave/chunk</A> commands can use
|
||||
the same compute chunk/atom compute. However, the time windows they
|
||||
induce for holding <I>Nchunk</I> constant must be identical, else an error
|
||||
will be generated.
|
||||
</P>
|
||||
<HR>
|
||||
|
||||
<HR>
|
||||
|
||||
<P>The various optional keywords operate as follows. Note that some of
|
||||
them function differently or are ignored by different chunk styles.
|
||||
Some of them also have different default values, depending on
|
||||
the chunk style, as listed below.
|
||||
</P>
|
||||
<P>The <I>region</I> keyword applies to all chunk styles. If used, an atom
|
||||
must be in both the specified group and the specified geometric
|
||||
<A HREF = "region.html">region</A> to be assigned to a chunk.
|
||||
</P>
|
||||
<HR>
|
||||
|
||||
<P>The <I>nchunk</I> keyword applies to all chunk styles. It specifies how
|
||||
often <I>Nchunk</I> is recalculated, which in turn can affect the chunk IDs
|
||||
assigned to individual atoms.
|
||||
</P>
|
||||
<P>If <I>nchunk</I> is set to <I>once</I>, then <I>Nchunk</I> is only calculated once,
|
||||
the first time this compute is invoked. If <I>nchunk</I> is set to
|
||||
<I>every</I>, then <I>Nchunk</I> is re-calculated every time the compute is
|
||||
invoked. Note that, as described above, the use of this compute
|
||||
by the <A HREF = "fix_ave_chunk.html">fix ave/chunk</A> command can override
|
||||
the <I>every</I> setting.
|
||||
</P>
|
||||
<P>The default values for <I>nchunk</I> are listed below and depend on the
|
||||
chunk style and other system and keyword settings. They attempt to
|
||||
represent typical use cases for the various chunk styles. The
|
||||
<I>nchunk</I> value can always be set explicitly if desired.
|
||||
</P>
|
||||
<HR>
|
||||
|
||||
<P>The <I>limit</I> keyword can be used to limit the calculated value of
|
||||
<I>Nchunk</I> = the number of chunks. The limit is applied each time
|
||||
<I>Nchunk</I> is calculated, which also limits the chunk IDs assigned to
|
||||
any atom. The <I>limit</I> keyword is used by all chunk styles except the
|
||||
<I>binning</I> styles, which ignore it. This is because the number of bins
|
||||
can be tailored using the <I>bound</I> keyword (described below) which
|
||||
effectively limits the size of <I>Nchunk</I>.
|
||||
</P>
|
||||
<P>If <I>limit</I> is set to <I>Nc</I> = 0, then no limit is imposed on <I>Nchunk</I>,
|
||||
though the <I>compress</I> keyword can still be used to reduce <I>Nchunk</I>, as
|
||||
described below.
|
||||
</P>
|
||||
<P>If <I>Nc</I> > 0, then the effect of the <I>limit</I> keyword depends on whether
|
||||
the <I>compress</I> keyword is also used with a setting of <I>yes</I>, and
|
||||
whether the <I>compress</I> keyword is specified before the <I>limit</I> keyword
|
||||
or after.
|
||||
</P>
|
||||
<P>In all cases, <I>Nchunk</I> is first calculated in the usual way for each
|
||||
chunk style, as described above.
|
||||
</P>
|
||||
<P>First, here is what occurs if <I>compress yes</I> is not set. If <I>limit</I>
|
||||
is set to <I>Nc max</I>, then <I>Nchunk</I> is reset to the smaller of <I>Nchunk</I>
|
||||
and <I>Nc</I>. If <I>limit</I> is set to <I>Nc exact</I>, then <I>Nchunk</I> is reset to
|
||||
<I>Nc</I>, whether the original <I>Nchunk</I> was larger or smaller than <I>Nc</I>.
|
||||
If <I>Nchunk</I> shrank due to the <I>limit</I> setting, then atom chunk IDs >
|
||||
<I>Nchunk</I> will be reset to 0 or <I>Nchunk</I>, depending on the setting of
|
||||
the <I>discard</I> keyword. If <I>Nchunk</I> grew, there will simply be some
|
||||
chunks with no atoms assigned to them.
|
||||
</P>
|
||||
<P>If <I>compress yes</I> is set, and the <I>compress</I> keyword comes before the
|
||||
<I>limit</I> keyword, the compression operation is performed first, as
|
||||
described below, which resets <I>Nchunk</I>. The <I>limit</I> keyword is then
|
||||
applied to the new <I>Nchunk</I> value, exactly as described in the
|
||||
preceeding paragraph. Note that in this case, all atoms will end up
|
||||
with chunk IDs <= <I>Nc</I>, but their original values (e.g. molecule ID or
|
||||
compute/fix/variable value) may have been > <I>Nc</I>, because of the
|
||||
compression operation.
|
||||
</P>
|
||||
<P>If <I>compress yes</I> is set, and the <I>compress</I> keyword comes after the
|
||||
<I>limit</I> keyword, then the <I>limit</I> value of <I>Nc</I> is applied first to
|
||||
the uncompressed value of <I>Nchunk</I>, but only if <I>Nc</I> < <I>Nchunk</I>
|
||||
(whether <I>Nc max</I> or <I>Nc exact</I> is used). This effectively means all
|
||||
atoms with chunk IDs > <I>Nc</I> have their chunk IDs reset to 0 or <I>Nc</I>,
|
||||
depending on the setting of the <I>discard</I> keyword. The compression
|
||||
operation is then performed, which may shrink <I>Nchunk</I> further. If
|
||||
the new <I>Nchunk</I> < <I>Nc</I> and <I>limit</I> = <I>Nc exact</I> is specified, then
|
||||
<I>Nchunk</I> is reset to <I>Nc</I>, which results in extra chunks with no atoms
|
||||
assigned to them. Note that in this case, all atoms will end up with
|
||||
chunk IDs <= <I>Nc</I>, and their original values (e.g. molecule ID or
|
||||
compute/fix/variable value) will also have been <= <I>Nc</I>.
|
||||
</P>
|
||||
<HR>
|
||||
|
||||
<P>The <I>ids</I> keyword applies to all chunk styles. If the setting is
|
||||
<I>once</I> then the chunk IDs assigned to atoms the first time this
|
||||
compute is invoked will be permanent, and never be re-computed.
|
||||
</P>
|
||||
<P>If the setting is <I>nfreq</I> and if a <A HREF = "fix_ave_chunk.html">fix ave/chunk</A>
|
||||
command is using this compute, then in each of the <I>Nchunk</I> = constant
|
||||
time windows (discussed above), the chunk ID's assigned to atoms on
|
||||
the first step of the time window will persist until the end of the
|
||||
time window.
|
||||
</P>
|
||||
<P>If the setting is <I>every</I>, which is the default, then chunk IDs are
|
||||
re-calculated on any timestep this compute is invoked.
|
||||
</P>
|
||||
<P>IMPORTANT NOTE: If you want the persistent chunk-IDs calculated by
|
||||
this compute to be continuous when running from a <A HREF = "read_restart.html">restart
|
||||
file</A>, then you should use the same ID for this
|
||||
compute, as in the original run. This is so that the fix this compute
|
||||
creates to store per-atom quantities will also have the same ID, and
|
||||
thus be initialized correctly with chunk IDs from the restart file.
|
||||
</P>
|
||||
<HR>
|
||||
|
||||
<P>The <I>compress</I> keyword applies to all chunk styles and affects how
|
||||
<I>Nchunk</I> is calculated, which in turn affects the chunk IDs assigned
|
||||
to each atom. It is useful for converting a "sparse" set of chunk IDs
|
||||
(with many IDs that have no atoms assigned to them), into a "dense"
|
||||
set of IDs, where every chunk has one or more atoms assigned to it.
|
||||
</P>
|
||||
<P>Two possible use cases are as follows. If a large simulation box is
|
||||
mostly empty space, then the <I>binning</I> style may produce many bins
|
||||
with no atoms. If <I>compress</I> is set to <I>yes</I>, only bins with atoms
|
||||
will be contribute to <I>Nchunk</I>. Likewise, the <I>molecule</I> or
|
||||
<I>compute/fix/variable</I> styles may produce large <I>Nchunk</I> values. For
|
||||
example, the <A HREF = "compute_cluster_atom.html">compute cluster/atom</A> command
|
||||
assigns every atom an atom ID for one of the atoms it is clustered
|
||||
with. For a million-atom system with 5 clusters, there would only be
|
||||
5 unique chunk IDs, but the largest chunk ID might be 1 million,
|
||||
resulting in <I>Nchunk</I> = 1 million. If <I>compress</I> is set to <I>yes</I>,
|
||||
<I>Nchunk</I> will be reset to 5.
|
||||
</P>
|
||||
<P>If <I>compress</I> is set to <I>no</I>, which is the default, no compression is
|
||||
done. If it is set to <I>yes</I>, all chunk IDs with no atoms are removed
|
||||
from the list of chunk IDs, and the list is sorted. The remaining
|
||||
chunk IDs are renumbered from 1 to <I>Nchunk</I> where <I>Nchunk</I> is the new
|
||||
length of the list. The chunk IDs assigned to each atom reflect
|
||||
the new renumbering from 1 to <I>Nchunk</I>.
|
||||
</P>
|
||||
<P>The original chunk IDs (before renumbering) can be accessed by the
|
||||
<A HREF = "compute_property_chunk.html">compute property/chunk</A> command and its
|
||||
<I>id</I> keyword, or by the <A HREF = "fix_ave_chunk.html">fix ave/chunk</A> command
|
||||
which outputs the original IDs as one of the columns in its global
|
||||
output array. For example, using the "compute cluster/atom" command
|
||||
discussed above, the original 5 unique chunk IDs might be atom IDs
|
||||
(27,4982,58374,857838,1000000). After compresion, these will be
|
||||
renumbered to (1,2,3,4,5). The original values (27,...,1000000) can
|
||||
be output to a file by the <A HREF = "fix_ave_chunk.html">fix ave/chunk</A> command,
|
||||
or by using the <A HREF = "fix_ave_time.html">fix ave/time</A> command in
|
||||
conjunction with the <A HREF = "compute_property_chunk.html">compute
|
||||
property/chunk</A> command.
|
||||
</P>
|
||||
<P>IMPORTANT NOTE: The compression operation requires global
|
||||
communication across all processors to share their chunk ID values.
|
||||
It can require large memory on every processor to store them, even
|
||||
after they are compressed, if there are are a large number of unique
|
||||
chunk IDs with atoms assigned to them. It uses a STL map to find
|
||||
unique chunk IDs and store them in sorted order. Each time an atom is
|
||||
assigned a compressed chunk ID, it must access the STL map. All of
|
||||
this means that compression can be expensive, both in memory and CPU
|
||||
time. The use of the <I>limit</I> keyword in conjunction with the
|
||||
<I>compress</I> keyword can affect these costs, depending on which keyword
|
||||
is used first. So use this option with care.
|
||||
</P>
|
||||
<HR>
|
||||
|
||||
<P>The <I>discard</I> keyword applies to all chunk styles. It affects what
|
||||
chunk IDs are assigned to atoms that do not match one of the valid
|
||||
chunk IDs from 1 to <I>Nchunk</I>. Note that it does not apply to atoms
|
||||
that are not in the specified group or optionally specified region.
|
||||
Those atoms are always assigned a chunk ID = 0.
|
||||
</P>
|
||||
<P>If the calculated chunk ID for an atom is not within the range 1 to
|
||||
<I>Nchunk</I> then it is a "discard" atom. Note that <I>Nchunk</I> may have
|
||||
been shrunk by the <I>limit</I> keyword. Or the <I>compress</I> keyword may
|
||||
have eliminated chunk IDs that were valid before the compression took
|
||||
place, and are now not in the compressed list. Also note that for the
|
||||
<I>molecule</I> chunk style, if new molecules are added to the system,
|
||||
their chunk IDs may exceed a previously calculated <I>Nchunk</I>.
|
||||
Likewise, evaluation of a compute/fix/variable on a later timestep may
|
||||
return chunk IDs that are invalid for the previously calculated
|
||||
<I>Nchunk</I>.
|
||||
</P>
|
||||
<P>All the chunk styles except the <I>binning</I> styles, must use <I>discard</I>
|
||||
set to either <I>yes</I> or <I>no</I>. If <I>discard</I> is set to <I>yes</I>, which is
|
||||
the default, then every "discard" atom has its chunk ID set to 0. If
|
||||
<I>discard</I> is set to <I>no</I>, every "discard" atom has its chunk ID set to
|
||||
<I>Nchunk</I>. I.e. it becomes part of the last chunk.
|
||||
</P>
|
||||
<P>The <I>binning</I> styles use the <I>discard</I> keyword to decide whether to
|
||||
discard atoms outside the spatial domain covered by bins, or to assign
|
||||
them to the bin they are nearest to. Details are as follows.
|
||||
</P>
|
||||
<P>If <I>discard</I> is set to <I>yes</I>, an out-of-domain atom will have its
|
||||
chunk ID set to 0. If <I>discard</I> is set to <I>no</I>, the atom will have
|
||||
its chunk ID set to the first or last bin in that dimension. If
|
||||
(discard</I> is set to <I>mixed</I>, which is the default, it will only have
|
||||
its chunk ID set to the first or last bin if bins extend to the
|
||||
simulation box boundary in that dimension. This is the case if the
|
||||
<I>bound</I> keyword settings are <I>lower</I> and <I>upper</I>, which is the
|
||||
default. If the <I>bound</I> keyword settings are numeric values, then the
|
||||
atom will have its chunk ID set to 0 if it is outside the bounds of
|
||||
any bin. Note that in this case, it is possible that the first or
|
||||
last bin extends beyond the numeric <I>bounds</I> settings, depending on
|
||||
the specified <I>origin</I>. If this is the case, the chunk ID of the atom
|
||||
is only set to 0 if it is outside the first or last bin, not if it is
|
||||
simply outside the numeric <I>bounds</I> setting.
|
||||
</P>
|
||||
<HR>
|
||||
|
||||
<P>The <I>bound</I> keyword only applies to the <I>binning</I> styles; otherwise it
|
||||
is ignored. It can be used one or more times to limit the extent of
|
||||
bin coverage in a specified dimension, i.e. to only bin a portion of
|
||||
the box. If the <I>lo</I> setting is <I>lower</I> or the <I>hi</I> setting is
|
||||
<I>upper</I>, the bin extent in that direction extends to the box boundary.
|
||||
If a numeric value is used for <I>lo</I> and/or <I>hi</I>, then the bin extent
|
||||
in the <I>lo</I> or <I>hi</I> direction extends only to that value, which is
|
||||
assumed to be inside (or at least near) the simulation box boundaries,
|
||||
though LAMMPS does not check for this. Note that using the <I>bound</I>
|
||||
keyword typically reduces the total number of bins and thus the number
|
||||
of chunks <I>Nchunk</I>.
|
||||
</P>
|
||||
<P>The <I>units</I> keyword only applies to the <I>binning</I> styles; otherwise it
|
||||
is ignored. It determines the meaning of the distance units used for
|
||||
the bin sizes <I>delta</I> and for <I>origin</I> and <I>bounds</I> values if they are
|
||||
coordinate values. For orthogonal simulation boxes, any of the 3
|
||||
options may be used. For non-orthogonal (triclinic) simulation boxes,
|
||||
only the <I>reduced</I> option may be used.
|
||||
</P>
|
||||
<P>A <I>box</I> value selects standard distance units as defined by the
|
||||
<A HREF = "units.html">units</A> command, e.g. Angstroms for units = real or metal.
|
||||
A <I>lattice</I> value means the distance units are in lattice spacings.
|
||||
The <A HREF = "lattice.html">lattice</A> command must have been previously used to
|
||||
define the lattice spacing. A <I>reduced</I> value means normalized
|
||||
unitless values between 0 and 1, which represent the lower and upper
|
||||
faces of the simulation box respectively. Thus an <I>origin</I> value of
|
||||
0.5 means the center of the box in any dimension. A <I>delta</I> value of
|
||||
0.1 means 10 bins span the box in that dimension.
|
||||
</P>
|
||||
<HR>
|
||||
|
||||
<HR>
|
||||
|
||||
<P><B>Output info:</B>
|
||||
</P>
|
||||
<P>This compute calculates a per-atom vector, which can be accessed by
|
||||
any command that uses per-atom values from a compute as input. See
|
||||
<A HREF = "Section_howto.html#howto_15">Section_howto 15</A> for an overview of
|
||||
LAMMPS output options.
|
||||
</P>
|
||||
<P>The per-atom vector values are unitless chunk IDs, ranging from 1 to
|
||||
<I>Nchunk</I> (inclusive) for atoms assigned to chunks, and 0 for atoms not
|
||||
belonging to a chunk.
|
||||
</P>
|
||||
<P><B>Restrictions:</B>
|
||||
</P>
|
||||
<P>Even if the <I>nchunk</I> keyword is set to <I>once</I>, the chunk IDs assigned
|
||||
to each atom are not stored in a restart files. This means you cannot
|
||||
expect those assignments to persist in a restarted simulation.
|
||||
Instead you must re-specify this command and assign atoms to chunks when
|
||||
the restarted simulation begins.
|
||||
</P>
|
||||
<P><B>Related commands:</B>
|
||||
</P>
|
||||
<P><A HREF = "fix_ave_chunk.html">fix ave/chunk</A>
|
||||
</P>
|
||||
<P><B>Default:</B>
|
||||
</P>
|
||||
<P>The option defaults are as follows:
|
||||
</P>
|
||||
<UL><LI>region = none
|
||||
<LI>nchunk = every if compress is yes, overriding other defaults listed here
|
||||
<LI>nchunk = once for type style
|
||||
<LI>nchunk = once for mol style if region is none
|
||||
<LI>nchunk = every for mol style if region is set
|
||||
<LI>nchunk = once for binning style if the simulation box size is static or units = reduced
|
||||
<LI>nchunk = every for binning style if the simulation box size is dynamic and units is lattice or box
|
||||
<LI>nchunk = every for compute/fix/variable style
|
||||
<LI>limit = 0
|
||||
<LI>ids = every
|
||||
<LI>compress = no
|
||||
<LI>discard = yes for all styles except binning
|
||||
<LI>discard = mixed for binning styles
|
||||
<LI>bound = lower and upper in all dimensions
|
||||
<LI>units = lattice
|
||||
</UL>
|
||||
</HTML>
|
||||
554
doc/compute_chunk_atom.txt
Normal file
554
doc/compute_chunk_atom.txt
Normal file
@ -0,0 +1,554 @@
|
||||
"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
|
||||
|
||||
compute chunk/atom command :h3
|
||||
|
||||
[Syntax:]
|
||||
|
||||
compute ID group-ID chunk/atom style args keyword values ... :pre
|
||||
|
||||
ID, group-ID are documented in "compute"_compute.html command :ulb,l
|
||||
chunk/atom = style name of this compute command :l
|
||||
style = {bin/1d} or {bin/2d} or {bin/3d} or {type} or {molecule} or {compute/fix/variable}
|
||||
{bin/1d} args = dim origin delta
|
||||
dim = {x} or {y} or {z}
|
||||
origin = {lower} or {center} or {upper} or coordinate value (distance units)
|
||||
delta = thickness of spatial bins in dim (distance units)
|
||||
{bin/2d} args = dim origin delta dim origin delta
|
||||
dim = {x} or {y} or {z}
|
||||
origin = {lower} or {center} or {upper} or coordinate value (distance units)
|
||||
delta = thickness of spatial bins in dim (distance units)
|
||||
{bin/3d} args = dim origin delta dim origin delta dim origin delta
|
||||
dim = {x} or {y} or {z}
|
||||
origin = {lower} or {center} or {upper} or coordinate value (distance units)
|
||||
delta = thickness of spatial bins in dim (distance units)
|
||||
{type} args = none
|
||||
{molecule} args = none
|
||||
{compute/fix/variable} = c_ID, c_ID\[I\], f_ID, f_ID\[I\], v_name with no args
|
||||
c_ID = per-atom vector calculated by a compute with ID
|
||||
c_ID\[I\] = Ith column of per-atom array calculated by a compute with ID
|
||||
f_ID = per-atom vector calculated by a fix with ID
|
||||
f_ID\[I\] = Ith column of per-atom array calculated by a fix with ID
|
||||
v_name = per-atom vector calculated by an atom-style variable with name :pre
|
||||
|
||||
zero or more keyword/values pairs may be appended :l
|
||||
keyword = {region} or {nchunk} or {static} or {compress} or {bound} or {discard} or {units} :l
|
||||
{region} value = region-ID
|
||||
region-ID = ID of region atoms must be in to be part of a chunk
|
||||
{nchunk} value = {once} or {every}
|
||||
once = only compute the number of chunks once
|
||||
every = re-compute the number of chunks whenever invoked
|
||||
{limit} values = 0 or Nc max or Nc exact
|
||||
0 = no limit on the number of chunks
|
||||
Nc max = limit number of chunks to be <= Nc
|
||||
Nc exact = set number of chunks to exactly Nc
|
||||
{ids} value = {once} or {nfreq} or {every}
|
||||
once = assign chunk IDs to atoms only once, they persist thereafter
|
||||
nfreq = assign chunk IDs to atoms only once every Nfreq steps (if invoked by "fix ave/chunk"_fix_ave_chunk.html which sets Nfreq)
|
||||
every = assign chunk IDs to atoms whenever invoked
|
||||
{compress} value = {yes} or {no}
|
||||
yes = compress chunk IDs to eliminate IDs with no atoms
|
||||
no = do not compress chunk IDs even if some IDs have no atoms
|
||||
{discard} value = {yes} or {no} or {mixed}
|
||||
yes = discard atoms with out-of-range chunk IDs by assigning a chunk ID = 0
|
||||
no = keep atoms with out-of-range chunk IDs by assigning a valid chunk ID
|
||||
mixed = keep or discard such atoms according to spatial binning rule
|
||||
{bound} values = x/y/z lo hi
|
||||
x/y/z = {x} or {y} or {z} to bound sptial bins in this dimension
|
||||
lo = {lower} or coordinate value (distance units)
|
||||
hi = {upper} or coordinate value (distance units)
|
||||
{units} value = {box} or {lattice} or {reduced} :pre
|
||||
:ule
|
||||
|
||||
[Examples:]
|
||||
|
||||
compute 1 all chunk/atom type
|
||||
compute 1 all chunk/atom bin/1d z lower 0.02 units reduced
|
||||
compute 1 all chunk/atom bin/2d z lower 1.0 y 0.0 2.5
|
||||
compute 1 all chunk/atom molecule region sphere nchunk once ids once compress yes :pre
|
||||
|
||||
[Description:]
|
||||
|
||||
Define a computation that calculates an integer chunk ID from 1 to
|
||||
Nchunk for each atom in the group. Values of chunk IDs are determined
|
||||
by the {style} of chunk, which can be based on atom type or molecule
|
||||
ID or spatial binning or a per-atom property or value calculated by
|
||||
another "compute"_compute.html, "fix"_fix.html, or "atom-style
|
||||
variable"_variable.html. Per-atom chunk IDs can be used by other
|
||||
computes with "chunk" in their style name, such as "compute
|
||||
com/chunk"_compute_com_chunk.html or "compute
|
||||
msd/chunk"_compute_msd_chunk.html. Or they can be used by the "fix
|
||||
ave/chunk"_fix_ave_chunk.html command to sum and time average a
|
||||
variety of per-atom properties over the atoms in each chunk. Or they
|
||||
can simply be accessed by any command that uses per-atom values from a
|
||||
compute as input, as discussed in "Section_howto
|
||||
15"_Section_howto.html#howto_15.
|
||||
|
||||
See "Section_howto 23"_Section_howto.html#howto_23 for an overview of
|
||||
how this compute can be used with a variety of other commands to
|
||||
tabulate properties of a simulation. The howto section gives several
|
||||
examples of input script commands that can be used to calculate
|
||||
interesting properties.
|
||||
|
||||
Conceptually it is important to realize that this compute does two
|
||||
simple things. First, it sets the value of {Nchunk} = the number of
|
||||
chunks, which can be a constant value or change over time. Second, it
|
||||
assigns each atom to a chunk via a chunk ID. Chunk IDs range from 1
|
||||
to {Nchunk} inclusive; some chunks may have no atoms assigned to them.
|
||||
Atoms that do not belong to any chunk are assigned a value of 0. Note
|
||||
that the two operations are not always performed together. For
|
||||
example, spatial bins can be setup once (which sets {Nchunk}), and
|
||||
atoms assigned to those bins many times thereafter (setting their
|
||||
chunk IDs).
|
||||
|
||||
All other commands in LAMMPS that use chunk IDs assume there are
|
||||
{Nchunk} number of chunks, and that every atom is assigned to one of
|
||||
those chunks, or not assigned to any chunk.
|
||||
|
||||
There are many options for specifying for how and when {Nchunk} is
|
||||
calculated, and how and when chunk IDs are assigned to atoms. The
|
||||
details depend on the chunk {style} and its {args}, as well as
|
||||
optional keyword settings. They can also depend on whether a "fix
|
||||
ave/chunk"_fix_ave_chunk.html command is using this compute, since
|
||||
that command requires {Nchunk} to remain static across windows of
|
||||
timesteps it specifies, while it accumulates per-chunk averages.
|
||||
|
||||
The details are described below.
|
||||
|
||||
:line
|
||||
:line
|
||||
|
||||
The different chunk styles operate as follows. For each style, how it
|
||||
calculates {Nchunk} and assigns chunk IDs to atoms is explained. Note
|
||||
that using the optional keywords can change both of those actions, as
|
||||
described further below where the keywords are discussed.
|
||||
|
||||
:line
|
||||
|
||||
The {binning} styles perform a spatial binning of atoms, and assign an
|
||||
atom the chunk ID corresponding to the bin number it is in. {Nchunk}
|
||||
is set to the number of bins, which can change if the simulation box
|
||||
size changes.
|
||||
|
||||
The {bin/1d}, {bin/2d}, and {bin/3d} styles define bins as 1d layers
|
||||
(slabs), 2d pencils, or 3d boxes. The {dim}, {origin}, and {delta}
|
||||
settings are specified 1, 2, or 3 times. For 2d or 3d bins, there is
|
||||
no restriction on specifying dim = x before dim = y or z, or dim = y
|
||||
before dim = z. Bins in a particular {dim} have a bin size in that
|
||||
dimension given by {delta}. In each dimension, bins are defined
|
||||
relative to a specified {origin}, which may be the lower/upper edge of
|
||||
the simulation box (in that dimension), or its center point, or a
|
||||
specified coordinate value. Starting at the origin, sufficient bins
|
||||
are created in both directions to completely span the simulation box
|
||||
or the bounds specified by the optional {bounds} keyword.
|
||||
|
||||
For orthogonal simulation boxes, the bins are layers, pencils, or
|
||||
boxes aligned with the xyz coordinate axes. For triclinic
|
||||
(non-orthogonal) simulation boxes, the bin faces are parallel to the
|
||||
tilted faces of the simulation box. See "this
|
||||
section"_Section_howto.html#howto_12 of the manual for a discussion of
|
||||
the geometry of triclinic boxes in LAMMPS. As described there, a
|
||||
tilted simulation box has edge vectors a,b,c. In that nomenclature,
|
||||
bins in the x dimension have faces with normals in the "b" cross "c"
|
||||
direction. Bins in y have faces normal to the "a" cross "c"
|
||||
direction. And bins in z have faces normal to the "a" cross "b"
|
||||
direction. Note that in order to define the size and position of
|
||||
these bins in an unambiguous fashion, the {units} option must be set
|
||||
to {reduced} when using a triclinic simulation box, as noted below.
|
||||
|
||||
The meaning of {origin} and {delta} for triclinic boxes is as follows.
|
||||
Consider a triclinic box with bins that are 1d layers or slabs in the
|
||||
x dimension. No matter how the box is tilted, an {origin} of 0.0
|
||||
means start layers at the lower "b" cross "c" plane of the simulation
|
||||
box and an {origin} of 1.0 means to start layers at the upper "b"
|
||||
cross "c" face of the box. A {delta} value of 0.1 in {reduced} units
|
||||
means there will be 10 layers from 0.0 to 1.0, regardless of the
|
||||
current size or shape of the simulation box.
|
||||
|
||||
The created bins (and hence the chunk IDs) are numbered consecutively
|
||||
from 1 to the number of bins = {Nchunk}. For 2d and 3d bins, the
|
||||
numbering varies most rapidly in the first dimension (which could be
|
||||
x, y, or z), next rapidly in the 2nd dimension, and most slowly in the
|
||||
3rd dimension.
|
||||
|
||||
Each time this compute is invoked, each atom is mapped to a bin based
|
||||
on its current position. Note that between reneighboring timesteps,
|
||||
atoms can move outside the current simulation box. If the box is
|
||||
periodic (in that dimension) the atom is remapping into the periodic
|
||||
box for purposes of binning. If the box in not periodic, the atom may
|
||||
have moved outside the bounds of all bins. If an atom is not inside
|
||||
any bin, the {discard} keyword is used to determine how a chunk ID is
|
||||
assigned to the atom.
|
||||
|
||||
:line
|
||||
|
||||
The {type} style uses the atom type as the chunk ID. {Nchunk} is set
|
||||
to the number of atom types defined for the simulation, e.g. via the
|
||||
"create_box"_create_box.html or "read_data"_read_data.html commands.
|
||||
|
||||
:line
|
||||
|
||||
The {molecule} style uses the molecule ID of each atom as its chunk
|
||||
ID. {Nchunk} is set to the largest chunk ID. Note that this excludes
|
||||
molecule IDs for atoms which are not in the specified group or
|
||||
optional region.
|
||||
|
||||
There is no requirement that all atoms in a particular molecule are
|
||||
assigned the same chunk ID (zero or non-zero), though you probably
|
||||
want that to be the case, if you wish to compute a per-molecule
|
||||
property. LAMMPS will issue a warning if that is not the case, but
|
||||
only the first time that {Nchunk} is calculated.
|
||||
|
||||
Note that atoms with a molecule ID = 0, which may be non-molecular
|
||||
solvent atoms, have an out-of-range chunk ID. These atoms are
|
||||
discarded (not assigned to any chunk) or assigned to {Nchunk},
|
||||
depending on the value of the {discard} keyword.
|
||||
|
||||
:line
|
||||
|
||||
The {compute/fix/variable} styles set the chunk ID of each atom based
|
||||
on a quantity calculated and stored by a compute, fix, or variable.
|
||||
In each case, it must be a per-atom quantity. In each case the
|
||||
referenced floating point values are converted to an integer chunk ID
|
||||
as follows. The floating point value is truncated (rounded down) to
|
||||
an integer value. If the integer value is <= 0, then a chunk ID of 0
|
||||
is assigned to the atom. If the integer value is > 0, it becomes the
|
||||
chunk ID to the atom. {Nchunk} is set to the largest chunk ID. Note
|
||||
that this excludes atoms which are not in the specified group or
|
||||
optional region.
|
||||
|
||||
If the style begins with "c_", a compute ID must follow which has been
|
||||
previously defined in the input script. If no bracketed integer is
|
||||
appended, the per-atom vector calculated by the compute is used. If a
|
||||
bracketed integer is appended, the Ith column of the per-atom array
|
||||
calculated by the compute is used. Users can also write code for
|
||||
their own compute styles and "add them to LAMMPS"_Section_modify.html.
|
||||
|
||||
If the style begins with "f_", a fix ID must follow which has been
|
||||
previously defined in the input script. If no bracketed integer is
|
||||
appended, the per-atom vector calculated by the fix is used. If a
|
||||
bracketed integer is appended, the Ith column of the per-atom array
|
||||
calculated by the fix is used. Note that some fixes only produce
|
||||
their values on certain timesteps, which must be compatible with the
|
||||
timestep on which this compute accesses the fix, else an error
|
||||
results. Users can also write code for their own fix styles and "add
|
||||
them to LAMMPS"_Section_modify.html.
|
||||
|
||||
If a value begins with "v_", a variable name for an {atom} or
|
||||
{atomfile} style "variable"_variable.html must follow which has been
|
||||
previously defined in the input script. Variables of style {atom} can
|
||||
reference thermodynamic keywords and various per-atom attributes, or
|
||||
invoke other computes, fixes, or variables when they are evaluated, so
|
||||
this is a very general means of generating per-atom quantities to
|
||||
treat as a chunk ID.
|
||||
|
||||
:line
|
||||
:line
|
||||
|
||||
Normally, {Nchunk} = the number of chunks, is re-calculated every time
|
||||
this fix is invoked, though the value may or may not change. As
|
||||
explained below, the {nchunk} keyword can be set to {once} which means
|
||||
{Nchunk} will never change.
|
||||
|
||||
If a "fix ave/chunk"_fix_ave_chunk.html command uses this compute, it
|
||||
can also turn off the re-calculation of {Nchunk} for one or more
|
||||
windows of timesteps. The extent of the windows, during which Nchunk
|
||||
is held constant, are determined by the {Nevery}, {Nrepeat}, {Nfreq}
|
||||
values and the {ave} keyword setting that are used by the "fix
|
||||
ave/chunk"_fix_ave_chunk.html command.
|
||||
|
||||
Specifically, if {ave} = {one}, then for each span of {Nfreq}
|
||||
timesteps, {Nchunk} is held constant between the first timestep when
|
||||
averaging is done (within the Nfreq-length window), and the last
|
||||
timestep when averaging is done (multiple of Nfreq). If {ave} =
|
||||
{running} or {window}, then {Nchunk} is held constant forever,
|
||||
starting on the first timestep when the "fix
|
||||
ave/chunk"_fix_ave_chunk.html command invokes this compute.
|
||||
|
||||
Note that multiple "fix ave/chunk"_fix_ave_chunk.html commands can use
|
||||
the same compute chunk/atom compute. However, the time windows they
|
||||
induce for holding {Nchunk} constant must be identical, else an error
|
||||
will be generated.
|
||||
|
||||
:line
|
||||
:line
|
||||
|
||||
The various optional keywords operate as follows. Note that some of
|
||||
them function differently or are ignored by different chunk styles.
|
||||
Some of them also have different default values, depending on
|
||||
the chunk style, as listed below.
|
||||
|
||||
The {region} keyword applies to all chunk styles. If used, an atom
|
||||
must be in both the specified group and the specified geometric
|
||||
"region"_region.html to be assigned to a chunk.
|
||||
|
||||
:line
|
||||
|
||||
The {nchunk} keyword applies to all chunk styles. It specifies how
|
||||
often {Nchunk} is recalculated, which in turn can affect the chunk IDs
|
||||
assigned to individual atoms.
|
||||
|
||||
If {nchunk} is set to {once}, then {Nchunk} is only calculated once,
|
||||
the first time this compute is invoked. If {nchunk} is set to
|
||||
{every}, then {Nchunk} is re-calculated every time the compute is
|
||||
invoked. Note that, as described above, the use of this compute
|
||||
by the "fix ave/chunk"_fix_ave_chunk.html command can override
|
||||
the {every} setting.
|
||||
|
||||
The default values for {nchunk} are listed below and depend on the
|
||||
chunk style and other system and keyword settings. They attempt to
|
||||
represent typical use cases for the various chunk styles. The
|
||||
{nchunk} value can always be set explicitly if desired.
|
||||
|
||||
:line
|
||||
|
||||
The {limit} keyword can be used to limit the calculated value of
|
||||
{Nchunk} = the number of chunks. The limit is applied each time
|
||||
{Nchunk} is calculated, which also limits the chunk IDs assigned to
|
||||
any atom. The {limit} keyword is used by all chunk styles except the
|
||||
{binning} styles, which ignore it. This is because the number of bins
|
||||
can be tailored using the {bound} keyword (described below) which
|
||||
effectively limits the size of {Nchunk}.
|
||||
|
||||
If {limit} is set to {Nc} = 0, then no limit is imposed on {Nchunk},
|
||||
though the {compress} keyword can still be used to reduce {Nchunk}, as
|
||||
described below.
|
||||
|
||||
If {Nc} > 0, then the effect of the {limit} keyword depends on whether
|
||||
the {compress} keyword is also used with a setting of {yes}, and
|
||||
whether the {compress} keyword is specified before the {limit} keyword
|
||||
or after.
|
||||
|
||||
In all cases, {Nchunk} is first calculated in the usual way for each
|
||||
chunk style, as described above.
|
||||
|
||||
First, here is what occurs if {compress yes} is not set. If {limit}
|
||||
is set to {Nc max}, then {Nchunk} is reset to the smaller of {Nchunk}
|
||||
and {Nc}. If {limit} is set to {Nc exact}, then {Nchunk} is reset to
|
||||
{Nc}, whether the original {Nchunk} was larger or smaller than {Nc}.
|
||||
If {Nchunk} shrank due to the {limit} setting, then atom chunk IDs >
|
||||
{Nchunk} will be reset to 0 or {Nchunk}, depending on the setting of
|
||||
the {discard} keyword. If {Nchunk} grew, there will simply be some
|
||||
chunks with no atoms assigned to them.
|
||||
|
||||
If {compress yes} is set, and the {compress} keyword comes before the
|
||||
{limit} keyword, the compression operation is performed first, as
|
||||
described below, which resets {Nchunk}. The {limit} keyword is then
|
||||
applied to the new {Nchunk} value, exactly as described in the
|
||||
preceeding paragraph. Note that in this case, all atoms will end up
|
||||
with chunk IDs <= {Nc}, but their original values (e.g. molecule ID or
|
||||
compute/fix/variable value) may have been > {Nc}, because of the
|
||||
compression operation.
|
||||
|
||||
If {compress yes} is set, and the {compress} keyword comes after the
|
||||
{limit} keyword, then the {limit} value of {Nc} is applied first to
|
||||
the uncompressed value of {Nchunk}, but only if {Nc} < {Nchunk}
|
||||
(whether {Nc max} or {Nc exact} is used). This effectively means all
|
||||
atoms with chunk IDs > {Nc} have their chunk IDs reset to 0 or {Nc},
|
||||
depending on the setting of the {discard} keyword. The compression
|
||||
operation is then performed, which may shrink {Nchunk} further. If
|
||||
the new {Nchunk} < {Nc} and {limit} = {Nc exact} is specified, then
|
||||
{Nchunk} is reset to {Nc}, which results in extra chunks with no atoms
|
||||
assigned to them. Note that in this case, all atoms will end up with
|
||||
chunk IDs <= {Nc}, and their original values (e.g. molecule ID or
|
||||
compute/fix/variable value) will also have been <= {Nc}.
|
||||
|
||||
:line
|
||||
|
||||
The {ids} keyword applies to all chunk styles. If the setting is
|
||||
{once} then the chunk IDs assigned to atoms the first time this
|
||||
compute is invoked will be permanent, and never be re-computed.
|
||||
|
||||
If the setting is {nfreq} and if a "fix ave/chunk"_fix_ave_chunk.html
|
||||
command is using this compute, then in each of the {Nchunk} = constant
|
||||
time windows (discussed above), the chunk ID's assigned to atoms on
|
||||
the first step of the time window will persist until the end of the
|
||||
time window.
|
||||
|
||||
If the setting is {every}, which is the default, then chunk IDs are
|
||||
re-calculated on any timestep this compute is invoked.
|
||||
|
||||
IMPORTANT NOTE: If you want the persistent chunk-IDs calculated by
|
||||
this compute to be continuous when running from a "restart
|
||||
file"_read_restart.html, then you should use the same ID for this
|
||||
compute, as in the original run. This is so that the fix this compute
|
||||
creates to store per-atom quantities will also have the same ID, and
|
||||
thus be initialized correctly with chunk IDs from the restart file.
|
||||
|
||||
:line
|
||||
|
||||
The {compress} keyword applies to all chunk styles and affects how
|
||||
{Nchunk} is calculated, which in turn affects the chunk IDs assigned
|
||||
to each atom. It is useful for converting a "sparse" set of chunk IDs
|
||||
(with many IDs that have no atoms assigned to them), into a "dense"
|
||||
set of IDs, where every chunk has one or more atoms assigned to it.
|
||||
|
||||
Two possible use cases are as follows. If a large simulation box is
|
||||
mostly empty space, then the {binning} style may produce many bins
|
||||
with no atoms. If {compress} is set to {yes}, only bins with atoms
|
||||
will be contribute to {Nchunk}. Likewise, the {molecule} or
|
||||
{compute/fix/variable} styles may produce large {Nchunk} values. For
|
||||
example, the "compute cluster/atom"_compute_cluster_atom.html command
|
||||
assigns every atom an atom ID for one of the atoms it is clustered
|
||||
with. For a million-atom system with 5 clusters, there would only be
|
||||
5 unique chunk IDs, but the largest chunk ID might be 1 million,
|
||||
resulting in {Nchunk} = 1 million. If {compress} is set to {yes},
|
||||
{Nchunk} will be reset to 5.
|
||||
|
||||
If {compress} is set to {no}, which is the default, no compression is
|
||||
done. If it is set to {yes}, all chunk IDs with no atoms are removed
|
||||
from the list of chunk IDs, and the list is sorted. The remaining
|
||||
chunk IDs are renumbered from 1 to {Nchunk} where {Nchunk} is the new
|
||||
length of the list. The chunk IDs assigned to each atom reflect
|
||||
the new renumbering from 1 to {Nchunk}.
|
||||
|
||||
The original chunk IDs (before renumbering) can be accessed by the
|
||||
"compute property/chunk"_compute_property_chunk.html command and its
|
||||
{id} keyword, or by the "fix ave/chunk"_fix_ave_chunk.html command
|
||||
which outputs the original IDs as one of the columns in its global
|
||||
output array. For example, using the "compute cluster/atom" command
|
||||
discussed above, the original 5 unique chunk IDs might be atom IDs
|
||||
(27,4982,58374,857838,1000000). After compresion, these will be
|
||||
renumbered to (1,2,3,4,5). The original values (27,...,1000000) can
|
||||
be output to a file by the "fix ave/chunk"_fix_ave_chunk.html command,
|
||||
or by using the "fix ave/time"_fix_ave_time.html command in
|
||||
conjunction with the "compute
|
||||
property/chunk"_compute_property_chunk.html command.
|
||||
|
||||
IMPORTANT NOTE: The compression operation requires global
|
||||
communication across all processors to share their chunk ID values.
|
||||
It can require large memory on every processor to store them, even
|
||||
after they are compressed, if there are are a large number of unique
|
||||
chunk IDs with atoms assigned to them. It uses a STL map to find
|
||||
unique chunk IDs and store them in sorted order. Each time an atom is
|
||||
assigned a compressed chunk ID, it must access the STL map. All of
|
||||
this means that compression can be expensive, both in memory and CPU
|
||||
time. The use of the {limit} keyword in conjunction with the
|
||||
{compress} keyword can affect these costs, depending on which keyword
|
||||
is used first. So use this option with care.
|
||||
|
||||
:line
|
||||
|
||||
The {discard} keyword applies to all chunk styles. It affects what
|
||||
chunk IDs are assigned to atoms that do not match one of the valid
|
||||
chunk IDs from 1 to {Nchunk}. Note that it does not apply to atoms
|
||||
that are not in the specified group or optionally specified region.
|
||||
Those atoms are always assigned a chunk ID = 0.
|
||||
|
||||
If the calculated chunk ID for an atom is not within the range 1 to
|
||||
{Nchunk} then it is a "discard" atom. Note that {Nchunk} may have
|
||||
been shrunk by the {limit} keyword. Or the {compress} keyword may
|
||||
have eliminated chunk IDs that were valid before the compression took
|
||||
place, and are now not in the compressed list. Also note that for the
|
||||
{molecule} chunk style, if new molecules are added to the system,
|
||||
their chunk IDs may exceed a previously calculated {Nchunk}.
|
||||
Likewise, evaluation of a compute/fix/variable on a later timestep may
|
||||
return chunk IDs that are invalid for the previously calculated
|
||||
{Nchunk}.
|
||||
|
||||
All the chunk styles except the {binning} styles, must use {discard}
|
||||
set to either {yes} or {no}. If {discard} is set to {yes}, which is
|
||||
the default, then every "discard" atom has its chunk ID set to 0. If
|
||||
{discard} is set to {no}, every "discard" atom has its chunk ID set to
|
||||
{Nchunk}. I.e. it becomes part of the last chunk.
|
||||
|
||||
The {binning} styles use the {discard} keyword to decide whether to
|
||||
discard atoms outside the spatial domain covered by bins, or to assign
|
||||
them to the bin they are nearest to. Details are as follows.
|
||||
|
||||
If {discard} is set to {yes}, an out-of-domain atom will have its
|
||||
chunk ID set to 0. If {discard} is set to {no}, the atom will have
|
||||
its chunk ID set to the first or last bin in that dimension. If
|
||||
(discard} is set to {mixed}, which is the default, it will only have
|
||||
its chunk ID set to the first or last bin if bins extend to the
|
||||
simulation box boundary in that dimension. This is the case if the
|
||||
{bound} keyword settings are {lower} and {upper}, which is the
|
||||
default. If the {bound} keyword settings are numeric values, then the
|
||||
atom will have its chunk ID set to 0 if it is outside the bounds of
|
||||
any bin. Note that in this case, it is possible that the first or
|
||||
last bin extends beyond the numeric {bounds} settings, depending on
|
||||
the specified {origin}. If this is the case, the chunk ID of the atom
|
||||
is only set to 0 if it is outside the first or last bin, not if it is
|
||||
simply outside the numeric {bounds} setting.
|
||||
|
||||
:line
|
||||
|
||||
The {bound} keyword only applies to the {binning} styles; otherwise it
|
||||
is ignored. It can be used one or more times to limit the extent of
|
||||
bin coverage in a specified dimension, i.e. to only bin a portion of
|
||||
the box. If the {lo} setting is {lower} or the {hi} setting is
|
||||
{upper}, the bin extent in that direction extends to the box boundary.
|
||||
If a numeric value is used for {lo} and/or {hi}, then the bin extent
|
||||
in the {lo} or {hi} direction extends only to that value, which is
|
||||
assumed to be inside (or at least near) the simulation box boundaries,
|
||||
though LAMMPS does not check for this. Note that using the {bound}
|
||||
keyword typically reduces the total number of bins and thus the number
|
||||
of chunks {Nchunk}.
|
||||
|
||||
The {units} keyword only applies to the {binning} styles; otherwise it
|
||||
is ignored. It determines the meaning of the distance units used for
|
||||
the bin sizes {delta} and for {origin} and {bounds} values if they are
|
||||
coordinate values. For orthogonal simulation boxes, any of the 3
|
||||
options may be used. For non-orthogonal (triclinic) simulation boxes,
|
||||
only the {reduced} option may be used.
|
||||
|
||||
A {box} value selects standard distance units as defined by the
|
||||
"units"_units.html command, e.g. Angstroms for units = real or metal.
|
||||
A {lattice} value means the distance units are in lattice spacings.
|
||||
The "lattice"_lattice.html command must have been previously used to
|
||||
define the lattice spacing. A {reduced} value means normalized
|
||||
unitless values between 0 and 1, which represent the lower and upper
|
||||
faces of the simulation box respectively. Thus an {origin} value of
|
||||
0.5 means the center of the box in any dimension. A {delta} value of
|
||||
0.1 means 10 bins span the box in that dimension.
|
||||
|
||||
:line
|
||||
:line
|
||||
|
||||
[Output info:]
|
||||
|
||||
This compute calculates a per-atom vector, which can be accessed by
|
||||
any command that uses per-atom values from a compute as input. See
|
||||
"Section_howto 15"_Section_howto.html#howto_15 for an overview of
|
||||
LAMMPS output options.
|
||||
|
||||
The per-atom vector values are unitless chunk IDs, ranging from 1 to
|
||||
{Nchunk} (inclusive) for atoms assigned to chunks, and 0 for atoms not
|
||||
belonging to a chunk.
|
||||
|
||||
[Restrictions:]
|
||||
|
||||
Even if the {nchunk} keyword is set to {once}, the chunk IDs assigned
|
||||
to each atom are not stored in a restart files. This means you cannot
|
||||
expect those assignments to persist in a restarted simulation.
|
||||
Instead you must re-specify this command and assign atoms to chunks when
|
||||
the restarted simulation begins.
|
||||
|
||||
[Related commands:]
|
||||
|
||||
"fix ave/chunk"_fix_ave_chunk.html
|
||||
|
||||
[Default:]
|
||||
|
||||
The option defaults are as follows:
|
||||
|
||||
region = none
|
||||
nchunk = every if compress is yes, overriding other defaults listed here
|
||||
nchunk = once for type style
|
||||
nchunk = once for mol style if region is none
|
||||
nchunk = every for mol style if region is set
|
||||
nchunk = once for binning style if the simulation box size is static or units = reduced
|
||||
nchunk = every for binning style if the simulation box size is dynamic and units is lattice or box
|
||||
nchunk = every for compute/fix/variable style
|
||||
limit = 0
|
||||
ids = every
|
||||
compress = no
|
||||
discard = yes for all styles except binning
|
||||
discard = mixed for binning styles
|
||||
bound = lower and upper in all dimensions
|
||||
units = lattice :ul
|
||||
@ -40,14 +40,6 @@ and how they are set for each atom. You can reset the image flags
|
||||
(e.g. to 0) before invoking this compute by using the <A HREF = "set.html">set
|
||||
image</A> command.
|
||||
</P>
|
||||
<P>IMPORTANT NOTE: If an atom is part of a rigid body (see the <A HREF = "fix_rigid.html">fix
|
||||
rigid</A> command), it's periodic image flags are altered,
|
||||
and its contribution to the center-of-mass may not reflect its true
|
||||
contribution. See the <A HREF = "fix_rigid.html">fix rigid</A> command for details.
|
||||
Thus, to compute the center-of-mass of rigid bodies as they cross
|
||||
periodic boundaries, you will need to post-process a <A HREF = "dump.html">dump
|
||||
file</A> containing coordinates of the atoms in the bodies.
|
||||
</P>
|
||||
<P><B>Output info:</B>
|
||||
</P>
|
||||
<P>This compute calculates a global vector of length 3, which can be
|
||||
|
||||
@ -37,14 +37,6 @@ and how they are set for each atom. You can reset the image flags
|
||||
(e.g. to 0) before invoking this compute by using the "set
|
||||
image"_set.html command.
|
||||
|
||||
IMPORTANT NOTE: If an atom is part of a rigid body (see the "fix
|
||||
rigid"_fix_rigid.html command), it's periodic image flags are altered,
|
||||
and its contribution to the center-of-mass may not reflect its true
|
||||
contribution. See the "fix rigid"_fix_rigid.html command for details.
|
||||
Thus, to compute the center-of-mass of rigid bodies as they cross
|
||||
periodic boundaries, you will need to post-process a "dump
|
||||
file"_dump.html containing coordinates of the atoms in the bodies.
|
||||
|
||||
[Output info:]
|
||||
|
||||
This compute calculates a global vector of length 3, which can be
|
||||
|
||||
92
doc/compute_com_chunk.html
Normal file
92
doc/compute_com_chunk.html
Normal file
@ -0,0 +1,92 @@
|
||||
<HTML>
|
||||
<CENTER><A HREF = "http://lammps.sandia.gov">LAMMPS WWW Site</A> - <A HREF = "Manual.html">LAMMPS Documentation</A> - <A HREF = "Section_commands.html#comm">LAMMPS Commands</A>
|
||||
</CENTER>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<HR>
|
||||
|
||||
<H3>compute com/chunk command
|
||||
</H3>
|
||||
<P><B>Syntax:</B>
|
||||
</P>
|
||||
<PRE>compute ID group-ID com/chunk chunkID
|
||||
</PRE>
|
||||
<UL><LI>ID, group-ID are documented in <A HREF = "compute.html">compute</A> command
|
||||
<LI>com/chunk = style name of this compute command
|
||||
<LI>chunkID = ID of <A HREF = "compute_chunk_atom.html">compute chunk/atom</A> command
|
||||
</UL>
|
||||
<P><B>Examples:</B>
|
||||
</P>
|
||||
<PRE>compute 1 fluid com/chunk molchunk
|
||||
</PRE>
|
||||
<P><B>Description:</B>
|
||||
</P>
|
||||
<P>Define a computation that calculates the center-of-mass for multiple
|
||||
chunks of atoms.
|
||||
</P>
|
||||
<P>In LAMMPS, chunks are collections of atoms defined by a <A HREF = "compute_chunk_atom.html">compute
|
||||
chunk/atom</A> command, which assigns each atom
|
||||
to a single chunk (or no chunk). The ID for this command is specified
|
||||
as chunkID. For example, a single chunk could be the atoms in a
|
||||
molecule or atoms in a spatial bin. See the <A HREF = "compute_chunk_atom.html">compute
|
||||
chunk/atom</A> doc page and "<A HREF = "Section_howto.html#howto_23">Section_howto
|
||||
23</A> for details of how chunks can be
|
||||
defined and examples of how they can be used to measure properties of
|
||||
a system.
|
||||
</P>
|
||||
<P>This compute calculates the x,y,z coordinates of the center-of-mass
|
||||
for each chunk, which includes all effects due to atoms passing thru
|
||||
periodic boundaries.
|
||||
</P>
|
||||
<P>Note that only atoms in the specified group contribute to the
|
||||
calculation. The <A HREF = "compute_chunk_atom.html">compute chunk/atom</A> command
|
||||
defines its own group; atoms will have a chunk ID = 0 if they are not
|
||||
in that group, signifying they are not assigned to a chunk, and will
|
||||
thus also not contribute to this calculation. You can specify the
|
||||
"all" group for this command if you simply want to include atoms with
|
||||
non-zero chunk IDs.
|
||||
</P>
|
||||
<P>IMPORTANT NOTE: The coordinates of an atom contribute to the chunk's
|
||||
center-of-mass in "unwrapped" form, by using the image flags
|
||||
associated with each atom. See the <A HREF = "dump.html">dump custom</A> command
|
||||
for a discussion of "unwrapped" coordinates. See the Atoms section of
|
||||
the <A HREF = "read_data.html">read_data</A> command for a discussion of image flags
|
||||
and how they are set for each atom. You can reset the image flags
|
||||
(e.g. to 0) before invoking this compute by using the <A HREF = "set.html">set
|
||||
image</A> command.
|
||||
</P>
|
||||
<P>The simplest way to output the results of the compute com/chunk
|
||||
calculation to a file is to use the <A HREF = "fix_ave_time.html">fix ave/time</A>
|
||||
command, for example:
|
||||
</P>
|
||||
<PRE>compute cc1 all chunk/atom molecule
|
||||
compute myChunk all com/chunk cc1
|
||||
fix 1 all ave/time 100 1 100 c_myChunk file tmp.out mode vector
|
||||
</PRE>
|
||||
<P><B>Output info:</B>
|
||||
</P>
|
||||
<P>This compute calculates a global array where the number of rows = the
|
||||
number of chunks <I>Nchunk</I> as calculated by the specified <A HREF = "compute_chunk_atom.html">compute
|
||||
chunk/atom</A> command. The number of columns =
|
||||
3 for the x,y,z center-of-mass coordinates of each chunk. These
|
||||
values can be accessed by any command that uses global array values
|
||||
from a compute as input. See <A HREF = "Section_howto.html#howto_15">Section_howto
|
||||
15</A> for an overview of LAMMPS output
|
||||
options.
|
||||
</P>
|
||||
<P>The array values are "intensive". The array values will be in
|
||||
distance <A HREF = "units.html">units</A>.
|
||||
</P>
|
||||
<P><B>Restrictions:</B> none
|
||||
</P>
|
||||
<P><B>Related commands:</B>
|
||||
</P>
|
||||
<P><A HREF = "compute_com.html">compute com</A>
|
||||
</P>
|
||||
<P><B>Default:</B> none
|
||||
</P>
|
||||
</HTML>
|
||||
87
doc/compute_com_chunk.txt
Normal file
87
doc/compute_com_chunk.txt
Normal file
@ -0,0 +1,87 @@
|
||||
"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
|
||||
|
||||
compute com/chunk command :h3
|
||||
|
||||
[Syntax:]
|
||||
|
||||
compute ID group-ID com/chunk chunkID :pre
|
||||
|
||||
ID, group-ID are documented in "compute"_compute.html command
|
||||
com/chunk = style name of this compute command
|
||||
chunkID = ID of "compute chunk/atom"_compute_chunk_atom.html command :ul
|
||||
|
||||
[Examples:]
|
||||
|
||||
compute 1 fluid com/chunk molchunk :pre
|
||||
|
||||
[Description:]
|
||||
|
||||
Define a computation that calculates the center-of-mass for multiple
|
||||
chunks of atoms.
|
||||
|
||||
In LAMMPS, chunks are collections of atoms defined by a "compute
|
||||
chunk/atom"_compute_chunk_atom.html command, which assigns each atom
|
||||
to a single chunk (or no chunk). The ID for this command is specified
|
||||
as chunkID. For example, a single chunk could be the atoms in a
|
||||
molecule or atoms in a spatial bin. See the "compute
|
||||
chunk/atom"_compute_chunk_atom.html doc page and ""Section_howto
|
||||
23"_Section_howto.html#howto_23 for details of how chunks can be
|
||||
defined and examples of how they can be used to measure properties of
|
||||
a system.
|
||||
|
||||
This compute calculates the x,y,z coordinates of the center-of-mass
|
||||
for each chunk, which includes all effects due to atoms passing thru
|
||||
periodic boundaries.
|
||||
|
||||
Note that only atoms in the specified group contribute to the
|
||||
calculation. The "compute chunk/atom"_compute_chunk_atom.html command
|
||||
defines its own group; atoms will have a chunk ID = 0 if they are not
|
||||
in that group, signifying they are not assigned to a chunk, and will
|
||||
thus also not contribute to this calculation. You can specify the
|
||||
"all" group for this command if you simply want to include atoms with
|
||||
non-zero chunk IDs.
|
||||
|
||||
IMPORTANT NOTE: The coordinates of an atom contribute to the chunk's
|
||||
center-of-mass in "unwrapped" form, by using the image flags
|
||||
associated with each atom. See the "dump custom"_dump.html command
|
||||
for a discussion of "unwrapped" coordinates. See the Atoms section of
|
||||
the "read_data"_read_data.html command for a discussion of image flags
|
||||
and how they are set for each atom. You can reset the image flags
|
||||
(e.g. to 0) before invoking this compute by using the "set
|
||||
image"_set.html command.
|
||||
|
||||
The simplest way to output the results of the compute com/chunk
|
||||
calculation to a file is to use the "fix ave/time"_fix_ave_time.html
|
||||
command, for example:
|
||||
|
||||
compute cc1 all chunk/atom molecule
|
||||
compute myChunk all com/chunk cc1
|
||||
fix 1 all ave/time 100 1 100 c_myChunk file tmp.out mode vector :pre
|
||||
|
||||
[Output info:]
|
||||
|
||||
This compute calculates a global array where the number of rows = the
|
||||
number of chunks {Nchunk} as calculated by the specified "compute
|
||||
chunk/atom"_compute_chunk_atom.html command. The number of columns =
|
||||
3 for the x,y,z center-of-mass coordinates of each chunk. These
|
||||
values can be accessed by any command that uses global array values
|
||||
from a compute as input. See "Section_howto
|
||||
15"_Section_howto.html#howto_15 for an overview of LAMMPS output
|
||||
options.
|
||||
|
||||
The array values are "intensive". The array values will be in
|
||||
distance "units"_units.html.
|
||||
|
||||
[Restrictions:] none
|
||||
|
||||
[Related commands:]
|
||||
|
||||
"compute com"_compute_com.html
|
||||
|
||||
[Default:] none
|
||||
@ -1,81 +0,0 @@
|
||||
<HTML>
|
||||
<CENTER><A HREF = "http://lammps.sandia.gov">LAMMPS WWW Site</A> - <A HREF = "Manual.html">LAMMPS Documentation</A> - <A HREF = "Section_commands.html#comm">LAMMPS Commands</A>
|
||||
</CENTER>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<HR>
|
||||
|
||||
<H3>compute com/molecule command
|
||||
</H3>
|
||||
<P><B>Syntax:</B>
|
||||
</P>
|
||||
<PRE>compute ID group-ID com/molecule
|
||||
</PRE>
|
||||
<UL><LI>ID, group-ID are documented in <A HREF = "compute.html">compute</A> command
|
||||
<LI>com/molecule = style name of this compute command
|
||||
</UL>
|
||||
<P><B>Examples:</B>
|
||||
</P>
|
||||
<PRE>compute 1 fluid com/molecule
|
||||
</PRE>
|
||||
<P><B>Description:</B>
|
||||
</P>
|
||||
<P>Define a computation that calculates the center-of-mass of individual
|
||||
molecules. The calculation includes all effects due to atoms passing
|
||||
thru periodic boundaries.
|
||||
</P>
|
||||
<P>The x,y,z coordinates of the center-of-mass for a particular molecule
|
||||
are only computed if one or more of its atoms are in the specified
|
||||
group. Normally all atoms in the molecule should be in the group,
|
||||
however this is not required. LAMMPS will warn you if this is not the
|
||||
case. Only atoms in the group contribute to the center-of-mass
|
||||
calculation for the molecule.
|
||||
</P>
|
||||
<P>The ordering of per-molecule quantities produced by this compute is
|
||||
consistent with the ordering produced by other compute commands that
|
||||
generate per-molecule datums. Conceptually, them molecule IDs will be
|
||||
in ascending order for any molecule with one or more of its atoms in
|
||||
the specified group.
|
||||
</P>
|
||||
<P>IMPORTANT NOTE: The coordinates of an atom contribute to the
|
||||
molecule's center-of-mass in "unwrapped" form, by using the image
|
||||
flags associated with each atom. See the <A HREF = "dump.html">dump custom</A>
|
||||
command for a discussion of "unwrapped" coordinates. See the Atoms
|
||||
section of the <A HREF = "read_data.html">read_data</A> command for a discussion of
|
||||
image flags and how they are set for each atom. You can reset the
|
||||
image flags (e.g. to 0) before invoking this compute by using the <A HREF = "set.html">set
|
||||
image</A> command.
|
||||
</P>
|
||||
<P>IMPORTANT NOTE: If an atom is part of a rigid body (see the <A HREF = "fix_rigid.html">fix
|
||||
rigid</A> command), it's periodic image flags are altered,
|
||||
and its contribution to the center-of-mass may not reflect its true
|
||||
contribution. See the <A HREF = "fix_rigid.html">fix rigid</A> command for details.
|
||||
Thus, to compute the center-of-mass of rigid bodies as they cross
|
||||
periodic boundaries, you will need to post-process a <A HREF = "dump.html">dump
|
||||
file</A> containing coordinates of the atoms in the bodies.
|
||||
</P>
|
||||
<P><B>Output info:</B>
|
||||
</P>
|
||||
<P>This compute calculates a global array where the number of rows =
|
||||
Nmolecules and the number of columns = 3 for the x,y,z center-of-mass
|
||||
coordinates of each molecule. These values can be accessed by any
|
||||
command that uses global array values from a compute as input. See
|
||||
<A HREF = "Section_howto.html#howto_15">Section_howto 15</A> for an overview of
|
||||
LAMMPS output options.
|
||||
</P>
|
||||
<P>The array values are "intensive". The array values will be in
|
||||
distance <A HREF = "units.html">units</A>.
|
||||
</P>
|
||||
<P><B>Restrictions:</B> none
|
||||
</P>
|
||||
<P><B>Related commands:</B>
|
||||
</P>
|
||||
<P><A HREF = "compute_com.html">compute com</A>
|
||||
</P>
|
||||
<P><B>Default:</B> none
|
||||
</P>
|
||||
</HTML>
|
||||
@ -1,76 +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
|
||||
|
||||
compute com/molecule command :h3
|
||||
|
||||
[Syntax:]
|
||||
|
||||
compute ID group-ID com/molecule :pre
|
||||
|
||||
ID, group-ID are documented in "compute"_compute.html command
|
||||
com/molecule = style name of this compute command :ul
|
||||
|
||||
[Examples:]
|
||||
|
||||
compute 1 fluid com/molecule :pre
|
||||
|
||||
[Description:]
|
||||
|
||||
Define a computation that calculates the center-of-mass of individual
|
||||
molecules. The calculation includes all effects due to atoms passing
|
||||
thru periodic boundaries.
|
||||
|
||||
The x,y,z coordinates of the center-of-mass for a particular molecule
|
||||
are only computed if one or more of its atoms are in the specified
|
||||
group. Normally all atoms in the molecule should be in the group,
|
||||
however this is not required. LAMMPS will warn you if this is not the
|
||||
case. Only atoms in the group contribute to the center-of-mass
|
||||
calculation for the molecule.
|
||||
|
||||
The ordering of per-molecule quantities produced by this compute is
|
||||
consistent with the ordering produced by other compute commands that
|
||||
generate per-molecule datums. Conceptually, them molecule IDs will be
|
||||
in ascending order for any molecule with one or more of its atoms in
|
||||
the specified group.
|
||||
|
||||
IMPORTANT NOTE: The coordinates of an atom contribute to the
|
||||
molecule's center-of-mass in "unwrapped" form, by using the image
|
||||
flags associated with each atom. See the "dump custom"_dump.html
|
||||
command for a discussion of "unwrapped" coordinates. See the Atoms
|
||||
section of the "read_data"_read_data.html command for a discussion of
|
||||
image flags and how they are set for each atom. You can reset the
|
||||
image flags (e.g. to 0) before invoking this compute by using the "set
|
||||
image"_set.html command.
|
||||
|
||||
IMPORTANT NOTE: If an atom is part of a rigid body (see the "fix
|
||||
rigid"_fix_rigid.html command), it's periodic image flags are altered,
|
||||
and its contribution to the center-of-mass may not reflect its true
|
||||
contribution. See the "fix rigid"_fix_rigid.html command for details.
|
||||
Thus, to compute the center-of-mass of rigid bodies as they cross
|
||||
periodic boundaries, you will need to post-process a "dump
|
||||
file"_dump.html containing coordinates of the atoms in the bodies.
|
||||
|
||||
[Output info:]
|
||||
|
||||
This compute calculates a global array where the number of rows =
|
||||
Nmolecules and the number of columns = 3 for the x,y,z center-of-mass
|
||||
coordinates of each molecule. These values can be accessed by any
|
||||
command that uses global array values from a compute as input. See
|
||||
"Section_howto 15"_Section_howto.html#howto_15 for an overview of
|
||||
LAMMPS output options.
|
||||
|
||||
The array values are "intensive". The array values will be in
|
||||
distance "units"_units.html.
|
||||
|
||||
[Restrictions:] none
|
||||
|
||||
[Related commands:]
|
||||
|
||||
"compute com"_compute_com.html
|
||||
|
||||
[Default:] none
|
||||
@ -45,20 +45,12 @@ discussion of image flags and how they are set for each atom. You can
|
||||
reset the image flags (e.g. to 0) before invoking this compute by
|
||||
using the <A HREF = "set.html">set image</A> command.
|
||||
</P>
|
||||
<P>IMPORTANT NOTE: If an atom is part of a rigid body (see the <A HREF = "fix_rigid.html">fix
|
||||
rigid</A> command), it's periodic image flags are altered,
|
||||
and the computed displacement may not reflect its true displacement.
|
||||
See the <A HREF = "fix_rigid.html">fix rigid</A> command for details. Thus, to
|
||||
compute the displacement of rigid bodies as they cross periodic
|
||||
boundaries, you will need to post-process a <A HREF = "dump.html">dump file</A>
|
||||
containing coordinates of the atoms in the bodies.
|
||||
</P>
|
||||
<P>IMPORTANT NOTE: If you want the quantities calculated by this compute
|
||||
to be continuous when running from a <A HREF = "read_restart.html">restart file</A>,
|
||||
then you should use the same ID for this compute, as in the original
|
||||
run. This is so that the created fix will also have the same ID, and
|
||||
thus be initialized correctly with atom coordinates from the restart
|
||||
file.
|
||||
run. This is so that the fix this compute creates to store per-atom
|
||||
quantities will also have the same ID, and thus be initialized
|
||||
correctly with time=0 atom coordinates from the restart file.
|
||||
</P>
|
||||
<P><B>Output info:</B>
|
||||
</P>
|
||||
|
||||
@ -42,20 +42,12 @@ discussion of image flags and how they are set for each atom. You can
|
||||
reset the image flags (e.g. to 0) before invoking this compute by
|
||||
using the "set image"_set.html command.
|
||||
|
||||
IMPORTANT NOTE: If an atom is part of a rigid body (see the "fix
|
||||
rigid"_fix_rigid.html command), it's periodic image flags are altered,
|
||||
and the computed displacement may not reflect its true displacement.
|
||||
See the "fix rigid"_fix_rigid.html command for details. Thus, to
|
||||
compute the displacement of rigid bodies as they cross periodic
|
||||
boundaries, you will need to post-process a "dump file"_dump.html
|
||||
containing coordinates of the atoms in the bodies.
|
||||
|
||||
IMPORTANT NOTE: If you want the quantities calculated by this compute
|
||||
to be continuous when running from a "restart file"_read_restart.html,
|
||||
then you should use the same ID for this compute, as in the original
|
||||
run. This is so that the created fix will also have the same ID, and
|
||||
thus be initialized correctly with atom coordinates from the restart
|
||||
file.
|
||||
run. This is so that the fix this compute creates to store per-atom
|
||||
quantities will also have the same ID, and thus be initialized
|
||||
correctly with time=0 atom coordinates from the restart file.
|
||||
|
||||
[Output info:]
|
||||
|
||||
|
||||
@ -83,8 +83,8 @@ energy. Therefore, this compute can apply perturbations to interaction
|
||||
parameters that are not directly proportional to the potential energy
|
||||
(e.g. σ in Lennard-Jones potentials).
|
||||
</P>
|
||||
<P>This command can be combined with <A HREF = "fix_adapt_fep.html">fix adapt/fep</A>
|
||||
to perform multistage free-energy perturbation calculations along
|
||||
<P>This command can be combined with <A HREF = "fix_adapt.html">fix adapt</A> to
|
||||
perform multistage free-energy perturbation calculations along
|
||||
stepwise alchemical transformations during a simulation run:
|
||||
</P>
|
||||
<CENTER><IMG SRC = "Eqs/compute_fep_fep.jpg">
|
||||
@ -96,9 +96,9 @@ perturbation method using a very small δ:
|
||||
</P>
|
||||
<CENTER><IMG SRC = "Eqs/compute_fep_fdti.jpg">
|
||||
</CENTER>
|
||||
<P>where <I>w</I><sub>i</sub> are weights of a numerical quadrature. The <A HREF = "fix_adapt_fep.html">fix
|
||||
adapt/fep</A> command can be used to define the stages
|
||||
of λ at which the derivative is calculated and averaged.
|
||||
<P>where <I>w</I><sub>i</sub> are weights of a numerical quadrature. The <A HREF = "fix_adapt.html">fix
|
||||
adapt</A> command can be used to define the stages of
|
||||
λ at which the derivative is calculated and averaged.
|
||||
</P>
|
||||
<P>The compute fep calculates the exponential Boltzmann term and also the
|
||||
potential energy difference <I>U</I><sub>1</sub>-<I>U</I><sub>0</sub>. By
|
||||
@ -148,9 +148,14 @@ the meaning of these parameters:
|
||||
<TR><TD ><A HREF = "pair_lj.html">lj/cut</A></TD><TD > epsilon,sigma</TD><TD > type pairs</TD></TR>
|
||||
<TR><TD ><A HREF = "pair_lj.html">lj/cut/coul/cut</A></TD><TD > epsilon,sigma</TD><TD > type pairs</TD></TR>
|
||||
<TR><TD ><A HREF = "pair_lj.html">lj/cut/coul/long</A></TD><TD > epsilon,sigma</TD><TD > type pairs</TD></TR>
|
||||
<TR><TD ><A HREF = "pair_lj_soft_coul_soft.html">lj/soft/coul/soft</A></TD><TD > epsilon,sigma,lambda</TD><TD > type pairs</TD></TR>
|
||||
<TR><TD ><A HREF = "pair_lj_soft_coul_soft.html">lj/soft</A></TD><TD > epsilon,sigma,lambda</TD><TD > type pairs</TD></TR>
|
||||
<TR><TD ><A HREF = "pair_lj_soft_coul_soft.html">coul/soft</A></TD><TD > lambda</TD><TD > type pairs</TD></TR>
|
||||
<TR><TD ><A HREF = "pair_lj_soft.html">lj/cut/soft</A></TD><TD > epsilon,sigma,lambda</TD><TD > type pairs</TD></TR>
|
||||
<TR><TD ><A HREF = "pair_lj_soft.html">coul/cut/soft</A></TD><TD > lambda</TD><TD > type pairs</TD></TR>
|
||||
<TR><TD ><A HREF = "pair_lj_soft.html">coul/long/soft</A></TD><TD > lambda</TD><TD > type pairs</TD></TR>
|
||||
<TR><TD ><A HREF = "pair_lj_soft.html">lj/cut/coul/cut/soft</A></TD><TD > epsilon,sigma,lambda</TD><TD > type pairs</TD></TR>
|
||||
<TR><TD ><A HREF = "pair_lj_soft.html">lj/cut/coul/long/soft</A></TD><TD > epsilon,sigma,lambda</TD><TD > type pairs</TD></TR>
|
||||
<TR><TD ><A HREF = "pair_lj_soft.html">lj/cut/tip4p/long/soft</A></TD><TD > epsilon,sigma,lambda</TD><TD > type pairs</TD></TR>
|
||||
<TR><TD ><A HREF = "pair_lj_soft.html">tip4p/long/soft</A></TD><TD > lambda</TD><TD > type pairs</TD></TR>
|
||||
<TR><TD ><A HREF = "pair_lj_soft.html">lj/charmm/coul/long/soft</A></TD><TD > epsilon,sigma,lambda</TD><TD > type pairs</TD></TR>
|
||||
<TR><TD ><A HREF = "pair_born.html">born</A></TD><TD > a,b,c</TD><TD > type pairs</TD></TR>
|
||||
<TR><TD ><A HREF = "pair_buck.html">buck</A></TD><TD > a,c </TD><TD > type pairs
|
||||
</TD></TR></TABLE></DIV>
|
||||
|
||||
@ -72,8 +72,8 @@ energy. Therefore, this compute can apply perturbations to interaction
|
||||
parameters that are not directly proportional to the potential energy
|
||||
(e.g. σ in Lennard-Jones potentials).
|
||||
|
||||
This command can be combined with "fix adapt/fep"_fix_adapt_fep.html
|
||||
to perform multistage free-energy perturbation calculations along
|
||||
This command can be combined with "fix adapt"_fix_adapt.html to
|
||||
perform multistage free-energy perturbation calculations along
|
||||
stepwise alchemical transformations during a simulation run:
|
||||
|
||||
:c,image(Eqs/compute_fep_fep.jpg)
|
||||
@ -86,8 +86,8 @@ perturbation method using a very small δ:
|
||||
:c,image(Eqs/compute_fep_fdti.jpg)
|
||||
|
||||
where {w}<sub>i</sub> are weights of a numerical quadrature. The "fix
|
||||
adapt/fep"_fix_adapt_fep.html command can be used to define the stages
|
||||
of λ at which the derivative is calculated and averaged.
|
||||
adapt"_fix_adapt.html command can be used to define the stages of
|
||||
λ at which the derivative is calculated and averaged.
|
||||
|
||||
The compute fep calculates the exponential Boltzmann term and also the
|
||||
potential energy difference {U}<sub>1</sub>-{U}<sub>0</sub>. By
|
||||
@ -136,9 +136,14 @@ the meaning of these parameters:
|
||||
"lj/cut"_pair_lj.html: epsilon,sigma: type pairs:
|
||||
"lj/cut/coul/cut"_pair_lj.html: epsilon,sigma: type pairs:
|
||||
"lj/cut/coul/long"_pair_lj.html: epsilon,sigma: type pairs:
|
||||
"lj/soft/coul/soft"_pair_lj_soft_coul_soft.html: epsilon,sigma,lambda: type pairs:
|
||||
"lj/soft"_pair_lj_soft_coul_soft.html: epsilon,sigma,lambda: type pairs:
|
||||
"coul/soft"_pair_lj_soft_coul_soft.html: lambda: type pairs:
|
||||
"lj/cut/soft"_pair_lj_soft.html: epsilon,sigma,lambda: type pairs:
|
||||
"coul/cut/soft"_pair_lj_soft.html: lambda: type pairs:
|
||||
"coul/long/soft"_pair_lj_soft.html: lambda: type pairs:
|
||||
"lj/cut/coul/cut/soft"_pair_lj_soft.html: epsilon,sigma,lambda: type pairs:
|
||||
"lj/cut/coul/long/soft"_pair_lj_soft.html: epsilon,sigma,lambda: type pairs:
|
||||
"lj/cut/tip4p/long/soft"_pair_lj_soft.html: epsilon,sigma,lambda: type pairs:
|
||||
"tip4p/long/soft"_pair_lj_soft.html: lambda: type pairs:
|
||||
"lj/charmm/coul/long/soft"_pair_lj_soft.html: epsilon,sigma,lambda: type pairs:
|
||||
"born"_pair_born.html: a,b,c: type pairs:
|
||||
"buck"_pair_buck.html: a,c : type pairs :tb(c=3,s=:)
|
||||
|
||||
|
||||
@ -28,19 +28,22 @@
|
||||
group of atoms, including all effects due to atoms passing thru
|
||||
periodic boundaries.
|
||||
</P>
|
||||
<P>Rg is a measure of the size of the group of atoms, and is computed by
|
||||
this formula
|
||||
<P>Rg is a measure of the size of the group of atoms, and is computed as
|
||||
the square root of the Rg^2 value in this formula
|
||||
</P>
|
||||
<CENTER><IMG SRC = "Eqs/compute_gyration.jpg">
|
||||
</CENTER>
|
||||
<P>where M is the total mass of the group, Rcm is the center-of-mass
|
||||
position of the group, and the sum is over all atoms in the group.
|
||||
</P>
|
||||
<P>A Rg tensor, stored as a 6-element vector, is also calculated by this
|
||||
compute. The formula for the components of the tensor is the same as
|
||||
the above formula, except that (Ri - Rcm)^2 is replaced by (Rix -
|
||||
Rcmx) * (Riy - Rcmy) for the xy component, etc. The 6 components of
|
||||
the vector are ordered xx, yy, zz, xy, xz, yz.
|
||||
<P>A Rg^2 tensor, stored as a 6-element vector, is also calculated by
|
||||
this compute. The formula for the components of the tensor is the
|
||||
same as the above formula, except that (Ri - Rcm)^2 is replaced by
|
||||
(Rix - Rcmx) * (Riy - Rcmy) for the xy component, etc. The 6
|
||||
components of the vector are ordered xx, yy, zz, xy, xz, yz. Note
|
||||
that unlike the scalar Rg, each of the 6 values of the tensor is
|
||||
effectively a "squared" value, since the cross-terms may be negative
|
||||
and taking a sqrt() would be invalid.
|
||||
</P>
|
||||
<P>IMPORTANT NOTE: The coordinates of an atom contribute to Rg in
|
||||
"unwrapped" form, by using the image flags associated with each atom.
|
||||
@ -54,16 +57,15 @@ image</A> command.
|
||||
<P><B>Output info:</B>
|
||||
</P>
|
||||
<P>This compute calculates a global scalar (Rg) and a global vector of
|
||||
length 6 (Rg tensor), which can be accessed by indices 1-6. These
|
||||
length 6 (Rg^2 tensor), which can be accessed by indices 1-6. These
|
||||
values can be used by any command that uses a global scalar value or
|
||||
vector values from a compute as input. See <A HREF = "Section_howto.html#howto_15">Section_howto
|
||||
15</A> for an overview of LAMMPS output
|
||||
options.
|
||||
</P>
|
||||
<P>The scalar and vector values calculated by this compute are
|
||||
"intensive". The scalar and vector values will be in distance
|
||||
<A HREF = "units.html">units</A>, since they are the square root of values
|
||||
represented by the formula above.
|
||||
"intensive". The scalar and vector values will be in distance and
|
||||
distance^2 <A HREF = "units.html">units</A> respectively.
|
||||
</P>
|
||||
<P><B>Restrictions:</B> none
|
||||
</P>
|
||||
|
||||
@ -25,19 +25,22 @@ Define a computation that calculates the radius of gyration Rg of the
|
||||
group of atoms, including all effects due to atoms passing thru
|
||||
periodic boundaries.
|
||||
|
||||
Rg is a measure of the size of the group of atoms, and is computed by
|
||||
this formula
|
||||
Rg is a measure of the size of the group of atoms, and is computed as
|
||||
the square root of the Rg^2 value in this formula
|
||||
|
||||
:c,image(Eqs/compute_gyration.jpg)
|
||||
|
||||
where M is the total mass of the group, Rcm is the center-of-mass
|
||||
position of the group, and the sum is over all atoms in the group.
|
||||
|
||||
A Rg tensor, stored as a 6-element vector, is also calculated by this
|
||||
compute. The formula for the components of the tensor is the same as
|
||||
the above formula, except that (Ri - Rcm)^2 is replaced by (Rix -
|
||||
Rcmx) * (Riy - Rcmy) for the xy component, etc. The 6 components of
|
||||
the vector are ordered xx, yy, zz, xy, xz, yz.
|
||||
A Rg^2 tensor, stored as a 6-element vector, is also calculated by
|
||||
this compute. The formula for the components of the tensor is the
|
||||
same as the above formula, except that (Ri - Rcm)^2 is replaced by
|
||||
(Rix - Rcmx) * (Riy - Rcmy) for the xy component, etc. The 6
|
||||
components of the vector are ordered xx, yy, zz, xy, xz, yz. Note
|
||||
that unlike the scalar Rg, each of the 6 values of the tensor is
|
||||
effectively a "squared" value, since the cross-terms may be negative
|
||||
and taking a sqrt() would be invalid.
|
||||
|
||||
IMPORTANT NOTE: The coordinates of an atom contribute to Rg in
|
||||
"unwrapped" form, by using the image flags associated with each atom.
|
||||
@ -51,16 +54,15 @@ image"_set.html command.
|
||||
[Output info:]
|
||||
|
||||
This compute calculates a global scalar (Rg) and a global vector of
|
||||
length 6 (Rg tensor), which can be accessed by indices 1-6. These
|
||||
length 6 (Rg^2 tensor), which can be accessed by indices 1-6. These
|
||||
values can be used by any command that uses a global scalar value or
|
||||
vector values from a compute as input. See "Section_howto
|
||||
15"_Section_howto.html#howto_15 for an overview of LAMMPS output
|
||||
options.
|
||||
|
||||
The scalar and vector values calculated by this compute are
|
||||
"intensive". The scalar and vector values will be in distance
|
||||
"units"_units.html, since they are the square root of values
|
||||
represented by the formula above.
|
||||
"intensive". The scalar and vector values will be in distance and
|
||||
distance^2 "units"_units.html respectively.
|
||||
|
||||
[Restrictions:] none
|
||||
|
||||
|
||||
122
doc/compute_gyration_chunk.html
Normal file
122
doc/compute_gyration_chunk.html
Normal file
@ -0,0 +1,122 @@
|
||||
<HTML>
|
||||
<CENTER><A HREF = "http://lammps.sandia.gov">LAMMPS WWW Site</A> - <A HREF = "Manual.html">LAMMPS Documentation</A> - <A HREF = "Section_commands.html#comm">LAMMPS Commands</A>
|
||||
</CENTER>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<HR>
|
||||
|
||||
<H3>compute gyration/chunk command
|
||||
</H3>
|
||||
<P><B>Syntax:</B>
|
||||
</P>
|
||||
<PRE>compute ID group-ID gyration/chunk chunkID keyword value ...
|
||||
</PRE>
|
||||
<UL><LI>ID, group-ID are documented in <A HREF = "compute.html">compute</A> command
|
||||
|
||||
<LI>gyration/chunk = style name of this compute command
|
||||
|
||||
<LI>chunkID = ID of <A HREF = "compute_chunk_atom.html">compute chunk/atom</A> command
|
||||
|
||||
<LI>zero or more keyword/value pairs may be appended
|
||||
|
||||
<LI>keyword = <I>tensor</I>
|
||||
|
||||
<PRE> <I>tensor</I> value = none
|
||||
</PRE>
|
||||
|
||||
</UL>
|
||||
<P><B>Examples:</B>
|
||||
</P>
|
||||
<PRE>compute 1 molecule gyration/chunk molchunk
|
||||
compute 2 molecule gyration/chunk molchunk tensor
|
||||
</PRE>
|
||||
<P><B>Description:</B>
|
||||
</P>
|
||||
<P>Define a computation that calculates the radius of gyration Rg for
|
||||
multiple chunks of atoms.
|
||||
</P>
|
||||
<P>In LAMMPS, chunks are collections of atoms defined by a <A HREF = "compute_chunk_atom.html">compute
|
||||
chunk/atom</A> command, which assigns each atom
|
||||
to a single chunk (or no chunk). The ID for this command is specified
|
||||
as chunkID. For example, a single chunk could be the atoms in a
|
||||
molecule or atoms in a spatial bin. See the <A HREF = "compute_chunk_atom.html">compute
|
||||
chunk/atom</A> doc page and "<A HREF = "Section_howto.html#howto_23">Section_howto
|
||||
23</A> for details of how chunks can be
|
||||
defined and examples of how they can be used to measure properties of
|
||||
a system.
|
||||
</P>
|
||||
<P>This compute calculates the radius of gyration Rg for each chunk,
|
||||
which includes all effects due to atoms passing thru periodic
|
||||
boundaries.
|
||||
</P>
|
||||
<P>Rg is a measure of the size of a chunk, and is computed by this
|
||||
formula
|
||||
</P>
|
||||
<CENTER><IMG SRC = "Eqs/compute_gyration.jpg">
|
||||
</CENTER>
|
||||
<P>where M is the total mass of the chunk, Rcm is the center-of-mass
|
||||
position of the chunk, and the sum is over all atoms in the
|
||||
chunk.
|
||||
</P>
|
||||
<P>Note that only atoms in the specified group contribute to the
|
||||
calculation. The <A HREF = "compute_chunk_atom.html">compute chunk/atom</A> command
|
||||
defines its own group; atoms will have a chunk ID = 0 if they are not
|
||||
in that group, signifying they are not assigned to a chunk, and will
|
||||
thus also not contribute to this calculation. You can specify the
|
||||
"all" group for this command if you simply want to include atoms with
|
||||
non-zero chunk IDs.
|
||||
</P>
|
||||
<P>If the <I>tensor</I> keyword is specified, then the scalar Rg value is not
|
||||
calculated, but an Rg tensor is instead calculated for each chunk.
|
||||
The formula for the components of the tensor is the same as the above
|
||||
formula, except that (Ri - Rcm)^2 is replaced by (Rix - Rcmx) * (Riy -
|
||||
Rcmy) for the xy component, etc. The 6 components of the tensor are
|
||||
ordered xx, yy, zz, xy, xz, yz.
|
||||
</P>
|
||||
<P>IMPORTANT NOTE: The coordinates of an atom contribute to Rg in
|
||||
"unwrapped" form, by using the image flags associated with each atom.
|
||||
See the <A HREF = "dump.html">dump custom</A> command for a discussion of
|
||||
"unwrapped" coordinates. See the Atoms section of the
|
||||
<A HREF = "read_data.html">read_data</A> command for a discussion of image flags and
|
||||
how they are set for each atom. You can reset the image flags
|
||||
(e.g. to 0) before invoking this compute by using the <A HREF = "set.html">set
|
||||
image</A> command.
|
||||
</P>
|
||||
<P>The simplest way to output the results of the compute gyration/chunk
|
||||
calculation to a file is to use the <A HREF = "fix_ave_time.html">fix ave/time</A>
|
||||
command, for example:
|
||||
</P>
|
||||
<PRE>compute cc1 all chunk/atom molecule
|
||||
compute myChunk all gyration/chunk cc1
|
||||
fix 1 all ave/time 100 1 100 c_myChunk file tmp.out mode vector
|
||||
</PRE>
|
||||
<P><B>Output info:</B>
|
||||
</P>
|
||||
<P>This compute calculates a global vector if the <I>tensor</I> keyword is not
|
||||
specified and a global array if it is. The length of the vector or
|
||||
number of rows in the array = the number of chunks <I>Nchunk</I> as
|
||||
calculated by the specified <A HREF = "compute_chunk_atom.html">compute
|
||||
chunk/atom</A> command. If the <I>tensor</I> keyword
|
||||
is specified, the global array has 6 columns. The vector or array can
|
||||
be accessed by any command that uses global values from a compute as
|
||||
input. See <A HREF = "Section_howto.html#howto_15">this section</A> for an overview
|
||||
of LAMMPS output options.
|
||||
</P>
|
||||
<P>All the vector or array values calculated by this compute are
|
||||
"intensive". The vector or array values will be in distance
|
||||
<A HREF = "units.html">units</A>, since they are the square root of values
|
||||
represented by the formula above.
|
||||
</P>
|
||||
<P><B>Restrictions:</B> none
|
||||
</P>
|
||||
<P><B>Related commands:</B> none
|
||||
</P>
|
||||
<P><A HREF = "compute_gyration.html">compute gyration</A>
|
||||
</P>
|
||||
<P><B>Default:</B> none
|
||||
</P>
|
||||
</HTML>
|
||||
111
doc/compute_gyration_chunk.txt
Normal file
111
doc/compute_gyration_chunk.txt
Normal file
@ -0,0 +1,111 @@
|
||||
"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
|
||||
|
||||
compute gyration/chunk command :h3
|
||||
|
||||
[Syntax:]
|
||||
|
||||
compute ID group-ID gyration/chunk chunkID keyword value ... :pre
|
||||
|
||||
ID, group-ID are documented in "compute"_compute.html command :ulb,l
|
||||
gyration/chunk = style name of this compute command :l
|
||||
chunkID = ID of "compute chunk/atom"_compute_chunk_atom.html command :l
|
||||
zero or more keyword/value pairs may be appended :l
|
||||
keyword = {tensor} :l
|
||||
{tensor} value = none :pre
|
||||
:ule
|
||||
|
||||
[Examples:]
|
||||
|
||||
compute 1 molecule gyration/chunk molchunk
|
||||
compute 2 molecule gyration/chunk molchunk tensor :pre
|
||||
|
||||
[Description:]
|
||||
|
||||
Define a computation that calculates the radius of gyration Rg for
|
||||
multiple chunks of atoms.
|
||||
|
||||
In LAMMPS, chunks are collections of atoms defined by a "compute
|
||||
chunk/atom"_compute_chunk_atom.html command, which assigns each atom
|
||||
to a single chunk (or no chunk). The ID for this command is specified
|
||||
as chunkID. For example, a single chunk could be the atoms in a
|
||||
molecule or atoms in a spatial bin. See the "compute
|
||||
chunk/atom"_compute_chunk_atom.html doc page and ""Section_howto
|
||||
23"_Section_howto.html#howto_23 for details of how chunks can be
|
||||
defined and examples of how they can be used to measure properties of
|
||||
a system.
|
||||
|
||||
This compute calculates the radius of gyration Rg for each chunk,
|
||||
which includes all effects due to atoms passing thru periodic
|
||||
boundaries.
|
||||
|
||||
Rg is a measure of the size of a chunk, and is computed by this
|
||||
formula
|
||||
|
||||
:c,image(Eqs/compute_gyration.jpg)
|
||||
|
||||
where M is the total mass of the chunk, Rcm is the center-of-mass
|
||||
position of the chunk, and the sum is over all atoms in the
|
||||
chunk.
|
||||
|
||||
Note that only atoms in the specified group contribute to the
|
||||
calculation. The "compute chunk/atom"_compute_chunk_atom.html command
|
||||
defines its own group; atoms will have a chunk ID = 0 if they are not
|
||||
in that group, signifying they are not assigned to a chunk, and will
|
||||
thus also not contribute to this calculation. You can specify the
|
||||
"all" group for this command if you simply want to include atoms with
|
||||
non-zero chunk IDs.
|
||||
|
||||
If the {tensor} keyword is specified, then the scalar Rg value is not
|
||||
calculated, but an Rg tensor is instead calculated for each chunk.
|
||||
The formula for the components of the tensor is the same as the above
|
||||
formula, except that (Ri - Rcm)^2 is replaced by (Rix - Rcmx) * (Riy -
|
||||
Rcmy) for the xy component, etc. The 6 components of the tensor are
|
||||
ordered xx, yy, zz, xy, xz, yz.
|
||||
|
||||
IMPORTANT NOTE: The coordinates of an atom contribute to Rg in
|
||||
"unwrapped" form, by using the image flags associated with each atom.
|
||||
See the "dump custom"_dump.html command for a discussion of
|
||||
"unwrapped" coordinates. See the Atoms section of the
|
||||
"read_data"_read_data.html command for a discussion of image flags and
|
||||
how they are set for each atom. You can reset the image flags
|
||||
(e.g. to 0) before invoking this compute by using the "set
|
||||
image"_set.html command.
|
||||
|
||||
The simplest way to output the results of the compute gyration/chunk
|
||||
calculation to a file is to use the "fix ave/time"_fix_ave_time.html
|
||||
command, for example:
|
||||
|
||||
compute cc1 all chunk/atom molecule
|
||||
compute myChunk all gyration/chunk cc1
|
||||
fix 1 all ave/time 100 1 100 c_myChunk file tmp.out mode vector :pre
|
||||
|
||||
[Output info:]
|
||||
|
||||
This compute calculates a global vector if the {tensor} keyword is not
|
||||
specified and a global array if it is. The length of the vector or
|
||||
number of rows in the array = the number of chunks {Nchunk} as
|
||||
calculated by the specified "compute
|
||||
chunk/atom"_compute_chunk_atom.html command. If the {tensor} keyword
|
||||
is specified, the global array has 6 columns. The vector or array can
|
||||
be accessed by any command that uses global values from a compute as
|
||||
input. See "this section"_Section_howto.html#howto_15 for an overview
|
||||
of LAMMPS output options.
|
||||
|
||||
All the vector or array values calculated by this compute are
|
||||
"intensive". The vector or array values will be in distance
|
||||
"units"_units.html, since they are the square root of values
|
||||
represented by the formula above.
|
||||
|
||||
[Restrictions:] none
|
||||
|
||||
[Related commands:] none
|
||||
|
||||
"compute gyration"_compute_gyration.html
|
||||
|
||||
[Default:] none
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user