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

Merge branch 'develop' into pair_style_tutorial

Browse Source
This commit is contained in:
Axel Kohlmeyer
2023-03-17 05:42:08 -04:00
parent 5dc9a570fa fce1f8e0af
commit aca8bc4ea9
226 changed files with 15065 additions and 8745 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
doc/src/Build_extras.rst
View File

@ -181,6 +181,9 @@ way no local OpenCL development headers or library needs to be present and only
OpenCL compatible drivers need to be installed to use OpenCL. If this is not
desired, you can set :code:`USE_STATIC_OPENCL_LOADER` to :code:`no`.
The GPU library has some multi-thread support using OpenMP. If LAMMPS is built
with ``-D BUILD_OMP=on`` this will also be enabled.
If you are compiling with HIP, note that before running CMake you will have to
set appropriate environment variables. Some variables such as
:code:`HCC_AMDGPU_TARGET` (for ROCm <= 4.0) or :code:`CUDA_PATH` are necessary for :code:`hipcc`
@ -278,6 +281,9 @@ To support the CUDA multiprocessor server you can set the define
the CUDA performance primitives and thus set the variable ``CUDPP_OPT``
to empty.
The GPU library has some multi-thread support using OpenMP. You need to add
the compiler flag that enables OpenMP to the ``CUDR_OPTS`` Makefile variable.
If the library build is successful, 3 files should be created:
``lib/gpu/libgpu.a``\ , ``lib/gpu/nvc_get_devices``\ , and
``lib/gpu/Makefile.lammps``\ . The latter has settings that enable LAMMPS

1
doc/src/Commands_bond.rst
View File

@ -42,6 +42,7 @@ OPT.
* :doc:`gaussian <bond_gaussian>`
* :doc:`gromos (o) <bond_gromos>`
* :doc:`harmonic (iko) <bond_harmonic>`
* :doc:`harmonic/restrain <bond_harmonic_restrain>`
* :doc:`harmonic/shift (o) <bond_harmonic_shift>`
* :doc:`harmonic/shift/cut (o) <bond_harmonic_shift_cut>`
* :doc:`lepton (o) <bond_lepton>`

2
doc/src/Commands_compute.rst
View File

@ -52,6 +52,8 @@ KOKKOS, o = OPENMP, t = OPT.
* :doc:`dilatation/atom <compute_dilatation_atom>`
* :doc:`dipole <compute_dipole>`
* :doc:`dipole/chunk <compute_dipole_chunk>`
* :doc:`dipole/tip4p <compute_dipole>`
* :doc:`dipole/tip4p/chunk <compute_dipole_chunk>`
* :doc:`displace/atom <compute_displace_atom>`
* :doc:`dpd <compute_dpd>`
* :doc:`dpd/atom <compute_dpd_atom>`

2
doc/src/Commands_fix.rst
View File

@ -70,6 +70,7 @@ OPT.
* :doc:`dt/reset (k) <fix_dt_reset>`
* :doc:`edpd/source <fix_dpd_source>`
* :doc:`efield <fix_efield>`
* :doc:`efield/tip4p <fix_efield>`
* :doc:`ehex <fix_ehex>`
* :doc:`electrode/conp (i) <fix_electrode>`
* :doc:`electrode/conq (i) <fix_electrode>`
@ -93,6 +94,7 @@ OPT.
* :doc:`grem <fix_grem>`
* :doc:`halt <fix_halt>`
* :doc:`heat <fix_heat>`
* :doc:`heat/flow <fix_heat_flow>`
* :doc:`hyper/global <fix_hyper_global>`
* :doc:`hyper/local <fix_hyper_local>`
* :doc:`imd <fix_imd>`

25
doc/src/Developer_notes.rst
View File

@ -11,6 +11,7 @@ Available topics are:
- `Reading and parsing of text and text files`_
- `Requesting and accessing neighbor lists`_
- `Choosing between a custom atom style, fix property/atom, and fix STORE/ATOM`_
- `Fix contributions to instantaneous energy, virial, and cumulative energy`_
- `KSpace PPPM FFT grids`_
@ -216,6 +217,30 @@ command:
neighbor->add_request(this, "delete_atoms", NeighConst::REQ_FULL);
Choosing between a custom atom style, fix property/atom, and fix STORE/ATOM
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
There are multiple ways to manage per-atom data within LAMMPS. Often
the per-atom storage is only used locally and managed by the class that
uses it. If the data has to persist between multiple time steps and
migrate with atoms when they move from sub-domain to sub-domain or
across periodic boundaries, then using a custom atom style, or :doc:`fix
property/atom <fix_property_atom>`, or the internal fix STORE/ATOM are
possible options.
- Using the atom style is usually the most programming effort and mostly
needed when the per-atom data is an integral part of the model like a
per-atom charge or diameter and thus should be part of the Atoms
section of a :doc:`data file <read_data>`.
- Fix property/atom is useful if the data is optional or should be
entered by the user, or accessed as a (named) custom property. In this
case the fix should be entered as part of the input (and not
internally) which allows to enter and store its content with data files.
- Fix STORE/ATOM should be used when the data should be accessed internally
only and thus the fix can be created internally.
Fix contributions to instantaneous energy, virial, and cumulative energy
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

29
doc/src/Developer_updating.rst
View File

@ -24,6 +24,7 @@ Available topics in mostly chronological order are:
- `Use of "override" instead of "virtual"`_
- `Simplified and more compact neighbor list requests`_
- `Split of fix STORE into fix STORE/GLOBAL and fix STORE/PERATOM`_
- `Rename of fix STORE/PERATOM to fix STORE/ATOM and change of arguments`_
- `Use Output::get_dump_by_id() instead of Output::find_dump()`_
- `Refactored grid communication using Grid3d/Grid2d classes instead of GridComm`_
@ -385,6 +386,34 @@ New:
This change is **required** or else the code will not compile.
Rename of fix STORE/PERATOM to fix STORE/ATOM and change of arguments
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. versionchanged:: TBD
The available functionality of the internal fix to store per-atom
properties was expanded to enable storing data with ghost atoms and to
support binary restart files. With those changes, the fix was renamed
to fix STORE/ATOM and the number and order of (required) arguments has
changed.
Old syntax: ``ID group-ID STORE/PERATOM rflag n1 n2 [n3]``
- *rflag* = 0/1, *no*/*yes* store per-atom values in restart file
- :math:`n1 = 1, n2 = 1, \mathrm{no}\;n3 \to` per-atom vector, single value per atom
- :math:`n1 = 1, n2 > 1, \mathrm{no}\;n3 \to` per-atom array, *n2* values per atom
- :math:`n1 = 1, n2 > 0, n3 > 0 \to` per-atom tensor, *n2* x *n3* values per atom
New syntax: ``ID group-ID STORE/ATOM n1 n2 gflag rflag``
- :math:`n1 = 1, n2 = 0 \to` per-atom vector, single value per atom
- :math:`n1 > 1, n2 = 0 \to` per-atom array, *n1* values per atom
- :math:`n1 > 0, n2 > 0 \to` per-atom tensor, *n1* x *n2* values per atom
- *gflag* = 0/1, *no*/*yes* communicate per-atom values with ghost atoms
- *rflag* = 0/1, *no*/*yes* store per-atom values in restart file
Since this is an internal fix, there is no user visible change.
Use Output::get_dump_by_id() instead of Output::find_dump()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

12
doc/src/Howto_granular.rst
View File

@ -43,6 +43,15 @@ The fix style *freeze* zeroes both the force and torque of frozen
atoms, and should be used for granular system instead of the fix style
*setforce*\ .
To model heat conduction, one must add the temperature and heatflow
atom variables with:
* :doc:`fix property/atom <fix_property_atom>`
a temperature integration fix
* :doc:`fix heat/flow <fix_heat_flow>`
and a heat conduction option defined in both
* :doc:`pair_style granular <pair_granular>`
* :doc:`fix wall/gran <fix_wall_gran>`
For computational efficiency, you can eliminate needless pairwise
computations between frozen atoms by using this command:
@ -55,3 +64,6 @@ computations between frozen atoms by using this command:
will be the same as in 3d. If you wish to model granular particles in
2d as 2d discs, see the note on this topic on the :doc:`Howto 2d <Howto_2d>`
doc page, where 2d simulations are discussed.
To add custom granular contact models, see the
:doc:`modifying granular sub-models page <Modify_gran_sub_mod>`.

2
doc/src/Install_linux.rst
View File

@ -172,7 +172,7 @@ Pre-built EPEL Linux executable
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Pre-built LAMMPS (and KIM) packages for stable releases are available
in the `Extra Packages for Enterprise Linux (EPEL) repository <https://fedoraproject.org/wiki/EPEL>`_
in the `Extra Packages for Enterprise Linux (EPEL) repository <https://docs.fedoraproject.org/en-US/epel/>`_
for use with Red Hat Enterprise Linux (RHEL) or CentOS version 7.x
and compatible Linux distributions. Names of packages, executable,
and content are the same as described above for Fedora Linux.

1
doc/src/Modify.rst
View File

@ -34,5 +34,6 @@ style requirements and recommendations <Modify_style>`.
Modify_min
Modify_region
Modify_body
Modify_gran_sub_mod
Modify_thermo
Modify_variable

177
doc/src/Modify_gran_sub_mod.rst Normal file
View File

@ -0,0 +1,177 @@
Granular Sub-Model styles
===============================
In granular models, particles are spheres with a finite radius and rotational
degrees of freedom as further described in the
:doc:`Howto granular page <Howto_granular>`. Interactions between pair of
particles or particles and walls may therefore depend on many different modes
of motion as described in :doc:`pair granular <pair_granular>` and
:doc:`fix wall/gran <fix_wall_gran>`. In both cases, the exchange of forces,
torques, and heat flow between two types of bodies is defined using a
GranularModel class. The GranularModel class organizes the details of an
interaction using a series of granular sub-models each of which describe a
particular interaction mode (e.g. normal forces or rolling friction). From a
parent GranSubMod class, several types of sub-model classes are derived:
* GranSubModNormal: normal force sub-model
* GranSubModDamping: normal damping sub-model
* GranSubModTangential: tangential forces and sliding friction sub-model
* GranSubModRolling: rolling friction sub-model
* GranSubModTwisting: twisting friction sub-model
* GranSubModHeat: heat conduction sub-model
For each type of sub-model, more classes are further derived, each describing a
specific implementation. For instance, from the GranSubModNormal class the
GranSubModNormalHooke, GranSubModNormalHertz, and GranSubModNormalJKR classes
are derived which calculate Hookean, Hertzian, or JKR normal forces,
respectively. This modular structure simplifies the addition of new granular
contact models as as one only needs to create a new GranSubMod class without
having to modify the more complex PairGranular, FixGranWall, and GranularModel
classes. Most GranSubMod methods are also already defined by the parent classes
so new contact models typically only require edits to a few relevant methods
(e.g. methods that define coefficients and calculate forces).
Each GranSubMod class has a pointer to both the LAMMPS class and the GranularModel
class which owns it, ``lmp`` and ``gm``, respectively. The GranularModel class
includes several public variables that describe the geometry/dynamics of the
contact such as
.. list-table::
* - ``xi`` and ``xj``
- Positions of the two contacting bodies
* - ``vi`` and ``vj``
- Velocities of the two contacting bodies
* - ``omegai`` and ``omegaj``
- Angular velocities of the two contacting bodies
* - ``dx`` and ``nx``
- The displacement and normalized displacement vectors
* - ``r``, ``rsq``, and ``rinv``
- The distance, distance squared, and inverse distance
* - ``radsum``
- The sum of particle radii
* - ``vr``, ``vn``, and ``vt``
- The relative velocity vector and its normal and tangential components
* - ``wr``
- The relative rotational velocity
These quantities, among others, are calculated in the ``GranularModel->check_contact()``
and ``GranularModel->calculate_forces()`` methods which can be referred to for more
details.
To create a new GranSubMod class, it is recommended that one first looks at similar
GranSubMod classes. All GranSubMod classes share several general methods which may
need to be defined
.. list-table::
* - ``GranSubMod->mix_coeff()``
- Optional method to define how coefficients are mixed for different atom types. By default, coefficients are mixed using a geometric mean.
* - ``GranSubMod->coeffs_to_local()``
- Parses coefficients to define local variables. Run once at model construction.
* - ``GranSubMod->init()``
- Optional method to define local variables after other GranSubMod types were created. For instance, this method may be used by a tangential model that derives parameters from the normal model.
There are also several type-specific methods
.. list-table::
* - ``GranSubModNormal->touch()``
- Optional method to test when particles are in contact. By default, this is when particles overlap.
* - ``GranSubModNormal->pulloff_distance()``
- Optional method to return the distance at which particles stop interacting. By default, this is when particles no longer overlap.
* - ``GranSubModNormal->calculate_area()``
- Optional method to return the surface area of the contact. By default, this returns the geometric cross section.
* - ``GranSubModNormal->set_fncrit()``
- Optional method that defines the critical force to break the contact used by some tangential, rolling, and twisting sub-models. By default, this is the current total normal force including damping.
* - ``GranSubModNormal->calculate_forces()``
- Required method that returns the normal contact force
* - ``GranSubModDamping->calculate_forces()``
- Required method that returns the normal damping force
* - ``GranSubModTangential->calculate_forces()``
- Required method that calculates tangential forces/torques
* - ``GranSubModTwisting->calculate_forces()``
- Required method that calculates twisting friction forces/torques
* - ``GranSubModRolling->calculate_forces()``
- Required method that calculates rolling friction forces/torques
* - ``GranSubModHeat->calculate_heat()``
- Required method that returns the rate of heat flow
As an example, say one wanted to create a new normal force option that consisted
of a Hookean force with a piecewise stiffness. This could be done by adding a new
set of files ``gran_sub_mod_custom.h``:
.. code-block:: c++
#ifdef GranSubMod_CLASS
// clang-format off
GranSubModStyle(hooke/piecewise,
GranSubModNormalHookePiecewise,
NORMAL);
// clang-format on
#else
#ifndef GRAN_SUB_MOD_CUSTOM_H_
#define GRAN_SUB_MOD_CUSTOM_H_
#include "gran_sub_mod.h"
#include "gran_sub_mod_normal.h"
namespace LAMMPS_NS {
namespace Granular_NS {
class GranSubModNormalHookePiecewise : public GranSubModNormal {
public:
GranSubModNormalHookePiecewise(class GranularModel *, class LAMMPS *);
void coeffs_to_local() override;
double calculate_forces();
protected:
double k1, k2, delta_switch;
};
} // namespace Granular_NS
} // namespace LAMMPS_NS
#endif /*GRAN_SUB_MOD_CUSTOM_H_ */
#endif /*GRAN_SUB_MOD_CLASS_H_ */
and ``gran_sub_mod_custom.cpp``
.. code-block:: c++
#include "gran_sub_mod_custom.h"
#include "gran_sub_mod_normal.h"
#include "granular_model.h"
using namespace LAMMPS_NS;
using namespace Granular_NS;
GranSubModNormalHookePiecewise::GranSubModNormalHookePiecewise(GranularModel *gm, LAMMPS *lmp) : GranSubModNormal(gm, lmp)
{
num_coeffs = 4;
}
/* ---------------------------------------------------------------------- */
void GranSubModNormalHookePiecewise::coeffs_to_local()
{
k1 = coeffs[0];
k2 = coeffs[1];
damp = coeffs[2];
delta_switch = coeffs[3];
}
/* ---------------------------------------------------------------------- */
double GranSubModNormalHookePiecewise::calculate_forces()
{
double Fne;
if (gm->delta >= delta_switch) {
Fne = k1 * delta_switch + k2 * (gm->delta - delta_switch);
} else {
Fne = k1 * gm->delta;
}
return Fne;
}

141
doc/src/Python_install.rst
View File

@ -27,124 +27,19 @@ interpreter can find it and installing the LAMMPS shared library into a
folder that the dynamic loader searches or inside of the installed
``lammps`` package folder. There are multiple ways to achieve this.
#. Do a full LAMMPS installation of libraries, executables, selected
headers, documentation (if enabled), and supporting files (only
available via CMake), which can also be either system-wide or into
user specific folders.
#. Install both components into a Python ``site-packages`` folder, either
system-wide or in the corresponding user-specific folder. This way no
additional environment variables need to be set, but the shared
library is otherwise not accessible.
#. Do an installation into a virtual environment. This can either be an
installation of the Python package only or a full installation of LAMMPS.
#. Do an installation into a virtual environment.
#. Leave the files where they are in the source/development tree and
adjust some environment variables.
.. tabs::
.. tab:: Full install (CMake-only)
:ref:`Build the LAMMPS executable and library <library>` with
``-DBUILD_SHARED_LIBS=on``, ``-DLAMMPS_EXCEPTIONS=on`` and
``-DPKG_PYTHON=on`` (The first option is required, the other two
are optional by recommended). The exact file name of the shared
library depends on the platform (Unix/Linux, macOS, Windows) and
the build configuration being used. The installation base folder
is already set by default to the ``$HOME/.local`` directory, but
it can be changed to a custom location defined by the
``CMAKE_INSTALL_PREFIX`` CMake variable. This uses a folder
called ``build`` to store files generated during compilation.
.. code-block:: bash
# create build folder
mkdir build
cd build
# configure LAMMPS compilation
cmake -C ../cmake/presets/basic.cmake -D BUILD_SHARED_LIBS=on \
-D LAMMPS_EXCEPTIONS=on -D PKG_PYTHON=on ../cmake
# compile LAMMPS
cmake --build .
# install LAMMPS into $HOME/.local
cmake --install .
This leads to an installation to the following locations:
+------------------------+-----------------------------------------------------------------+-------------------------------------------------------------+
| File | Location | Notes |
+========================+=================================================================+=============================================================+
| LAMMPS Python package | * ``$HOME/.local/lib/pythonX.Y/site-packages/lammps`` (32bit) | ``X.Y`` depends on the installed Python version |
| | * ``$HOME/.local/lib64/pythonX.Y/site-packages/lammps`` (64bit) | |
+------------------------+-----------------------------------------------------------------+-------------------------------------------------------------+
| LAMMPS shared library | * ``$HOME/.local/lib/`` (32bit) | Set shared loader environment variable to this path |
| | * ``$HOME/.local/lib64/`` (64bit) | (see below for more info on this) |
+------------------------+-----------------------------------------------------------------+-------------------------------------------------------------+
| LAMMPS executable | * ``$HOME/.local/bin/`` | |
+------------------------+-----------------------------------------------------------------+-------------------------------------------------------------+
| LAMMPS potential files | * ``$HOME/.local/share/lammps/potentials/`` | Set ``LAMMPS_POTENTIALS`` environment variable to this path |
+------------------------+-----------------------------------------------------------------+-------------------------------------------------------------+
For a system-wide installation you need to set
``CMAKE_INSTALL_PREFIX`` to a system folder like ``/usr`` (or
``/usr/local``); the default is ``${HOME}/.local``. The
installation step for a system folder installation (**not** the
configuration/compilation) needs to be done with superuser
privilege, e.g. by using ``sudo cmake --install .``. The
installation folders will then be changed to (assuming ``/usr`` as
prefix):
+------------------------+---------------------------------------------------------+-------------------------------------------------------------+
| File | Location | Notes |
+========================+=========================================================+=============================================================+
| LAMMPS Python package | * ``/usr/lib/pythonX.Y/site-packages/lammps`` (32bit) | ``X.Y`` depends on the installed Python version |
| | * ``/usr/lib64/pythonX.Y/site-packages/lammps`` (64bit) | |
+------------------------+---------------------------------------------------------+-------------------------------------------------------------+
| LAMMPS shared library | * ``/usr/lib/`` (32bit) | |
| | * ``/usr/lib64/`` (64bit) | |
+------------------------+---------------------------------------------------------+-------------------------------------------------------------+
| LAMMPS executable | * ``/usr/bin/`` | |
+------------------------+---------------------------------------------------------+-------------------------------------------------------------+
| LAMMPS potential files | * ``/usr/share/lammps/potentials/`` | |
+------------------------+---------------------------------------------------------+-------------------------------------------------------------+
To be able to use the "user" installation you have to ensure that
the folder containing the LAMMPS shared library is either included
in a path searched by the shared linker (e.g. like
``/usr/lib64/``) or part of the ``LD_LIBRARY_PATH`` environment
variable (or ``DYLD_LIBRARY_PATH`` on macOS). Otherwise you will
get an error when trying to create a LAMMPS object through the
Python module.
.. code-block:: bash
# Unix/Linux
export LD_LIBRARY_PATH=$HOME/.local/lib:$LD_LIBRARY_PATH
# macOS
export DYLD_LIBRARY_PATH=$HOME/.local/lib:$DYLD_LIBRARY_PATH
If you plan to use the LAMMPS executable (e.g., ``lmp``), you may
also need to adjust the ``PATH`` environment variable (but many
newer Linux distributions already have ``$HOME/.local/bin``
included). Example:
.. code-block:: bash
export PATH=$HOME/.local/bin:$PATH
To make those changes permanent, you can add the commands to your
``$HOME/.bashrc`` file. For a system-wide installation is is not
necessary due to files installed in system folders that are loaded
automatically when a login shell is started.
.. tab:: Python package only
.. tab:: Python package
Compile LAMMPS with either :doc:`CMake <Build_cmake>` or the
:doc:`traditional make <Build_make>` procedure in :ref:`shared
@ -272,38 +167,6 @@ folder that the dynamic loader searches or inside of the installed
| LAMMPS shared library | * ``$VIRTUAL_ENV/lib/pythonX.Y/site-packages/lammps`` | ``X.Y`` depends on the installed Python version |
+------------------------+--------------------------------------------------------+-------------------------------------------------------------+
If you do a full installation (CMake only) with "install", this
leads to the following installation locations:
+------------------------+--------------------------------------------------------+-------------------------------------------------------------+
| File | Location | Notes |
+========================+========================================================+=============================================================+
| LAMMPS Python Module | * ``$VIRTUAL_ENV/lib/pythonX.Y/site-packages/lammps`` | ``X.Y`` depends on the installed Python version |
+------------------------+--------------------------------------------------------+-------------------------------------------------------------+
| LAMMPS shared library | * ``$VIRTUAL_ENV/lib/`` (32bit) | Set shared loader environment variable to this path |
| | * ``$VIRTUAL_ENV/lib64/`` (64bit) | (see below for more info on this) |
+------------------------+--------------------------------------------------------+-------------------------------------------------------------+
| LAMMPS executable | * ``$VIRTUAL_ENV/bin/`` | |
+------------------------+--------------------------------------------------------+-------------------------------------------------------------+
| LAMMPS potential files | * ``$VIRTUAL_ENV/share/lammps/potentials/`` | Set ``LAMMPS_POTENTIALS`` environment variable to this path |
+------------------------+--------------------------------------------------------+-------------------------------------------------------------+
In that case you need to modify the ``$HOME/myenv/bin/activate``
script in a similar fashion you need to update your
``$HOME/.bashrc`` file to include the shared library and
executable locations in ``LD_LIBRARY_PATH`` (or
``DYLD_LIBRARY_PATH`` on macOS) and ``PATH``, respectively.
For example with:
.. code-block:: bash
# Unix/Linux
echo 'export LD_LIBRARY_PATH=$VIRTUAL_ENV/lib:$LD_LIBRARY_PATH' >> $HOME/myenv/bin/activate
# macOS
echo 'export DYLD_LIBRARY_PATH=$VIRTUAL_ENV/lib:$DYLD_LIBRARY_PATH' >> $HOME/myenv/bin/activate
.. tab:: In place usage
You can also :doc:`compile LAMMPS <Build>` as usual in

17
doc/src/atom_style.rst
View File

@ -161,15 +161,14 @@ and each stores a per-particle diameter and mass. If the diameter >
0.0, the particle is a finite-size sphere. If the diameter = 0.0, it
is a point particle. Note that by use of the *disc* keyword with the
:doc:`fix nve/sphere <fix_nve_sphere>`, :doc:`fix nvt/sphere
<fix_nvt_sphere>`, :doc:`fix nph/sphere <fix_nph_sphere>`, :doc:`fix
npt/sphere <fix_npt_sphere>` commands for the *sphere* style, spheres
can be effectively treated as 2d discs for a 2d simulation if desired.
See also the :doc:`set density/disc <set>` command. The *sphere* and
*bpm/sphere* styles take an optional 0 or 1 argument. A value of 0
means the radius of each sphere is constant for the duration of the
simulation. A value of 1 means the radii may vary dynamically during
the simulation, e.g. due to use of the :doc:`fix adapt <fix_adapt>`
command.
<fix_nvt_sphere>`, :doc:`fix nph/sphere <fix_nph_sphere>`,
:doc:`fix npt/sphere <fix_npt_sphere>` commands for the *sphere* style,
spheres can be effectively treated as 2d discs for a 2d simulation if
desired. See also the :doc:`set density/disc <set>` command. These
styles take an optional 0 or 1 argument. A value of 0 means the
radius of each sphere is constant for the duration of the simulation.
A value of 1 means the radii may vary dynamically during the simulation,
e.g. due to use of the :doc:`fix adapt <fix_adapt>` command.
For the *ellipsoid* style, the particles are ellipsoids and each
stores a flag which indicates whether it is a finite-size ellipsoid or

90
doc/src/bond_harmonic_restrain.rst Normal file
View File

@ -0,0 +1,90 @@
.. index:: bond_style harmonic/restrain
bond_style harmonic/restrain command
====================================
Syntax
""""""
.. code-block:: LAMMPS
bond_style harmonic/restrain
Examples
""""""""
.. code-block:: LAMMPS
bond_style harmonic
bond_coeff 5 80.0
Description
"""""""""""
.. versionadded:: TBD
The *harmonic/restrain* bond style uses the potential
.. math::
E = K (r - r_{t=0})^2
where :math:`r_{t=0}` is the distance between the bonded atoms at the
beginning of the first :doc:`run <run>` or :doc:`minimize <minimize>`
command after the bond style has been defined (*t=0*). Note that the
usual 1/2 factor is included in :math:`K`. This will effectively
restrain bonds to their initial length, whatever that is. This is where
this bond style differs from :doc:`bond style harmonic <bond_harmonic>`
where the bond length is set through the per bond type coefficients.
The following coefficient must be defined for each bond type via the
:doc:`bond_coeff <bond_coeff>` command as in the example above, or in
the data file or restart files read by the :doc:`read_data <read_data>`
or :doc:`read_restart <read_restart>` commands
* :math:`K` (energy/distance\^2)
This bond style differs from other options to add harmonic restraints
like :doc:`fix restrain <fix_restrain>` or :doc:`pair style list
<pair_list>` or :doc:`fix colvars <fix_colvars>` in that it requires a
bond topology, and thus the defined bonds will trigger exclusion of
special neighbors from the neighbor list according to the
:doc:`special_bonds <special_bonds>` settings.
Restart info
""""""""""""
This bond style supports the :doc:`write_restart <write_restart>` and
:doc:`read_restart <read_restart>` commands. The state of the initial
bond lengths is stored with restart files and read back.
Restrictions
""""""""""""
This bond style can only be used if LAMMPS was built with the
EXTRA-MOLECULE package. See the :doc:`Build package <Build_package>`
page for more info.
This bond style maintains internal data to determine the original bond
lengths :math:`r_{t=0}`. This information will be written to
:doc:`binary restart files <write_restart>` but **not** to :doc:`data
files <write_data>`. Thus, continuing a simulation is *only* possible
with :doc:`read_restart <read_restart>`. When using the :doc:`read_data
command <read_data>`, the reference bond lengths :math:`r_{t=0}` will be
re-initialized from the current geometry.
This bond style cannot be used with :doc:`fix shake or fix rattle
<fix_shake>`, with :doc:`fix filter/corotate <fix_filter_corotate>`, or
any :doc:`tip4p pair style <pair_lj_cut_tip4p>` since there is no specific
equilibrium distance for a given bond type.
Related commands
""""""""""""""""
:doc:`bond_coeff <bond_coeff>`, :doc:`bond_harmonic <bond_harmonic>`,
:doc:`fix restrain <fix_restrain>`, :doc:`pair style list <pair_list>`
Default
"""""""
none

3
doc/src/bond_style.rst
View File

@ -10,7 +10,7 @@ Syntax
bond_style style args
* style = *none* or *zero* or *hybrid* or *bpm/rotational* or *bpm/spring* or *class2* or *fene* or *fene/expand* or *fene/nm* or *gaussian* or *gromos* or *harmonic* or *harmonic/shift* or *harmonic/shift/cut* or *lepton* or *morse* or *nonlinear* or *oxdna/fene* or *oxdena2/fene* or *oxrna2/fene* or *quartic* or *special* or *table*
* style = *none* or *zero* or *hybrid* or *bpm/rotational* or *bpm/spring* or *class2* or *fene* or *fene/expand* or *fene/nm* or *gaussian* or *gromos* or *harmonic* or *harmonic/restrain* *harmonic/shift* or *harmonic/shift/cut* or *lepton* or *morse* or *nonlinear* or *oxdna/fene* or *oxdena2/fene* or *oxrna2/fene* or *quartic* or *special* or *table*
* args = none for any style except *hybrid*
@ -93,6 +93,7 @@ accelerated styles exist.
* :doc:`gaussian <bond_gaussian>` - multicentered Gaussian-based bond potential
* :doc:`gromos <bond_gromos>` - GROMOS force field bond
* :doc:`harmonic <bond_harmonic>` - harmonic bond
* :doc:`harmonic/restrain <bond_harmonic_restrain>` - harmonic bond to restrain to original bond distance
* :doc:`harmonic/shift <bond_harmonic_shift>` - shifted harmonic bond
* :doc:`harmonic/shift/cut <bond_harmonic_shift_cut>` - shifted harmonic bond with a cutoff
* :doc:`lepton <bond_lepton>` - bond potential from evaluating a string

2
doc/src/compute.rst
View File

@ -206,6 +206,8 @@ The individual style names on the :doc:`Commands compute <Commands_compute>` pag
* :doc:`dilatation/atom <compute_dilatation_atom>` - Peridynamic dilatation for each atom
* :doc:`dipole <compute_dipole>` - dipole vector and total dipole
* :doc:`dipole/chunk <compute_dipole_chunk>` - dipole vector and total dipole for each chunk
* :doc:`dipole/tip4p <compute_dipole>` - dipole vector and total dipole with TIP4P pair style
* :doc:`dipole/tip4p/chunk <compute_dipole_chunk>` - dipole vector and total dipole for each chunk with TIP4P pair style
* :doc:`displace/atom <compute_displace_atom>` - displacement of each atom
* :doc:`dpd <compute_dpd>` - total values of internal conductive energy, internal mechanical energy, chemical energy, and harmonic average of internal temperature
* :doc:`dpd/atom <compute_dpd_atom>` - per-particle values of internal conductive energy, internal mechanical energy, chemical energy, and internal temperature

45
doc/src/compute_dipole.rst
View File

@ -1,6 +1,10 @@
.. index:: compute dipole
.. index:: compute dipole/tip4p
compute dipole command
======================
compute dipole/tip4p command
============================
Syntax
@ -8,10 +12,10 @@ Syntax
.. code-block:: LAMMPS
compute ID group-ID dipole arg
compute ID group-ID style arg
* ID, group-ID are documented in :doc:`compute <compute>` command
* dipole = style name of this compute command
* style = *dipole* or *dipole/tip4p*
* arg = *mass* or *geometry* = use COM or geometric center for charged chunk correction (optional)
Examples
@ -21,6 +25,7 @@ Examples
compute 1 fluid dipole
compute dw water dipole geometry
compute dw water dipole/tip4p
Description
"""""""""""
@ -28,13 +33,20 @@ Description
Define a computation that calculates the dipole vector and total dipole
for a group of atoms.
This compute calculates the x,y,z coordinates of the dipole vector
and the total dipole moment for the atoms in the compute group.
This includes all effects due to atoms passing through periodic boundaries.
For a group with a net charge the resulting dipole is made position independent
by subtracting the position vector of the center of mass or geometric center
times the net charge from the computed dipole vector. Both per-atom charges
and per-atom dipole moments, if present, contribute to the computed dipole.
These computes calculate the x,y,z coordinates of the dipole vector and
the total dipole moment for the atoms in the compute group. This
includes all effects due to atoms passing through periodic boundaries.
For a group with a net charge the resulting dipole is made position
independent by subtracting the position vector of the center of mass or
geometric center times the net charge from the computed dipole
vector. Both per-atom charges and per-atom dipole moments, if present,
contribute to the computed dipole.
.. versionadded:: TBD
Compute *dipole/tip4p* includes adjustments for the charge carrying
point M in molecules with TIP4P water geometry. The corresponding
parameters are extracted from the pair style.
.. note::
@ -49,10 +61,10 @@ and per-atom dipole moments, if present, contribute to the computed dipole.
Output info
"""""""""""
This compute calculations a global scalar containing the magnitude of
the computed dipole moment and a global vector of length 3 with the
dipole vector. See the :doc:`Howto output <Howto_output>` page for
an overview of LAMMPS output options.
These computes calculate a global scalar containing the magnitude of the
computed dipole moment and a global vector of length 3 with the dipole
vector. See the :doc:`Howto output <Howto_output>` page for an overview
of LAMMPS output options.
The computed values are "intensive". The array values will be in
dipole units (i.e., charge :doc:`units <units>` times distance
@ -60,7 +72,12 @@ dipole units (i.e., charge :doc:`units <units>` times distance
Restrictions
""""""""""""
none
Compute style *dipole/tip4p* is part of the EXTRA-COMPUTE package. It is
only enabled if LAMMPS was built with that package. See the :doc:`Build
package <Build_package>` page for more info.
Compute style *dipole/tip4p* can only be used with tip4p pair styles.
Related commands
""""""""""""""""

47
doc/src/compute_dipole_chunk.rst
View File

@ -1,17 +1,21 @@
.. index:: compute dipole/chunk
.. index:: compute dipole/tip4p/chunk
compute dipole/chunk command
============================
compute dipole/tip4p/chunk command
==================================
Syntax
""""""
.. code-block:: LAMMPS
compute ID group-ID dipole/chunk chunkID arg
compute ID group-ID style chunkID arg
* ID, group-ID are documented in :doc:`compute <compute>` command
* dipole/chunk = style name of this compute command
* style = *dipole/chunk* or *dipole/tip4p/chunk*
* chunkID = ID of :doc:`compute chunk/atom <compute_chunk_atom>` command
* arg = *mass* or *geometry* = use COM or geometric center for charged chunk correction (optional)
@ -38,13 +42,20 @@ or atoms in a spatial bin. See the :doc:`compute chunk/atom
details of how chunks can be defined and examples of how they can be
used to measure properties of a system.
This compute calculates the :math:`(x,y,z)` coordinates of the dipole vector
and the total dipole moment for each chunk, which includes all effects due
to atoms passing through periodic boundaries. For chunks with a net
charge the resulting dipole is made position independent by subtracting
the position vector of the center of mass or geometric center times the
net charge from the computed dipole vector. Both per-atom charges and
per-atom dipole moments, if present, contribute to the computed dipole.
These computes calculate the :math:`(x,y,z)` coordinates of the dipole
vector and the total dipole moment for each chunk, which includes all
effects due to atoms passing through periodic boundaries. For chunks
with a net charge the resulting dipole is made position independent by
subtracting the position vector of the center of mass or geometric
center times the net charge from the computed dipole vector. Both
per-atom charges and per-atom dipole moments, if present, contribute to
the computed dipole.
.. versionadded:: TBD
Compute *dipole/tip4p/chunk* includes adjustments for the charge
carrying point M in molecules with TIP4P water geometry. The
corresponding parameters are extracted from the pair style.
Note that only atoms in the specified group contribute to the
calculation. The :doc:`compute chunk/atom <compute_chunk_atom>` command
@ -78,12 +89,12 @@ command, for example:
Output info
"""""""""""
This compute calculates a global array where the number of rows = the
These computes calculate a global array where the number of rows = the
number of chunks *Nchunk* as calculated by the specified :doc:`compute
chunk/atom <compute_chunk_atom>` command. The number of columns is 4 for
the :math:`(x,y,z)` dipole vector components and the total dipole of each
chunk. These values can be accessed by any command that uses global
array values from a compute as input. See the :doc:`Howto output
chunk/atom <compute_chunk_atom>` command. The number of columns is 4
for the :math:`(x,y,z)` dipole vector components and the total dipole of
each chunk. These values can be accessed by any command that uses
global array values from a compute as input. See the :doc:`Howto output
<Howto_output>` page for an overview of LAMMPS output options.
The array values are "intensive". The array values will be in
@ -92,7 +103,13 @@ dipole units (i.e., charge :doc:`units <units>` times distance
Restrictions
""""""""""""
none
Compute style *dipole/tip4p/chunk* is part of the EXTRA-COMPUTE
package. It is only enabled if LAMMPS was built with that package. See
the :doc:`Build package <Build_package>` page for more info.
Compute style *dipole/tip4p/chunk* can only be used with tip4p pair
styles.
Related commands
""""""""""""""""

5
doc/src/dump.rst
View File

@ -111,6 +111,7 @@ Syntax
q, mux, muy, muz, mu,
radius, diameter, omegax, omegay, omegaz,
angmomx, angmomy, angmomz, tqx, tqy, tqz,
heatflow, temperature,
c_ID, c_ID[I], f_ID, f_ID[I], v_name,
i_name, d_name, i2_name[I], d2_name[I]
@ -133,10 +134,12 @@ Syntax
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
radius,diameter = radius, diameter of spherical particle
omegax,omegay,omegaz = angular velocity of spherical particle
angmomx,angmomy,angmomz = angular momentum of aspherical particle
tqx,tqy,tqz = torque on finite-size particles
heatflow = rate of heat flow into particle
temperature = temperature of particle
c_ID = per-atom vector calculated by a compute with ID
c_ID[I] = Ith column of per-atom array calculated by a compute with ID, I can include wildcard (see below)
f_ID = per-atom vector calculated by a fix with ID

2
doc/src/fix.rst
View File

@ -222,6 +222,7 @@ accelerated styles exist.
* :doc:`dt/reset <fix_dt_reset>` - reset the timestep based on velocity, forces
* :doc:`edpd/source <fix_dpd_source>` - add heat source to eDPD simulations
* :doc:`efield <fix_efield>` - impose electric field on system
* :doc:`efield/tip4p <fix_efield>` - impose electric field on system with TIP4P molecules
* :doc:`ehex <fix_ehex>` - enhanced heat exchange algorithm
* :doc:`electrode/conp <fix_electrode>` - impose electric potential
* :doc:`electrode/conq <fix_electrode>` - impose total electric charge
@ -245,6 +246,7 @@ accelerated styles exist.
* :doc:`grem <fix_grem>` - implements the generalized replica exchange method
* :doc:`halt <fix_halt>` - terminate a dynamics run or minimization
* :doc:`heat <fix_heat>` - add/subtract momentum-conserving heat
* :doc:`heat/flow <fix_heat_flow>` - plain time integration of heat flow with per-atom temperature updates
* :doc:`hyper/global <fix_hyper_global>` - global hyperdynamics
* :doc:`hyper/local <fix_hyper_local>` - local hyperdynamics
* :doc:`imd <fix_imd>` - implements the "Interactive MD" (IMD) protocol

96
doc/src/fix_efield.rst
View File

@ -1,17 +1,21 @@
.. index:: fix efield
.. index:: fix efield/tip4p
fix efield command
==================
fix efield/tip4p command
========================
Syntax
""""""
.. parsed-literal::
fix ID group-ID efield ex ey ez keyword value ...
fix ID group-ID style ex ey ez keyword value ...
* ID, group-ID are documented in :doc:`fix <fix>` command
* efield = style name of this fix command
* style = *efield* or *efield/tip4p*
* ex,ey,ez = E-field component values (electric field units)
* any of ex,ey,ez can be a variable (see below)
* zero or more keyword/value pairs may be appended to args
@ -31,27 +35,36 @@ Examples
fix kick external-field efield 1.0 0.0 0.0
fix kick external-field efield 0.0 0.0 v_oscillate
fix kick external-field efield/tip4p 1.0 0.0 0.0
Description
"""""""""""
Add a force F = qE to each charged atom in the group due to an
Add a force :math:`\vec{F} = q\vec{E}` to each charged atom in the group due to an
external electric field being applied to the system. If the system
contains point-dipoles, also add a torque on the dipoles due to the
external electric field.
For charges, any of the 3 quantities defining the E-field components
can be specified as an equal-style or atom-style
:doc:`variable <variable>`, namely *ex*, *ey*, *ez*\ . 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 evaluated each timestep, and
its value used to determine the E-field component.
.. versionadded:: TBD
When the *efield/tip4p* style is used, the E-field will be applied to
the position of the virtual charge site M of a TIP4P molecule instead of
the oxygen position as it is defined by a corresponding :doc:`TIP4P pair
style <pair_lj_cut_tip4p>`. The forces on the M site due to the
external field are projected on the oxygen and hydrogen atoms of the
TIP4P molecules.
For charges, any of the 3 quantities defining the E-field components can
be specified as an equal-style or atom-style :doc:`variable <variable>`,
namely *ex*, *ey*, *ez*\ . 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 evaluated each timestep, and its value used to
determine the E-field component.
For point-dipoles, equal-style variables can be used, but atom-style
variables are not currently supported, since they imply a spatial
gradient in the electric field which means additional terms with
gradients of the field are required for the force and torque on
dipoles.
gradients of the field are required for the force and torque on dipoles.
Equal-style variables can specify formulas with various mathematical
functions, and include :doc:`thermo_style <thermo_style>` command
@ -81,10 +94,18 @@ self-consistent minimization problem (see below).
The *energy* keyword is not allowed if the added field is a constant
vector (ex,ey,ez), with all components defined as numeric constants
and not as variables. This is because LAMMPS can compute the energy
for each charged particle directly as E = -x dot qE = -q (x\*ex + y\*ey
+ z\*ez), so that -Grad(E) = F. Similarly for point-dipole particles
the energy can be computed as E = -mu dot E = -(mux\*ex + muy\*ey +
muz\*ez).
for each charged particle directly as
.. math::
U_{efield} = -\vec{x} \cdot q\vec{E} = -q (x\cdot E_x + y\cdot E_y + z\cdot Ez),
so that :math:`-\nabla U_{efield} = \vec{F}`. Similarly for point-dipole particles
the energy can be computed as
.. math::
U_{efield} = -\vec{\mu} \cdot \vec{E} = -\mu_x\cdot E_x + \mu_y\cdot E_y + \mu_z\cdot E_z
The *energy* keyword is optional if the added force is defined with
one or more variables, and if you are performing dynamics via the
@ -120,29 +141,28 @@ Restart, fix_modify, output, run start/stop, minimize info
No information about this fix is written to :doc:`binary restart files
<restart>`.
The :doc:`fix_modify <fix_modify>` *energy* option is supported by
this fix to add the potential energy inferred by the added force due
to the electric field to the global potential energy of the system as
part of :doc:`thermodynamic output <thermo_style>`. The default
setting for this fix is :doc:`fix_modify energy no <fix_modify>`.
Note that this energy is a fictitious quantity but is needed so that
the :doc:`minimize <minimize>` command can include the forces added by
this fix in a consistent manner. I.e. there is a decrease in
potential energy when atoms move in the direction of the added force
due to the electric field.
The :doc:`fix_modify <fix_modify>` *energy* option is supported by this
fix to add the potential energy inferred by the added force due to the
electric field to the global potential energy of the system as part of
:doc:`thermodynamic output <thermo_style>`. The default setting for
this fix is :doc:`fix_modify energy no <fix_modify>`. Note that this
energy is a fictitious quantity but is needed so that the :doc:`minimize
<minimize>` command can include the forces added by this fix in a
consistent manner. I.e. there is a decrease in potential energy when
atoms move in the direction of the added force due to the electric
field.
The :doc:`fix_modify <fix_modify>` *virial* option is supported by
this fix to add the contribution due to the added forces on atoms to
both the global pressure and per-atom stress of the system via the
:doc:`compute pressure <compute_pressure>` and :doc:`compute
stress/atom <compute_stress_atom>` commands. The former can be
accessed by :doc:`thermodynamic output <thermo_style>`. The default
setting for this fix is :doc:`fix_modify virial no <fix_modify>`.
The :doc:`fix_modify <fix_modify>` *virial* option is supported by this
fix to add the contribution due to the added forces on atoms to both the
global pressure and per-atom stress of the system via the :doc:`compute
pressure <compute_pressure>` and :doc:`compute stress/atom
<compute_stress_atom>` commands. The former can be accessed by
:doc:`thermodynamic output <thermo_style>`. The default setting for
this fix is :doc:`fix_modify virial no <fix_modify>`.
The :doc:`fix_modify <fix_modify>` *respa* option is supported by this
fix. This allows to set at which level of the :doc:`r-RESPA
<run_style>` integrator the fix adding its forces. Default is the
outermost level.
fix. This allows to set at which level of the :doc:`r-RESPA <run_style>`
integrator the fix adding its forces. Default is the outermost level.
This fix computes a global scalar and a global 3-vector of forces,
which can be accessed by various :doc:`output commands
@ -169,7 +189,11 @@ the iteration count during the minimization.
Restrictions
""""""""""""
None
Fix style *efield/tip4p* is part of the EXTRA-FIX package. It is only
enabled if LAMMPS was built with that package. See the :doc:`Build
package <Build_package>` page for more info.
Fix style *efield/tip4p* can only be used with tip4p pair styles.
Related commands
""""""""""""""""

70
doc/src/fix_heat_flow.rst Normal file
View File

@ -0,0 +1,70 @@
.. index:: fix heat/flow
fix heat/flow command
==========================
Syntax
""""""
.. parsed-literal::
fix ID group-ID heat/flow style values ...
* ID, group-ID are documented in :doc:`fix <fix>` command
* heat/flow = style name of this fix command
* one style with corresponding value(s) needs to be listed
.. parsed-literal::
style = *constant* or *type*
*constant* = cp
cp = value of specifc heat (energy/(mass * temperature) units)
*type* = cp1 ... cpN
cpN = value of specifc heat for type N (energy/(mass * temperature) units)
*
Examples
""""""""
.. code-block:: LAMMPS
fix 1 all heat/flow constant 1.0
fix 1 all heat/flow type 1.0 0.5
Description
"""""""""""
Perform plain time integration to update temperature for atoms in the
group each timestep. The specific heat of atoms can be defined using either
the *constant* or *type* keywords. For style *constant*, the specific heat
is a constant value *cp* for all atoms. For style *type*, *N* different values
of the specific heat are defined, one for each of the *N* types of atoms.
----------
Restart, fix_modify, output, run start/stop, minimize info
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
No information about this fix is written to :doc:`binary restart files <restart>`.
None of the :doc:`fix_modify <fix_modify>` options are relevant to this fix.
No global or per-atom quantities are stored by this fix for access by various
:doc:`output commands <Howto_output>`. No parameter of this fix can be used
with the *start/stop* keywords of the :doc:`run <run>` command. This fix is
not invoked during :doc:`energy minimization <minimize>`.
Restrictions
""""""""""""
This fix requires that atoms store temperature and heat flow
as defined by the :doc:`fix property/atom <fix_property_atom>` command.
Related commands
""""""""""""""""
:doc:`pair granular <pair_granular>`, :doc:`fix property/atom <fix_property_atom>`
Default
"""""""
none

16
doc/src/fix_wall_gran.rst
View File

@ -46,7 +46,7 @@ Syntax
radius = cylinder radius (distance units)
* zero or more keyword/value pairs may be appended to args
* keyword = *wiggle* or *shear* or *contacts*
* keyword = *wiggle* or *shear* or *contacts* or *temperature*
.. parsed-literal::
@ -59,6 +59,8 @@ Syntax
vshear = magnitude of shear velocity (velocity units)
*contacts* value = none
generate contact information for each particle
*temperature* value = temperature
specify temperature of wall
Examples
@ -71,7 +73,7 @@ Examples
fix 2 all wall/gran hooke 100000.0 20000.0 50.0 30.0 0.5 1 zcylinder 15.0 wiggle z 3.0 2.0
fix 3 all wall/gran/region granular hooke 1000.0 50.0 tangential linear_nohistory 1.0 0.4 damping velocity region myBox
fix 4 all wall/gran/region granular jkr 1e5 1500.0 0.3 10.0 tangential mindlin NULL 1.0 0.5 rolling sds 500.0 200.0 0.5 twisting marshall region myCone
fix 5 all wall/gran/region granular dmt 1e5 0.2 0.3 10.0 tangential mindlin NULL 1.0 0.5 rolling sds 500.0 200.0 0.5 twisting marshall damping tsuji region myCone
fix 5 all wall/gran/region granular dmt 1e5 0.2 0.3 10.0 tangential mindlin NULL 1.0 0.5 rolling sds 500.0 200.0 0.5 twisting marshall damping tsuji heat 10 region myCone temperature 1.0
fix 6 all wall/gran hooke 200000.0 NULL 50.0 NULL 0.5 0 xplane -10.0 10.0 contacts
Description
@ -177,6 +179,16 @@ the clockwise direction for *vshear* > 0 or counter-clockwise for
*vshear* < 0. In this case, *vshear* is the tangential velocity of
the wall at whatever *radius* has been defined.
The *temperature* keyword is used to assign a temperature to the wall.
The following value can either be a numeric value or an equal-style
:doc:`variable <variable>`. 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 evaluated each timestep, and its value used to determine
the temperature. This option must be used in conjunction with a heat
conduction model defined in :doc:`pair_style granular <pair_granular>`,
:doc:`fix property/atom <fix_property_atom>` to store temperature and a
heat flow, and :doc:`fix heat/flow <fix_heat_flow>` to integrate heat
flow.
Restart, fix_modify, output, run start/stop, minimize info
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""

15
doc/src/fix_wall_gran_region.rst
View File

@ -36,12 +36,14 @@ Syntax
* wallstyle = region (see :doc:`fix wall/gran <fix_wall_gran>` for options for other kinds of walls)
* region-ID = region whose boundary will act as wall
* keyword = *contacts*
* keyword = *contacts* or *temperature*
.. parsed-literal::
*contacts* value = none
generate contact information for each particle
*temperature* value = temperature
specify temperature of wall
Examples
""""""""
@ -200,6 +202,17 @@ values for the 6 wall/particle coefficients than for particle/particle
interactions. E.g. if you wish to model the wall as a different
material.
The *temperature* keyword is used to assign a temperature to the wall.
The following value can either be a numeric value or an equal-style
:doc:`variable <variable>`. 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 evaluated each timestep, and its value used to determine
the temperature. This option must be used in conjunction with a heat
conduction model defined in :doc:`pair_style granular <pair_granular>`,
:doc:`fix property/atom <fix_property_atom>` to store temperature and a
heat flow, and :doc:`fix heat/flow <fix_heat_flow>` to integrate heat
flow.
Restart, fix_modify, output, run start/stop, minimize info
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""

5
doc/src/pair_gran.rst
View File

@ -279,6 +279,11 @@ statistically similar results. This is because the forces they
compute depend on atom velocities. See the
:doc:`read_restart <read_restart>` command for more details.
Accumulated values for individual contacts are saved to to restart
files but are not saved to data files. Therefore, forces may
differ significantly when a system is reloaded using A
:doc:`read_data <read_data>` command.
Related commands
""""""""""""""""

80
doc/src/pair_granular.rst
View File

@ -37,6 +37,9 @@ Examples
pair_coeff 1 1 dmt 1000.0 50.0 0.3 0.0 tangential mindlin NULL 0.5 0.5 rolling sds 500.0 200.0 0.5 twisting marshall
pair_coeff 2 2 dmt 1000.0 50.0 0.3 10.0 tangential mindlin NULL 0.5 0.1 rolling sds 500.0 200.0 0.1 twisting marshall
pair_style granular
pair_coeff * * hertz 1000.0 50.0 tangential mindlin 1000.0 1.0 0.4 heat area 0.1
Description
"""""""""""
@ -223,16 +226,19 @@ for all models except *jkr*, for which it is given implicitly according
to :math:`\delta = a^2/R - 2\sqrt{\pi \gamma a/E}`. For *damping viscoelastic*,
:math:`\eta_{n0}` is in units of 1/(\ *time*\ \*\ *distance*\ ).
The *tsuji* model is based on the work of :ref:`(Tsuji et al) <Tsuji1992>`. Here, the damping coefficient specified as part of
the normal model is interpreted as a restitution coefficient
:math:`e`. The damping constant :math:`\eta_n` is given by:
The *tsuji* model is based on the work of :ref:`(Tsuji et al) <Tsuji1992>`.
Here, the damping coefficient specified as part of the normal model is interpreted
as a restitution coefficient :math:`e`. The damping constant :math:`\eta_n` is
given by:
.. math::
\eta_n = \alpha (m_{eff}k_n)^{1/2}
For normal contact models based on material parameters, :math:`k_n = 4/3Ea`. The parameter :math:`\alpha` is related to the restitution
coefficient *e* according to:
For normal contact models based on material parameters, :math:`k_n = 4/3Ea`. This
damping model is not compatible with cohesive normal models such as *JKR* or *DMT*.
The parameter :math:`\alpha` is related to the restitution coefficient *e*
according to:
.. math::
@ -631,6 +637,34 @@ attractive force. This keyword cannot be used with the JKR or DMT models.
----------
The optional *heat* keyword enables heat conduction. The options currently
supported are:
1. *none*
2. *area* : :math:`k_{s}`
If the *heat* keyword is not specified, the model defaults to *none*.
For *heat* *area*, the heat
:math:`Q` conducted between two particles is given by
.. math::
Q = k_{s} a \Delta T
where :math:`\Delta T` is the difference in the two particles' temperature,
:math:`k_{s}` is a non-negative numeric value for the conductivity, and
:math:`a` is the area of the contact and depends on the normal force model.
Note that the option *none* must either be used in all or none of of the
*pair_coeff* calls. See :doc:`fix heat/flow <fix_heat_flow>` and
:doc:`fix property/atom <fix_property_atom>` for more information on this
option.
----------
The *granular* pair style can reproduce the behavior of the
*pair gran/\** styles with the appropriate settings (some very
minor differences can be expected due to corrections in
@ -641,7 +675,7 @@ is equivalent to *pair gran/hooke 1000.0 NULL 50.0 50.0 0.4 1*\ .
The second example is equivalent to
*pair gran/hooke/history 1000.0 500.0 50.0 50.0 0.4 1*\ .
The third example is equivalent to
*pair gran/hertz/history 1000.0 500.0 50.0 50.0 0.4 1*\ .
*pair gran/hertz/history 1000.0 500.0 50.0 50.0 0.4 1 limit_damping*\ .
----------
@ -733,22 +767,30 @@ These extra quantities can be accessed by the :doc:`compute pair/local <compute_
Restrictions
""""""""""""
All the granular pair styles are part of the GRANULAR package. It is
only enabled if LAMMPS was built with that package. See the :doc:`Build package <Build_package>` page for more info.
This pair style is part of the GRANULAR package. It is
only enabled if LAMMPS was built with that package.
See the :doc:`Build package <Build_package>` page for more info.
These pair styles require that atoms store torque and angular velocity
(omega) as defined by the :doc:`atom_style <atom_style>`. They also
require a per-particle radius is stored. The *sphere* atom style does
all of this.
This pair style requires that atoms store per-particle radius,
torque, and angular velocity (omega) as defined by the
:doc:`atom_style sphere <atom_style>`.
This pair style requires you to use the :doc:`comm_modify vel yes <comm_modify>` command so that velocities are stored by ghost
atoms.
This pair style requires you to use the :doc:`comm_modify vel yes <comm_modify>`
command so that velocities are stored by ghost atoms.
These pair styles will not restart exactly when using the
:doc:`read_restart <read_restart>` command, though they should provide
statistically similar results. This is because the forces they
compute depend on atom velocities. See the
:doc:`read_restart <read_restart>` command for more details.
This pair style will not restart exactly when using the
:doc:`read_restart <read_restart>` command, though it should provide
statistically similar results. This is because the forces it
computes depend on atom velocities and the atom velocities have
been propagated half a timestep between the force computation and
when the restart is written, due to using Velocity Verlet time
integration. See the :doc:`read_restart <read_restart>` command
for more details.
Accumulated values for individual contacts are saved to restart
files but are not saved to data files. Therefore, forces may
differ significantly when a system is reloaded using the
:doc:`read_data <read_data>` command.
Related commands
""""""""""""""""

10
doc/src/set.rst
View File

@ -19,7 +19,7 @@ Syntax
*spin/electron* or *radius/electron* or
*quat* or *quat/random* or *diameter* or *shape* or *length* or *tri* or
*theta* or *theta/random* or *angmom* or *omega* or
*mass* or *density* or *density/disc* or
*mass* or *density* or *density/disc* or *temperature* or
*volume* or *image* or *bond* or *angle* or *dihedral* or
*improper* or *sph/e* or *sph/cv* or *sph/rho* or
*smd/contact/radius* or *smd/mass/density* or *dpd/theta* or
@ -100,6 +100,8 @@ Syntax
value can be an atom-style variable (see below)
*density/disc* value = particle density for a 2d disc or ellipse (mass/distance\^2 units)
value can be an atom-style variable (see below)
*temperature* value = temperature for finite-size particles (temperature units)
value can be an atom-style variable (see below)
*volume* value = particle volume for Peridynamic particle (distance\^3 units)
value can be an atom-style variable (see below)
*image* nx ny nz
@ -429,6 +431,12 @@ assumed to be in mass/distance\^2 units).
If none of these cases are valid, then the mass is set to the density
value directly (the input density is assumed to be in mass units).
Keyword *temperature* sets the temperature of a finite-size particle.
Currently, only the GRANULAR package supports this attribute. The
temperature must be added using an instance of
:doc:`fix property/atom <fix_property_atom>` The values for the
temperature must be positive.
Keyword *volume* sets the volume of all selected particles. Currently,
only the :doc:`atom_style peri <atom_style>` command defines particles
with a volume attribute. Note that this command does not adjust the