diff --git a/doc/src/Howto.rst b/doc/src/Howto.rst index 9423f0dd33..f229deafb3 100644 --- a/doc/src/Howto.rst +++ b/doc/src/Howto.rst @@ -4,10 +4,10 @@ Howto discussions These doc pages describe how to perform various tasks with LAMMPS, both for users and developers. The `glossary `_ 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 ` 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 ============= diff --git a/doc/src/Howto_bpm.rst b/doc/src/Howto_bpm.rst index 46e7e70131..8b84e96b99 100644 --- a/doc/src/Howto_bpm.rst +++ b/doc/src/Howto_bpm.rst @@ -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 ` or :doc:`create bonds ` command. Alternatively, a :doc:`molecule ` template with bonds can be used with -:doc:`fix deposit ` or :doc:`fix pour ` to -create solid grains. +:doc:`fix deposit ` or :doc:`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 -`, only applies pairwise, central body forces. Point -particles must have :doc:`bond atom style ` and may be -thought of as nodes in a spring network. Alternatively, the second -bond style, :doc:`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 -`, :doc:`atom style sphere `. However, -they must also track the current orientation of particles and store bonds -and therefore use a :doc:`bpm/sphere atom style `. -This also requires a unique integrator :doc:`fix nve/bpm/sphere -` which numerically integrates orientation similar -to :doc:`fix nve/asphere `. +Currently, there are two types of bonds included in the BPM package. The +first bond style, :doc:`bond bpm/spring `, only applies +pairwise, central body forces. Point particles must have :doc:`bond atom +style ` and may be thought of as nodes in a spring +network. Alternatively, the second bond style, :doc:`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 `, :doc:`atom style sphere +`. However, they must also track the current orientation of +particles and store bonds, and therefore use a :doc:`bpm/sphere atom +style `. This also requires a unique integrator :doc:`fix +nve/bpm/sphere ` which numerically integrates +orientation similar to :doc:`fix nve/asphere `. In addition to bond styles, a new pair style :doc:`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 ` command. Various properties of bonds can be computed using the :doc:`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 ` @@ -90,7 +89,7 @@ bond settings Alternatively, one can turn off all pair interactions between bonded particles. Unlike :doc:`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 ` bond off @@ -134,7 +133,10 @@ the following are currently compatible with BPM bond styles: * :doc:`fix bond/break ` * :doc:`fix bond/swap ` -Note :doc:`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 ` command requires certain + :doc:`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``. diff --git a/doc/src/Howto_broken_bonds.rst b/doc/src/Howto_broken_bonds.rst index 1a356df510..88c8acb87f 100644 --- a/doc/src/Howto_broken_bonds.rst +++ b/doc/src/Howto_broken_bonds.rst @@ -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 ` 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 ` and the bond styles in the :doc:`BPM package ` which contains the -:doc:`bpm/spring ` and -:doc:`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 ` and :doc:`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 `. diff --git a/doc/src/Howto_couple.rst b/doc/src/Howto_couple.rst index 2f24fa93f8..4cd764adf1 100644 --- a/doc/src/Howto_couple.rst +++ b/doc/src/Howto_couple.rst @@ -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 ` 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 ` 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 ` package, which performs density-functional tight-binding calculations using the `LATTE software - `_ to compute forces, is hooked to + `_ to compute forces, is interfaced to LAMMPS. See the :doc:`fix latte ` command for more - details. Also see the :doc:`Modify ` doc pages for info on - how to add a new fix to LAMMPS. + details. Also see the :doc:`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 ` page for info on how - to add a new command to LAMMPS. + See the :doc:`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 ` 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 - ` 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 ` 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 ` documentation. .. spacer -4. Couple LAMMPS with another code in a client/server fashion, using - using the `MDI Library - `_ +4. Couple LAMMPS with another code in a client/server fashion, using the + `MDI Library `_ developed by the `Molecular Sciences Software Institute (MolSSI) - `_ 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. + `_ 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. diff --git a/doc/src/Howto_library.rst b/doc/src/Howto_library.rst index f63ea64a1b..9b62f0824f 100644 --- a/doc/src/Howto_library.rst +++ b/doc/src/Howto_library.rst @@ -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 ` with other codes, or driven through a :doc:`Python interface `. -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 `, can be used from C and C++, -and is also the basis for the :doc:`Python ` and -:doc:`Fortran ` interfaces or wrappers included in the +files ``src/library.cpp`` and ``src/library.h``. This :ref:`C language +API `, can be used from C and C++, and is also the basis +for the :doc:`Python ` and :doc:`Fortran ` +interfaces or the :ref:`SWIG based wrappers ` included in the LAMMPS source code. The ``examples/COUPLE`` and ``python/examples`` directories contain some diff --git a/doc/src/Howto_mdi.rst b/doc/src/Howto_mdi.rst index 9a26aa9243..9cc947d8aa 100644 --- a/doc/src/Howto_mdi.rst +++ b/doc/src/Howto_mdi.rst @@ -12,11 +12,11 @@ developed by the `Molecular Sciences Software Institute (MolSSI) `_, which is supported by the :ref:`MDI ` package. -Alternate methods for code coupling with LAMMPS are described on the -:doc:`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 ` package provides a :doc:`mdi engine ` -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 ` command which +The package also provides a :doc:`mdi plugin ` 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 ` command in which -LAMMPS operates as an MDI driver in conjunction with a quantum +The package furthermore includes a `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 ` 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 ` 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) -`_ and `INQ -`_. 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) `_ +and `INQ `_. 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 `_. 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 `_ 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 /q-e/MDI/src: +which results in a ``libqemdi.so`` file in ``/q-e/MDI/src``: .. code-block:: bash @@ -149,8 +149,8 @@ which results in a libqemdi.so file in /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 -/inq/build/examples: +plugin mode, which results in a ``libinqmdi.so`` file in +``/inq/build/examples``: .. code-block:: bash diff --git a/doc/src/Howto_multiple.rst b/doc/src/Howto_multiple.rst index f86bcccca4..a0680ccd42 100644 --- a/doc/src/Howto_multiple.rst +++ b/doc/src/Howto_multiple.rst @@ -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 ` command multiple times. For example, this script diff --git a/doc/src/Howto_replica.rst b/doc/src/Howto_replica.rst index d286762e01..5504133426 100644 --- a/doc/src/Howto_replica.rst +++ b/doc/src/Howto_replica.rst @@ -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. diff --git a/doc/src/Howto_restart.rst b/doc/src/Howto_restart.rst index 25f311f5a7..545e98137c 100644 --- a/doc/src/Howto_restart.rst +++ b/doc/src/Howto_restart.rst @@ -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 ` command. At a later time, these binary files can be read via a :doc:`read_restart ` command in a new script. Or they can -be converted to text data files using the :doc:`-r command-line switch ` and read by a :doc:`read_data ` -command in a new script. +be converted to text data files using the :doc:`-r command-line switch +` and read by a :doc:`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 ` 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. diff --git a/doc/src/Howto_viz.rst b/doc/src/Howto_viz.rst index 28ecbfb838..5de8b000a1 100644 --- a/doc/src/Howto_viz.rst +++ b/doc/src/Howto_viz.rst @@ -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 ` 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 `_ for MD +simulation trajectories. `OVITO `_ and `VMD +`_ seem to be the most popular +choices among them. -LAMMPS snapshots are created by the :doc:`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 ` and :doc:`dump movie ` 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 ` page for details. +The :doc:`dump image ` and :doc:`dump movie ` +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 `_ for details. Specifically, Pizza.py can convert LAMMPS -dump files into PDB, XYZ, `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 +` page for details. These are rarely needed these days.