ICODE-ADC/lammps
4
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

revise a chunk of Howto pages with the help of languagetool.org

Browse Source
This commit is contained in:
Axel Kohlmeyer
2023-02-05 18:09:36 -05:00
parent d1550bf9f6
commit 3955bc8bfe
10 changed files with 153 additions and 164 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
doc/src/Howto.rst
View File

@ -4,10 +4,10 @@ Howto discussions
These doc pages describe how to perform various tasks with LAMMPS,
both for users and developers. The
`glossary <https://www.lammps.org/glossary.html>`_ website page also lists MD
terminology with links to corresponding LAMMPS manual pages. The
example input scripts included in the examples directory of the LAMMPS
distribution and highlighted on the :doc:`Examples <Examples>` doc page
also show how to setup and run various kinds of simulations.
terminology, with links to corresponding LAMMPS manual pages. The
example input scripts included in the ``examples`` directory of the LAMMPS
source code distribution and highlighted on the :doc:`Examples` page
also show how to set up and run various kinds of simulations.
General howto
=============

58
doc/src/Howto_bpm.rst
View File

@ -3,16 +3,16 @@ Bonded particle models
The BPM package implements bonded particle models which can be used to
simulate mesoscale solids. Solids are constructed as a collection of
particles which each represent a coarse-grained region of space much
larger than the atomistic scale. Particles within a solid region are
particles, which each represent a coarse-grained region of space much
larger than the atomistic scale. Particles within a solid region are
then connected by a network of bonds to provide solid elasticity.
Unlike traditional bonds in molecular dynamics, the equilibrium bond
length can vary between bonds. Bonds store the reference state. This
includes setting the equilibrium length equal to the initial distance
between the two particles but can also include data on the bond
orientation for rotational models. This produces a stress free initial
state. Furthermore, bonds are allowed to break under large strains
between the two particles, but can also include data on the bond
orientation for rotational models. This produces a stress-free initial
state. Furthermore, bonds are allowed to break under large strains,
producing fracture. The examples/bpm directory has sample input scripts
for simulations of the fragmentation of an impacted plate and the
pouring of extended, elastic bodies.
@ -22,8 +22,8 @@ pouring of extended, elastic bodies.
Bonds can be created using a :doc:`read data <read_data>` or
:doc:`create bonds <create_bonds>` command. Alternatively, a
:doc:`molecule <molecule>` template with bonds can be used with
:doc:`fix deposit <fix_deposit>` or :doc:`fix pour <fix_pour>` to
create solid grains.
:doc:`fix deposit <fix_deposit>` or :doc:`fix pour <fix_pour>` to create
solid grains.
In this implementation, bonds store their reference state when they are
first computed in the setup of the first simulation run. Data is then
@ -35,21 +35,20 @@ such as those created by pouring grains using :doc:`fix pour
----------
Currently there are two types of bonds included in the BPM
package. The first bond style, :doc:`bond bpm/spring
<bond_bpm_spring>`, only applies pairwise, central body forces. Point
particles must have :doc:`bond atom style <atom_style>` and may be
thought of as nodes in a spring network. Alternatively, the second
bond style, :doc:`bond bpm/rotational <bond_bpm_rotational>`, resolves
tangential forces and torques arising with the shearing, bending, and
twisting of the bond due to rotation or displacement of particles.
Particles are similar to those used in the :doc:`granular package
<Howto_granular>`, :doc:`atom style sphere <atom_style>`. However,
they must also track the current orientation of particles and store bonds
and therefore use a :doc:`bpm/sphere atom style <atom_style>`.
This also requires a unique integrator :doc:`fix nve/bpm/sphere
<fix_nve_bpm_sphere>` which numerically integrates orientation similar
to :doc:`fix nve/asphere <fix_nve_asphere>`.
Currently, there are two types of bonds included in the BPM package. The
first bond style, :doc:`bond bpm/spring <bond_bpm_spring>`, only applies
pairwise, central body forces. Point particles must have :doc:`bond atom
style <atom_style>` and may be thought of as nodes in a spring
network. Alternatively, the second bond style, :doc:`bond bpm/rotational
<bond_bpm_rotational>`, resolves tangential forces and torques arising
with the shearing, bending, and twisting of the bond due to rotation or
displacement of particles. Particles are similar to those used in the
:doc:`granular package <Howto_granular>`, :doc:`atom style sphere
<atom_style>`. However, they must also track the current orientation of
particles and store bonds, and therefore use a :doc:`bpm/sphere atom
style <atom_style>`. This also requires a unique integrator :doc:`fix
nve/bpm/sphere <fix_nve_bpm_sphere>` which numerically integrates
orientation similar to :doc:`fix nve/asphere <fix_nve_asphere>`.
In addition to bond styles, a new pair style :doc:`pair bpm/spring
<pair_bpm_spring>` was added to accompany the bpm/spring bond
@ -63,7 +62,7 @@ A list of IDs for bonded atoms can be generated using the
:doc:`compute property/local <compute_property_local>` command.
Various properties of bonds can be computed using the
:doc:`compute bond/local <compute_bond_local>` command. This
command allows one to access data saved to the bond's history
command allows one to access data saved to the bond's history,
such as the reference length of the bond. More information on
bond history data can be found on the documentation pages for the specific
BPM bond styles. Finally, this data can be output using a :doc:`dump local <dump>`
@ -90,7 +89,7 @@ bond settings
Alternatively, one can turn off all pair interactions between bonded
particles. Unlike :doc:`bond quartic <bond_quartic>`, this is not done
by subtracting pair forces during the bond computation but rather by
by subtracting pair forces during the bond computation, but rather by
dynamically updating the special bond list. This is the default behavior
of BPM bond styles and is done by updating the 1-2 special bond list as
bonds break. To do this, LAMMPS requires :doc:`newton <newton>` bond off
@ -134,7 +133,10 @@ the following are currently compatible with BPM bond styles:
* :doc:`fix bond/break <fix_bond_break>`
* :doc:`fix bond/swap <fix_bond_swap>`
Note :doc:`create_bonds <create_bonds>` requires certain special_bonds settings.
To subtract pair interactions, one will need to switch between different
special_bonds settings in the input script. An example is found in
examples/bpm/impact.
.. note::
The :doc:`create_bonds <create_bonds>` command requires certain
:doc:`special_bonds <special_bonds>` settings. To subtract pair
interactions, one will need to switch between different *special_bonds*
settings in the input script. An example is found in
``examples/bpm/impact``.

16
doc/src/Howto_broken_bonds.rst
View File

@ -1,15 +1,15 @@
Broken Bonds
============
Typically, bond interactions persist for the duration of a simulation
in LAMMPS. However, there are some exceptions that allow for bonds to
break including the :doc:`quartic bond style <bond_quartic>` and the
Typically, bond interactions persist for the duration of a simulation in
LAMMPS. However, there are some exceptions that allow for bonds to
break, including the :doc:`quartic bond style <bond_quartic>` and the
bond styles in the :doc:`BPM package <Howto_bpm>` which contains the
:doc:`bpm/spring <bond_bpm_spring>` and
:doc:`bpm/rotational <bond_bpm_rotational>` bond styles. In these cases,
a bond can be broken if it is stretched beyond a user-defined threshold.
LAMMPS accomplishes this by setting the bond type to zero such that the
bond force is no longer computed.
:doc:`bpm/spring <bond_bpm_spring>` and :doc:`bpm/rotational
<bond_bpm_rotational>` bond styles. In these cases, a bond can be broken
if it is stretched beyond a user-defined threshold. LAMMPS accomplishes
this by setting the bond type to 0, such that the bond force is no
longer computed.
Users are normally able to weight the contribution of pair forces to atoms
that are bonded using the :doc:`special_bonds command <special_bonds>`.

56
doc/src/Howto_couple.rst
View File

@ -1,27 +1,27 @@
Coupling LAMMPS to other codes
==============================
LAMMPS is designed to allow it to be coupled to other codes. For
LAMMPS is designed to support being coupled to other codes. For
example, a quantum mechanics code might compute forces on a subset of
atoms and pass those forces to LAMMPS. Or a continuum finite element
(FE) simulation might use atom positions as boundary conditions on FE
nodal points, compute a FE solution, and return interpolated forces on
MD atoms.
LAMMPS can be coupled to other codes in at least 4 ways. Each has
advantages and disadvantages, which you will have to think about in the
context of your application.
LAMMPS can be coupled to other codes in at least 4 different ways. Each
has advantages and disadvantages, which you will have to think about in
the context of your application.
1. Define a new :doc:`fix <fix>` command that calls the other code.
In this scenario, LAMMPS is the driver code. During timestepping,
the fix is invoked, and can make library calls to the other code,
which has been linked to LAMMPS as a library. This is the way the
1. Define a new :doc:`fix <fix>` command that calls the other code. In
this scenario, LAMMPS is the driver code. During timestepping, the
fix is invoked, and can make library calls to the other code, which
has been linked to LAMMPS as a library. This is the way the
:ref:`LATTE <PKG-LATTE>` package, which performs density-functional
tight-binding calculations using the `LATTE software
<https://github.com/lanl/LATTE>`_ to compute forces, is hooked to
<https://github.com/lanl/LATTE>`_ to compute forces, is interfaced to
LAMMPS. See the :doc:`fix latte <fix_latte>` command for more
details. Also see the :doc:`Modify <Modify>` doc pages for info on
how to add a new fix to LAMMPS.
details. Also see the :doc:`Modify <Modify>` pages for information
on how to add a new fix to LAMMPS.
.. spacer
@ -42,28 +42,26 @@ context of your application.
stand-alone code could communicate with LAMMPS through files that the
command writes and reads.
See the :doc:`Modify command <Modify_command>` page for info on how
to add a new command to LAMMPS.
See the :doc:`Modify command <Modify_command>` page for information
on how to add a new command to LAMMPS.
.. spacer
3. Use LAMMPS as a library called by another code. In this case the
other code is the driver and calls LAMMPS as needed. Or a wrapper
code could link and call both LAMMPS and another code as libraries.
Again, the :doc:`run <run>` command has options that allow it to be
invoked with minimal overhead (no setup or clean-up) if you wish to
do multiple short runs, driven by another program. Details about
using the library interface are given in the :doc:`library API
<Library>` documentation.
3. Use LAMMPS as a library called by another code. In this case, the
other code is the driver and calls LAMMPS as needed. Alternately, a
wrapper code could link and call both LAMMPS and another code as
libraries. Again, the :doc:`run <run>` command has options that
allow it to be invoked with minimal overhead (no setup or clean-up)
if you wish to do multiple short runs, driven by another program.
Details about using the library interface are given in the
:doc:`library API <Library>` documentation.
.. spacer
4. Couple LAMMPS with another code in a client/server fashion, using
using the `MDI Library
<https://molssi-mdi.github.io/MDI_Library/html/index.html>`_
4. Couple LAMMPS with another code in a client/server fashion, using the
`MDI Library <https://molssi-mdi.github.io/MDI_Library/html/index.html>`_
developed by the `Molecular Sciences Software Institute (MolSSI)
<https://molssi.org>`_ to run LAMMPS as either an MDI driver
(client) or an MDI engine (server). The MDI driver issues commands
to the MDI server to exchange data between them. See the
:doc:`Howto mdi <Howto_mdi>` page for more information about how
LAMMPS can operate in either of these modes.
<https://molssi.org>`_ to run LAMMPS as either an MDI driver (client)
or an MDI engine (server). The MDI driver issues commands to the MDI
server to exchange data between them. See the :doc:`Howto_mdi` page for
more information about how LAMMPS can operate in either of these modes.

18
doc/src/Howto_library.rst
View File

@ -6,22 +6,22 @@ can be built as a static or shared library, so that it can be called by
another code, used in a :doc:`coupled manner <Howto_couple>` with other
codes, or driven through a :doc:`Python interface <Python_head>`.
At the core of LAMMPS is the ``LAMMPS`` class which encapsulates the
At the core of LAMMPS is the ``LAMMPS`` class, which encapsulates the
state of the simulation program through the state of the various class
instances that it is composed of. So a calculation using LAMMPS
requires to create an instance of the ``LAMMPS`` class and then send it
requires creating an instance of the ``LAMMPS`` class and then send it
(text) commands, either individually or from a file, or perform other
operations that modify the state stored inside that instance or drive
simulations. This is essentially what the ``src/main.cpp`` file does
as well for the standalone LAMMPS executable with reading commands
either from an input file or stdin.
simulations. This is essentially what the ``src/main.cpp`` file does as
well for the standalone LAMMPS executable, reading commands either from
an input file or the standard input.
Creating a LAMMPS instance can be done by using C++ code directly or
through a C-style interface library to LAMMPS that is provided in the
files ``src/library.cpp`` and ``library.h``. This
:ref:`C language API <lammps_c_api>`, can be used from C and C++,
and is also the basis for the :doc:`Python <Python_module>` and
:doc:`Fortran <Fortran>` interfaces or wrappers included in the
files ``src/library.cpp`` and ``src/library.h``. This :ref:`C language
API <lammps_c_api>`, can be used from C and C++, and is also the basis
for the :doc:`Python <Python_module>` and :doc:`Fortran <Fortran>`
interfaces or the :ref:`SWIG based wrappers <swig>` included in the
LAMMPS source code.
The ``examples/COUPLE`` and ``python/examples`` directories contain some

100
doc/src/Howto_mdi.rst
View File

@ -12,11 +12,11 @@ developed by the `Molecular Sciences Software Institute (MolSSI)
<https://molssi.org>`_, which is supported by the :ref:`MDI <PKG-MDI>`
package.
Alternate methods for code coupling with LAMMPS are described on the
:doc:`Howto couple <Howto_couple>` doc page.
Alternate methods for coupling codes with LAMMPS are described on the
:doc:`Howto_couple` page.
Some advantages of client/server coupling are that the codes can run
as stand-alone executables; they need not be linked together. Thus
as stand-alone executables; they need not be linked together. Thus,
neither code needs to have a library interface. This also makes it
easy to run the two codes on different numbers of processors. If a
message protocol (format and content) is defined for a particular kind
@ -41,7 +41,7 @@ within that sub-communicator exchange messages with the corresponding
engine instance, and can also send MPI messages to other processors in
the driver. The driver code can also destroy engine instances and
re-instantiate them. LAMMPS can operate as either a stand-alone or
plugin MDI engine. When it operates as a driver, if can use either
plugin MDI engine. When it operates as a driver, it can use either
stand-alone or plugin MDI engines.
The way in which an MDI driver communicates with an MDI engine is by
@ -50,83 +50,83 @@ to MPI_Send() and MPI_Recv() calls. Each send or receive operation
uses a string to identify the command name, and optionally some data,
which can be a single value or vector of values of any data type.
Inside the MDI library, data is exchanged between the driver and
engine via MPI calls or sockets. This a run-time choice by the user.
engine via MPI calls or sockets. This is a run-time choice by the user.
----------
The :ref:`MDI <PKG-MDI>` package provides a :doc:`mdi engine <mdi>`
command which enables LAMMPS to operate as an MDI engine. Its doc
command, which enables LAMMPS to operate as an MDI engine. Its doc
page explains the variety of standard and custom MDI commands which
the LAMMPS engine recognizes and can respond to.
The package also provides a :doc:`mdi plugin <mdi>` command which
The package also provides a :doc:`mdi plugin <mdi>` command, which
enables LAMMPS to operate as an MDI driver and load an MDI engine as a
plugin library.
The package also has a `fix mdi/qm <fix_mdi_qm>` command in which
LAMMPS operates as an MDI driver in conjunction with a quantum
The package furthermore includes a `fix mdi/qm <fix_mdi_qm>` command, in
which LAMMPS operates as an MDI driver in conjunction with a quantum
mechanics code as an MDI engine. The post_force() method of the
fix_mdi_qm.cpp file shows how a driver issues MDI commands to another
code. This command can be used to couple to an MDI engine which is
``fix_mdi_qm.cpp`` file shows how a driver issues MDI commands to another
code. This command can be used to couple to an MDI engine, which is
either a stand-alone code or a plugin library.
As explained on the `fix mdi/qm <fix_mdi_qm>` command doc page, it can
be used to perform *ab initio* MD simulations or energy minimizations,
or to evaluate the quantum energy and forces for a series of
independent systems. The examples/mdi directory has example input
scripts for all of these use cases.
As explained in the `fix mdi/qm <fix_mdi_qm>` command documentation, it
can be used to perform *ab initio* MD simulations or energy
minimizations, or to evaluate the quantum energy and forces for a series
of independent systems. The ``examples/mdi`` directory has example
input scripts for all of these use cases.
----------
The examples/mdi directory contains Python scripts and LAMMPS input
script which use LAMMPS as either an MDI driver or engine or both.
script which use LAMMPS as either an MDI driver or engine, or both.
Currently, 5 example use cases are provided:
* Run ab initio MD (AIMD) using 2 instances of LAMMPS. As a driver
* Run ab initio MD (AIMD) using 2 instances of LAMMPS. As a driver,
LAMMPS performs the timestepping in either NVE or NPT mode. As an
engine, LAMMPS computes forces and is a surrogate for a quantum
code.
* As a driver, LAMMPS runs an MD simulation. Every N steps it passes
the current snapshot to an MDI engine to evaluate the energy,
virial, and peratom forces. As the engine LAMMPS is a surrogate for
a quantum code.
* As a driver, LAMMPS loops over a series of data files and passes the
configuration to an MDI engine to evaluate the energy, virial, and
peratom forces. As the engine LAMMPS is a surrogate for a quantum
* LAMMPS runs an MD simulation as a driver. Every N steps it passes the
current snapshot to an MDI engine to evaluate the energy, virial, and
peratom forces. As the engine, LAMMPS is a surrogate for a quantum
code.
* LAMMPS loops over a series of data files and passes the configuration
to an MDI engine to evaluate the energy, virial, and peratom forces
and thus acts as a simulation driver. As the engine, LAMMPS is used
as a surrogate for a quantum code.
* A Python script driver invokes a sequence of unrelated LAMMPS
calculations. Calculations can be single-point energy/force
evaluations, MD runs, or energy minimizations.
* Run AIMD with a Python driver code and 2 LAMMPS instances as
engines. The first LAMMPS instance performs MD timestepping. The
second LAMMPS instance acts as a surrogate QM code to compute
forces.
* Run AIMD with a Python driver code and 2 LAMMPS instances as engines.
The first LAMMPS instance performs MD timestepping. The second LAMMPS
instance acts as a surrogate QM code to compute forces.
Note that in any of these example where LAMMPS is used as an engine,
an actual QM code (which supports MDI) could be used in its place,
without modifying the input scripts or launch commands, except to
specify the name of the QM code.
.. note::
The examples/mdi/Run.sh file illustrates how to launch both driver and
engine codes so that they communicate using the MDI library via either
MPI or sockets. Or using the engine as a stand-alone code or plugin
library.
In any of these example where LAMMPS is used as an engine, an actual
QM code (proivded it has support for MDI) could be used in its place,
without modifying the input scripts or launch commands, except to
specify the name of the QM code.
The ``examples/mdi/Run.sh`` file illustrates how to launch both driver
and engine codes so that they communicate using the MDI library via
either MPI or sockets, or using the engine as a stand-alone code, or
as a plugin library.
-------------
Currently there are at least two quantum DFT codes which have direct
MDI support, `Quantum ESPRESSO (QE)
<https://www.quantum-espresso.org/>`_ and `INQ
<https://qsg.llnl.gov/node/101.html>`_. There are also several QM
codes which have indirect support through QCEngine or i-PI. The
former means they require a wrapper program (QCEngine) with MDI
support which writes/read files to pass data to the quantum code
itself. The list of QCEngine-supported and i-PI-supported quantum
codes is on the `MDI webpage
Currently, there are at least two quantum DFT codes which have direct MDI
support, `Quantum ESPRESSO (QE) <https://www.quantum-espresso.org/>`_
and `INQ <https://qsg.llnl.gov/node/101.html>`_. There are also several
QM codes which have indirect support through QCEngine or i-PI. The
former means they require a wrapper program (QCEngine) with MDI support
which writes/read files to pass data to the quantum code itself. The
list of QCEngine-supported and i-PI-supported quantum codes is on the
`MDI webpage
<https://molssi-mdi.github.io/MDI_Library/html/index.html>`_.
Here is how to build QE as a stand-alone ``pw.x`` file which can be
@ -138,7 +138,7 @@ used in stand-alone mode:
build the executable pw.x, following the `QE build guide <https://gitlab.com/QEF/q-e/-/wikis/Developers/CMake-build-system>`_
Here is how to build QE as a shared library which can be used in plugin mode,
which results in a libqemdi.so file in <base_path>/q-e/MDI/src:
which results in a ``libqemdi.so`` file in ``<base_path>/q-e/MDI/src``:
.. code-block:: bash
@ -149,8 +149,8 @@ which results in a libqemdi.so file in <base_path>/q-e/MDI/src:
INQ cannot be built as a stand-alone code; it is by design a library.
Here is how to build INQ as a shared library which can be used in
plugin mode, which results in a libinqmdi.so file in
<base_path>/inq/build/examples:
plugin mode, which results in a ``libinqmdi.so`` file in
``<base_path>/inq/build/examples``:
.. code-block:: bash

2
doc/src/Howto_multiple.rst
View File

@ -4,7 +4,7 @@ Run multiple simulations from one input script
This can be done in several ways. See the documentation for
individual commands for more details on how these examples work.
If "multiple simulations" means continue a previous simulation for
If "multiple simulations" means to continue a previous simulation for
more timesteps, then you simply use the :doc:`run <run>` command
multiple times. For example, this script

4
doc/src/Howto_replica.rst
View File

@ -47,9 +47,9 @@ script which is required when running in multi-replica mode.
Also note that with MPI installed on a machine (e.g. your desktop), you
can run on more (virtual) processors than you have physical processors.
Thus the above commands could be run on a single-processor (or
Thus, the above commands could be run on a single-processor (or
few-processor) desktop so that you can run a multi-replica simulation on
more replicas than you have physical processors. This is useful for
testing and debugging, since with most modern processors and MPI
libraries the efficiency of a calculation can severely diminish when
libraries, the efficiency of a calculation can severely diminish when
oversubscribing processors.

13
doc/src/Howto_restart.rst
View File

@ -7,8 +7,9 @@ run will continue from where the previous run left off. Or binary
restart files can be saved to disk using the :doc:`restart <restart>`
command. At a later time, these binary files can be read via a
:doc:`read_restart <read_restart>` command in a new script. Or they can
be converted to text data files using the :doc:`-r command-line switch <Run_options>` and read by a :doc:`read_data <read_data>`
command in a new script.
be converted to text data files using the :doc:`-r command-line switch
<Run_options>` and read by a :doc:`read_data <read_data>` command in a
new script.
Here we give examples of 2 scripts that read either a binary restart
file or a converted data file and then issue a new run command to
@ -47,7 +48,7 @@ last 50 timesteps:
Note that the following commands do not need to be repeated because
their settings are included in the restart file: *units, atom_style,
special_bonds, pair_style, bond_style*. However these commands do
special_bonds, pair_style, bond_style*. However, these commands do
need to be used, since their settings are not in the restart file:
*neighbor, fix, timestep*\ .
@ -90,7 +91,7 @@ Then, this script could be used to re-run the last 50 steps:
Note that nearly all the settings specified in the original *in.chain*
script must be repeated, except the *pair_coeff* and *bond_coeff*
commands since the new data file lists the force field coefficients.
commands, since the new data file lists the force field coefficients.
Also, the :doc:`reset_timestep <reset_timestep>` command is used to tell
LAMMPS the current timestep. This value is stored in restart files,
but not in data files.
LAMMPS the current timestep. This value is stored in restart files, but
not in data files.

42
doc/src/Howto_viz.rst
View File

@ -1,33 +1,21 @@
Visualize LAMMPS snapshots
==========================
LAMMPS itself does not do visualization, but snapshots from LAMMPS
simulations can be visualized (and analyzed) in a variety of ways.
Snapshots from LAMMPS simulations can be viewed, visualized, and
analyzed in a variety of ways.
Mention dump image and dump movie.
LAMMPS snapshots are created by the :doc:`dump <dump>` command, which
can create files in several formats. The native LAMMPS dump format is a
text file (see "dump atom" or "dump custom") which can be visualized by
`several visualization tools <https://www.lammps.org/viz.html>`_ for MD
simulation trajectories. `OVITO <https://www.ovito.org>`_ and `VMD
<https://www.ks.uiuc.edu/Research/vmd>`_ seem to be the most popular
choices among them.
LAMMPS snapshots are created by the :doc:`dump <dump>` command which can
create files in several formats. The native LAMMPS dump format is a
text file (see "dump atom" or "dump custom") which can be visualized
by several popular visualization tools. The :doc:`dump image <dump_image>` and :doc:`dump movie <dump_image>` styles can
output internally rendered images and convert a sequence of them to a
movie during the MD run. Several programs included with LAMMPS as
auxiliary tools can convert between LAMMPS format files and other
formats. See the :doc:`Tools <Tools>` page for details.
The :doc:`dump image <dump_image>` and :doc:`dump movie <dump_image>`
styles can output internally rendered images or convert them to a movie
during the MD run.
A Python-based toolkit distributed by our group can read native LAMMPS
dump files, including custom dump files with additional columns of
user-specified atom information, and convert them to various formats or
pipe them into visualization software directly. See the `Pizza.py WWW
site <pizza_>`_ for details. Specifically, Pizza.py can convert LAMMPS
dump files into PDB, XYZ, `EnSight <ensight_>`_, and VTK formats.
Pizza.py can pipe LAMMPS dump files directly into the Raster3d and
RasMol visualization programs. Pizza.py has tools that do interactive
3d OpenGL visualization and one that creates SVG images of dump file
snapshots.
.. _pizza: https://lammps.github.io/pizza
.. _ensight: https://www.ansys.com/products/fluids/ansys-ensight
.. _atomeye: http://li.mit.edu/Archive/Graphics/A/
Programs included with LAMMPS as auxiliary tools can convert
between LAMMPS format files and other formats. See the :doc:`Tools
<Tools>` page for details. These are rarely needed these days.