diff --git a/doc/Manual.html b/doc/Manual.html
index fe933d19e..a1a5010f5 100644
--- a/doc/Manual.html
+++ b/doc/Manual.html
@@ -1,420 +1,420 @@
<HTML>
<HEAD>
<TITLE>LAMMPS Users Manual</TITLE>
<META NAME="docnumber" CONTENT="24 Jan 2013 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>
<BODY>
<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>
<H1></H1>
<CENTER><H3>LAMMPS Documentation
</H3></CENTER>
<CENTER><H4>27 Jan 2013 version
</H4></CENTER>
<H4>Version info:
</H4>
<P>The LAMMPS "version" is the date when it was released, such as 1 May
2010. LAMMPS is updated continuously. Whenever we fix a bug or add a
feature, we release it immediately, and post a notice on <A HREF = "http://lammps.sandia.gov/bug.html">this page of
the WWW site</A>. Each dated copy of LAMMPS contains all the
features and bug-fixes up to and including that version date. The
version date is printed to the screen and logfile every time you run
LAMMPS. It is also in the file src/version.h and in the LAMMPS
directory name created when you unpack a tarball, and at the top of
the first page of the manual (this page).
</P>
<UL><LI>If you browse the HTML doc pages on the LAMMPS WWW site, they always
describe the most current version of LAMMPS.
<LI>If you browse the HTML doc pages included in your tarball, they
describe the version you have.
<LI>The <A HREF = "Manual.pdf">PDF file</A> on the WWW site or in the tarball is updated
about once per month. This is because it is large, and we don't want
it to be part of every patch.
<LI>There is also a <A HREF = "Developer.pdf">Developer.pdf</A> file in the doc
directory, which describes the internal structure and algorithms of
LAMMPS.
</UL>
<P>LAMMPS stands for Large-scale Atomic/Molecular Massively Parallel
Simulator.
</P>
<P>LAMMPS is a classical molecular dynamics simulation code designed to
run efficiently on parallel computers. It was developed at Sandia
National Laboratories, a US Department of Energy facility, with
funding from the DOE. It is an open-source code, distributed freely
under the terms of the GNU Public License (GPL).
</P>
<P>The primary developers of LAMMPS are <A HREF = "http://www.sandia.gov/~sjplimp">Steve Plimpton</A>, Aidan
Thompson, and Paul Crozier who can be contacted at
sjplimp,athomps,pscrozi at sandia.gov. The <A HREF = "http://lammps.sandia.gov">LAMMPS WWW Site</A> at
http://lammps.sandia.gov has more information about the code and its
uses.
</P>
<HR>
<P>The LAMMPS documentation is organized into the following sections. If
you find errors or omissions in this manual or have suggestions for
useful information to add, please send an email to the developers so
we can improve the LAMMPS documentation.
</P>
<P>Once you are familiar with LAMMPS, you may want to bookmark <A HREF = "Section_commands.html#comm">this
page</A> at Section_commands.html#comm since
it gives quick access to documentation for all LAMMPS commands.
</P>
<P><A HREF = "Manual.pdf">PDF file</A> of the entire manual, generated by
<A HREF = "http://www.easysw.com/htmldoc">htmldoc</A>
</P>
<OL><LI><A HREF = "Section_intro.html">Introduction</A>
<UL> 1.1 <A HREF = "Section_intro.html#intro_1">What is LAMMPS</A>
<BR>
1.2 <A HREF = "Section_intro.html#intro_2">LAMMPS features</A>
<BR>
1.3 <A HREF = "Section_intro.html#intro_3">LAMMPS non-features</A>
<BR>
1.4 <A HREF = "Section_intro.html#intro_4">Open source distribution</A>
<BR>
1.5 <A HREF = "Section_intro.html#intro_5">Acknowledgments and citations</A>
<BR></UL>
<LI><A HREF = "Section_start.html">Getting started</A>
<UL> 2.1 <A HREF = "Section_start.html#start_1">What's in the LAMMPS distribution</A>
<BR>
2.2 <A HREF = "Section_start.html#start_2">Making LAMMPS</A>
<BR>
2.3 <A HREF = "Section_start.html#start_3">Making LAMMPS with optional packages</A>
<BR>
2.4 <A HREF = "Section_start.html#start_4">Building LAMMPS via the Make.py script</A>
<BR>
2.5 <A HREF = "Section_start.html#start_5">Building LAMMPS as a library</A>
<BR>
2.6 <A HREF = "Section_start.html#start_6">Running LAMMPS</A>
<BR>
2.7 <A HREF = "Section_start.html#start_7">Command-line options</A>
<BR>
2.8 <A HREF = "Section_start.html#start_8">Screen output</A>
<BR>
2.9 <A HREF = "Section_start.html#start_9">Tips for users of previous versions</A>
<BR></UL>
<LI><A HREF = "Section_commands.html">Commands</A>
<UL> 3.1 <A HREF = "Section_commands.html#cmd_1">LAMMPS input script</A>
<BR>
3.2 <A HREF = "Section_commands.html#cmd_2">Parsing rules</A>
<BR>
3.3 <A HREF = "Section_commands.html#cmd_3">Input script structure</A>
<BR>
3.4 <A HREF = "Section_commands.html#cmd_4">Commands listed by category</A>
<BR>
3.5 <A HREF = "Section_commands.html#cmd_5">Commands listed alphabetically</A>
<BR></UL>
<LI><A HREF = "Section_packages.html">Packages</A>
<UL> 4.1 <A HREF = "Section_packages.html#pkg_1">Standard packages</A>
<BR>
4.2 <A HREF = "Section_packages.html#pkg_2">User packages</A>
<BR></UL>
<LI><A HREF = "Section_accelerate.html">Accelerating LAMMPS performance</A>
<UL> 5.1 <A HREF = "Section_accelerate.html#acc_1">Measuring performance</A>
<BR>
5.2 <A HREF = "Section_accelerate.html#acc_2">General strategies</A>
<BR>
5.3 <A HREF = "Section_accelerate.html#acc_3">Packages with optimized styles</A>
<BR>
5.4 <A HREF = "Section_accelerate.html#acc_4">OPT package</A>
<BR>
5.5 <A HREF = "Section_accelerate.html#acc_5">USER-OMP package</A>
<BR>
5.6 <A HREF = "Section_accelerate.html#acc_6">GPU package</A>
<BR>
5.7 <A HREF = "Section_accelerate.html#acc_7">USER-CUDA package</A>
<BR>
5.8 <A HREF = "Section_accelerate.html#acc_8">Comparison of GPU and USER-CUDA packages</A>
<BR></UL>
<LI><A HREF = "Section_howto.html">How-to discussions</A>
<UL> 6.1 <A HREF = "Section_howto.html#howto_1">Restarting a simulation</A>
<BR>
6.2 <A HREF = "Section_howto.html#howto_2">2d simulations</A>
<BR>
6.3 <A HREF = "Section_howto.html#howto_3">CHARMM and AMBER force fields</A>
<BR>
6.4 <A HREF = "Section_howto.html#howto_4">Running multiple simulations from one input script</A>
<BR>
6.5 <A HREF = "Section_howto.html#howto_5">Multi-replica simulations</A>
<BR>
6.6 <A HREF = "Section_howto.html#howto_6">Granular models</A>
<BR>
6.7 <A HREF = "Section_howto.html#howto_7">TIP3P water model</A>
<BR>
6.8 <A HREF = "Section_howto.html#howto_8">TIP4P water model</A>
<BR>
6.9 <A HREF = "Section_howto.html#howto_9">SPC water model</A>
<BR>
6.10 <A HREF = "Section_howto.html#howto_10">Coupling LAMMPS to other codes</A>
<BR>
6.11 <A HREF = "Section_howto.html#howto_11">Visualizing LAMMPS snapshots</A>
<BR>
6.12 <A HREF = "Section_howto.html#howto_12">Triclinic (non-orthogonal) simulation boxes</A>
<BR>
6.13 <A HREF = "Section_howto.html#howto_13">NEMD simulations</A>
<BR>
6.14 <A HREF = "Section_howto.html#howto_14">Extended spherical and aspherical particles</A>
<BR>
6.15 <A HREF = "Section_howto.html#howto_15">Output from LAMMPS (thermo, dumps, computes, fixes, variables)</A>
<BR>
6.16 <A HREF = "Section_howto.html#howto_16">Thermostatting, barostatting, and compute temperature</A>
<BR>
6.17 <A HREF = "Section_howto.html#howto_17">Walls</A>
<BR>
6.18 <A HREF = "Section_howto.html#howto_18">Elastic constants</A>
<BR>
6.19 <A HREF = "Section_howto.html#howto_19">Library interface to LAMMPS</A>
<BR>
6.20 <A HREF = "Section_howto.html#howto_20">Calculating thermal conductivity</A>
<BR>
6.21 <A HREF = "Section_howto.html#howto_21">Calculating viscosity</A>
+<BR>
+ 6.22 <A HREF = "Section_howto.html#howto_22">Body particles</A>
<BR></UL>
<LI><A HREF = "Section_example.html">Example problems</A>
<LI><A HREF = "Section_perf.html">Performance & scalability</A>
<LI><A HREF = "Section_tools.html">Additional tools</A>
<LI><A HREF = "Section_modify.html">Modifying & extending LAMMPS</A>
<UL> 10.1 <A HREF = "Section_modify.html#mod_1">Atom styles</A>
<BR>
10.2 <A HREF = "Section_modify.html#mod_2">Bond, angle, dihedral, improper potentials</A>
<BR>
10.3 <A HREF = "Section_modify.html#mod_3">Compute styles</A>
<BR>
10.4 <A HREF = "Section_modify.html#mod_4">Dump styles</A>
<BR>
10.5 <A HREF = "Section_modify.html#mod_5">Dump custom output options</A>
<BR>
10.6 <A HREF = "Section_modify.html#mod_6">Fix styles</A>
<BR>
10.7 <A HREF = "Section_modify.html#mod_7">Input script commands</A>
<BR>
10.8 <A HREF = "Section_modify.html#mod_8">Kspace computations</A>
<BR>
10.9 <A HREF = "Section_modify.html#mod_9">Minimization styles</A>
<BR>
10.10 <A HREF = "Section_modify.html#mod_10">Pairwise potentials</A>
<BR>
10.11 <A HREF = "Section_modify.html#mod_11">Region styles</A>
<BR>
10.12 <A HREF = "Section_modify.html#mod_12">Thermodynamic output options</A>
<BR>
10.13 <A HREF = "Section_modify.html#mod_13">Variable options</A>
<BR>
10.14 <A HREF = "Section_modify.html#mod_14">Submitting new features for inclusion in LAMMPS</A>
<BR></UL>
<LI><A HREF = "Section_python.html">Python interface</A>
-<UL> 11.1 <A HREF = "Section_python.html#py_1">Extending Python with a serial version of LAMMPS</A>
-<BR>
- 11.2 <A HREF = "Section_python.html#py_2">Creating a shared MPI library</A>
+<UL> 11.1 <A HREF = "Section_python.html#py_1">Building LAMMPS as a shared library</A>
<BR>
- 11.3 <A HREF = "Section_python.html#py_3">Extending Python with a parallel version of LAMMPS</A>
+ 11.2 <A HREF = "Section_python.html#py_2">Installing the Python wrapper into Python</A>
<BR>
- 11.4 <A HREF = "Section_python.html#py_4">Extending Python with MPI</A>
+ 11.3 <A HREF = "Section_python.html#py_3">Extending Python with MPI to run in parallel</A>
<BR>
- 11.5 <A HREF = "Section_python.html#py_5">Testing the Python-LAMMPS interface</A>
+ 11.4 <A HREF = "Section_python.html#py_4">Testing the Python-LAMMPS interface</A>
<BR>
- 11.6 <A HREF = "Section_python.html#py_6">Using LAMMPS from Python</A>
+ 11.5 <A HREF = "Section_python.html#py_5">Using LAMMPS from Python</A>
<BR>
- 11.7 <A HREF = "Section_python.html#py_7">Example Python scripts that use LAMMPS</A>
+ 11.6 <A HREF = "Section_python.html#py_6">Example Python scripts that use LAMMPS</A>
<BR></UL>
<LI><A HREF = "Section_errors.html">Errors</A>
<UL> 12.1 <A HREF = "Section_errors.html#err_1">Common problems</A>
<BR>
12.2 <A HREF = "Section_errors.html#err_2">Reporting bugs</A>
<BR>
12.3 <A HREF = "Section_errors.html#err_3">Error & warning messages</A>
<BR></UL>
<LI><A HREF = "Section_history.html">Future and history</A>
<UL> 13.1 <A HREF = "Section_history.html#hist_1">Coming attractions</A>
<BR>
13.2 <A HREF = "Section_history.html#hist_2">Past versions</A>
<BR></UL>
</OL>
</BODY>
</HTML>
diff --git a/doc/Manual.txt b/doc/Manual.txt
index 67147e167..e17ffd770 100644
--- a/doc/Manual.txt
+++ b/doc/Manual.txt
@@ -1,258 +1,258 @@
<HEAD>
<TITLE>LAMMPS Users Manual</TITLE>
<META NAME="docnumber" CONTENT="24 Jan 2013 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>
<BODY>
"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
<H1></H1>
LAMMPS Documentation :c,h3
27 Jan 2013 version :c,h4
Version info: :h4
The LAMMPS "version" is the date when it was released, such as 1 May
2010. LAMMPS is updated continuously. Whenever we fix a bug or add a
feature, we release it immediately, and post a notice on "this page of
the WWW site"_bug. Each dated copy of LAMMPS contains all the
features and bug-fixes up to and including that version date. The
version date is printed to the screen and logfile every time you run
LAMMPS. It is also in the file src/version.h and in the LAMMPS
directory name created when you unpack a tarball, and at the top of
the first page of the manual (this page).
If you browse the HTML doc pages on the LAMMPS WWW site, they always
describe the most current version of LAMMPS. :ulb,l
If you browse the HTML doc pages included in your tarball, they
describe the version you have. :l
The "PDF file"_Manual.pdf on the WWW site or in the tarball is updated
about once per month. This is because it is large, and we don't want
it to be part of every patch. :l
There is also a "Developer.pdf"_Developer.pdf file in the doc
directory, which describes the internal structure and algorithms of
LAMMPS. :ule,l
LAMMPS stands for Large-scale Atomic/Molecular Massively Parallel
Simulator.
LAMMPS is a classical molecular dynamics simulation code designed to
run efficiently on parallel computers. It was developed at Sandia
National Laboratories, a US Department of Energy facility, with
funding from the DOE. It is an open-source code, distributed freely
under the terms of the GNU Public License (GPL).
The primary developers of LAMMPS are "Steve Plimpton"_sjp, Aidan
Thompson, and Paul Crozier who can be contacted at
sjplimp,athomps,pscrozi at sandia.gov. The "LAMMPS WWW Site"_lws at
http://lammps.sandia.gov has more information about the code and its
uses.
:link(bug,http://lammps.sandia.gov/bug.html)
:link(sjp,http://www.sandia.gov/~sjplimp)
:line
The LAMMPS documentation is organized into the following sections. If
you find errors or omissions in this manual or have suggestions for
useful information to add, please send an email to the developers so
we can improve the LAMMPS documentation.
Once you are familiar with LAMMPS, you may want to bookmark "this
page"_Section_commands.html#comm at Section_commands.html#comm since
it gives quick access to documentation for all LAMMPS commands.
"PDF file"_Manual.pdf of the entire manual, generated by
"htmldoc"_http://www.easysw.com/htmldoc
"Introduction"_Section_intro.html :olb,l
1.1 "What is LAMMPS"_intro_1 :ulb,b
1.2 "LAMMPS features"_intro_2 :b
1.3 "LAMMPS non-features"_intro_3 :b
1.4 "Open source distribution"_intro_4 :b
1.5 "Acknowledgments and citations"_intro_5 :ule,b
"Getting started"_Section_start.html :l
2.1 "What's in the LAMMPS distribution"_start_1 :ulb,b
2.2 "Making LAMMPS"_start_2 :b
2.3 "Making LAMMPS with optional packages"_start_3 :b
2.4 "Building LAMMPS via the Make.py script"_start_4 :b
2.5 "Building LAMMPS as a library"_start_5 :b
2.6 "Running LAMMPS"_start_6 :b
2.7 "Command-line options"_start_7 :b
2.8 "Screen output"_start_8 :b
2.9 "Tips for users of previous versions"_start_9 :ule,b
"Commands"_Section_commands.html :l
3.1 "LAMMPS input script"_cmd_1 :ulb,b
3.2 "Parsing rules"_cmd_2 :b
3.3 "Input script structure"_cmd_3 :b
3.4 "Commands listed by category"_cmd_4 :b
3.5 "Commands listed alphabetically"_cmd_5 :ule,b
"Packages"_Section_packages.html :l
4.1 "Standard packages"_pkg_1 :ulb,b
4.2 "User packages"_pkg_2 :ule,b
"Accelerating LAMMPS performance"_Section_accelerate.html :l
5.1 "Measuring performance"_acc_1 :ulb,b
5.2 "General strategies"_acc_2 :b
5.3 "Packages with optimized styles"_acc_3 :b
5.4 "OPT package"_acc_4 :b
5.5 "USER-OMP package"_acc_5 :b
5.6 "GPU package"_acc_6 :b
5.7 "USER-CUDA package"_acc_7 :b
5.8 "Comparison of GPU and USER-CUDA packages"_acc_8 :ule,b
"How-to discussions"_Section_howto.html :l
6.1 "Restarting a simulation"_howto_1 :ulb,b
6.2 "2d simulations"_howto_2 :b
6.3 "CHARMM and AMBER force fields"_howto_3 :b
6.4 "Running multiple simulations from one input script"_howto_4 :b
6.5 "Multi-replica simulations"_howto_5 :b
6.6 "Granular models"_howto_6 :b
6.7 "TIP3P water model"_howto_7 :b
6.8 "TIP4P water model"_howto_8 :b
6.9 "SPC water model"_howto_9 :b
6.10 "Coupling LAMMPS to other codes"_howto_10 :b
6.11 "Visualizing LAMMPS snapshots"_howto_11 :b
6.12 "Triclinic (non-orthogonal) simulation boxes"_howto_12 :b
6.13 "NEMD simulations"_howto_13 :b
6.14 "Extended spherical and aspherical particles"_howto_14 :b
6.15 "Output from LAMMPS (thermo, dumps, computes, fixes, variables)"_howto_15 :b
6.16 "Thermostatting, barostatting, and compute temperature"_howto_16 :b
6.17 "Walls"_howto_17 :b
6.18 "Elastic constants"_howto_18 :b
6.19 "Library interface to LAMMPS"_howto_19 :b
6.20 "Calculating thermal conductivity"_howto_20 :b
- 6.21 "Calculating viscosity"_howto_21 :ule,b
+ 6.21 "Calculating viscosity"_howto_21 :b
+ 6.22 "Body particles"_howto_22 :ule,b
"Example problems"_Section_example.html :l
"Performance & scalability"_Section_perf.html :l
"Additional tools"_Section_tools.html :l
"Modifying & extending LAMMPS"_Section_modify.html :l
10.1 "Atom styles"_mod_1 :ulb,b
10.2 "Bond, angle, dihedral, improper potentials"_mod_2 :b
10.3 "Compute styles"_mod_3 :b
10.4 "Dump styles"_mod_4 :b
10.5 "Dump custom output options"_mod_5 :b
10.6 "Fix styles"_mod_6 :b
10.7 "Input script commands"_mod_7 :b
10.8 "Kspace computations"_mod_8 :b
10.9 "Minimization styles"_mod_9 :b
10.10 "Pairwise potentials"_mod_10 :b
10.11 "Region styles"_mod_11 :b
10.12 "Thermodynamic output options"_mod_12 :b
10.13 "Variable options"_mod_13 :b
10.14 "Submitting new features for inclusion in LAMMPS"_mod_14 :ule,b
"Python interface"_Section_python.html :l
- 11.1 "Extending Python with a serial version of LAMMPS"_py_1 :ulb,b
- 11.2 "Creating a shared MPI library"_py_2 :b
- 11.3 "Extending Python with a parallel version of LAMMPS"_py_3 :b
- 11.4 "Extending Python with MPI"_py_4 :b
- 11.5 "Testing the Python-LAMMPS interface"_py_5 :b
- 11.6 "Using LAMMPS from Python"_py_6 :b
- 11.7 "Example Python scripts that use LAMMPS"_py_7 :ule,b
+ 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
"Errors"_Section_errors.html :l
12.1 "Common problems"_err_1 :ulb,b
12.2 "Reporting bugs"_err_2 :b
12.3 "Error & warning messages"_err_3 :ule,b
"Future and history"_Section_history.html :l
13.1 "Coming attractions"_hist_1 :ulb,b
13.2 "Past versions"_hist_2 :ule,b
:ole
:link(intro_1,Section_intro.html#intro_1)
:link(intro_2,Section_intro.html#intro_2)
:link(intro_3,Section_intro.html#intro_3)
:link(intro_4,Section_intro.html#intro_4)
:link(intro_5,Section_intro.html#intro_5)
:link(start_1,Section_start.html#start_1)
:link(start_2,Section_start.html#start_2)
:link(start_3,Section_start.html#start_3)
:link(start_4,Section_start.html#start_4)
:link(start_5,Section_start.html#start_5)
:link(start_6,Section_start.html#start_6)
:link(start_7,Section_start.html#start_7)
:link(start_8,Section_start.html#start_8)
:link(start_9,Section_start.html#start_9)
:link(cmd_1,Section_commands.html#cmd_1)
:link(cmd_2,Section_commands.html#cmd_2)
:link(cmd_3,Section_commands.html#cmd_3)
:link(cmd_4,Section_commands.html#cmd_4)
:link(cmd_5,Section_commands.html#cmd_5)
:link(pkg_1,Section_packages.html#pkg_1)
:link(pkg_2,Section_packages.html#pkg_2)
:link(acc_1,Section_accelerate.html#acc_1)
:link(acc_2,Section_accelerate.html#acc_2)
:link(acc_3,Section_accelerate.html#acc_3)
:link(acc_4,Section_accelerate.html#acc_4)
:link(acc_5,Section_accelerate.html#acc_5)
:link(acc_6,Section_accelerate.html#acc_6)
:link(acc_7,Section_accelerate.html#acc_7)
:link(acc_8,Section_accelerate.html#acc_8)
:link(howto_1,Section_howto.html#howto_1)
:link(howto_2,Section_howto.html#howto_2)
:link(howto_3,Section_howto.html#howto_3)
:link(howto_4,Section_howto.html#howto_4)
:link(howto_5,Section_howto.html#howto_5)
:link(howto_6,Section_howto.html#howto_6)
:link(howto_7,Section_howto.html#howto_7)
:link(howto_8,Section_howto.html#howto_8)
:link(howto_9,Section_howto.html#howto_9)
:link(howto_10,Section_howto.html#howto_10)
:link(howto_11,Section_howto.html#howto_11)
:link(howto_12,Section_howto.html#howto_12)
:link(howto_13,Section_howto.html#howto_13)
:link(howto_14,Section_howto.html#howto_14)
:link(howto_15,Section_howto.html#howto_15)
:link(howto_16,Section_howto.html#howto_16)
:link(howto_17,Section_howto.html#howto_17)
:link(howto_18,Section_howto.html#howto_18)
:link(howto_19,Section_howto.html#howto_19)
:link(howto_20,Section_howto.html#howto_20)
:link(howto_21,Section_howto.html#howto_21)
+:link(howto_22,Section_howto.html#howto_22)
:link(mod_1,Section_modify.html#mod_1)
:link(mod_2,Section_modify.html#mod_2)
:link(mod_3,Section_modify.html#mod_3)
:link(mod_4,Section_modify.html#mod_4)
:link(mod_5,Section_modify.html#mod_5)
:link(mod_6,Section_modify.html#mod_6)
:link(mod_7,Section_modify.html#mod_7)
:link(mod_8,Section_modify.html#mod_8)
:link(mod_9,Section_modify.html#mod_9)
:link(mod_10,Section_modify.html#mod_10)
:link(mod_11,Section_modify.html#mod_11)
:link(mod_12,Section_modify.html#mod_12)
:link(mod_13,Section_modify.html#mod_13)
:link(mod_14,Section_modify.html#mod_14)
:link(py_1,Section_python.html#py_1)
:link(py_2,Section_python.html#py_2)
:link(py_3,Section_python.html#py_3)
:link(py_4,Section_python.html#py_4)
:link(py_5,Section_python.html#py_5)
:link(py_6,Section_python.html#py_6)
-:link(py_7,Section_python.html#py_7)
:link(err_1,Section_errors.html#err_1)
:link(err_2,Section_errors.html#err_2)
:link(err_3,Section_errors.html#err_3)
:link(hist_1,Section_history.html#hist_1)
:link(hist_2,Section_history.html#hist_2)
</BODY>
diff --git a/doc/compute_angle_local.html b/doc/compute_angle_local.html
index 772388db4..60ba03541 100644
--- a/doc/compute_angle_local.html
+++ b/doc/compute_angle_local.html
@@ -1,86 +1,87 @@
<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 angle/local command
</H3>
<P><B>Syntax:</B>
</P>
<PRE>compute ID group-ID angle/local input1 input2 ...
</PRE>
<UL><LI>ID, group-ID are documented in <A HREF = "compute.html">compute</A> command
<LI>angle/local = style name of this compute command
-<LI>zero or more keywords may be appended
+<LI>one or more keywords may be appended
<LI>keyword = <I>theta</I> or <I>eng</I>
<PRE> <I>theta</I> = tabulate angles
<I>eng</I> = tabulate angle energies
</PRE>
</UL>
<P><B>Examples:</B>
</P>
<PRE>compute 1 all angle/local theta
compute 1 all angle/local eng theta
</PRE>
<P><B>Description:</B>
</P>
<P>Define a computation that calculates properties of individual angle
interactions. The number of datums generated, aggregated across all
-processors, equals the number of angles in the system.
+processors, equals the number of angles in the system, modified by the
+group parameter as explained below.
</P>
<P>The local data stored by this command is generated by looping over all
the atoms owned on a processor and their angles. An angle will only
be included if all 3 atoms in the angle are in the specified compute
group. Any angles that have been broken (see the
<A HREF = "angle_style.html">angle_style</A> command) by setting their angle type to
0 are not included. Angles that have been turned off (see the <A HREF = "fix_shake.html">fix
shake</A> or <A HREF = "delete_bonds.html">delete_bonds</A> commands) by
setting their angle type negative are written into the file, but their
energy will be 0.0.
</P>
<P>Note that as atoms migrate from processor to processor, there will be
no consistent ordering of the entries within the local vector or array
from one timestep to the next. The only consistency that is
guaranteed is that the ordering on a particular timestep will be the
same for local vectors or arrays generated by other compute commands.
For example, angle output from the <A HREF = "compute_property_local.html">compute
property/local</A> command can be combined
with data from this command and output by the <A HREF = "dump.html">dump local</A>
command in a consistent way.
</P>
<P><B>Output info:</B>
</P>
<P>This compute calculates a local vector or local array depending on the
number of keywords. The length of the vector or number of rows in the
array is the number of angles. If a single keyword is specified, a
local vector is produced. If two or more keywords are specified, a
local array is produced where the number of columns = the number of
keywords. The vector or array can be accessed by any command that
uses local 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>The output for <I>theta</I> will be in degrees. The output for <I>eng</I> will
be in energy <A HREF = "units.html">units</A>.
</P>
<P><B>Restrictions:</B> none
</P>
<P><B>Related commands:</B>
</P>
<P><A HREF = "dump.html">dump local</A>, <A HREF = "compute_property_local.html">compute
property/local</A>
</P>
<P><B>Default:</B> none
</P>
</HTML>
diff --git a/doc/compute_angle_local.txt b/doc/compute_angle_local.txt
index 253a78e8f..0f31292e4 100644
--- a/doc/compute_angle_local.txt
+++ b/doc/compute_angle_local.txt
@@ -1,76 +1,77 @@
"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 angle/local command :h3
[Syntax:]
compute ID group-ID angle/local input1 input2 ... :pre
ID, group-ID are documented in "compute"_compute.html command :ulb,l
angle/local = style name of this compute command :l
-zero or more keywords may be appended :l
+one or more keywords may be appended :l
keyword = {theta} or {eng} :l
{theta} = tabulate angles
{eng} = tabulate angle energies :pre
:ule
[Examples:]
compute 1 all angle/local theta
compute 1 all angle/local eng theta :pre
[Description:]
Define a computation that calculates properties of individual angle
interactions. The number of datums generated, aggregated across all
-processors, equals the number of angles in the system.
+processors, equals the number of angles in the system, modified by the
+group parameter as explained below.
The local data stored by this command is generated by looping over all
the atoms owned on a processor and their angles. An angle will only
be included if all 3 atoms in the angle are in the specified compute
group. Any angles that have been broken (see the
"angle_style"_angle_style.html command) by setting their angle type to
0 are not included. Angles that have been turned off (see the "fix
shake"_fix_shake.html or "delete_bonds"_delete_bonds.html commands) by
setting their angle type negative are written into the file, but their
energy will be 0.0.
Note that as atoms migrate from processor to processor, there will be
no consistent ordering of the entries within the local vector or array
from one timestep to the next. The only consistency that is
guaranteed is that the ordering on a particular timestep will be the
same for local vectors or arrays generated by other compute commands.
For example, angle output from the "compute
property/local"_compute_property_local.html command can be combined
with data from this command and output by the "dump local"_dump.html
command in a consistent way.
[Output info:]
This compute calculates a local vector or local array depending on the
number of keywords. The length of the vector or number of rows in the
array is the number of angles. If a single keyword is specified, a
local vector is produced. If two or more keywords are specified, a
local array is produced where the number of columns = the number of
keywords. The vector or array can be accessed by any command that
uses local values from a compute as input. See "this
section"_Section_howto.html#howto_15 for an overview of LAMMPS output
options.
The output for {theta} will be in degrees. The output for {eng} will
be in energy "units"_units.html.
[Restrictions:] none
[Related commands:]
"dump local"_dump.html, "compute
property/local"_compute_property_local.html
[Default:] none
diff --git a/doc/compute_body_local.html b/doc/compute_body_local.html
new file mode 100644
index 000000000..bf79d80d5
--- /dev/null
+++ b/doc/compute_body_local.html
@@ -0,0 +1,98 @@
+<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 body/local command
+</H3>
+<P><B>Syntax:</B>
+</P>
+<PRE>compute ID group-ID body/local input1 input2 ...
+</PRE>
+<UL><LI>ID, group-ID are documented in <A HREF = "compute.html">compute</A> command
+
+<LI>body/local = style name of this compute command
+
+<LI>one or more keywords may be appended
+
+<LI>keyword = <I>type</I> or <I>integer</I>
+
+<PRE> <I>type</I> = atom type of the body particle
+ <I>integer</I> = 1,2,3,etc = index of fields defined by body style
+</PRE>
+
+</UL>
+<P><B>Examples:</B>
+</P>
+<PRE>compute 1 all body/local type 1 2 3
+compute 1 all body/local 3 6
+</PRE>
+<P><B>Description:</B>
+</P>
+<P>Define a computation that calculates properties of individual body
+sub-particles. The number of datums generated, aggregated across all
+processors, equals the number of body sub-particles plus the number of
+non-body particles in the system, modified by the group parameter as
+explained below. See <A HREF = "Section_howto.html">Section_howto 22</A> of the
+manual for an overview of using body particles.
+</P>
+<P>The local data stored by this command is generated by looping over all
+the atoms. An atom will only be included if it is in the group. If
+the atom is a body particle, then its N sub-particles will be looped
+over, and it will contribute N datums to the count of datums. If it
+is not a body particle, it will contribute 1 datum.
+</P>
+<P>For both body particles and non-body particles, the <I>type</I> keyword
+will store the type of the atom.
+</P>
+<P>The <I>integer</I> keywords mean different things for body and non-body
+particles. If the atom is not a body particle, only its <I>x</I>, <I>y</I>, <I>z</I>
+coordinates can be referenced, using the <I>integer</I> keywords 1,2,3.
+Note that this means that if you want to access more fields than this
+for body particles, then you cannot include non-body particles in the
+group.
+</P>
+<P>For a body particle, the <I>integer</I> keywords refer to fields calculated
+by the body style for each sub-particle. The body style, as specified
+by the <A HREF = "atom_style.html">atom_style body</A>, determines how many fields
+exist and what they are. See the <A HREF = "body.html">body</A> doc page for
+details of the different styles.
+</P>
+<P>Here is an example of how to output body information using the <A HREF = "dump.html">dump
+local</A> command with this compute. If fields 1,2,3 for the
+body sub-particles are x,y,z coordinates, then the dump file will be
+formatted similar to the output of a <A HREF = "dump.html">dump atom or custom</A>
+command.
+</P>
+<PRE>compute 1 all body/local type 1 2 3
+dump 1 all local 1000 tmp.dump index c_1[1] c_1[2] c_1[3] c_1[4]
+</PRE>
+<P><B>Output info:</B>
+</P>
+<P>This compute calculates a local vector or local array depending on the
+number of keywords. The length of the vector or number of rows in the
+array is the number of datums as described above. If a single keyword
+is specified, a local vector is produced. If two or more keywords are
+specified, a local array is produced where the number of columns = the
+number of keywords. The vector or array can be accessed by any
+command that uses local 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>The <A HREF = "units.html">units</A> for output values depend on the body style.
+</P>
+<P><B>Restrictions:</B> none
+</P>
+<P><B>Related commands:</B>
+</P>
+<P><A HREF = "dump.html">dump local</A>
+</P>
+<P><B>Default:</B> none
+</P>
+</HTML>
diff --git a/doc/compute_body_local.txt b/doc/compute_body_local.txt
new file mode 100644
index 000000000..c7d6b9fe9
--- /dev/null
+++ b/doc/compute_body_local.txt
@@ -0,0 +1,88 @@
+"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 body/local command :h3
+
+[Syntax:]
+
+compute ID group-ID body/local input1 input2 ... :pre
+
+ID, group-ID are documented in "compute"_compute.html command :ulb,l
+body/local = style name of this compute command :l
+one or more keywords may be appended :l
+keyword = {type} or {integer} :l
+ {type} = atom type of the body particle
+ {integer} = 1,2,3,etc = index of fields defined by body style :pre
+:ule
+
+[Examples:]
+
+compute 1 all body/local type 1 2 3
+compute 1 all body/local 3 6 :pre
+
+[Description:]
+
+Define a computation that calculates properties of individual body
+sub-particles. The number of datums generated, aggregated across all
+processors, equals the number of body sub-particles plus the number of
+non-body particles in the system, modified by the group parameter as
+explained below. See "Section_howto 22"_Section_howto.html of the
+manual for an overview of using body particles.
+
+The local data stored by this command is generated by looping over all
+the atoms. An atom will only be included if it is in the group. If
+the atom is a body particle, then its N sub-particles will be looped
+over, and it will contribute N datums to the count of datums. If it
+is not a body particle, it will contribute 1 datum.
+
+For both body particles and non-body particles, the {type} keyword
+will store the type of the atom.
+
+The {integer} keywords mean different things for body and non-body
+particles. If the atom is not a body particle, only its {x}, {y}, {z}
+coordinates can be referenced, using the {integer} keywords 1,2,3.
+Note that this means that if you want to access more fields than this
+for body particles, then you cannot include non-body particles in the
+group.
+
+For a body particle, the {integer} keywords refer to fields calculated
+by the body style for each sub-particle. The body style, as specified
+by the "atom_style body"_atom_style.html, determines how many fields
+exist and what they are. See the "body"_body.html doc page for
+details of the different styles.
+
+Here is an example of how to output body information using the "dump
+local"_dump.html command with this compute. If fields 1,2,3 for the
+body sub-particles are x,y,z coordinates, then the dump file will be
+formatted similar to the output of a "dump atom or custom"_dump.html
+command.
+
+compute 1 all body/local type 1 2 3
+dump 1 all local 1000 tmp.dump index c_1\[1\] c_1\[2\] c_1\[3\] c_1\[4\] :pre
+
+[Output info:]
+
+This compute calculates a local vector or local array depending on the
+number of keywords. The length of the vector or number of rows in the
+array is the number of datums as described above. If a single keyword
+is specified, a local vector is produced. If two or more keywords are
+specified, a local array is produced where the number of columns = the
+number of keywords. The vector or array can be accessed by any
+command that uses local values from a compute as input. See "this
+section"_Section_howto.html#howto_15 for an overview of LAMMPS output
+options.
+
+The "units"_units.html for output values depend on the body style.
+
+[Restrictions:] none
+
+[Related commands:]
+
+"dump local"_dump.html
+
+[Default:] none
diff --git a/doc/compute_bond_local.html b/doc/compute_bond_local.html
index 026cd877a..7462ad1da 100644
--- a/doc/compute_bond_local.html
+++ b/doc/compute_bond_local.html
@@ -1,91 +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 bond/local command
</H3>
<P><B>Syntax:</B>
</P>
<PRE>compute ID group-ID bond/local input1 input2 ...
</PRE>
<UL><LI>ID, group-ID are documented in <A HREF = "compute.html">compute</A> command
<LI>bond/local = style name of this compute command
-<LI>zero or more keywords may be appended
+<LI>one or more keywords may be appended
<LI>keyword = <I>dist</I> or <I>eng</I>
<PRE> <I>dist</I> = tabulate bond distances
<I>eng</I> = tablutate bond energies
</PRE>
</UL>
<P><B>Examples:</B>
</P>
<PRE>compute 1 all bond/local eng
compute 1 all bond/local dist eng
</PRE>
<P><B>Description:</B>
</P>
<P>Define a computation that calculates properties of individual bond
interactions. The number of datums generated, aggregated across all
-processors, equals the number of bonds in the system.
+processors, equals the number of bonds in the system, modified
+by the group parameter as explained below.
</P>
<P>The local data stored by this command is generated by looping over all
the atoms owned on a processor and their bonds. A bond will only be
included if both atoms in the bond are in the specified compute group.
Any bonds that have been broken (see the <A HREF = "bond_style.html">bond_style</A>
command) by setting their bond type to 0 are not included. Bonds that
have been turned off (see the <A HREF = "fix_shake.html">fix shake</A> or
<A HREF = "delete_bonds.html">delete_bonds</A> commands) by setting their bond type
negative are written into the file, but their energy will be 0.0.
</P>
<P>Note that as atoms migrate from processor to processor, there will be
no consistent ordering of the entries within the local vector or array
from one timestep to the next. The only consistency that is
guaranteed is that the ordering on a particular timestep will be the
same for local vectors or arrays generated by other compute commands.
For example, bond output from the <A HREF = "compute_property_local.html">compute
property/local</A> command can be combined
with data from this command and output by the <A HREF = "dump.html">dump local</A>
command in a consistent way.
</P>
<P>Here is an example of how to do this:
</P>
<PRE>compute 1 all property/local batom1 batom2 btype
compute 2 all bond/local dist eng
dump 1 all local 1000 tmp.dump index c_1[1] c_1[2] c_1[3] c_2[1] c_2[2]
</PRE>
<P><B>Output info:</B>
</P>
<P>This compute calculates a local vector or local array depending on the
number of keywords. The length of the vector or number of rows in the
array is the number of bonds. If a single keyword is specified, a
local vector is produced. If two or more keywords are specified, a
local array is produced where the number of columns = the number of
keywords. The vector or array can be accessed by any command that
uses local 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>The output for <I>dist</I> will be in distance <A HREF = "units.html">units</A>. The
output for <I>eng</I> will be in energy <A HREF = "units.html">units</A>.
</P>
<P><B>Restrictions:</B> none
</P>
<P><B>Related commands:</B>
</P>
<P><A HREF = "dump.html">dump local</A>, <A HREF = "compute_property_local.html">compute
property/local</A>
</P>
<P><B>Default:</B> none
</P>
</HTML>
diff --git a/doc/compute_bond_local.txt b/doc/compute_bond_local.txt
index 42dcf17cd..ba01dedb8 100644
--- a/doc/compute_bond_local.txt
+++ b/doc/compute_bond_local.txt
@@ -1,81 +1,82 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
compute bond/local command :h3
[Syntax:]
compute ID group-ID bond/local input1 input2 ... :pre
ID, group-ID are documented in "compute"_compute.html command :ulb,l
bond/local = style name of this compute command :l
-zero or more keywords may be appended :l
+one or more keywords may be appended :l
keyword = {dist} or {eng} :l
{dist} = tabulate bond distances
{eng} = tablutate bond energies :pre
:ule
[Examples:]
compute 1 all bond/local eng
compute 1 all bond/local dist eng :pre
[Description:]
Define a computation that calculates properties of individual bond
interactions. The number of datums generated, aggregated across all
-processors, equals the number of bonds in the system.
+processors, equals the number of bonds in the system, modified
+by the group parameter as explained below.
The local data stored by this command is generated by looping over all
the atoms owned on a processor and their bonds. A bond will only be
included if both atoms in the bond are in the specified compute group.
Any bonds that have been broken (see the "bond_style"_bond_style.html
command) by setting their bond type to 0 are not included. Bonds that
have been turned off (see the "fix shake"_fix_shake.html or
"delete_bonds"_delete_bonds.html commands) by setting their bond type
negative are written into the file, but their energy will be 0.0.
Note that as atoms migrate from processor to processor, there will be
no consistent ordering of the entries within the local vector or array
from one timestep to the next. The only consistency that is
guaranteed is that the ordering on a particular timestep will be the
same for local vectors or arrays generated by other compute commands.
For example, bond output from the "compute
property/local"_compute_property_local.html command can be combined
with data from this command and output by the "dump local"_dump.html
command in a consistent way.
Here is an example of how to do this:
compute 1 all property/local batom1 batom2 btype
compute 2 all bond/local dist eng
dump 1 all local 1000 tmp.dump index c_1\[1\] c_1\[2\] c_1\[3\] c_2\[1\] c_2\[2\] :pre
[Output info:]
This compute calculates a local vector or local array depending on the
number of keywords. The length of the vector or number of rows in the
array is the number of bonds. If a single keyword is specified, a
local vector is produced. If two or more keywords are specified, a
local array is produced where the number of columns = the number of
keywords. The vector or array can be accessed by any command that
uses local values from a compute as input. See "this
section"_Section_howto.html#howto_15 for an overview of LAMMPS output
options.
The output for {dist} will be in distance "units"_units.html. The
output for {eng} will be in energy "units"_units.html.
[Restrictions:] none
[Related commands:]
"dump local"_dump.html, "compute
property/local"_compute_property_local.html
[Default:] none
diff --git a/doc/compute_dihedral_local.html b/doc/compute_dihedral_local.html
index e1f9cf13b..b8d4bb567 100644
--- a/doc/compute_dihedral_local.html
+++ b/doc/compute_dihedral_local.html
@@ -1,78 +1,79 @@
<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 dihedral/local command
</H3>
<P><B>Syntax:</B>
</P>
<PRE>compute ID group-ID dihedral/local input1 input2 ...
</PRE>
<UL><LI>ID, group-ID are documented in <A HREF = "compute.html">compute</A> command
<LI>dihedral/local = style name of this compute command
-<LI>zero or more keywords may be appended
+<LI>one or more keywords may be appended
<LI>keyword = <I>phi</I>
<PRE> <I>phi</I> = tabulate dihedral angles
</PRE>
</UL>
<P><B>Examples:</B>
</P>
<PRE>compute 1 all dihedral/local phi
</PRE>
<P><B>Description:</B>
</P>
<P>Define a computation that calculates properties of individual dihedral
interactions. The number of datums generated, aggregated across all
-processors, equals the number of angles in the system.
+processors, equals the number of angles in the system, modified by the
+group parameter as explained below.
</P>
<P>The local data stored by this command is generated by looping over all
the atoms owned on a processor and their dihedrals. A dihedral will
only be included if all 4 atoms in the dihedral are in the specified
compute group.
</P>
<P>Note that as atoms migrate from processor to processor, there will be
no consistent ordering of the entries within the local vector or array
from one timestep to the next. The only consistency that is
guaranteed is that the ordering on a particular timestep will be the
same for local vectors or arrays generated by other compute commands.
For example, dihedral output from the <A HREF = "compute_property_local.html">compute
property/local</A> command can be combined
with data from this command and output by the <A HREF = "dump.html">dump local</A>
command in a consistent way.
</P>
<P><B>Output info:</B>
</P>
<P>This compute calculates a local vector or local array depending on the
number of keywords. The length of the vector or number of rows in the
array is the number of dihedrals. If a single keyword is specified, a
local vector is produced. If two or more keywords are specified, a
local array is produced where the number of columns = the number of
keywords. The vector or array can be accessed by any command that
uses local 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>The output for <I>phi</I> will be in degrees.
</P>
<P><B>Restrictions:</B> none
</P>
<P><B>Related commands:</B>
</P>
<P><A HREF = "dump.html">dump local</A>, <A HREF = "compute_property_local.html">compute
property/local</A>
</P>
<P><B>Default:</B> none
</P>
</HTML>
diff --git a/doc/compute_dihedral_local.txt b/doc/compute_dihedral_local.txt
index 0bc32936f..b8e79fff4 100644
--- a/doc/compute_dihedral_local.txt
+++ b/doc/compute_dihedral_local.txt
@@ -1,68 +1,69 @@
"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 dihedral/local command :h3
[Syntax:]
compute ID group-ID dihedral/local input1 input2 ... :pre
ID, group-ID are documented in "compute"_compute.html command :ulb,l
dihedral/local = style name of this compute command :l
-zero or more keywords may be appended :l
+one or more keywords may be appended :l
keyword = {phi} :l
{phi} = tabulate dihedral angles :pre
:ule
[Examples:]
compute 1 all dihedral/local phi :pre
[Description:]
Define a computation that calculates properties of individual dihedral
interactions. The number of datums generated, aggregated across all
-processors, equals the number of angles in the system.
+processors, equals the number of angles in the system, modified by the
+group parameter as explained below.
The local data stored by this command is generated by looping over all
the atoms owned on a processor and their dihedrals. A dihedral will
only be included if all 4 atoms in the dihedral are in the specified
compute group.
Note that as atoms migrate from processor to processor, there will be
no consistent ordering of the entries within the local vector or array
from one timestep to the next. The only consistency that is
guaranteed is that the ordering on a particular timestep will be the
same for local vectors or arrays generated by other compute commands.
For example, dihedral output from the "compute
property/local"_compute_property_local.html command can be combined
with data from this command and output by the "dump local"_dump.html
command in a consistent way.
[Output info:]
This compute calculates a local vector or local array depending on the
number of keywords. The length of the vector or number of rows in the
array is the number of dihedrals. If a single keyword is specified, a
local vector is produced. If two or more keywords are specified, a
local array is produced where the number of columns = the number of
keywords. The vector or array can be accessed by any command that
uses local values from a compute as input. See "this
section"_Section_howto.html#howto_15 for an overview of LAMMPS output
options.
The output for {phi} will be in degrees.
[Restrictions:] none
[Related commands:]
"dump local"_dump.html, "compute
property/local"_compute_property_local.html
[Default:] none
diff --git a/doc/compute_improper_local.html b/doc/compute_improper_local.html
index cf529f222..cdf58f1b6 100644
--- a/doc/compute_improper_local.html
+++ b/doc/compute_improper_local.html
@@ -1,78 +1,79 @@
<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 improper/local command
</H3>
<P><B>Syntax:</B>
</P>
<PRE>compute ID group-ID improper/local input1 input2 ...
</PRE>
<UL><LI>ID, group-ID are documented in <A HREF = "compute.html">compute</A> command
<LI>improper/local = style name of this compute command
-<LI>zero or more keywords may be appended
+<LI>one or more keywords may be appended
<LI>keyword = <I>chi</I>
<PRE> <I>chi</I> = tabulate improper angles
</PRE>
</UL>
<P><B>Examples:</B>
</P>
<PRE>compute 1 all improper/local chi
</PRE>
<P><B>Description:</B>
</P>
<P>Define a computation that calculates properties of individual improper
interactions. The number of datums generated, aggregated across all
-processors, equals the number of impropers in the system.
+processors, equals the number of impropers in the system, modified by
+the group parameter as explained below.
</P>
<P>The local data stored by this command is generated by looping over all
the atoms owned on a processor and their impropers. An improper will
only be included if all 4 atoms in the improper are in the specified
compute group.
</P>
<P>Note that as atoms migrate from processor to processor, there will be
no consistent ordering of the entries within the local vector or array
from one timestep to the next. The only consistency that is
guaranteed is that the ordering on a particular timestep will be the
same for local vectors or arrays generated by other compute commands.
For example, improper output from the <A HREF = "compute_property_local.html">compute
property/local</A> command can be combined
with data from this command and output by the <A HREF = "dump.html">dump local</A>
command in a consistent way.
</P>
<P><B>Output info:</B>
</P>
<P>This compute calculates a local vector or local array depending on the
number of keywords. The length of the vector or number of rows in the
array is the number of impropers. If a single keyword is specified, a
local vector is produced. If two or more keywords are specified, a
local array is produced where the number of columns = the number of
keywords. The vector or array can be accessed by any command that
uses local 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>The output for <I>chi</I> will be in degrees.
</P>
<P><B>Restrictions:</B> none
</P>
<P><B>Related commands:</B>
</P>
<P><A HREF = "dump.html">dump local</A>, <A HREF = "compute_property_local.html">compute
property/local</A>
</P>
<P><B>Default:</B> none
</P>
</HTML>
diff --git a/doc/compute_improper_local.txt b/doc/compute_improper_local.txt
index c227cb2b8..9289435da 100644
--- a/doc/compute_improper_local.txt
+++ b/doc/compute_improper_local.txt
@@ -1,68 +1,69 @@
"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 improper/local command :h3
[Syntax:]
compute ID group-ID improper/local input1 input2 ... :pre
ID, group-ID are documented in "compute"_compute.html command :ulb,l
improper/local = style name of this compute command :l
-zero or more keywords may be appended :l
+one or more keywords may be appended :l
keyword = {chi} :l
{chi} = tabulate improper angles :pre
:ule
[Examples:]
compute 1 all improper/local chi :pre
[Description:]
Define a computation that calculates properties of individual improper
interactions. The number of datums generated, aggregated across all
-processors, equals the number of impropers in the system.
+processors, equals the number of impropers in the system, modified by
+the group parameter as explained below.
The local data stored by this command is generated by looping over all
the atoms owned on a processor and their impropers. An improper will
only be included if all 4 atoms in the improper are in the specified
compute group.
Note that as atoms migrate from processor to processor, there will be
no consistent ordering of the entries within the local vector or array
from one timestep to the next. The only consistency that is
guaranteed is that the ordering on a particular timestep will be the
same for local vectors or arrays generated by other compute commands.
For example, improper output from the "compute
property/local"_compute_property_local.html command can be combined
with data from this command and output by the "dump local"_dump.html
command in a consistent way.
[Output info:]
This compute calculates a local vector or local array depending on the
number of keywords. The length of the vector or number of rows in the
array is the number of impropers. If a single keyword is specified, a
local vector is produced. If two or more keywords are specified, a
local array is produced where the number of columns = the number of
keywords. The vector or array can be accessed by any command that
uses local values from a compute as input. See "this
section"_Section_howto.html#howto_15 for an overview of LAMMPS output
options.
The output for {chi} will be in degrees.
[Restrictions:] none
[Related commands:]
"dump local"_dump.html, "compute
property/local"_compute_property_local.html
[Default:] none
diff --git a/doc/compute_property_atom.html b/doc/compute_property_atom.html
index 3adf2535d..76c95b701 100644
--- a/doc/compute_property_atom.html
+++ b/doc/compute_property_atom.html
@@ -1,134 +1,135 @@
<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 property/atom command
</H3>
<P><B>Syntax:</B>
</P>
<PRE>compute ID group-ID property/atom input1 input2 ...
</PRE>
<UL><LI>ID, group-ID are documented in <A HREF = "compute.html">compute</A> command
<LI>property/atom = style name of this compute command
<LI>input = one or more atom attributes
<PRE> possible attributes = id, mol, type, mass,
x, y, z, xs, ys, zs, xu, yu, zu, ix, iy, iz,
vx, vy, vz, fx, fy, fz,
q, mux, muy, muz, mu,
radius, diameter, omegax, omegay, omegaz,
angmomx, angmomy, angmomz,
shapex,shapey, shapez,
quatw, quati, quatj, quatk, tqx, tqy, tqz,
spin, eradius, ervel, erforce
end1x, end1y, end1z, end2x, end2y, end2z,
corner1x, corner1y, corner1z,
corner2x, corner2y, corner2z,
corner3x, corner3y, corner3z
</PRE>
<PRE> id = atom ID
mol = molecule ID
type = atom type
mass = atom mass
x,y,z = unscaled atom coordinates
xs,ys,zs = scaled atom coordinates
xu,yu,zu = unwrapped atom coordinates
ix,iy,iz = box image that the atom is in
vx,vy,vz = atom velocities
fx,fy,fz = forces on atoms
q = atom charge
mux,muy,muz = orientation of dipole moment of atom
mu = magnitude of dipole moment of atom
radius,diameter = radius,diameter of spherical particle
omegax,omegay,omegaz = angular velocity of extended particle
angmomx,angmomy,angmomz = angular momentum of extended particle
shapex,shapey,shapez = 3 diameters of aspherical particle
- quatw,quati,quatj,quatk = quaternion components for aspherical particles
+ quatw,quati,quatj,quatk = quaternion components for aspherical or body particles
tqx,tqy,tqz = torque on extended particles
spin = electron spin
eradius = electron radius
ervel = electron radial velocity
erforce = electron radial force
end12x, end12y, end12z = end points of line segment
coner123x, corner123y, corner123z = corner points of triangle
</PRE>
</UL>
<P><B>Examples:</B>
</P>
<PRE>compute 1 all property/atom xs vx fx mux
compute 2 all property/atom type
compute 1 all property/atom ix iy iz
</PRE>
<P><B>Description:</B>
</P>
<P>Define a computation that simply stores atom attributes for each atom
in the group. This is useful so that the values can be used by other
<A HREF = "Section_howto.html#howto_15">output commands</A> that take computes as
inputs. See for example, the <A HREF = "compute_reduce.html">compute reduce</A>,
<A HREF = "fix_ave_atom.html">fix ave/atom</A>, <A HREF = "fix_ave_histo.html">fix ave/histo</A>,
<A HREF = "fix_ave_spatial.html">fix ave/spatial</A>, and <A HREF = "variable.html">atom-style
variable</A> commands.
</P>
<P>The list of possible attributes is the same as that used by the <A HREF = "dump.html">dump
custom</A> command, which describes their meaning, with some
additional quantities that are only defined for certain <A HREF = "atom_style.html">atom
styles</A>. Basically, this list gives your input script
access to any per-atom quantity stored by LAMMPS.
</P>
<P>The values are stored in a per-atom vector or array as discussed
below. Zeroes are stored for atoms not in the specified group or for
quantities that are not defined for a particular particle in the group
(e.g. <I>shapex</I> if the particle is not an ellipsoid).
</P>
<P>The additional quantities only accessible via this command, and not
directly via the <A HREF = "dump.html">dump custom</A> command, are as follows.
</P>
<P><I>Shapex</I>, <I>shapey</I>, and <I>shapez</I> are defined for ellipsoidal particles
-and define the 3d shape of each particle. <I>Quatw</I>, <I>quati</I>, <I>quatj</I>,
-and <I>quatk</I> are also defined for ellipsoidal particles and store the
-4-vector quaternion representing the orientation of each particle.
-See the <A HREF = "set.html">set</A> command for an explanation of the quaternion
-vector.
+and define the 3d shape of each particle.
+</P>
+<P><I>Quatw</I>, <I>quati</I>, <I>quatj</I>, and <I>quatk</I> are defined for ellipsoidal
+particles and body particles and store the 4-vector quaternion
+representing the orientation of each particle. See the <A HREF = "set.html">set</A>
+command for an explanation of the quaternion vector.
</P>
<P><I>End1x</I>, <I>end1y</I>, <I>end1z</I>, <I>end2x</I>, <I>end2y</I>, <I>end2z</I>, are defined for
line segment particles and define the end points of each line segment.
</P>
<P><I>Corner1x</I>, <I>corner1y</I>, <I>corner1z</I>, <I>corner2x</I>, <I>corner2y</I>,
<I>corner2z</I>, <I>corner3x</I>, <I>corner3y</I>, <I>corner3z</I>, are defined for
triangular particles and define the corner points of each triangle.
</P>
<P><B>Output info:</B>
</P>
<P>This compute calculates a per-atom vector or per-atom array depending
on the number of input values. If a single input is specified, a
per-atom vector is produced. If two or more inputs are specified, a
per-atom array is produced where the number of columns = the number of
inputs. The vector or array can be accessed by any command that uses
per-atom 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>The vector or array values will be in whatever <A HREF = "units.html">units</A> the
corresponding attribute is in, e.g. velocity units for vx, charge
units for q, etc.
</P>
<P><B>Restrictions:</B> none
</P>
<P><B>Related commands:</B>
</P>
<P><A HREF = "dump.html">dump custom</A>, <A HREF = "compute_reduce.html">compute reduce</A>, <A HREF = "fix_ave_atom.html">fix
ave/atom</A>, <A HREF = "fix_ave_spatial.html">fix ave/spatial</A>
</P>
<P><B>Default:</B> none
</P>
</HTML>
diff --git a/doc/compute_property_atom.txt b/doc/compute_property_atom.txt
index 500ca25df..f710eb688 100644
--- a/doc/compute_property_atom.txt
+++ b/doc/compute_property_atom.txt
@@ -1,124 +1,125 @@
"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 property/atom command :h3
[Syntax:]
compute ID group-ID property/atom input1 input2 ... :pre
ID, group-ID are documented in "compute"_compute.html command :ulb,l
property/atom = style name of this compute command :l
input = one or more atom attributes :l
possible attributes = id, mol, type, mass,
x, y, z, xs, ys, zs, xu, yu, zu, ix, iy, iz,
vx, vy, vz, fx, fy, fz,
q, mux, muy, muz, mu,
radius, diameter, omegax, omegay, omegaz,
angmomx, angmomy, angmomz,
shapex,shapey, shapez,
quatw, quati, quatj, quatk, tqx, tqy, tqz,
spin, eradius, ervel, erforce
end1x, end1y, end1z, end2x, end2y, end2z,
corner1x, corner1y, corner1z,
corner2x, corner2y, corner2z,
corner3x, corner3y, corner3z :pre
id = atom ID
mol = molecule ID
type = atom type
mass = atom mass
x,y,z = unscaled atom coordinates
xs,ys,zs = scaled atom coordinates
xu,yu,zu = unwrapped atom coordinates
ix,iy,iz = box image that the atom is in
vx,vy,vz = atom velocities
fx,fy,fz = forces on atoms
q = atom charge
mux,muy,muz = orientation of dipole moment of atom
mu = magnitude of dipole moment of atom
radius,diameter = radius,diameter of spherical particle
omegax,omegay,omegaz = angular velocity of extended particle
angmomx,angmomy,angmomz = angular momentum of extended particle
shapex,shapey,shapez = 3 diameters of aspherical particle
- quatw,quati,quatj,quatk = quaternion components for aspherical particles
+ quatw,quati,quatj,quatk = quaternion components for aspherical or body particles
tqx,tqy,tqz = torque on extended particles
spin = electron spin
eradius = electron radius
ervel = electron radial velocity
erforce = electron radial force
end12x, end12y, end12z = end points of line segment
coner123x, corner123y, corner123z = corner points of triangle :pre
:ule
[Examples:]
compute 1 all property/atom xs vx fx mux
compute 2 all property/atom type
compute 1 all property/atom ix iy iz :pre
[Description:]
Define a computation that simply stores atom attributes for each atom
in the group. This is useful so that the values can be used by other
"output commands"_Section_howto.html#howto_15 that take computes as
inputs. See for example, the "compute reduce"_compute_reduce.html,
"fix ave/atom"_fix_ave_atom.html, "fix ave/histo"_fix_ave_histo.html,
"fix ave/spatial"_fix_ave_spatial.html, and "atom-style
variable"_variable.html commands.
The list of possible attributes is the same as that used by the "dump
custom"_dump.html command, which describes their meaning, with some
additional quantities that are only defined for certain "atom
styles"_atom_style.html. Basically, this list gives your input script
access to any per-atom quantity stored by LAMMPS.
The values are stored in a per-atom vector or array as discussed
below. Zeroes are stored for atoms not in the specified group or for
quantities that are not defined for a particular particle in the group
(e.g. {shapex} if the particle is not an ellipsoid).
The additional quantities only accessible via this command, and not
directly via the "dump custom"_dump.html command, are as follows.
{Shapex}, {shapey}, and {shapez} are defined for ellipsoidal particles
-and define the 3d shape of each particle. {Quatw}, {quati}, {quatj},
-and {quatk} are also defined for ellipsoidal particles and store the
-4-vector quaternion representing the orientation of each particle.
-See the "set"_set.html command for an explanation of the quaternion
-vector.
+and define the 3d shape of each particle.
+
+{Quatw}, {quati}, {quatj}, and {quatk} are defined for ellipsoidal
+particles and body particles and store the 4-vector quaternion
+representing the orientation of each particle. See the "set"_set.html
+command for an explanation of the quaternion vector.
{End1x}, {end1y}, {end1z}, {end2x}, {end2y}, {end2z}, are defined for
line segment particles and define the end points of each line segment.
{Corner1x}, {corner1y}, {corner1z}, {corner2x}, {corner2y},
{corner2z}, {corner3x}, {corner3y}, {corner3z}, are defined for
triangular particles and define the corner points of each triangle.
[Output info:]
This compute calculates a per-atom vector or per-atom array depending
on the number of input values. If a single input is specified, a
per-atom vector is produced. If two or more inputs are specified, a
per-atom array is produced where the number of columns = the number of
inputs. The vector or array can be accessed by any command that uses
per-atom values from a compute as input. See "this
section"_Section_howto.html#howto_15 for an overview of LAMMPS output
options.
The vector or array values will be in whatever "units"_units.html the
corresponding attribute is in, e.g. velocity units for vx, charge
units for q, etc.
[Restrictions:] none
[Related commands:]
"dump custom"_dump.html, "compute reduce"_compute_reduce.html, "fix
ave/atom"_fix_ave_atom.html, "fix ave/spatial"_fix_ave_spatial.html
[Default:] none
diff --git a/doc/dump.html b/doc/dump.html
index 0d2400e53..1aa895f46 100644
--- a/doc/dump.html
+++ b/doc/dump.html
@@ -1,564 +1,564 @@
<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>dump command
</H3>
<H3><A HREF = "dump_image.html">dump image</A> command
</H3>
<H3><A HREF = "dump_molfile.html">dump molfile</A> command
</H3>
<P><B>Syntax:</B>
</P>
<PRE>dump ID group-ID style N file args
</PRE>
<UL><LI>ID = user-assigned name for the dump
<LI>group-ID = ID of the group of atoms to be dumped
<LI>style = <I>atom</I> or <I>cfg</I> or <I>dcd</I> or <I>xtc</I> or <I>xyz</I> or <I>image</I> or <I>molfile</I> or <I>local</I> or <I>custom</I>
<LI>N = dump every this many timesteps
<LI>file = name of file to write dump info to
<LI>args = list of arguments for a particular style
<PRE> <I>atom</I> args = none
<I>cfg</I> args = same as <I>custom</I> args, see below
<I>dcd</I> args = none
<I>xtc</I> args = none
<I>xyz</I> args = none
</PRE>
<PRE> <I>image</I> args = discussed on <A HREF = "dump_image.html">dump image</A> doc page
</PRE>
<PRE> <I>molfile</I> args = discussed on <A HREF = "dump_molfile.html">dump molfile</A> doc page
</PRE>
<PRE> <I>local</I> args = list of local attributes
possible attributes = index, c_ID, c_ID[N], f_ID, f_ID[N]
index = enumeration of local values
c_ID = local vector calculated by a compute with ID
c_ID[N] = Nth column of local array calculated by a compute with ID
f_ID = local vector calculated by a fix with ID
f_ID[N] = Nth column of local array calculated by a fix with ID
</PRE>
<PRE> <I>custom</I> args = list of atom attributes
possible attributes = id, mol, type, element, mass,
x, y, z, xs, ys, zs, xu, yu, zu,
xsu, ysu, zsu, ix, iy, iz,
vx, vy, vz, fx, fy, fz,
q, mux, muy, muz, mu,
radius, diameter, omegax, omegay, omegaz,
angmomx, angmomy, angmomz, tqx, tqy, tqz,
spin, eradius, ervel, erforce,
c_ID, c_ID[N], f_ID, f_ID[N], v_name
</PRE>
<PRE> id = atom ID
mol = molecule ID
type = atom type
element = name of atom element, as defined by <A HREF = "dump_modify.html">dump_modify</A> command
mass = atom mass
x,y,z = unscaled atom coordinates
xs,ys,zs = scaled atom coordinates
xu,yu,zu = unwrapped atom coordinates
xsu,ysu,zsu = scaled unwrapped atom coordinates
ix,iy,iz = box image that the atom is in
vx,vy,vz = atom velocities
fx,fy,fz = forces on atoms
q = atom charge
mux,muy,muz = orientation of dipole moment of atom
mu = magnitude of dipole moment of atom
radius,diameter = radius,diameter of spherical particle
omegax,omegay,omegaz = angular velocity of extended particle
angmomx,angmomy,angmomz = angular momentum of extended particle
tqx,tqy,tqz = torque on extended particles
spin = electron spin
eradius = electron radius
ervel = electron radial velocity
erforce = electron radial force
c_ID = per-atom vector calculated by a compute with ID
c_ID[N] = Nth column of per-atom array calculated by a compute with ID
f_ID = per-atom vector calculated by a fix with ID
f_ID[N] = Nth column of per-atom array calculated by a fix with ID
v_name = per-atom vector calculated by an atom-style variable with name
</PRE>
</UL>
<P><B>Examples:</B>
</P>
<PRE>dump myDump all atom 100 dump.atom
dump 2 subgroup atom 50 dump.run.bin
dump 4a all custom 100 dump.myforce.* id type x y vx fx
dump 4b flow custom 100 dump.%.myforce id type c_myF[3] v_ke
dump 2 inner cfg 10 dump.snap.*.cfg id type xs ys zs vx vy vz
dump snap all cfg 100 dump.config.*.cfg id type xs ys zs id type c_Stress<B>2</B>
dump 1 all xtc 1000 file.xtc
dump e_data all custom 100 dump.eff id type x y z spin eradius fx fy fz eforce
</PRE>
<P><B>Description:</B>
</P>
<P>Dump a snapshot of atom quantities to one or more files every N
timesteps in one of several styles. The <I>image</I> style is the
exception; it creates a JPG or PPM image file of the atom
configuration every N timesteps, as discussed on the <A HREF = "dump_image.html">dump
image</A> doc page. The timesteps on which dump output
is written can also be controlled by a variable. See the <A HREF = "dump_modify.html">dump_modify
every</A> command.
</P>
<P>Only information for atoms in the specified group is dumped. The
<A HREF = "dump_modify.html">dump_modify thresh and region</A> commands can also
alter what atoms are included. Not all styles support all these
options; see details below.
</P>
<P>As described below, the filename determines the kind of output (text
or binary or gzipped, one big file or one per timestep, one big file
or one per processor).
</P>
<P>IMPORTANT NOTE: Because periodic boundary conditions are enforced only
on timesteps when neighbor lists are rebuilt, the coordinates of an
atom written to a dump file may be slightly outside the simulation
box.
</P>
<P>IMPORTANT NOTE: Unless the <A HREF = "dump_modify.html">dump_modify sort</A> option
is invoked, the lines of atom information written to dump files
(typically one line per atom) will be in an indeterminate order for
each snapshot. This is even true when running on a single processor,
if the <A HREF = "atom_modify.html">atom_modify sort</A> option is on, which it is
by default. In this case atoms are re-ordered periodically during a
simulation, due to spatial sorting. It is also true when running in
parallel, because data for a single snapshot is collected from
multiple processors.
</P>
<P>For the <I>atom</I>, <I>custom</I>, <I>cfg</I>, and <I>local</I> styles, sorting is off by
default. For the <I>dcd</I>, <I>xtc</I>, <I>xyz</I>, and <I>molfile</I> styles, sorting by
atom ID is on by default. See the <A HREF = "dump_modify.html">dump_modify</A> doc
page for details.
</P>
<HR>
<P>The <I>style</I> keyword determines what atom quantities are written to the
file and in what format. Settings made via the
<A HREF = "dump_modify.html">dump_modify</A> command can also alter the format of
individual values and the file itself.
</P>
<P>The <I>atom</I>, <I>local</I>, and <I>custom</I> styles create files in a simple text
format that is self-explanatory when viewing a dump file. Many of the
LAMMPS <A HREF = "Section_tools.html">post-processing tools</A>, including
<A HREF = "http://www.sandia.gov/~sjplimp/pizza.html">Pizza.py</A>, work with this
format, as does the <A HREF = "rerun.html">rerun</A> command.
</P>
-<P>For post-processing purposes the <I>atom</I> and <I>custom</I> text files are
-self-describing in the following sense.
+<P>For post-processing purposes the <I>atom</I>, <I>local</I>, and <I>custom</I> text
+files are self-describing in the following sense.
</P>
<P>The dimensions of the simulation box are included in each snapshot.
For an orthogonal simulation box this information is is formatted as:
</P>
<PRE>ITEM: BOX BOUNDS xx yy zz
xlo xhi
ylo yhi
zlo zhi
</PRE>
<P>where xlo,xhi are the maximum extents of the simulation box in the
x-dimension, and similarly for y and z. The "xx yy zz" represent 6
characters that encode the style of boundary for each of the 6
simulation box boundaries (xlo,xhi and ylo,yhi and zlo,zhi). Each of
the 6 characters is either p = periodic, f = fixed, s = shrink wrap,
or m = shrink wrapped with a minimum value. See the
<A HREF = "doc/boundary.html">boundary</A> command for details.
</P>
<P>For triclinic simulation boxes (non-orthogonal), an orthogonal
bounding box which encloses the triclinic simulation box is output,
along with the 3 tilt factors (xy, xz, yz) of the triclinic box,
formatted as follows:
</P>
<PRE>ITEM: BOX BOUNDS xy xz yz xx yy zz
xlo_bound xhi_bound xy
ylo_bound yhi_bound xz
zlo_bound zhi_bound yz
</PRE>
<P>The presence of the text "xy xz yz" in the ITEM line indicates that
the 3 tilt factors will be included on each of the 3 following lines.
This bounding box is convenient for many visualization programs. The
meaning of the 6 character flags for "xx yy zz" is the same as above.
</P>
<P>Note that the first two numbers on each line are now xlo_bound instead
of xlo, etc, since they repesent a bounding box. See <A HREF = "Section_howto.html#howto_12">this
section</A> of the doc pages for a geometric
description of triclinic boxes, as defined by LAMMPS, simple formulas
for how the 6 bounding box extents (xlo_bound,xhi_bound,etc) are
calculated from the triclinic parameters, and how to transform those
parameters to and from other commonly used triclinic representations.
</P>
<P>The "ITEM: ATOMS" line in each snapshot lists column descriptors for
the per-atom lines that follow. For example, the descriptors would be
"id type xs ys zs" for the default <I>atom</I> style, and would be the atom
attributes you specify in the dump command for the <I>custom</I> style.
</P>
<P>For style <I>atom</I>, atom coordinates are written to the file, along with
the atom ID and atom type. By default, atom coords are written in a
scaled format (from 0 to 1). I.e. an x value of 0.25 means the atom
is at a location 1/4 of the distance from xlo to xhi of the box
boundaries. The format can be changed to unscaled coords via the
<A HREF = "dump_modify.html">dump_modify</A> settings. Image flags can also be
added for each atom via dump_modify.
</P>
<P>Style <I>custom</I> allows you to specify a list of atom attributes to be
written to the dump file for each atom. Possible attributes are
listed above and will appear in the order specified. You cannot
specify a quantity that is not defined for a particular simulation -
such as <I>q</I> for atom style <I>bond</I>, since that atom style doesn't
assign charges. Dumps occur at the very end of a timestep, so atom
attributes will include effects due to fixes that are applied during
the timestep. An explanation of the possible dump custom attributes
is given below.
</P>
<P>For style <I>local</I>, local output generated by <A HREF = "compute.html">computes</A>
and <A HREF = "fix.html">fixes</A> is used to generate lines of output that is
written to the dump file. This local data is typically calculated by
each processor based on the atoms it owns, but there may be zero or
more entities per atom, e.g. a list of bond distances. An explanation
of the possible dump local attributes is given below. Note that by
using input from the <A HREF = "compute_property_local.html">compute
property/local</A> command with dump local,
it is possible to generate information on bonds, angles, etc that can
be cut and pasted directly into a data file read by the
<A HREF = "read_data.html">read_data</A> command.
</P>
<P>Style <I>cfg</I> has the same command syntax as style <I>custom</I> and writes
extended CFG format files, as used by the
<A HREF = "http://mt.seas.upenn.edu/Archive/Graphics/A">AtomEye</A> visualization
package. Since the extended CFG format uses a single snapshot of the
system per file, a wildcard "*" must be included in the filename, as
discussed below. The list of atom attributes for style <I>cfg</I> must
begin with either "id type xs ys zs" or "id type xsu ysu zsu" or
since these quantities are needed to
write the CFG files in the appropriate format (though the "id" and
"type" fields do not appear explicitly in the file). Any remaining
attributes will be stored as "auxiliary properties" in the CFG files.
Note that you will typically want to use the <A HREF = "dump_modify.html">dump_modify
element</A> command with CFG-formatted files, to
associate element names with atom types, so that AtomEye can render
atoms appropriately. When unwrapped coordinates <I>xsu</I>, <I>ysu</I>, and <I>zsu</I>
are requested, the nominal AtomEye periodic cell dimensions are expanded
by a large factor UNWRAPEXPAND = 10.0, which ensures atoms that are
displayed correctly for up to UNWRAPEXPAND/2 periodic boundary crossings
in any direction.
Beyond this, AtomEye will rewrap the unwrapped coordinates.
The expansion causes the atoms to be drawn farther
away from the viewer, but it is easy to zoom the atoms closer, and
the interatomic distances are unaffected.
</P>
<P>The <I>dcd</I> style writes DCD files, a standard atomic trajectory format
used by the CHARMM, NAMD, and XPlor molecular dynamics packages. DCD
files are binary and thus may not be portable to different machines.
The number of atoms per snapshot cannot change with the <I>dcd</I> style.
The <I>unwrap</I> option of the <A HREF = "dump_modify.html">dump_modify</A> command
allows DCD coordinates to be written "unwrapped" by the image flags
for each atom. Unwrapped means that if the atom has passed through
a periodic boundary one or more times, the value is printed for what
the coordinate would be if it had not been wrapped back into the
periodic box. Note that these coordinates may thus be far outside
the box size stored with the snapshot.
</P>
<P>The <I>xtc</I> style writes XTC files, a compressed trajectory format used
by the GROMACS molecular dynamics package, and described
<A HREF = "http://manual.gromacs.org/current/online/xtc.html">here</A>.
The precision used in XTC files can be adjusted via the
<A HREF = "dump_modify.html">dump_modify</A> command. The default value of 1000
means that coordinates are stored to 1/1000 nanometer accuracy. XTC
files are portable binary files written in the NFS XDR data format,
so that any machine which supports XDR should be able to read them.
The number of atoms per snapshot cannot change with the <I>xtc</I> style.
The <I>unwrap</I> option of the <A HREF = "dump_modify.html">dump_modify</A> command allows
XTC coordinates to be written "unwrapped" by the image flags for each
atom. Unwrapped means that if the atom has passed thru a periodic
boundary one or more times, the value is printed for what the
coordinate would be if it had not been wrapped back into the periodic
box. Note that these coordinates may thus be far outside the box size
stored with the snapshot.
</P>
<P>The <I>xyz</I> style writes XYZ files, which is a simple text-based
coordinate format that many codes can read. Specifically it has
a line with the number of atoms, then a comment line that is
usually ignored followed by one line per atom with the atom type
and the x-, y-, and z-coordinate of that atom. You can use the
<A HREF = "dump_modify.html">dump_modify element</A> option to change the output
from using the (numerical) atom type to an element name (or some
other label). This will help many visualization programs to guess
bonds and colors.
</P>
<P>Note that <I>atom</I>, <I>custom</I>, <I>dcd</I>, <I>xtc</I>, and <I>xyz</I> style dump files can
be read directly by <A HREF = "http://www.ks.uiuc.edu/Research/vmd">VMD</A> (a popular
molecular viewing program). See <A HREF = "Section_tools.html#vmd">Section tools</A>
of the manual and the tools/lmp2vmd/README.txt file for more information
about support in VMD for reading and visualizing LAMMPS dump files.
</P>
<HR>
<P>Dumps are performed on timesteps that are a multiple of N (including
timestep 0) and on the last timestep of a minimization if the
minimization converges. Note that this means a dump will not be
performed on the initial timestep after the dump command is invoked,
if the current timestep is not a multiple of N. This behavior can be
changed via the <A HREF = "dump_modify.html">dump_modify first</A> command, which
can also be useful if the dump command is invoked after a minimization
ended on an arbitrary timestep. N can be changed between runs by
using the <A HREF = "dump_modify.html">dump_modify every</A> command (not allowed
for <I>dcd</I> style). The <A HREF = "dump_modify.html">dump_modify every</A> command
also allows a variable to be used to determine the sequence of
timesteps on which dump files are written. In this mode a dump on the
first timestep of a run will also not be written unless the
<A HREF = "dump_modify.html">dump_modify first</A> command is used.
</P>
<P>The specified filename determines how the dump file(s) is written.
The default is to write one large text file, which is opened when the
dump command is invoked and closed when an <A HREF = "undump.html">undump</A>
command is used or when LAMMPS exits. For the <I>dcd</I> and <I>xtc</I> styles,
this is a single large binary file.
</P>
<P>Dump filenames can contain two wildcard characters. If a "*"
character appears in the filename, then one file per snapshot is
written and the "*" character is replaced with the timestep value.
For example, tmp.dump.* becomes tmp.dump.0, tmp.dump.10000,
tmp.dump.20000, etc. This option is not available for the <I>dcd</I> and
<I>xtc</I> styles. Note that the <A HREF = "dump_modify.html">dump_modify pad</A>
command can be used to insure all timestep numbers are the same length
(e.g. 00010), which can make it easier to read a series of dump files
in order by some post-processing tools.
</P>
<P>If a "%" character appears in the filename, then one file is written
for each processor and the "%" character is replaced with the
processor ID from 0 to P-1. For example, tmp.dump.% becomes
tmp.dump.0, tmp.dump.1, ... tmp.dump.P-1, etc. This creates smaller
files and can be a fast mode of output on parallel machines that
support parallel I/O for output. This option is not available for the
<I>dcd</I>, <I>xtc</I>, and <I>xyz</I> styles.
</P>
<P>Note that the "*" and "%" characters can be used together to produce a
large number of small dump files!
</P>
<P>If the filename ends with ".bin", the dump file (or files, if "*" or
"%" is also used) is written in binary format. A binary dump file
will be about the same size as a text version, but will typically
write out much faster. Of course, when post-processing, you will need
to convert it back to text format (see the <A HREF = "Section_tools.html#binary">binary2txt
tool</A>) or write your own code to read the
binary file. The format of the binary file can be understood by
looking at the tools/binary2txt.cpp file. This option is only
available for the <I>atom</I> and <I>custom</I> styles.
</P>
<P>If the filename ends with ".gz", the dump file (or files, if "*" or "%"
is also used) is written in gzipped format. A gzipped dump file will
be about 3x smaller than the text version, but will also take longer
to write. This option is not available for the <I>dcd</I> and <I>xtc</I>
styles.
</P>
<HR>
<P>This section explains the local attributes that can be specified as
part of the <I>local</I> style.
</P>
<P>The <I>index</I> attribute can be used to generate an index number from 1
to N for each line written into the dump file, where N is the total
number of local datums from all processors, or lines of output that
will appear in the snapshot. Note that because data from different
processors depend on what atoms they currently own, and atoms migrate
between processor, there is no guarantee that the same index will be
used for the same info (e.g. a particular bond) in successive
snapshots.
</P>
<P>The <I>c_ID</I> and <I>c_ID[N]</I> attributes allow local vectors or arrays
calculated by a <A HREF = "compute.html">compute</A> to be output. The ID in the
attribute should be replaced by the actual ID of the compute that has
been defined previously in the input script. See the
<A HREF = "compute.html">compute</A> command for details. There are computes for
calculating local information such as indices, types, and energies for
bonds and angles.
</P>
<P>Note that computes which calculate global or per-atom quantities, as
opposed to local quantities, cannot be output in a dump local command.
Instead, global quantities can be output by the <A HREF = "thermo_style.html">thermo_style
custom</A> command, and per-atom quantities can be
output by the dump custom command.
</P>
<P>If <I>c_ID</I> is used as a attribute, then the local vector calculated by
the compute is printed. If <I>c_ID[N]</I> is used, then N must be in the
range from 1-M, which will print the Nth column of the M-length local
array calculated by the compute.
</P>
<P>The <I>f_ID</I> and <I>f_ID[N]</I> attributes allow local vectors or arrays
calculated by a <A HREF = "fix.html">fix</A> to be output. The ID in the attribute
should be replaced by the actual ID of the fix that has been defined
previously in the input script.
</P>
<P>If <I>f_ID</I> is used as a attribute, then the local vector calculated by
the fix is printed. If <I>f_ID[N]</I> is used, then N must be in the
range from 1-M, which will print the Nth column of the M-length local
array calculated by the fix.
</P>
<P>Here is an example of how to dump bond info for a system,
including the distance and energy of each bond:
</P>
<PRE>compute 1 all property/local batom1 batom2 btype
compute 2 all bond/local dist eng
dump 1 all local 1000 tmp.dump index c_1[1] c_1[2] c_1[3] c_2[1] c_2[2]
</PRE>
<HR>
<P>This section explains the atom attributes that can be specified as
part of the <I>custom</I> and <I>cfg</I> styles.
</P>
<P>The <I>id</I>, <I>mol</I>, <I>type</I>, <I>element</I>, <I>mass</I>, <I>vx</I>, <I>vy</I>, <I>vz</I>, <I>fx</I>, <I>fy</I>,
<I>fz</I>, <I>q</I> attributes are self-explanatory.
</P>
<P><I>Id</I> is the atom ID. <I>Mol</I> is the molecule ID, included in the data
file for molecular systems. <I>Type</I> is the atom type. <I>Element</I> is
typically the chemical name of an element, which you must assign to
each type via the <A HREF = "dump_modify.html">dump_modify element</A> command.
More generally, it can be any string you wish to associated with an
atom type. <I>Mass</I> is the atom mass. <I>Vx</I>, <I>vy</I>, <I>vz</I>, <I>fx</I>, <I>fy</I>,
<I>fz</I>, and <I>q</I> are components of atom velocity and force and atomic
charge.
</P>
<P>There are several options for outputting atom coordinates. The <I>x</I>,
<I>y</I>, <I>z</I> attributes write atom coordinates "unscaled", in the
appropriate distance <A HREF = "units.html">units</A> (Angstroms, sigma, etc). Use
<I>xs</I>, <I>ys</I>, <I>zs</I> if you want the coordinates "scaled" to the box size,
so that each value is 0.0 to 1.0. If the simulation box is triclinic
(tilted), then all atom coords will still be between 0.0 and 1.0. Use
<I>xu</I>, <I>yu</I>, <I>zu</I> if you want the coordinates "unwrapped" by the image
flags for each atom. Unwrapped means that if the atom has passed thru
a periodic boundary one or more times, the value is printed for what
the coordinate would be if it had not been wrapped back into the
periodic box. Note that using <I>xu</I>, <I>yu</I>, <I>zu</I> means that the
coordinate values may be far outside the box bounds printed with the
snapshot. Using <I>xsu</I>, <I>ysu</I>, <I>zsu</I> is similar to using <I>xu</I>, <I>yu</I>, <I>zu</I>,
except that the unwrapped coordinates are scaled by the box size. Atoms
that have passed through a periodic boundary will have the corresponding
cooordinate increased or decreased by 1.0.
</P>
<P>The image flags can be printed directly using the <I>ix</I>,
<I>iy</I>, <I>iz</I> attributes. The <A HREF = "dump_modify.html">dump_modify</A> command
describes in more detail what is meant by scaled vs unscaled
coordinates and the image flags.
</P>
<P>The <I>mux</I>, <I>muy</I>, <I>muz</I> attributes are specific to dipolar systems
defined with an atom style of <I>dipole</I>. They give the orientation of
the atom's point dipole moment. The <I>mu</I> attribute gives the
magnitude of the atom's dipole moment.
</P>
<P>The <I>radius</I> and <I>diameter</I> attributes are specific to extended
spherical particles that have a finite size, such as those defined
with an atom style of <I>sphere</I>.
</P>
<P>The <I>omegax</I>, <I>omegay</I>, and <I>omegaz</I> attributes are specific to
extended spherical or aspherical particles that have an angular
velocity. Only certain atom styles, such as <I>sphere</I> define this
quantity.
</P>
<P>The <I>angmomx</I>, <I>angmomy</I>, and <I>angmomz</I> attributes are specific to
extended aspherical particles that have an angular momentum. Only
the <I>ellipsoid</I> atom style defines this quantity.
</P>
<P>The <I>tqx</I>, <I>tqy</I>, <I>tqz</I> attributes are for extended spherical or
aspherical particles that can sustain a rotational torque due
to interactions with other particles.
</P>
<P>The <I>spin</I>, <I>eradius</I>, <I>ervel</I>, and <I>erforce</I> attributes are for
particles that represent nuclei and electrons modeled with the
electronic force field (EFF). See <A HREF = "atom_style.html">atom_style
electron</A> and <A HREF = "pair_eff.html">pair_style eff</A> for more
details.
</P>
<P>The <I>c_ID</I> and <I>c_ID[N]</I> attributes allow per-atom vectors or arrays
calculated by a <A HREF = "compute.html">compute</A> to be output. The ID in the
attribute should be replaced by the actual ID of the compute that has
been defined previously in the input script. See the
<A HREF = "compute.html">compute</A> command for details. There are computes for
calculating the per-atom energy, stress, centro-symmetry parameter,
and coordination number of individual atoms.
</P>
<P>Note that computes which calculate global or local quantities, as
opposed to per-atom quantities, cannot be output in a dump custom
command. Instead, global quantities can be output by the
<A HREF = "thermo_style.html">thermo_style custom</A> command, and local quantities
can be output by the dump local command.
</P>
<P>If <I>c_ID</I> is used as a attribute, then the per-atom vector calculated
by the compute is printed. If <I>c_ID[N]</I> is used, then N must be in
the range from 1-M, which will print the Nth column of the M-length
per-atom array calculated by the compute.
</P>
<P>The <I>f_ID</I> and <I>f_ID[N]</I> attributes allow vector or array per-atom
quantities calculated by a <A HREF = "fix.html">fix</A> to be output. The ID in the
attribute should be replaced by the actual ID of the fix that has been
defined previously in the input script. The <A HREF = "fix_ave_atom.html">fix
ave/atom</A> command is one that calculates per-atom
quantities. Since it can time-average per-atom quantities produced by
any <A HREF = "compute.html">compute</A>, <A HREF = "fix.html">fix</A>, or atom-style
<A HREF = "variable.html">variable</A>, this allows those time-averaged results to
be written to a dump file.
</P>
<P>If <I>f_ID</I> is used as a attribute, then the per-atom vector calculated
by the fix is printed. If <I>f_ID[N]</I> is used, then N must be in the
range from 1-M, which will print the Nth column of the M-length
per-atom array calculated by the fix.
</P>
<P>The <I>v_name</I> attribute allows per-atom vectors calculated by a
<A HREF = "variable.html">variable</A> to be output. The name in the attribute
should be replaced by the actual name of the variable that has been
defined previously in the input script. Only an atom-style variable
can be referenced, since it is the only style that generates per-atom
values. Variables of style <I>atom</I> can reference individual atom
attributes, per-atom atom attributes, thermodynamic keywords, or
invoke other computes, fixes, or variables when they are evaluated, so
this is a very general means of creating quantities to output to a
dump file.
</P>
<P>See <A HREF = "Section_modify.html">Section_modify</A> of the manual for information
on how to add new compute and fix styles to LAMMPS to calculate
per-atom quantities which could then be output into dump files.
</P>
<HR>
<P><B>Restrictions:</B>
</P>
<P>To write gzipped dump files, you must compile LAMMPS with the
-DLAMMPS_GZIP option - see the <A HREF = "Section_start.html#start_2">Making
LAMMPS</A> section of the documentation.
</P>
<P>The <I>xtc</I> style is part of the XTC package. It is 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. This is
because some machines may not support the low-level XDR data format
that XTC files are written with, which will result in a compile-time
error when a low-level include file is not found. Putting this style
in a package makes it easy to exclude from a LAMMPS build for those
machines. However, the XTC package also includes two compatibility
header files and associated functions, which should be a suitable
substitute on machines that do not have the appropriate native header
files. This option can be invoked at build time by adding
-DLAMMPS_XDR to the CCFLAGS variable in the appropriate low-level
Makefile, e.g. src/MAKE/Makefile.foo. This compatibility mode has
been tested successfully on Cray XT3/XT4/XT5 and IBM BlueGene/L
machines and should also work on IBM BG/P, and Windows XP/Vista/7
machines.
</P>
<P><B>Related commands:</B>
</P>
<P><A HREF = "dump_image.html">dump image</A>, <A HREF = "dump_modify.html">dump_modify</A>,
<A HREF = "undump.html">undump</A>
</P>
<P><B>Default:</B>
</P>
<P>The defaults for the image style are listed on the <A HREF = "dump_image.html">dump
image</A> doc page.
</P>
</HTML>
diff --git a/doc/dump.txt b/doc/dump.txt
index fd51cc385..d041eae08 100644
--- a/doc/dump.txt
+++ b/doc/dump.txt
@@ -1,550 +1,550 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
dump command :h3
"dump image"_dump_image.html command :h3
"dump molfile"_dump_molfile.html command :h3
[Syntax:]
dump ID group-ID style N file args :pre
ID = user-assigned name for the dump :ulb,l
group-ID = ID of the group of atoms to be dumped :l
style = {atom} or {cfg} or {dcd} or {xtc} or {xyz} or {image} or {molfile} or {local} or {custom} :l
N = dump every this many timesteps :l
file = name of file to write dump info to :l
args = list of arguments for a particular style :l
{atom} args = none
{cfg} args = same as {custom} args, see below
{dcd} args = none
{xtc} args = none
{xyz} args = none :pre
{image} args = discussed on "dump image"_dump_image.html doc page :pre
{molfile} args = discussed on "dump molfile"_dump_molfile.html doc page :pre
{local} args = list of local attributes
possible attributes = index, c_ID, c_ID\[N\], f_ID, f_ID\[N\]
index = enumeration of local values
c_ID = local vector calculated by a compute with ID
c_ID\[N\] = Nth column of local array calculated by a compute with ID
f_ID = local vector calculated by a fix with ID
f_ID\[N\] = Nth column of local array calculated by a fix with ID :pre
{custom} args = list of atom attributes
possible attributes = id, mol, type, element, mass,
x, y, z, xs, ys, zs, xu, yu, zu,
xsu, ysu, zsu, ix, iy, iz,
vx, vy, vz, fx, fy, fz,
q, mux, muy, muz, mu,
radius, diameter, omegax, omegay, omegaz,
angmomx, angmomy, angmomz, tqx, tqy, tqz,
spin, eradius, ervel, erforce,
c_ID, c_ID\[N\], f_ID, f_ID\[N\], v_name :pre
id = atom ID
mol = molecule ID
type = atom type
element = name of atom element, as defined by "dump_modify"_dump_modify.html command
mass = atom mass
x,y,z = unscaled atom coordinates
xs,ys,zs = scaled atom coordinates
xu,yu,zu = unwrapped atom coordinates
xsu,ysu,zsu = scaled unwrapped atom coordinates
ix,iy,iz = box image that the atom is in
vx,vy,vz = atom velocities
fx,fy,fz = forces on atoms
q = atom charge
mux,muy,muz = orientation of dipole moment of atom
mu = magnitude of dipole moment of atom
radius,diameter = radius,diameter of spherical particle
omegax,omegay,omegaz = angular velocity of extended particle
angmomx,angmomy,angmomz = angular momentum of extended particle
tqx,tqy,tqz = torque on extended particles
spin = electron spin
eradius = electron radius
ervel = electron radial velocity
erforce = electron radial force
c_ID = per-atom vector calculated by a compute with ID
c_ID\[N\] = Nth column of per-atom array calculated by a compute with ID
f_ID = per-atom vector calculated by a fix with ID
f_ID\[N\] = Nth column of per-atom array calculated by a fix with ID
v_name = per-atom vector calculated by an atom-style variable with name :pre
:ule
[Examples:]
dump myDump all atom 100 dump.atom
dump 2 subgroup atom 50 dump.run.bin
dump 4a all custom 100 dump.myforce.* id type x y vx fx
dump 4b flow custom 100 dump.%.myforce id type c_myF\[3\] v_ke
dump 2 inner cfg 10 dump.snap.*.cfg id type xs ys zs vx vy vz
dump snap all cfg 100 dump.config.*.cfg id type xs ys zs id type c_Stress[2]
dump 1 all xtc 1000 file.xtc
dump e_data all custom 100 dump.eff id type x y z spin eradius fx fy fz eforce :pre
[Description:]
Dump a snapshot of atom quantities to one or more files every N
timesteps in one of several styles. The {image} style is the
exception; it creates a JPG or PPM image file of the atom
configuration every N timesteps, as discussed on the "dump
image"_dump_image.html doc page. The timesteps on which dump output
is written can also be controlled by a variable. See the "dump_modify
every"_dump_modify.html command.
Only information for atoms in the specified group is dumped. The
"dump_modify thresh and region"_dump_modify.html commands can also
alter what atoms are included. Not all styles support all these
options; see details below.
As described below, the filename determines the kind of output (text
or binary or gzipped, one big file or one per timestep, one big file
or one per processor).
IMPORTANT NOTE: Because periodic boundary conditions are enforced only
on timesteps when neighbor lists are rebuilt, the coordinates of an
atom written to a dump file may be slightly outside the simulation
box.
IMPORTANT NOTE: Unless the "dump_modify sort"_dump_modify.html option
is invoked, the lines of atom information written to dump files
(typically one line per atom) will be in an indeterminate order for
each snapshot. This is even true when running on a single processor,
if the "atom_modify sort"_atom_modify.html option is on, which it is
by default. In this case atoms are re-ordered periodically during a
simulation, due to spatial sorting. It is also true when running in
parallel, because data for a single snapshot is collected from
multiple processors.
For the {atom}, {custom}, {cfg}, and {local} styles, sorting is off by
default. For the {dcd}, {xtc}, {xyz}, and {molfile} styles, sorting by
atom ID is on by default. See the "dump_modify"_dump_modify.html doc
page for details.
:line
The {style} keyword determines what atom quantities are written to the
file and in what format. Settings made via the
"dump_modify"_dump_modify.html command can also alter the format of
individual values and the file itself.
The {atom}, {local}, and {custom} styles create files in a simple text
format that is self-explanatory when viewing a dump file. Many of the
LAMMPS "post-processing tools"_Section_tools.html, including
"Pizza.py"_http://www.sandia.gov/~sjplimp/pizza.html, work with this
format, as does the "rerun"_rerun.html command.
-For post-processing purposes the {atom} and {custom} text files are
-self-describing in the following sense.
+For post-processing purposes the {atom}, {local}, and {custom} text
+files are self-describing in the following sense.
The dimensions of the simulation box are included in each snapshot.
For an orthogonal simulation box this information is is formatted as:
ITEM: BOX BOUNDS xx yy zz
xlo xhi
ylo yhi
zlo zhi :pre
where xlo,xhi are the maximum extents of the simulation box in the
x-dimension, and similarly for y and z. The "xx yy zz" represent 6
characters that encode the style of boundary for each of the 6
simulation box boundaries (xlo,xhi and ylo,yhi and zlo,zhi). Each of
the 6 characters is either p = periodic, f = fixed, s = shrink wrap,
or m = shrink wrapped with a minimum value. See the
"boundary"_doc/boundary.html command for details.
For triclinic simulation boxes (non-orthogonal), an orthogonal
bounding box which encloses the triclinic simulation box is output,
along with the 3 tilt factors (xy, xz, yz) of the triclinic box,
formatted as follows:
ITEM: BOX BOUNDS xy xz yz xx yy zz
xlo_bound xhi_bound xy
ylo_bound yhi_bound xz
zlo_bound zhi_bound yz :pre
The presence of the text "xy xz yz" in the ITEM line indicates that
the 3 tilt factors will be included on each of the 3 following lines.
This bounding box is convenient for many visualization programs. The
meaning of the 6 character flags for "xx yy zz" is the same as above.
Note that the first two numbers on each line are now xlo_bound instead
of xlo, etc, since they repesent a bounding box. See "this
section"_Section_howto.html#howto_12 of the doc pages for a geometric
description of triclinic boxes, as defined by LAMMPS, simple formulas
for how the 6 bounding box extents (xlo_bound,xhi_bound,etc) are
calculated from the triclinic parameters, and how to transform those
parameters to and from other commonly used triclinic representations.
The "ITEM: ATOMS" line in each snapshot lists column descriptors for
the per-atom lines that follow. For example, the descriptors would be
"id type xs ys zs" for the default {atom} style, and would be the atom
attributes you specify in the dump command for the {custom} style.
For style {atom}, atom coordinates are written to the file, along with
the atom ID and atom type. By default, atom coords are written in a
scaled format (from 0 to 1). I.e. an x value of 0.25 means the atom
is at a location 1/4 of the distance from xlo to xhi of the box
boundaries. The format can be changed to unscaled coords via the
"dump_modify"_dump_modify.html settings. Image flags can also be
added for each atom via dump_modify.
Style {custom} allows you to specify a list of atom attributes to be
written to the dump file for each atom. Possible attributes are
listed above and will appear in the order specified. You cannot
specify a quantity that is not defined for a particular simulation -
such as {q} for atom style {bond}, since that atom style doesn't
assign charges. Dumps occur at the very end of a timestep, so atom
attributes will include effects due to fixes that are applied during
the timestep. An explanation of the possible dump custom attributes
is given below.
For style {local}, local output generated by "computes"_compute.html
and "fixes"_fix.html is used to generate lines of output that is
written to the dump file. This local data is typically calculated by
each processor based on the atoms it owns, but there may be zero or
more entities per atom, e.g. a list of bond distances. An explanation
of the possible dump local attributes is given below. Note that by
using input from the "compute
property/local"_compute_property_local.html command with dump local,
it is possible to generate information on bonds, angles, etc that can
be cut and pasted directly into a data file read by the
"read_data"_read_data.html command.
Style {cfg} has the same command syntax as style {custom} and writes
extended CFG format files, as used by the
"AtomEye"_http://mt.seas.upenn.edu/Archive/Graphics/A visualization
package. Since the extended CFG format uses a single snapshot of the
system per file, a wildcard "*" must be included in the filename, as
discussed below. The list of atom attributes for style {cfg} must
begin with either "id type xs ys zs" or "id type xsu ysu zsu" or
since these quantities are needed to
write the CFG files in the appropriate format (though the "id" and
"type" fields do not appear explicitly in the file). Any remaining
attributes will be stored as "auxiliary properties" in the CFG files.
Note that you will typically want to use the "dump_modify
element"_dump_modify.html command with CFG-formatted files, to
associate element names with atom types, so that AtomEye can render
atoms appropriately. When unwrapped coordinates {xsu}, {ysu}, and {zsu}
are requested, the nominal AtomEye periodic cell dimensions are expanded
by a large factor UNWRAPEXPAND = 10.0, which ensures atoms that are
displayed correctly for up to UNWRAPEXPAND/2 periodic boundary crossings
in any direction.
Beyond this, AtomEye will rewrap the unwrapped coordinates.
The expansion causes the atoms to be drawn farther
away from the viewer, but it is easy to zoom the atoms closer, and
the interatomic distances are unaffected.
The {dcd} style writes DCD files, a standard atomic trajectory format
used by the CHARMM, NAMD, and XPlor molecular dynamics packages. DCD
files are binary and thus may not be portable to different machines.
The number of atoms per snapshot cannot change with the {dcd} style.
The {unwrap} option of the "dump_modify"_dump_modify.html command
allows DCD coordinates to be written "unwrapped" by the image flags
for each atom. Unwrapped means that if the atom has passed through
a periodic boundary one or more times, the value is printed for what
the coordinate would be if it had not been wrapped back into the
periodic box. Note that these coordinates may thus be far outside
the box size stored with the snapshot.
The {xtc} style writes XTC files, a compressed trajectory format used
by the GROMACS molecular dynamics package, and described
"here"_http://manual.gromacs.org/current/online/xtc.html.
The precision used in XTC files can be adjusted via the
"dump_modify"_dump_modify.html command. The default value of 1000
means that coordinates are stored to 1/1000 nanometer accuracy. XTC
files are portable binary files written in the NFS XDR data format,
so that any machine which supports XDR should be able to read them.
The number of atoms per snapshot cannot change with the {xtc} style.
The {unwrap} option of the "dump_modify"_dump_modify.html command allows
XTC coordinates to be written "unwrapped" by the image flags for each
atom. Unwrapped means that if the atom has passed thru a periodic
boundary one or more times, the value is printed for what the
coordinate would be if it had not been wrapped back into the periodic
box. Note that these coordinates may thus be far outside the box size
stored with the snapshot.
The {xyz} style writes XYZ files, which is a simple text-based
coordinate format that many codes can read. Specifically it has
a line with the number of atoms, then a comment line that is
usually ignored followed by one line per atom with the atom type
and the x-, y-, and z-coordinate of that atom. You can use the
"dump_modify element"_dump_modify.html option to change the output
from using the (numerical) atom type to an element name (or some
other label). This will help many visualization programs to guess
bonds and colors.
Note that {atom}, {custom}, {dcd}, {xtc}, and {xyz} style dump files can
be read directly by "VMD"_http://www.ks.uiuc.edu/Research/vmd (a popular
molecular viewing program). See "Section tools"_Section_tools.html#vmd
of the manual and the tools/lmp2vmd/README.txt file for more information
about support in VMD for reading and visualizing LAMMPS dump files.
:line
Dumps are performed on timesteps that are a multiple of N (including
timestep 0) and on the last timestep of a minimization if the
minimization converges. Note that this means a dump will not be
performed on the initial timestep after the dump command is invoked,
if the current timestep is not a multiple of N. This behavior can be
changed via the "dump_modify first"_dump_modify.html command, which
can also be useful if the dump command is invoked after a minimization
ended on an arbitrary timestep. N can be changed between runs by
using the "dump_modify every"_dump_modify.html command (not allowed
for {dcd} style). The "dump_modify every"_dump_modify.html command
also allows a variable to be used to determine the sequence of
timesteps on which dump files are written. In this mode a dump on the
first timestep of a run will also not be written unless the
"dump_modify first"_dump_modify.html command is used.
The specified filename determines how the dump file(s) is written.
The default is to write one large text file, which is opened when the
dump command is invoked and closed when an "undump"_undump.html
command is used or when LAMMPS exits. For the {dcd} and {xtc} styles,
this is a single large binary file.
Dump filenames can contain two wildcard characters. If a "*"
character appears in the filename, then one file per snapshot is
written and the "*" character is replaced with the timestep value.
For example, tmp.dump.* becomes tmp.dump.0, tmp.dump.10000,
tmp.dump.20000, etc. This option is not available for the {dcd} and
{xtc} styles. Note that the "dump_modify pad"_dump_modify.html
command can be used to insure all timestep numbers are the same length
(e.g. 00010), which can make it easier to read a series of dump files
in order by some post-processing tools.
If a "%" character appears in the filename, then one file is written
for each processor and the "%" character is replaced with the
processor ID from 0 to P-1. For example, tmp.dump.% becomes
tmp.dump.0, tmp.dump.1, ... tmp.dump.P-1, etc. This creates smaller
files and can be a fast mode of output on parallel machines that
support parallel I/O for output. This option is not available for the
{dcd}, {xtc}, and {xyz} styles.
Note that the "*" and "%" characters can be used together to produce a
large number of small dump files!
If the filename ends with ".bin", the dump file (or files, if "*" or
"%" is also used) is written in binary format. A binary dump file
will be about the same size as a text version, but will typically
write out much faster. Of course, when post-processing, you will need
to convert it back to text format (see the "binary2txt
tool"_Section_tools.html#binary) or write your own code to read the
binary file. The format of the binary file can be understood by
looking at the tools/binary2txt.cpp file. This option is only
available for the {atom} and {custom} styles.
If the filename ends with ".gz", the dump file (or files, if "*" or "%"
is also used) is written in gzipped format. A gzipped dump file will
be about 3x smaller than the text version, but will also take longer
to write. This option is not available for the {dcd} and {xtc}
styles.
:line
This section explains the local attributes that can be specified as
part of the {local} style.
The {index} attribute can be used to generate an index number from 1
to N for each line written into the dump file, where N is the total
number of local datums from all processors, or lines of output that
will appear in the snapshot. Note that because data from different
processors depend on what atoms they currently own, and atoms migrate
between processor, there is no guarantee that the same index will be
used for the same info (e.g. a particular bond) in successive
snapshots.
The {c_ID} and {c_ID\[N\]} attributes allow local vectors or arrays
calculated by a "compute"_compute.html to be output. The ID in the
attribute should be replaced by the actual ID of the compute that has
been defined previously in the input script. See the
"compute"_compute.html command for details. There are computes for
calculating local information such as indices, types, and energies for
bonds and angles.
Note that computes which calculate global or per-atom quantities, as
opposed to local quantities, cannot be output in a dump local command.
Instead, global quantities can be output by the "thermo_style
custom"_thermo_style.html command, and per-atom quantities can be
output by the dump custom command.
If {c_ID} is used as a attribute, then the local vector calculated by
the compute is printed. If {c_ID\[N\]} is used, then N must be in the
range from 1-M, which will print the Nth column of the M-length local
array calculated by the compute.
The {f_ID} and {f_ID\[N\]} attributes allow local vectors or arrays
calculated by a "fix"_fix.html to be output. The ID in the attribute
should be replaced by the actual ID of the fix that has been defined
previously in the input script.
If {f_ID} is used as a attribute, then the local vector calculated by
the fix is printed. If {f_ID\[N\]} is used, then N must be in the
range from 1-M, which will print the Nth column of the M-length local
array calculated by the fix.
Here is an example of how to dump bond info for a system,
including the distance and energy of each bond:
compute 1 all property/local batom1 batom2 btype
compute 2 all bond/local dist eng
dump 1 all local 1000 tmp.dump index c_1\[1\] c_1\[2\] c_1\[3\] c_2\[1\] c_2\[2\] :pre
:line
This section explains the atom attributes that can be specified as
part of the {custom} and {cfg} styles.
The {id}, {mol}, {type}, {element}, {mass}, {vx}, {vy}, {vz}, {fx}, {fy},
{fz}, {q} attributes are self-explanatory.
{Id} is the atom ID. {Mol} is the molecule ID, included in the data
file for molecular systems. {Type} is the atom type. {Element} is
typically the chemical name of an element, which you must assign to
each type via the "dump_modify element"_dump_modify.html command.
More generally, it can be any string you wish to associated with an
atom type. {Mass} is the atom mass. {Vx}, {vy}, {vz}, {fx}, {fy},
{fz}, and {q} are components of atom velocity and force and atomic
charge.
There are several options for outputting atom coordinates. The {x},
{y}, {z} attributes write atom coordinates "unscaled", in the
appropriate distance "units"_units.html (Angstroms, sigma, etc). Use
{xs}, {ys}, {zs} if you want the coordinates "scaled" to the box size,
so that each value is 0.0 to 1.0. If the simulation box is triclinic
(tilted), then all atom coords will still be between 0.0 and 1.0. Use
{xu}, {yu}, {zu} if you want the coordinates "unwrapped" by the image
flags for each atom. Unwrapped means that if the atom has passed thru
a periodic boundary one or more times, the value is printed for what
the coordinate would be if it had not been wrapped back into the
periodic box. Note that using {xu}, {yu}, {zu} means that the
coordinate values may be far outside the box bounds printed with the
snapshot. Using {xsu}, {ysu}, {zsu} is similar to using {xu}, {yu}, {zu},
except that the unwrapped coordinates are scaled by the box size. Atoms
that have passed through a periodic boundary will have the corresponding
cooordinate increased or decreased by 1.0.
The image flags can be printed directly using the {ix},
{iy}, {iz} attributes. The "dump_modify"_dump_modify.html command
describes in more detail what is meant by scaled vs unscaled
coordinates and the image flags.
The {mux}, {muy}, {muz} attributes are specific to dipolar systems
defined with an atom style of {dipole}. They give the orientation of
the atom's point dipole moment. The {mu} attribute gives the
magnitude of the atom's dipole moment.
The {radius} and {diameter} attributes are specific to extended
spherical particles that have a finite size, such as those defined
with an atom style of {sphere}.
The {omegax}, {omegay}, and {omegaz} attributes are specific to
extended spherical or aspherical particles that have an angular
velocity. Only certain atom styles, such as {sphere} define this
quantity.
The {angmomx}, {angmomy}, and {angmomz} attributes are specific to
extended aspherical particles that have an angular momentum. Only
the {ellipsoid} atom style defines this quantity.
The {tqx}, {tqy}, {tqz} attributes are for extended spherical or
aspherical particles that can sustain a rotational torque due
to interactions with other particles.
The {spin}, {eradius}, {ervel}, and {erforce} attributes are for
particles that represent nuclei and electrons modeled with the
electronic force field (EFF). See "atom_style
electron"_atom_style.html and "pair_style eff"_pair_eff.html for more
details.
The {c_ID} and {c_ID\[N\]} attributes allow per-atom vectors or arrays
calculated by a "compute"_compute.html to be output. The ID in the
attribute should be replaced by the actual ID of the compute that has
been defined previously in the input script. See the
"compute"_compute.html command for details. There are computes for
calculating the per-atom energy, stress, centro-symmetry parameter,
and coordination number of individual atoms.
Note that computes which calculate global or local quantities, as
opposed to per-atom quantities, cannot be output in a dump custom
command. Instead, global quantities can be output by the
"thermo_style custom"_thermo_style.html command, and local quantities
can be output by the dump local command.
If {c_ID} is used as a attribute, then the per-atom vector calculated
by the compute is printed. If {c_ID\[N\]} is used, then N must be in
the range from 1-M, which will print the Nth column of the M-length
per-atom array calculated by the compute.
The {f_ID} and {f_ID\[N\]} attributes allow vector or array per-atom
quantities calculated by a "fix"_fix.html to be output. The ID in the
attribute should be replaced by the actual ID of the fix that has been
defined previously in the input script. The "fix
ave/atom"_fix_ave_atom.html command is one that calculates per-atom
quantities. Since it can time-average per-atom quantities produced by
any "compute"_compute.html, "fix"_fix.html, or atom-style
"variable"_variable.html, this allows those time-averaged results to
be written to a dump file.
If {f_ID} is used as a attribute, then the per-atom vector calculated
by the fix is printed. If {f_ID\[N\]} is used, then N must be in the
range from 1-M, which will print the Nth column of the M-length
per-atom array calculated by the fix.
The {v_name} attribute allows per-atom vectors calculated by a
"variable"_variable.html to be output. The name in the attribute
should be replaced by the actual name of the variable that has been
defined previously in the input script. Only an atom-style variable
can be referenced, since it is the only style that generates per-atom
values. Variables of style {atom} can reference individual atom
attributes, per-atom atom attributes, thermodynamic keywords, or
invoke other computes, fixes, or variables when they are evaluated, so
this is a very general means of creating quantities to output to a
dump file.
See "Section_modify"_Section_modify.html of the manual for information
on how to add new compute and fix styles to LAMMPS to calculate
per-atom quantities which could then be output into dump files.
:line
[Restrictions:]
To write gzipped dump files, you must compile LAMMPS with the
-DLAMMPS_GZIP option - see the "Making
LAMMPS"_Section_start.html#start_2 section of the documentation.
The {xtc} style is part of the XTC package. It is only enabled if
LAMMPS was built with that package. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info. This is
because some machines may not support the low-level XDR data format
that XTC files are written with, which will result in a compile-time
error when a low-level include file is not found. Putting this style
in a package makes it easy to exclude from a LAMMPS build for those
machines. However, the XTC package also includes two compatibility
header files and associated functions, which should be a suitable
substitute on machines that do not have the appropriate native header
files. This option can be invoked at build time by adding
-DLAMMPS_XDR to the CCFLAGS variable in the appropriate low-level
Makefile, e.g. src/MAKE/Makefile.foo. This compatibility mode has
been tested successfully on Cray XT3/XT4/XT5 and IBM BlueGene/L
machines and should also work on IBM BG/P, and Windows XP/Vista/7
machines.
[Related commands:]
"dump image"_dump_image.html, "dump_modify"_dump_modify.html,
"undump"_undump.html
[Default:]
The defaults for the image style are listed on the "dump
image"_dump_image.html doc page.
diff --git a/doc/fix_nve_line.html b/doc/fix_nve_body.html
similarity index 61%
copy from doc/fix_nve_line.html
copy to doc/fix_nve_body.html
index 2a39e7b17..1cfd4ef04 100644
--- a/doc/fix_nve_line.html
+++ b/doc/fix_nve_body.html
@@ -1,60 +1,67 @@
<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>fix nve/line command
+<H3>fix nve/body command
</H3>
<P><B>Syntax:</B>
</P>
-<PRE>fix ID group-ID nve/line
+<PRE>fix ID group-ID nve/body
</PRE>
<UL><LI>ID, group-ID are documented in <A HREF = "fix.html">fix</A> command
-<LI>nve/line = style name of this fix command
+<LI>nve/body = style name of this fix command
</UL>
<P><B>Examples:</B>
</P>
-<PRE>fix 1 all nve/line
+<PRE>fix 1 all nve/body
</PRE>
<P><B>Description:</B>
</P>
<P>Perform constant NVE integration to update position, velocity,
-orientation, and angular velocity for line segment particles in the
-group each timestep. V is volume; E is energy. This creates a system
-trajectory consistent with the microcanonical ensemble.
+orientation, and angular velocity for body particles in the group each
+timestep. V is volume; E is energy. This creates a system trajectory
+consistent with the microcanonical ensemble. See <A HREF = "Section_howto.html">Section_howto
+22</A> of the manual for an overview of using body
+particles.
</P>
<P>This fix differs from the <A HREF = "fix_nve.html">fix nve</A> command, which
assumes point particles and only updates their position and velocity.
</P>
<P><B>Restart, fix_modify, output, run start/stop, minimize info:</B>
</P>
<P>No information about this fix is written to <A HREF = "restart.html">binary restart
files</A>. None of the <A HREF = "fix_modify.html">fix_modify</A> options
are relevant to this fix. No global or per-atom quantities are stored
by this fix for access by various <A HREF = "Section_howto.html#howto_15">output
commands</A>. No parameter of this fix can
be used with the <I>start/stop</I> keywords of the <A HREF = "run.html">run</A> command.
This fix is not invoked during <A HREF = "minimize.html">energy minimization</A>.
</P>
<P><B>Restrictions:</B>
</P>
-<P>This fix is part of the ASPHERE package. It is only enabled if LAMMPS
+<P>This fix is part of the BODY package. It is 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.
</P>
-<P>This fix requires that particles be line segments as defined by the
-<A HREF = "atom_style.html">atom_style line</A> command.
+<P>This fix requires that atoms store torque and angular momementum and a
+quaternion as defined by the <A HREF = "atom_style.html">atom_style body</A>
+command.
+</P>
+<P>All particles in the group must be body particles. They cannot be
+point particles.
</P>
<P><B>Related commands:</B>
</P>
-<P><A HREF = "fix_nve.html">fix nve</A>, <A HREF = "fix_nve_asphere.html">fix nve/asphere</A>
+<P><A HREF = "fix_nve.html">fix nve</A>, <A HREF = "fix_nve_sphere.html">fix nve/sphere</A>, <A HREF = "fix_nve_asphere.html">fix
+nve/asphere</A>
</P>
<P><B>Default:</B> none
</P>
</HTML>
diff --git a/doc/fix_nve_line.txt b/doc/fix_nve_body.txt
similarity index 58%
copy from doc/fix_nve_line.txt
copy to doc/fix_nve_body.txt
index da93f30db..c74e2b7ff 100755
--- a/doc/fix_nve_line.txt
+++ b/doc/fix_nve_body.txt
@@ -1,55 +1,62 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
-fix nve/line command :h3
+fix nve/body command :h3
[Syntax:]
-fix ID group-ID nve/line :pre
+fix ID group-ID nve/body :pre
ID, group-ID are documented in "fix"_fix.html command
-nve/line = style name of this fix command :ul
+nve/body = style name of this fix command :ul
[Examples:]
-fix 1 all nve/line :pre
+fix 1 all nve/body :pre
[Description:]
Perform constant NVE integration to update position, velocity,
-orientation, and angular velocity for line segment particles in the
-group each timestep. V is volume; E is energy. This creates a system
-trajectory consistent with the microcanonical ensemble.
+orientation, and angular velocity for body particles in the group each
+timestep. V is volume; E is energy. This creates a system trajectory
+consistent with the microcanonical ensemble. See "Section_howto
+22"_Section_howto.html of the manual for an overview of using body
+particles.
This fix differs from the "fix nve"_fix_nve.html command, which
assumes point particles and only updates their position and velocity.
[Restart, fix_modify, output, run start/stop, minimize info:]
No information about this fix is written to "binary restart
files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to this fix. No global or per-atom quantities are stored
by this fix for access by various "output
commands"_Section_howto.html#howto_15. No parameter of this fix can
be used with the {start/stop} keywords of the "run"_run.html command.
This fix is not invoked during "energy minimization"_minimize.html.
[Restrictions:]
-This fix is part of the ASPHERE package. It is only enabled if LAMMPS
+This fix is part of the BODY package. It is only enabled if LAMMPS
was built with that package. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
-This fix requires that particles be line segments as defined by the
-"atom_style line"_atom_style.html command.
+This fix requires that atoms store torque and angular momementum and a
+quaternion as defined by the "atom_style body"_atom_style.html
+command.
+
+All particles in the group must be body particles. They cannot be
+point particles.
[Related commands:]
-"fix nve"_fix_nve.html, "fix nve/asphere"_fix_nve_asphere.html
+"fix nve"_fix_nve.html, "fix nve/sphere"_fix_nve_sphere.html, "fix
+nve/asphere"_fix_nve_asphere.html
[Default:] none
diff --git a/doc/fix_nve_line.html b/doc/fix_nve_line.html
index 2a39e7b17..9b18cfeaa 100644
--- a/doc/fix_nve_line.html
+++ b/doc/fix_nve_line.html
@@ -1,60 +1,62 @@
<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>fix nve/line command
</H3>
<P><B>Syntax:</B>
</P>
<PRE>fix ID group-ID nve/line
</PRE>
<UL><LI>ID, group-ID are documented in <A HREF = "fix.html">fix</A> command
<LI>nve/line = style name of this fix command
</UL>
<P><B>Examples:</B>
</P>
<PRE>fix 1 all nve/line
</PRE>
<P><B>Description:</B>
</P>
<P>Perform constant NVE integration to update position, velocity,
orientation, and angular velocity for line segment particles in the
group each timestep. V is volume; E is energy. This creates a system
-trajectory consistent with the microcanonical ensemble.
+trajectory consistent with the microcanonical ensemble. See
+<A HREF = "Section_howto.html">Section_howto 14</A> of the manual for an overview of
+using line segment particles.
</P>
<P>This fix differs from the <A HREF = "fix_nve.html">fix nve</A> command, which
assumes point particles and only updates their position and velocity.
</P>
<P><B>Restart, fix_modify, output, run start/stop, minimize info:</B>
</P>
<P>No information about this fix is written to <A HREF = "restart.html">binary restart
files</A>. None of the <A HREF = "fix_modify.html">fix_modify</A> options
are relevant to this fix. No global or per-atom quantities are stored
by this fix for access by various <A HREF = "Section_howto.html#howto_15">output
commands</A>. No parameter of this fix can
be used with the <I>start/stop</I> keywords of the <A HREF = "run.html">run</A> command.
This fix is not invoked during <A HREF = "minimize.html">energy minimization</A>.
</P>
<P><B>Restrictions:</B>
</P>
<P>This fix is part of the ASPHERE package. It is 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.
</P>
<P>This fix requires that particles be line segments as defined by the
<A HREF = "atom_style.html">atom_style line</A> command.
</P>
<P><B>Related commands:</B>
</P>
<P><A HREF = "fix_nve.html">fix nve</A>, <A HREF = "fix_nve_asphere.html">fix nve/asphere</A>
</P>
<P><B>Default:</B> none
</P>
</HTML>
diff --git a/doc/fix_nve_line.txt b/doc/fix_nve_line.txt
index da93f30db..5ae29434f 100755
--- a/doc/fix_nve_line.txt
+++ b/doc/fix_nve_line.txt
@@ -1,55 +1,57 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
fix nve/line command :h3
[Syntax:]
fix ID group-ID nve/line :pre
ID, group-ID are documented in "fix"_fix.html command
nve/line = style name of this fix command :ul
[Examples:]
fix 1 all nve/line :pre
[Description:]
Perform constant NVE integration to update position, velocity,
orientation, and angular velocity for line segment particles in the
group each timestep. V is volume; E is energy. This creates a system
-trajectory consistent with the microcanonical ensemble.
+trajectory consistent with the microcanonical ensemble. See
+"Section_howto 14"_Section_howto.html of the manual for an overview of
+using line segment particles.
This fix differs from the "fix nve"_fix_nve.html command, which
assumes point particles and only updates their position and velocity.
[Restart, fix_modify, output, run start/stop, minimize info:]
No information about this fix is written to "binary restart
files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to this fix. No global or per-atom quantities are stored
by this fix for access by various "output
commands"_Section_howto.html#howto_15. No parameter of this fix can
be used with the {start/stop} keywords of the "run"_run.html command.
This fix is not invoked during "energy minimization"_minimize.html.
[Restrictions:]
This fix is part of the ASPHERE package. It is only enabled if LAMMPS
was built with that package. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
This fix requires that particles be line segments as defined by the
"atom_style line"_atom_style.html command.
[Related commands:]
"fix nve"_fix_nve.html, "fix nve/asphere"_fix_nve_asphere.html
[Default:] none
diff --git a/doc/fix_nve_tri.html b/doc/fix_nve_tri.html
index cddb90aba..de9d25b43 100644
--- a/doc/fix_nve_tri.html
+++ b/doc/fix_nve_tri.html
@@ -1,60 +1,62 @@
<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>fix nve/tri command
</H3>
<P><B>Syntax:</B>
</P>
<PRE>fix ID group-ID nve/tri
</PRE>
<UL><LI>ID, group-ID are documented in <A HREF = "fix.html">fix</A> command
<LI>nve/tri = style name of this fix command
</UL>
<P><B>Examples:</B>
</P>
<PRE>fix 1 all nve/tri
</PRE>
<P><B>Description:</B>
</P>
<P>Perform constant NVE integration to update position, velocity,
orientation, and angular momentum for triangular particles in the
group each timestep. V is volume; E is energy. This creates a system
-trajectory consistent with the microcanonical ensemble.
+trajectory consistent with the microcanonical ensemble. See
+<A HREF = "Section_howto.html">Section_howto 14</A> of the manual for an overview of
+using triangular particles.
</P>
<P>This fix differs from the <A HREF = "fix_nve.html">fix nve</A> command, which
assumes point particles and only updates their position and velocity.
</P>
<P><B>Restart, fix_modify, output, run start/stop, minimize info:</B>
</P>
<P>No information about this fix is written to <A HREF = "restart.html">binary restart
files</A>. None of the <A HREF = "fix_modify.html">fix_modify</A> options
are relevant to this fix. No global or per-atom quantities are stored
by this fix for access by various <A HREF = "Section_howto.html#howto_15">output
commands</A>. No parameter of this fix can
be used with the <I>start/stop</I> keywords of the <A HREF = "run.html">run</A> command.
This fix is not invoked during <A HREF = "minimize.html">energy minimization</A>.
</P>
<P><B>Restrictions:</B>
</P>
<P>This fix is part of the ASPHERE package. It is 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.
</P>
<P>This fix requires that particles be triangles as defined by the
<A HREF = "atom_style.html">atom_style tri</A> command.
</P>
<P><B>Related commands:</B>
</P>
<P><A HREF = "fix_nve.html">fix nve</A>, <A HREF = "fix_nve_asphere.html">fix nve/asphere</A>
</P>
<P><B>Default:</B> none
</P>
</HTML>
diff --git a/doc/fix_nve_tri.txt b/doc/fix_nve_tri.txt
index 6ea568b4e..e8ee78609 100755
--- a/doc/fix_nve_tri.txt
+++ b/doc/fix_nve_tri.txt
@@ -1,55 +1,57 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
fix nve/tri command :h3
[Syntax:]
fix ID group-ID nve/tri :pre
ID, group-ID are documented in "fix"_fix.html command
nve/tri = style name of this fix command :ul
[Examples:]
fix 1 all nve/tri :pre
[Description:]
Perform constant NVE integration to update position, velocity,
orientation, and angular momentum for triangular particles in the
group each timestep. V is volume; E is energy. This creates a system
-trajectory consistent with the microcanonical ensemble.
+trajectory consistent with the microcanonical ensemble. See
+"Section_howto 14"_Section_howto.html of the manual for an overview of
+using triangular particles.
This fix differs from the "fix nve"_fix_nve.html command, which
assumes point particles and only updates their position and velocity.
[Restart, fix_modify, output, run start/stop, minimize info:]
No information about this fix is written to "binary restart
files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to this fix. No global or per-atom quantities are stored
by this fix for access by various "output
commands"_Section_howto.html#howto_15. No parameter of this fix can
be used with the {start/stop} keywords of the "run"_run.html command.
This fix is not invoked during "energy minimization"_minimize.html.
[Restrictions:]
This fix is part of the ASPHERE package. It is only enabled if LAMMPS
was built with that package. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
This fix requires that particles be triangles as defined by the
"atom_style tri"_atom_style.html command.
[Related commands:]
"fix nve"_fix_nve.html, "fix nve/asphere"_fix_nve_asphere.html
[Default:] none