Merge branch 'lammps:develop' into alphataubio-kokkos-fixes
This commit is contained in:
alphataubio
@ -138,12 +138,27 @@ during development:
|
||||
The status of this automated testing can be viewed on `https://ci.lammps.org
|
||||
<https://ci.lammps.org>`_.
|
||||
|
||||
The scripts and inputs for integration, run, and regression testing
|
||||
are maintained in a
|
||||
`separate repository <https://github.com/lammps/lammps-testing>`_
|
||||
of the LAMMPS project on GitHub. A few tests are also run as GitHub
|
||||
Actions and their configuration files are in the ``.github/workflows/``
|
||||
folder of the LAMMPS git tree.
|
||||
The scripts and inputs for integration, run, and legacy regression
|
||||
testing are maintained in a `separate repository
|
||||
<https://github.com/lammps/lammps-testing>`_ of the LAMMPS project on
|
||||
GitHub. A few tests are also run as GitHub Actions and their
|
||||
configuration files are in the ``.github/workflows/`` folder of the
|
||||
LAMMPS git tree.
|
||||
|
||||
Regression tests can also be performed locally with the :ref:`regression
|
||||
tester tool <regression>`. The tool checks if a given LAMMPS binary run
|
||||
with selected input examples produces thermo output that is consistent
|
||||
with the provided log files. The script can be run in one pass over all
|
||||
available input files, but it can also first create multiple lists of
|
||||
inputs or folders that can then be run with multiple workers
|
||||
concurrently to speed things up. Another mode allows to do a quick
|
||||
check of inputs that contain commands that have changes in the current
|
||||
checkout branch relative to a git branch. This works similar to the two
|
||||
pass mode, but will select only shorter runs and no more than 100 inputs
|
||||
that are chosen randomly. This ensures that this test runs
|
||||
significantly faster compared to the full test run. These test runs can
|
||||
also be performed with instrumented LAMMPS binaries (see previous
|
||||
section).
|
||||
|
||||
The unit testing facility is integrated into the CMake build process of
|
||||
the LAMMPS source code distribution itself. It can be enabled by
|
||||
|
||||
@ -2251,28 +2251,38 @@ verified to work in February 2020 with Quantum Espresso versions 6.3 to
|
||||
RHEO package
|
||||
------------
|
||||
|
||||
To build with this package you must have the `GNU Scientific Library
|
||||
(GSL) <https://www.gnu.org/software/gsl/>` installed in locations that
|
||||
are accessible in your environment. The GSL library should be at least
|
||||
version 2.7.
|
||||
This package depends on the BPM package.
|
||||
|
||||
.. tabs::
|
||||
|
||||
.. tab:: CMake build
|
||||
|
||||
If CMake cannot find the GSL library or include files, you can set:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
-D GSL_ROOT_DIR=path # path to root of GSL installation
|
||||
-D PKG_RHEO=yes # enable the package itself
|
||||
-D PKG_BPM=yes # the RHEO package requires BPM
|
||||
-D USE_INTERNAL_LINALG=value # prefer internal LAPACK if true
|
||||
|
||||
Some features in the RHEO package are dependent on code in the BPM
|
||||
package so the latter one *must* be enabled as well.
|
||||
|
||||
The RHEO package also requires LAPACK (and BLAS) and CMake
|
||||
can identify their locations and pass that info to the RHEO
|
||||
build script. But on some systems this may cause problems when
|
||||
linking or the dependency is not desired. By using the setting
|
||||
``-D USE_INTERNAL_LINALG=yes`` when running the CMake
|
||||
configuration, you will select compiling and linking the bundled
|
||||
linear algebra library and work around the limitations.
|
||||
|
||||
.. tab:: Traditional make
|
||||
|
||||
LAMMPS will try to auto-detect the GSL compiler and linker flags
|
||||
from the corresponding ``pkg-config`` file (``gsl.pc``), otherwise
|
||||
you can edit the file ``lib/rheo/Makefile.lammps``
|
||||
to specify the paths and library names where indicated by comments.
|
||||
This must be done **before** the package is installed.
|
||||
The RHEO package requires LAPACK (and BLAS) which can be either
|
||||
a system provided library or the bundled "linalg" library. This
|
||||
is a subset of LAPACK translated to C++. For that, one of the
|
||||
provided ``Makefile.lammps.<config>`` files needs to be copied
|
||||
to ``Makefile.lammps`` and edited as needed. The default file
|
||||
uses the bundled "linalg" library, which can be built by
|
||||
``make lib-linalg args='-m serial'`` in the ``src`` folder.
|
||||
|
||||
----------
|
||||
|
||||
|
||||
@ -229,8 +229,7 @@ can be used with the Intel or GNU compiler (see the ``FFT_LIB`` setting
|
||||
above).
|
||||
|
||||
The NVIDIA Performance Libraries (NVPL) FFT library is optimized for NVIDIA
|
||||
Grace Armv9.0 architecture. You can download it from
|
||||
`https://docs.nvidia.com/nvpl/`_.
|
||||
Grace Armv9.0 architecture. You can download it from https://docs.nvidia.com/nvpl/
|
||||
|
||||
The cuFFT and hipFFT FFT libraries are packaged with NVIDIA's CUDA and
|
||||
AMD's HIP installations, respectively. These FFT libraries require the
|
||||
|
||||
@ -56,7 +56,7 @@ lammps.org". General questions about LAMMPS should be posted in the
|
||||
- SNL
|
||||
- jmgoff at sandia.gov
|
||||
- machine learned potentials, QEq solvers, Python
|
||||
* - Megan McCarthy
|
||||
* - Meg McCarthy
|
||||
- SNL
|
||||
- megmcca at sandia.gov
|
||||
- alloys, micro-structure, machine learned potentials
|
||||
@ -67,7 +67,7 @@ lammps.org". General questions about LAMMPS should be posted in the
|
||||
* - `Trung Nguyen <tn_>`_
|
||||
- U Chicago
|
||||
- ndactrung at gmail.com
|
||||
- soft matter, GPU package
|
||||
- soft matter, GPU package, DIELECTRIC package, regression testing
|
||||
|
||||
.. _rb: https://rbberger.github.io/
|
||||
.. _gc: https://enthalpiste.fr/
|
||||
|
||||
@ -3,71 +3,70 @@ Running LAMMPS on Windows
|
||||
|
||||
To run a serial (non-MPI) executable, follow these steps:
|
||||
|
||||
* Get a command prompt by going to Start->Run... ,
|
||||
then typing "cmd".
|
||||
* Move to the directory where you have your input script,
|
||||
* Install a LAMMPS installer package from https://packages.lammps.org/windows.html
|
||||
* Open the "Command Prompt" or "Terminal" app.
|
||||
* Change to the directory where you have your input script,
|
||||
(e.g. by typing: cd "Documents").
|
||||
* At the command prompt, type "lmp -in in.file", where
|
||||
in.file is the name of your LAMMPS input script.
|
||||
* At the command prompt, type "lmp -in in.file.lmp", where
|
||||
``in.file.lmp`` is the name of your LAMMPS input script.
|
||||
|
||||
Note that the serial executable includes support for multi-threading
|
||||
parallelization from the styles in the OPENMP packages. To run with
|
||||
4 threads, you can type this:
|
||||
parallelization from the styles in the OPENMP and KOKKOS packages.
|
||||
To run with 4 threads, you can type this:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
lmp -in in.lj -pk omp 4 -sf omp
|
||||
lmp -in in.lj.lmp -pk omp 4 -sf omp
|
||||
lmp -in in.lj.lmp -k on t 4 -sf kk
|
||||
|
||||
Alternately, you can also install a package with LAMMPS-GUI included and
|
||||
open the LAMMPS-GUI app (the package includes the command line version
|
||||
of LAMMPS as well) and open the input file in the GUI and run it from
|
||||
there. For details on LAMMPS-GUI, see :doc:`Howto_lammps_gui`.
|
||||
|
||||
----------
|
||||
|
||||
For the MPI executable, which allows you to run LAMMPS under Windows
|
||||
in parallel, follow these steps.
|
||||
For the MS-MPI executables, which allow you to run LAMMPS under Windows
|
||||
in parallel using MPI rather than multi-threading, follow these steps.
|
||||
|
||||
Download and install a compatible MPI library binary package:
|
||||
|
||||
* for 32-bit Windows: `mpich2-1.4.1p1-win-ia32.msi <https://download.lammps.org/thirdparty/mpich2-1.4.1p1-win-ia32.msi>`_
|
||||
* for 64-bit Windows: `mpich2-1.4.1p1-win-x86-64.msi <https://download.lammps.org/thirdparty/mpich2-1.4.1p1-win-x86-64.msi>`_
|
||||
|
||||
The LAMMPS Windows installer packages will automatically adjust your
|
||||
path for the default location of this MPI package. After the
|
||||
installation of the MPICH2 software, it needs to be integrated into
|
||||
the system. For this you need to start a Command Prompt in
|
||||
*Administrator Mode* (right click on the icon and select it). Change
|
||||
into the MPICH2 installation directory, then into the subdirectory
|
||||
**bin** and execute **smpd.exe -install**\ . Exit the command window.
|
||||
|
||||
* Get a new, regular command prompt by going to Start->Run... ,
|
||||
then typing "cmd".
|
||||
* Move to the directory where you have your input file
|
||||
(e.g. by typing: cd "Documents").
|
||||
Download and install the MS-MPI runtime package ``msmpisetup.exe`` from
|
||||
https://www.microsoft.com/en-us/download/details.aspx?id=105289 (Note
|
||||
that the ``msmpisdk.msi`` is **only** required for **compilation** of
|
||||
LAMMPS from source on Windows using Microsoft Visual Studio). After
|
||||
installation of MS-MPI perform a reboot.
|
||||
|
||||
Then you can run the executable in serial like in the example above
|
||||
or in parallel using MPI with one of the following commands:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
mpiexec -localonly 4 lmp -in in.file
|
||||
mpiexec -np 4 lmp -in in.file
|
||||
mpiexec -localonly 4 lmp -in in.file.lmp
|
||||
mpiexec -np 4 lmp -in in.file.lmp
|
||||
|
||||
where in.file is the name of your LAMMPS input script. For the latter
|
||||
case, you may be prompted to enter the password that you set during
|
||||
installation of the MPI library software.
|
||||
where ``in.file.lmp`` is the name of your LAMMPS input script. For the
|
||||
latter case, you may be prompted to enter the password that you set
|
||||
during installation of the MPI library software.
|
||||
|
||||
In this mode, output may not immediately show up on the screen, so if
|
||||
your input script takes a long time to execute, you may need to be
|
||||
patient before the output shows up.
|
||||
|
||||
The parallel executable can also run on a single processor by typing
|
||||
something like this:
|
||||
Note that the parallel executable also includes OpenMP multi-threading
|
||||
through both the OPENMP and the KOKKOS package, which can be combined
|
||||
with MPI using something like:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
lmp -in in.lj
|
||||
mpiexec -localonly 2 lmp -in in.lj.lmp -pk omp 2 -sf omp
|
||||
mpiexec -localonly 2 lmp -in in.lj.lmp -kokkos on t 2 -sf kk
|
||||
|
||||
Note that the parallel executable also includes OpenMP
|
||||
multi-threading, which can be combined with MPI using something like:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
mpiexec -localonly 2 lmp -in in.lj -pk omp 2 -sf omp
|
||||
-------------
|
||||
|
||||
MPI parallelization will work for *all* functionality in LAMMPS and in
|
||||
many cases the MPI parallelization is more efficient than
|
||||
multi-threading since LAMMPS was designed from ground up for MPI
|
||||
parallelization using domain decomposition. Multi-threading is only
|
||||
available for selected styles and implemented on top of the MPI
|
||||
parallelization. Multi-threading is most useful for systems with large
|
||||
load imbalances when using domain decomposition and a smaller number
|
||||
of threads (<= 8).
|
||||
|
||||
@ -1022,7 +1022,7 @@ regression tests with a given LAMMPS binary. The tool launches the
|
||||
LAMMPS binary with any given input script under one of the `examples`
|
||||
subdirectories, and compares the thermo output in the generated log file
|
||||
with those in the provided log file with the same number of processors
|
||||
ub the same subdirectory. If the differences between the actual and
|
||||
in the same subdirectory. If the differences between the actual and
|
||||
reference values are within specified tolerances, the test is considered
|
||||
passed. For each test batch, that is, a set of example input scripts,
|
||||
the mpirun command, the LAMMPS command line arguments, and the
|
||||
|
||||
@ -319,25 +319,34 @@ all types from 1 to :math:`N`. A leading asterisk means all types from
|
||||
:math:`N` (inclusive). A middle asterisk means all types from m to n
|
||||
(inclusive).
|
||||
|
||||
Currently *bond* does not support bond_style hybrid nor bond_style
|
||||
hybrid/overlay as bond styles. The bond styles that currently work
|
||||
with fix_adapt are
|
||||
If :doc:`bond_style hybrid <bond_hybrid>` is used, *bstyle* should be a
|
||||
sub-style name. The bond styles that currently work with fix adapt are:
|
||||
|
||||
+------------------------------------+------------+------------+
|
||||
| :doc:`class2 <bond_class2>` | r0 | type bonds |
|
||||
+------------------------------------+------------+------------+
|
||||
| :doc:`fene <bond_fene>` | k,r0 | type bonds |
|
||||
+------------------------------------+------------+------------+
|
||||
| :doc:`fene/nm <bond_fene>` | k,r0 | type bonds |
|
||||
+------------------------------------+------------+------------+
|
||||
| :doc:`gromos <bond_gromos>` | k,r0 | type bonds |
|
||||
+------------------------------------+------------+------------+
|
||||
| :doc:`harmonic <bond_harmonic>` | k,r0 | type bonds |
|
||||
+------------------------------------+------------+------------+
|
||||
| :doc:`morse <bond_morse>` | r0 | type bonds |
|
||||
+------------------------------------+------------+------------+
|
||||
| :doc:`nonlinear <bond_nonlinear>` | epsilon,r0 | type bonds |
|
||||
+------------------------------------+------------+------------+
|
||||
+-----------------------------------------------------+---------------------------+------------+
|
||||
| :doc:`class2 <bond_class2>` | r0 | type bonds |
|
||||
+-----------------------------------------------------+---------------------------+------------+
|
||||
| :doc:`fene <bond_fene>` | k,r0 | type bonds |
|
||||
+-----------------------------------------------------+---------------------------+------------+
|
||||
| :doc:`fene/expand <bond_fene_expand>` | k,r0,epsilon,sigma,shift | type bonds |
|
||||
+-----------------------------------------------------+---------------------------+------------+
|
||||
| :doc:`fene/nm <bond_fene>` | k,r0 | type bonds |
|
||||
+-----------------------------------------------------+---------------------------+------------+
|
||||
| :doc:`gromos <bond_gromos>` | k,r0 | type bonds |
|
||||
+-----------------------------------------------------+---------------------------+------------+
|
||||
| :doc:`harmonic <bond_harmonic>` | k,r0 | type bonds |
|
||||
+-----------------------------------------------------+---------------------------+------------+
|
||||
| :doc:`harmonic/restrain <bond_harmonic_restrain>` | k | type bonds |
|
||||
+-----------------------------------------------------+---------------------------+------------+
|
||||
| :doc:`harmonic/shift <bond_harmonic_shift>` | k,r0,r1 | type bonds |
|
||||
+-----------------------------------------------------+---------------------------+------------+
|
||||
| :doc:`harmonic/shift/cut <bond_harmonic_shift_cut>` | k,r0,r1 | type bonds |
|
||||
+-----------------------------------------------------+---------------------------+------------+
|
||||
| :doc:`mm3 <bond_mm3>` | k,r0 | type bonds |
|
||||
+-----------------------------------------------------+---------------------------+------------+
|
||||
| :doc:`morse <bond_morse>` | r0 | type bonds |
|
||||
+-----------------------------------------------------+---------------------------+------------+
|
||||
| :doc:`nonlinear <bond_nonlinear>` | epsilon,r0 | type bonds |
|
||||
+-----------------------------------------------------+---------------------------+------------+
|
||||
|
||||
----------
|
||||
|
||||
@ -357,15 +366,34 @@ all types from 1 to :math:`N`. A leading asterisk means all types from
|
||||
:math:`N` (inclusive). A middle asterisk means all types from m to n
|
||||
(inclusive).
|
||||
|
||||
Currently *angle* does not support angle_style hybrid nor angle_style
|
||||
hybrid/overlay as angle styles. The angle styles that currently work
|
||||
with fix_adapt are
|
||||
If :doc:`angle_style hybrid <angle_hybrid>` is used, *astyle* should be a
|
||||
sub-style name. The angle styles that currently work with fix adapt are:
|
||||
|
||||
+------------------------------------+----------+-------------+
|
||||
| :doc:`harmonic <angle_harmonic>` | k,theta0 | type angles |
|
||||
+------------------------------------+----------+-------------+
|
||||
| :doc:`cosine <angle_cosine>` | k | type angles |
|
||||
+------------------------------------+----------+-------------+
|
||||
+--------------------------------------------------------------------+-----------------+-------------+
|
||||
| :doc:`harmonic <angle_harmonic>` | k,theta0 | type angles |
|
||||
+--------------------------------------------------------------------+-----------------+-------------+
|
||||
| :doc:`charmm <angle_charmm>` | k,theta0 | type angles |
|
||||
+--------------------------------------------------------------------+-----------------+-------------+
|
||||
| :doc:`class2 <angle_class2>` | k2,k3,k4,theta0 | type angles |
|
||||
+--------------------------------------------------------------------+-----------------+-------------+
|
||||
| :doc:`cosine <angle_cosine>` | k | type angles |
|
||||
+--------------------------------------------------------------------+-----------------+-------------+
|
||||
| :doc:`cosine/periodic <angle_cosine_periodic>` | k,b,n | type angles |
|
||||
+--------------------------------------------------------------------+-----------------+-------------+
|
||||
| :doc:`cosine/squared/restricted <angle_cosine_squared_restricted>` | k,theta0 | type angles |
|
||||
+--------------------------------------------------------------------+-----------------+-------------+
|
||||
| :doc:`dipole <angle_dipole>` | k,gamma0 | type angles |
|
||||
+--------------------------------------------------------------------+-----------------+-------------+
|
||||
| :doc:`fourier <angle_fourier>` | k,c0,c1,c2 | type angles |
|
||||
+--------------------------------------------------------------------+-----------------+-------------+
|
||||
| :doc:`fourier/simple <angle_fourier_simple>` | k,c,n | type angles |
|
||||
+--------------------------------------------------------------------+-----------------+-------------+
|
||||
| :doc:`mm3 <angle_mm3>` | k,theta0 | type angles |
|
||||
+--------------------------------------------------------------------+-----------------+-------------+
|
||||
| :doc:`quartic <angle_quartic>` | k2,k3,k4,theta0 | type angles |
|
||||
+--------------------------------------------------------------------+-----------------+-------------+
|
||||
| :doc:`spica <angle_spica>` | k,theta0 | type angles |
|
||||
+--------------------------------------------------------------------+-----------------+-------------+
|
||||
|
||||
Note that internally, theta0 is stored in radians, so the variable
|
||||
this fix uses to reset theta0 needs to generate values in radians.
|
||||
|
||||
@ -50,8 +50,8 @@ Syntax
|
||||
*intra_energy* value = intramolecular energy (energy units)
|
||||
*tfac_insert* value = scale up/down temperature of inserted atoms (unitless)
|
||||
*overlap_cutoff* value = maximum pair distance for overlap rejection (distance units)
|
||||
*max* value = Maximum number of molecules allowed in the system
|
||||
*min* value = Minimum number of molecules allowed in the system
|
||||
*max* value = Maximum number of atoms allowed in the fix group (and region)
|
||||
*min* value = Minimum number of atoms allowed in the fix group (and region)
|
||||
|
||||
Examples
|
||||
""""""""
|
||||
@ -380,10 +380,11 @@ an infinite positive energy to all new configurations that place any
|
||||
pair of atoms closer than the specified overlap cutoff distance.
|
||||
|
||||
The *max* and *min* keywords allow for the restriction of the number of
|
||||
atoms in the simulation. They automatically reject all insertion or
|
||||
deletion moves that would take the system beyond the set boundaries.
|
||||
Should the system already be beyond the boundary, only moves that bring
|
||||
the system closer to the bounds may be accepted.
|
||||
atoms in the fix group (and region in case the *region* keyword is
|
||||
used). They automatically reject all insertion or deletion moves that
|
||||
would take the system beyond the set boundaries. Should the system
|
||||
already be beyond the boundary, only moves that bring the system closer
|
||||
to the bounds may be accepted.
|
||||
|
||||
The *group* keyword adds all inserted atoms to the :doc:`group <group>`
|
||||
of the group-ID value. The *grouptype* keyword adds all inserted atoms
|
||||
|
||||
@ -51,7 +51,7 @@ index file. When specifying group IDs, only those groups will be
|
||||
written to the index file. In order to follow the Gromacs conventions,
|
||||
the group *all* will be renamed to *System* in the index file.
|
||||
|
||||
The *ndx2group* command will create of update group definitions from
|
||||
The *ndx2group* command will create or update group definitions from
|
||||
those stored in an index file. Without specifying any group IDs, all
|
||||
groups except *System* will be read from the index file and the
|
||||
corresponding groups recreated. If a group of the same name already
|
||||
|
||||
@ -115,10 +115,11 @@ to tell LAMMPS how many parallel files exist, via its specified
|
||||
|
||||
The format of the dump file is selected through the *format* keyword.
|
||||
If specified, it must be the last keyword used, since all remaining
|
||||
arguments are passed on to the dump reader. The *native* format is
|
||||
for native LAMMPS dump files, written with a :doc:`dump atom <dump>`
|
||||
or :doc:`dump custom <dump>` command. The *xyz* format is for generic XYZ
|
||||
formatted dump files. These formats take no additional values.
|
||||
arguments are passed on to the dump reader. The *native* format is for
|
||||
native LAMMPS dump files, written with a :doc:`dump atom <dump>` or
|
||||
:doc:`dump custom <dump>` command. The *xyz* format is for generic XYZ
|
||||
formatted dump files (see details below). These formats take no
|
||||
additional values.
|
||||
|
||||
The *molfile* format supports reading data through using the `VMD <vmd_>`_
|
||||
molfile plugin interface. This dump reader format is only available,
|
||||
@ -230,23 +231,39 @@ will then have a label corresponding to the fix-ID rather than "x" or
|
||||
"xs". The *label* keyword can also be used to specify new column
|
||||
labels for fields *id* and *type*\ .
|
||||
|
||||
For dump files in *xyz* format, only the *x*, *y*, and *z* fields are
|
||||
supported. The dump file does not store atom IDs, so these are
|
||||
assigned consecutively to the atoms as they appear in the dump file,
|
||||
starting from 1. Thus you should ensure that order of atoms is
|
||||
consistent from snapshot to snapshot in the XYZ dump file. See
|
||||
the :doc:`dump_modify sort <dump_modify>` command if the XYZ dump file
|
||||
was written by LAMMPS.
|
||||
For dump files in *xyz* format, only the *type*, *x*, *y*, and *z*
|
||||
fields are supported. There are many variants of the XYZ file format.
|
||||
LAMMPS will read the number of atoms from the first line of each frame,
|
||||
ignore the second (title) line, and then read one line for each atom in the format:
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
<label> <x coordinate> <y coordinate> <z coordinate>
|
||||
|
||||
|
||||
If the atom label is a numeric integer (like with XYZ files created by
|
||||
created with default settings by :doc:`dump style <dump>` *xyz*), that
|
||||
number will be used as the atom type. If the atom label is a string,
|
||||
then a type map must be created using the :doc:`labelmap command
|
||||
<labelmap>`. This map needs to associate each (numeric) atom type with
|
||||
a string label. The numeric atom type is stored internally.
|
||||
|
||||
The xyz format dump file does not store atom IDs, so these are assigned
|
||||
consecutively to the atoms as they appear in the dump file, starting
|
||||
from 1. Thus you should ensure that the order of atoms is consistent
|
||||
from snapshot to snapshot in the XYZ dump file. See the
|
||||
:doc:`dump_modify sort <dump_modify>` command if the XYZ dump file was
|
||||
written by LAMMPS.
|
||||
|
||||
For dump files in *molfile* format, the *x*, *y*, *z*, *vx*, *vy*, and
|
||||
*vz* fields can be specified. However, not all molfile formats store
|
||||
velocities, or their respective plugins may not support reading of
|
||||
velocities. The molfile dump files do not store atom IDs, so these
|
||||
are assigned consecutively to the atoms as they appear in the dump
|
||||
file, starting from 1. Thus you should ensure that order of atoms are
|
||||
consistent from snapshot to snapshot in the molfile dump file.
|
||||
See the :doc:`dump_modify sort <dump_modify>` command if the dump file
|
||||
was written by LAMMPS.
|
||||
velocities. The molfile dump files do not store atom IDs, so these are
|
||||
assigned consecutively to the atoms as they appear in the dump file,
|
||||
starting from 1. Thus you should ensure that the order of atoms are
|
||||
consistent from snapshot to snapshot in the molfile dump file. See the
|
||||
:doc:`dump_modify sort <dump_modify>` command if the dump file was
|
||||
written by LAMMPS.
|
||||
|
||||
The *adios* format supports all fields that the *native* format supports
|
||||
except for the *q* charge field.
|
||||
|
||||
@ -18,13 +18,13 @@ Syntax
|
||||
*delete* = no args
|
||||
*block* args = xlo xhi ylo yhi zlo zhi
|
||||
xlo,xhi,ylo,yhi,zlo,zhi = bounds of block in all dimensions (distance units)
|
||||
xlo,xhi,ylo,yhi,zlo,zhi can be a variable
|
||||
xlo,xhi,ylo,yhi,zlo,zhi can be a variable (see below)
|
||||
*cone* args = dim c1 c2 radlo radhi lo hi
|
||||
dim = *x* or *y* or *z* = axis of cone
|
||||
c1,c2 = coords of cone axis in other 2 dimensions (distance units)
|
||||
radlo,radhi = cone radii at lo and hi end (distance units)
|
||||
lo,hi = bounds of cone in dim (distance units)
|
||||
c1,c2,radlo,radhi,lo,hi can be a variable (see below)
|
||||
c1,c2,radlo,radhi,lo,hi can be a variable (see below)
|
||||
*cylinder* args = dim c1 c2 radius lo hi
|
||||
dim = *x* or *y* or *z* = axis of cylinder
|
||||
c1,c2 = coords of cylinder axis in other 2 dimensions (distance units)
|
||||
@ -38,6 +38,7 @@ Syntax
|
||||
*plane* args = px py pz nx ny nz
|
||||
px,py,pz = point on the plane (distance units)
|
||||
nx,ny,nz = direction normal to plane (distance units)
|
||||
px,py,pz can be a variable (see below)
|
||||
*prism* args = xlo xhi ylo yhi zlo zhi xy xz yz
|
||||
xlo,xhi,ylo,yhi,zlo,zhi = bounds of untilted prism (distance units)
|
||||
xy = distance to tilt y in x direction (distance units)
|
||||
@ -166,7 +167,7 @@ extending in the y-direction from -5.0 to the upper box boundary.
|
||||
|
||||
.. versionadded:: 4May2022
|
||||
|
||||
For style *ellipsoid*, an axis-aligned ellipsoid is defined. The
|
||||
For style *ellipsoid*, an axis-aligned ellipsoid is defined. The
|
||||
ellipsoid has its center at (x,y,z) and is defined by 3 axis-aligned
|
||||
vectors given by A = (a,0,0); B = (0,b,0); C = (0,0,c). Note that
|
||||
although the ellipsoid is specified as axis-aligned it can be rotated
|
||||
@ -206,9 +207,10 @@ parameters a,b,c for style *ellipsoid*, can each be specified as an
|
||||
equal-style :doc:`variable <variable>`. Likewise, for style *sphere*
|
||||
and *ellipsoid* the x-, y-, and z- coordinates of the center of the
|
||||
sphere/ellipsoid can be specified as an equal-style variable. And for
|
||||
style *cylinder* the two center positions c1 and c2 for the location
|
||||
of the cylinder axes can be specified as a equal-style variable. For style *cone*
|
||||
all properties can be defined via equal-style variables.
|
||||
style *cylinder* the two center positions c1 and c2 for the location of
|
||||
the cylinder axes can be specified as a equal-style variable. For style
|
||||
*cone* all properties can be defined via equal-style variables. For
|
||||
style *plane* the point can be defined via equal-style variables.
|
||||
|
||||
If the value is a variable, it should be specified as v_name, where
|
||||
name is the variable name. In this case, the variable will be
|
||||
|
||||
Reference in New Issue
Block a user