Fix merge conflicts
This commit is contained in:
rohskopf
@ -138,6 +138,8 @@ KOKKOS, o = OPENMP, t = OPT.
|
||||
* :doc:`smd/vol <compute_smd_vol>`
|
||||
* :doc:`snap <compute_sna_atom>`
|
||||
* :doc:`sna/atom <compute_sna_atom>`
|
||||
* :doc:`sna/grid <compute_sna_atom>`
|
||||
* :doc:`sna/grid/local <compute_sna_atom>`
|
||||
* :doc:`snad/atom <compute_sna_atom>`
|
||||
* :doc:`snav/atom <compute_sna_atom>`
|
||||
* :doc:`sph/e/atom <compute_sph_e_atom>`
|
||||
|
||||
@ -103,7 +103,7 @@ OPT.
|
||||
* :doc:`lb/viscous <fix_lb_viscous>`
|
||||
* :doc:`lineforce <fix_lineforce>`
|
||||
* :doc:`manifoldforce <fix_manifoldforce>`
|
||||
* :doc:`mdi/aimd <fix_mdi_aimd>`
|
||||
* :doc:`mdi/qm <fix_mdi_qm>`
|
||||
* :doc:`meso/move <fix_meso_move>`
|
||||
* :doc:`mol/swap <fix_mol_swap>`
|
||||
* :doc:`momentum (k) <fix_momentum>`
|
||||
|
||||
@ -194,7 +194,7 @@ OPT.
|
||||
* :doc:`lubricateU/poly <pair_lubricateU>`
|
||||
* :doc:`mdpd <pair_mesodpd>`
|
||||
* :doc:`mdpd/rhosum <pair_mesodpd>`
|
||||
* :doc:`meam <pair_meam>`
|
||||
* :doc:`meam (k) <pair_meam>`
|
||||
* :doc:`meam/spline (o) <pair_meam_spline>`
|
||||
* :doc:`meam/sw/spline <pair_meam_sw_spline>`
|
||||
* :doc:`mesocnt <pair_mesocnt>`
|
||||
|
||||
@ -470,6 +470,12 @@ This will most likely cause errors in kinetic fluctuations.
|
||||
*More than one compute sna/atom*
|
||||
Self-explanatory.
|
||||
|
||||
*More than one compute sna/grid*
|
||||
Self-explanatory.
|
||||
|
||||
*More than one compute sna/grid/local*
|
||||
Self-explanatory.
|
||||
|
||||
*More than one compute snad/atom*
|
||||
Self-explanatory.
|
||||
|
||||
|
||||
@ -5,9 +5,9 @@ Client/server coupling of two (or more) codes is where one code is the
|
||||
"client" and sends request messages (data) to one (or more) "server"
|
||||
code(s). A server responds to each request with a reply message
|
||||
(data). This enables two (or more) codes to work in tandem to perform
|
||||
a simulation. LAMMPS can act as either a client or server code; it
|
||||
does this by using the `MolSSI Driver Interface (MDI) library
|
||||
<https://molssi-mdi.github.io/MDI_Library/html/index.html>`_,
|
||||
a simulation. In this context, LAMMPS can act as either a client or
|
||||
server code. It does this by using the `MolSSI Driver Interface (MDI)
|
||||
library <https://molssi-mdi.github.io/MDI_Library/html/index.html>`_,
|
||||
developed by the `Molecular Sciences Software Institute (MolSSI)
|
||||
<https://molssi.org>`_, which is supported by the :ref:`MDI <PKG-MDI>`
|
||||
package.
|
||||
@ -63,22 +63,39 @@ The package also provides a :doc:`mdi plugin <mdi>` command which
|
||||
enables LAMMPS to operate as an MDI driver and load an MDI engine as a
|
||||
plugin library.
|
||||
|
||||
The package also has a `fix mdi/aimd <fix_mdi_aimd>` command in which
|
||||
LAMMPS operates as an MDI driver to perform *ab initio* MD simulations
|
||||
in conjunction with a quantum mechanics code. Its post_force() method
|
||||
illustrates 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.
|
||||
The package also has a `fix mdi/qm <fix_mdi_qm>` command in which
|
||||
LAMMPS operates as an MDI driver in conjunction with a quantum
|
||||
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
|
||||
either a stand-alone code or a plugin library.
|
||||
|
||||
As explained on the `fix mdi/qm <fix_mdi_qm>` command doc page, it can
|
||||
be used to perform *ab initio* MD simulations or energy minimizations,
|
||||
or to evaluate the quantum energy and forces for a series of
|
||||
independent systems. The examples/mdi directory has example input
|
||||
scripts for all of these use cases.
|
||||
|
||||
----------
|
||||
|
||||
The examples/mdi directory contains Python scripts and LAMMPS input
|
||||
script which use LAMMPS as either an MDI driver or engine or both.
|
||||
Three example use cases are provided:
|
||||
Currently, 5 example use cases are provided:
|
||||
|
||||
* Run ab initio MD (AIMD) using 2 instances of LAMMPS, one as driver
|
||||
and one as an engine. As an engine, LAMMPS is a surrogate for a
|
||||
quantum code.
|
||||
* 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
|
||||
code.
|
||||
|
||||
* A Python script driver invokes a sequence of unrelated LAMMPS
|
||||
calculations. Calculations can be single-point energy/force
|
||||
@ -91,20 +108,22 @@ Three example use cases are provided:
|
||||
|
||||
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 other code or scripts, except to specify the name of
|
||||
the QM code.
|
||||
without modifying the input scripts or launch commands, except to
|
||||
specify the name of the QM code.
|
||||
|
||||
The examples/mdi/README file explains how to launch both driver and
|
||||
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.
|
||||
MPI or sockets. Or using the engine as a stand-alone code or plugin
|
||||
library.
|
||||
|
||||
-------------
|
||||
|
||||
Currently there are two quantum DFT codes which have direct MDI
|
||||
support, `Quantum ESPRESSO (QE) <https://www.quantum-espresso.org/>`_
|
||||
and `INQ <https://qsg.llnl.gov/node/101.html>`_. There are also
|
||||
several QM codes which have indirect support through QCEngine or i-PI.
|
||||
The former means they require a wrapper program (QCEngine) with MDI
|
||||
Currently there are at least two quantum DFT codes which have direct
|
||||
MDI support, `Quantum ESPRESSO (QE)
|
||||
<https://www.quantum-espresso.org/>`_ and `INQ
|
||||
<https://qsg.llnl.gov/node/101.html>`_. There are also several QM
|
||||
codes which have indirect support through QCEngine or i-PI. The
|
||||
former means they require a wrapper program (QCEngine) with MDI
|
||||
support which writes/read files to pass data to the quantum code
|
||||
itself. The list of QCEngine-supported and i-PI-supported quantum
|
||||
codes is on the `MDI webpage
|
||||
|
||||
@ -68,7 +68,8 @@ liquid Ar via the GK formalism:
|
||||
# Sample LAMMPS input script for viscosity of liquid Ar
|
||||
|
||||
units real
|
||||
variable T equal 86.4956
|
||||
variable T equal 200.0 # run temperature
|
||||
variable Tinit equal 250.0 # equilibration temperature
|
||||
variable V equal vol
|
||||
variable dt equal 4.0
|
||||
variable p equal 400 # correlation length
|
||||
@ -99,12 +100,14 @@ liquid Ar via the GK formalism:
|
||||
|
||||
# equilibration and thermalization
|
||||
|
||||
velocity all create $T 102486 mom yes rot yes dist gaussian
|
||||
fix NVT all nvt temp $T $T 10 drag 0.2
|
||||
velocity all create ${Tinit} 102486 mom yes rot yes dist gaussian
|
||||
fix NVT all nvt temp ${Tinit} ${Tinit} 10 drag 0.2
|
||||
run 8000
|
||||
|
||||
# viscosity calculation, switch to NVE if desired
|
||||
|
||||
velocity all create $T 102486 mom yes rot yes dist gaussian
|
||||
fix NVT all nvt temp $T $T 10 drag 0.2
|
||||
#unfix NVT
|
||||
#fix NVE all nve
|
||||
|
||||
@ -122,7 +125,7 @@ liquid Ar via the GK formalism:
|
||||
run 100000
|
||||
variable v equal (v_v11+v_v22+v_v33)/3.0
|
||||
variable ndens equal count(all)/vol
|
||||
print "average viscosity: $v [Pa.s] @ $T K, ${ndens} /A^3"
|
||||
print "average viscosity: $v [Pa.s] @ $T K, ${ndens} atoms/A^3"
|
||||
|
||||
The fifth method is related to the above Green-Kubo method,
|
||||
but uses the Einstein formulation, analogous to the Einstein
|
||||
@ -131,9 +134,9 @@ time-integrated momentum fluxes play the role of Cartesian
|
||||
coordinates, whose mean-square displacement increases linearly
|
||||
with time at sufficiently long times.
|
||||
|
||||
The sixth is periodic perturbation method. It is also a non-equilibrium MD method.
|
||||
However, instead of measure the momentum flux in response of applied velocity gradient,
|
||||
it measures the velocity profile in response of applied stress.
|
||||
The sixth is the periodic perturbation method, which is also a non-equilibrium MD method.
|
||||
However, instead of measuring the momentum flux in response to an applied velocity gradient,
|
||||
it measures the velocity profile in response to applied stress.
|
||||
A cosine-shaped periodic acceleration is added to the system via the
|
||||
:doc:`fix accelerate/cos <fix_accelerate_cos>` command,
|
||||
and the :doc:`compute viscosity/cos<compute_viscosity_cos>` command is used to monitor the
|
||||
|
||||
@ -1479,7 +1479,7 @@ the :doc:`Build extras <Build_extras>` page.
|
||||
* lib/mdi/README
|
||||
* :doc:`Howto MDI <Howto_mdi>`
|
||||
* :doc:`mdi <mdi>`
|
||||
* :doc:`fix mdi/aimd <fix_mdi_aimd>`
|
||||
* :doc:`fix mdi/qm <fix_mdi_qm>`
|
||||
* examples/PACKAGES/mdi
|
||||
|
||||
----------
|
||||
@ -1801,6 +1801,8 @@ computes which analyze attributes of the potential.
|
||||
* src/ML-SNAP: filenames -> commands
|
||||
* :doc:`pair_style snap <pair_snap>`
|
||||
* :doc:`compute sna/atom <compute_sna_atom>`
|
||||
* :doc:`compute sna/grid <compute_sna_atom>`
|
||||
* :doc:`compute sna/grid/local <compute_sna_atom>`
|
||||
* :doc:`compute snad/atom <compute_sna_atom>`
|
||||
* :doc:`compute snav/atom <compute_sna_atom>`
|
||||
* examples/snap
|
||||
|
||||
@ -284,6 +284,8 @@ The individual style names on the :doc:`Commands compute <Commands_compute>` pag
|
||||
* :doc:`smd/vol <compute_smd_vol>` - per-particle volumes and their sum in Smooth Mach Dynamics
|
||||
* :doc:`snap <compute_sna_atom>` - gradients of SNAP energy and forces w.r.t. linear coefficients and related quantities for fitting SNAP potentials
|
||||
* :doc:`sna/atom <compute_sna_atom>` - bispectrum components for each atom
|
||||
* :doc:`sna/grid <compute_sna_atom>` - global array of bispectrum components on a regular grid
|
||||
* :doc:`sna/grid/local <compute_sna_atom>` - local array of bispectrum components on a regular grid
|
||||
* :doc:`snad/atom <compute_sna_atom>` - derivative of bispectrum components for each atom
|
||||
* :doc:`snav/atom <compute_sna_atom>` - virial contribution from bispectrum components for each atom
|
||||
* :doc:`sph/e/atom <compute_sph_e_atom>` - per-atom internal energy of Smooth-Particle Hydrodynamics atoms
|
||||
|
||||
@ -2,6 +2,8 @@
|
||||
.. index:: compute snad/atom
|
||||
.. index:: compute snav/atom
|
||||
.. index:: compute snap
|
||||
.. index:: compute sna/grid
|
||||
.. index:: compute sna/grid/local
|
||||
|
||||
compute sna/atom command
|
||||
========================
|
||||
@ -15,6 +17,12 @@ compute snav/atom command
|
||||
compute snap command
|
||||
====================
|
||||
|
||||
compute sna/grid command
|
||||
========================
|
||||
|
||||
compute sna/grid/local command
|
||||
==============================
|
||||
|
||||
Syntax
|
||||
""""""
|
||||
|
||||
@ -24,6 +32,9 @@ Syntax
|
||||
compute ID group-ID snad/atom rcutfac rfac0 twojmax R_1 R_2 ... w_1 w_2 ... keyword values ...
|
||||
compute ID group-ID snav/atom rcutfac rfac0 twojmax R_1 R_2 ... w_1 w_2 ... keyword values ...
|
||||
compute ID group-ID snap rcutfac rfac0 twojmax R_1 R_2 ... w_1 w_2 ... keyword values ...
|
||||
compute ID group-ID snap rcutfac rfac0 twojmax R_1 R_2 ... w_1 w_2 ... keyword values ...
|
||||
compute ID group-ID sna/grid nx ny nz rcutfac rfac0 twojmax R_1 R_2 ... w_1 w_2 ... keyword values ...
|
||||
compute ID group-ID sna/grid/local nx ny nz rcutfac rfac0 twojmax R_1 R_2 ... w_1 w_2 ... keyword values ...
|
||||
|
||||
* ID, group-ID are documented in :doc:`compute <compute>` command
|
||||
* sna/atom = style name of this compute command
|
||||
@ -32,6 +43,7 @@ Syntax
|
||||
* twojmax = band limit for bispectrum components (non-negative integer)
|
||||
* R_1, R_2,... = list of cutoff radii, one for each type (distance units)
|
||||
* w_1, w_2,... = list of neighbor weights, one for each type
|
||||
* nx, ny, nz = number of grid points in x, y, and z directions (positive integer)
|
||||
* zero or more keyword/value pairs may be appended
|
||||
* keyword = *rmin0* or *switchflag* or *bzeroflag* or *quadraticflag* or *chem* or *bnormflag* or *wselfallflag* or *bikflag* or *switchinnerflag* or *sinner* or *dinner* or *dgradflag*
|
||||
|
||||
@ -81,6 +93,7 @@ Examples
|
||||
compute snap all snap 1.4 0.95 6 2.0 1.0
|
||||
compute snap all snap 1.0 0.99363 6 3.81 3.83 1.0 0.93 chem 2 0 1
|
||||
compute snap all snap 1.0 0.99363 6 3.81 3.83 1.0 0.93 switchinnerflag 1 sinner 1.35 1.6 dinner 0.25 0.3
|
||||
compute bgrid all sna/grid/local 200 200 200 1.4 0.95 6 2.0 1.0
|
||||
|
||||
Description
|
||||
"""""""""""
|
||||
@ -215,6 +228,46 @@ command:
|
||||
See section below on output for a detailed explanation of the data
|
||||
layout in the global array.
|
||||
|
||||
The compute *sna/grid* and *sna/grid/local* commands calculate
|
||||
bispectrum components for a regular grid of points.
|
||||
These are calculated from the local density of nearby atoms *i'*
|
||||
around each grid point, as if there was a central atom *i*
|
||||
at the grid point. This is useful for characterizing fine-scale
|
||||
structure in a configuration of atoms, and it is used
|
||||
in the `MALA package <https://github.com/casus/mala>`_
|
||||
to build machine-learning surrogates for finite-temperature Kohn-Sham
|
||||
density functional theory (:ref:`Ellis et al. <Ellis2021>`)
|
||||
Neighbor atoms not in the group do not contribute to the
|
||||
bispectrum components of the grid points. The distance cutoff :math:`R_{ii'}`
|
||||
assumes that *i* has the same type as the neighbor atom *i'*.
|
||||
|
||||
Compute *sna/grid* calculates a global array containing bispectrum
|
||||
components for a regular grid of points.
|
||||
The grid is aligned with the current box dimensions, with the
|
||||
first point at the box origin, and forming a regular 3d array with
|
||||
*nx*, *ny*, and *nz* points in the x, y, and z directions. For triclinic
|
||||
boxes, the array is congruent with the periodic lattice vectors
|
||||
a, b, and c. The array contains one row for each of the
|
||||
:math:`nx \times ny \times nz` grid points, looping over the index for *ix* fastest,
|
||||
then *iy*, and *iz* slowest. Each row of the array contains the *x*, *y*,
|
||||
and *z* coordinates of the grid point, followed by the bispectrum
|
||||
components. See section below on output for a detailed explanation of the data
|
||||
layout in the global array.
|
||||
|
||||
Compute *sna/grid/local* calculates bispectrum components of a regular
|
||||
grid of points similarly to compute *sna/grid* described above.
|
||||
However, because the array is local, it contains only rows for grid points
|
||||
that are local to the processor sub-domain. The global grid
|
||||
of :math:`nx \times ny \times nz` points is still laid out in space the same as for *sna/grid*,
|
||||
but grid points are strictly partitioned, so that every grid point appears in
|
||||
one and only one local array. The array contains one row for each of the
|
||||
local grid points, looping over the global index *ix* fastest,
|
||||
then *iy*, and *iz* slowest. Each row of the array contains
|
||||
the global indexes *ix*, *iy*, and *iz* first, followed by the *x*, *y*,
|
||||
and *z* coordinates of the grid point, followed by the bispectrum
|
||||
components. See section below on output for a detailed explanation of the data
|
||||
layout in the global array.
|
||||
|
||||
The value of all bispectrum components will be zero for atoms not in
|
||||
the group. Neighbor atoms not in the group do not contribute to the
|
||||
bispectrum of atoms in the group.
|
||||
@ -428,6 +481,21 @@ number of columns in the global array generated by *snap* are 31, and
|
||||
931, respectively, while the number of rows is 1+3\*\ *N*\ +6, where *N*
|
||||
is the total number of atoms.
|
||||
|
||||
Compute *sna/grid* evaluates a global array.
|
||||
The array contains one row for each of the
|
||||
:math:`nx \times ny \times nz` grid points, looping over the index for *ix* fastest,
|
||||
then *iy*, and *iz* slowest. Each row of the array contains the *x*, *y*,
|
||||
and *z* coordinates of the grid point, followed by the bispectrum
|
||||
components.
|
||||
|
||||
Compute *sna/grid/local* evaluates a local array.
|
||||
The array contains one row for each of the
|
||||
local grid points, looping over the global index *ix* fastest,
|
||||
then *iy*, and *iz* slowest. Each row of the array contains
|
||||
the global indexes *ix*, *iy*, and *iz* first, followed by the *x*, *y*,
|
||||
and *z* coordinates of the grid point, followed by the bispectrum
|
||||
components.
|
||||
|
||||
If the *quadratic* keyword value is set to 1, then additional columns
|
||||
are generated, corresponding to the products of all distinct pairs of
|
||||
bispectrum components. If the number of bispectrum components is *K*,
|
||||
@ -509,8 +577,7 @@ The optional keyword defaults are *rmin0* = 0,
|
||||
|
||||
.. _Thompson20141:
|
||||
|
||||
**(Thompson)** Thompson, Swiler, Trott, Foiles, Tucker, under review, preprint
|
||||
available at `arXiv:1409.3880 <http://arxiv.org/abs/1409.3880>`_
|
||||
**(Thompson)** Thompson, Swiler, Trott, Foiles, Tucker, J Comp Phys, 285, 316, (2015).
|
||||
|
||||
.. _Bartok20101:
|
||||
|
||||
@ -531,4 +598,8 @@ of Angular Momentum, World Scientific, Singapore (1987).
|
||||
|
||||
.. _Cusentino2020:
|
||||
|
||||
**(Cusentino)** Cusentino, Wood, and Thompson, J Phys Chem A, xxx, xxxxx, (2020)
|
||||
**(Cusentino)** Cusentino, Wood, Thompson, J Phys Chem A, 124, 5456, (2020)
|
||||
|
||||
.. _Ellis2021:
|
||||
|
||||
**(Ellis)** Ellis, Fiedler, Popoola, Modine, Stephens, Thompson, Cangi, Rajamanickam, Phys Rev B, 104, 035120, (2021)
|
||||
|
||||
@ -27,6 +27,9 @@ dump command
|
||||
:doc:`dump custom/adios <dump_adios>` command
|
||||
=============================================
|
||||
|
||||
:doc:`dump cfg/uef <dump_cfg_uef>` command
|
||||
==========================================
|
||||
|
||||
Syntax
|
||||
""""""
|
||||
|
||||
@ -36,7 +39,7 @@ Syntax
|
||||
|
||||
* ID = user-assigned name for the dump
|
||||
* group-ID = ID of the group of atoms to be dumped
|
||||
* style = *atom* or *atom/gz* or *atom/zstd or *atom/mpiio* or *cfg* or *cfg/gz* or *cfg/zstd* or *cfg/mpiio* or *custom* or *custom/gz* or *custom/zstd* or *custom/mpiio* or *dcd* or *h5md* or *image* or *local* or *local/gz* or *local/zstd* or *molfile* or *movie* or *netcdf* or *netcdf/mpiio* or *vtk* or *xtc* or *xyz* or *xyz/gz* or *xyz/zstd* or *xyz/mpiio* or *yaml*
|
||||
* style = *atom* or *atom/gz* or *atom/zstd or *atom/mpiio* or *cfg* or *cfg/gz* or *cfg/zstd* or *cfg/mpiio* or *cfg/uef* or *custom* or *custom/gz* or *custom/zstd* or *custom/mpiio* or *dcd* or *h5md* or *image* or *local* or *local/gz* or *local/zstd* or *molfile* or *movie* or *netcdf* or *netcdf/mpiio* or *vtk* or *xtc* or *xyz* or *xyz/gz* or *xyz/zstd* or *xyz/mpiio* or *yaml*
|
||||
* N = dump every this many timesteps
|
||||
* file = name of file to write dump info to
|
||||
* args = list of arguments for a particular style
|
||||
@ -47,22 +50,23 @@ Syntax
|
||||
*atom/gz* args = none
|
||||
*atom/zstd* args = none
|
||||
*atom/mpiio* args = none
|
||||
*atom/adios* args = none, discussed on :doc:`dump atom/adios <dump_adios>` doc page
|
||||
*atom/adios* args = none, discussed on :doc:`dump atom/adios <dump_adios>` page
|
||||
*cfg* args = same as *custom* args, see below
|
||||
*cfg/gz* args = same as *custom* args, see below
|
||||
*cfg/zstd* args = same as *custom* args, see below
|
||||
*cfg/mpiio* args = same as *custom* args, see below
|
||||
*cfg/uef* args = same as *custom* args, discussed on :doc:`dump cfg/uef <dump_cfg_uef>` page
|
||||
*custom*, *custom/gz*, *custom/zstd*, *custom/mpiio* args = see below
|
||||
*custom/adios* args = same as *custom* args, discussed on :doc:`dump custom/adios <dump_adios>` doc page
|
||||
*custom/adios* args = same as *custom* args, discussed on :doc:`dump custom/adios <dump_adios>` page
|
||||
*dcd* args = none
|
||||
*h5md* args = discussed on :doc:`dump h5md <dump_h5md>` doc page
|
||||
*image* args = discussed on :doc:`dump image <dump_image>` doc page
|
||||
*h5md* args = discussed on :doc:`dump h5md <dump_h5md>` page
|
||||
*image* args = discussed on :doc:`dump image <dump_image>` page
|
||||
*local*, *local/gz*, *local/zstd* args = see below
|
||||
*molfile* args = discussed on :doc:`dump molfile <dump_molfile>` doc page
|
||||
*movie* args = discussed on :doc:`dump image <dump_image>` doc page
|
||||
*netcdf* args = discussed on :doc:`dump netcdf <dump_netcdf>` doc page
|
||||
*netcdf/mpiio* args = discussed on :doc:`dump netcdf <dump_netcdf>` doc page
|
||||
*vtk* args = same as *custom* args, see below, also :doc:`dump vtk <dump_vtk>` doc page
|
||||
*molfile* args = discussed on :doc:`dump molfile <dump_molfile>` page
|
||||
*movie* args = discussed on :doc:`dump image <dump_image>` page
|
||||
*netcdf* args = discussed on :doc:`dump netcdf <dump_netcdf>` page
|
||||
*netcdf/mpiio* args = discussed on :doc:`dump netcdf <dump_netcdf>` page
|
||||
*vtk* args = same as *custom* args, see below, also :doc:`dump vtk <dump_vtk>` page
|
||||
*xtc* args = none
|
||||
*xyz* args = none
|
||||
*xyz/gz* args = none
|
||||
@ -155,7 +159,7 @@ timesteps in one of several styles. The *image* and *movie* styles are
|
||||
the exception: the *image* style renders a JPG, PNG, or PPM image file
|
||||
of the atom configuration every N timesteps while the *movie* style
|
||||
combines and compresses them into a movie file; both are discussed in
|
||||
detail on the :doc:`dump image <dump_image>` doc page. The timesteps on
|
||||
detail on the :doc:`dump image <dump_image>` page. The timesteps on
|
||||
which dump output is written can also be controlled by a variable.
|
||||
See the :doc:`dump_modify every <dump_modify>` command.
|
||||
|
||||
@ -194,7 +198,7 @@ or multiple smaller files).
|
||||
For the *atom*, *custom*, *cfg*, and *local* styles, sorting is off by
|
||||
default. For the *dcd*, *xtc*, *xyz*, and *molfile* styles, sorting
|
||||
by atom ID is on by default. See the :doc:`dump_modify <dump_modify>`
|
||||
doc page for details.
|
||||
page for details.
|
||||
|
||||
The *atom/gz*, *cfg/gz*, *custom/gz*, *local/gz*, and *xyz/gz* styles
|
||||
are identical in command syntax to the corresponding styles without
|
||||
@ -204,7 +208,7 @@ alternative approach to writing compressed files via a pipe, as done
|
||||
by the regular dump styles, which may be required on clusters where
|
||||
the interface to the high-speed network disallows using the fork()
|
||||
library call (which is needed for a pipe). For the remainder of this
|
||||
doc page, you should thus consider the *atom* and *atom/gz* styles
|
||||
page, you should thus consider the *atom* and *atom/gz* styles
|
||||
(etc) to be inter-changeable, with the exception of the required
|
||||
filename suffix.
|
||||
|
||||
@ -218,7 +222,7 @@ As explained below, the *atom/mpiio*, *cfg/mpiio*, *custom/mpiio*, and
|
||||
*xyz/mpiio* styles are identical in command syntax and in the format
|
||||
of the dump files they create, to the corresponding styles without
|
||||
"mpiio", except the single dump file they produce is written in
|
||||
parallel via the MPI-IO library. For the remainder of this doc page,
|
||||
parallel via the MPI-IO library. For the remainder of this page,
|
||||
you should thus consider the *atom* and *atom/mpiio* styles (etc) to
|
||||
be inter-changeable. The one exception is how the filename is
|
||||
specified for the MPI-IO styles, as explained below.
|
||||
@ -664,7 +668,7 @@ so that each value is 0.0 to 1.0. If the simulation box is triclinic
|
||||
(tilted), then all atom coords will still be between 0.0 and 1.0.
|
||||
I.e. actual unscaled (x,y,z) = xs\*A + ys\*B + zs\*C, where (A,B,C) are
|
||||
the non-orthogonal vectors of the simulation box edges, as discussed
|
||||
on the :doc:`Howto triclinic <Howto_triclinic>` doc page.
|
||||
on the :doc:`Howto triclinic <Howto_triclinic>` page.
|
||||
|
||||
Use *xu*, *yu*, *zu* if you want the coordinates "unwrapped" by the
|
||||
image flags for each atom. Unwrapped means that if the atom has
|
||||
@ -787,7 +791,7 @@ more info.
|
||||
The *atom/mpiio*, *cfg/mpiio*, *custom/mpiio*, and *xyz/mpiio* styles
|
||||
are part of the MPIIO package. They are only enabled if LAMMPS was
|
||||
built with that package. See the :doc:`Build package <Build_package>`
|
||||
doc page for more info.
|
||||
page for more info.
|
||||
|
||||
The *xtc*, *dcd* and *yaml* styles are part of the EXTRA-DUMP package.
|
||||
They are only enabled if LAMMPS was built with that package. See the
|
||||
@ -797,12 +801,12 @@ Related commands
|
||||
""""""""""""""""
|
||||
|
||||
:doc:`dump atom/adios <dump_adios>`, :doc:`dump custom/adios <dump_adios>`,
|
||||
:doc:`dump h5md <dump_h5md>`, :doc:`dump image <dump_image>`,
|
||||
:doc:`dump molfile <dump_molfile>`, :doc:`dump_modify <dump_modify>`,
|
||||
:doc:`undump <undump>`
|
||||
:doc:`dump cfg/uef <dump_cfg_uef>`, :doc:`dump h5md <dump_h5md>`,
|
||||
:doc:`dump image <dump_image>`, :doc:`dump molfile <dump_molfile>`,
|
||||
:doc:`dump_modify <dump_modify>`, :doc:`undump <undump>`, :doc:`write_dump <write_dump>`
|
||||
|
||||
Default
|
||||
"""""""
|
||||
|
||||
The defaults for the *image* and *movie* styles are listed on the
|
||||
:doc:`dump image <dump_image>` doc page.
|
||||
:doc:`dump image <dump_image>` page.
|
||||
|
||||
@ -246,7 +246,7 @@ accelerated styles exist.
|
||||
* :doc:`lb/viscous <fix_lb_viscous>` -
|
||||
* :doc:`lineforce <fix_lineforce>` - constrain atoms to move in a line
|
||||
* :doc:`manifoldforce <fix_manifoldforce>` - restrain atoms to a manifold during minimization
|
||||
* :doc:`mdi/aimd <fix_mdi_aimd>` - LAMMPS operates as driver for ab initio MD (AIMD) via the MolSSI Driver Interface (MDI)
|
||||
* :doc:`mdi/qm <fix_mdi_qm>` - LAMMPS operates as driver for a quantum code via the MolSSI Driver Interface (MDI)
|
||||
* :doc:`meso/move <fix_meso_move>` - move mesoscopic SPH/SDPD particles in a prescribed fashion
|
||||
* :doc:`mol/swap <fix_mol_swap>` - Monte Carlo atom type swapping with a molecule
|
||||
* :doc:`momentum <fix_momentum>` - zero the linear and/or angular momentum of a group of atoms
|
||||
|
||||
@ -116,13 +116,6 @@ potential energy of the system as part of :doc:`thermodynamic output
|
||||
<thermo_style>`. The default setting for this fix is :doc:`fix_modify
|
||||
energy yes <fix_modify>`.
|
||||
|
||||
The :doc:`fix_modify <fix_modify>` *virial* option is supported by
|
||||
this fix to add the contribution compute by LATTE to the global
|
||||
pressure of the system via the :doc:`compute pressure
|
||||
<compute_pressure>` command. This can be accessed by
|
||||
:doc:`thermodynamic output <thermo_style>`. The default setting for
|
||||
this fix is :doc:`fix_modify virial yes <fix_modify>`.
|
||||
|
||||
The :doc:`fix_modify <fix_modify>` *virial* option is supported by
|
||||
this fix to add the contribution computed by LATTE to the global
|
||||
pressure of the system as part of :doc:`thermodynamic output
|
||||
@ -137,7 +130,7 @@ energy discussed above. The scalar value calculated by this fix is
|
||||
No parameter of this fix can be used with the *start/stop* keywords of
|
||||
the :doc:`run <run>` command.
|
||||
|
||||
The DFTB forces computed by LATTE via this fix are imposed during an
|
||||
The DFTB forces computed by LATTE via this fix are used during an
|
||||
energy minimization, invoked by the :doc:`minimize <minimize>`
|
||||
command.
|
||||
|
||||
|
||||
@ -1,93 +0,0 @@
|
||||
.. index:: fix mdi/aimd
|
||||
|
||||
fix mdi/aimd command
|
||||
======================
|
||||
|
||||
Syntax
|
||||
""""""
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
fix ID group-ID mdi/aimd keyword
|
||||
|
||||
* ID, group-ID are documented in :doc:`fix <fix>` command
|
||||
* mdi/aimd = style name of this fix command
|
||||
|
||||
Examples
|
||||
""""""""
|
||||
|
||||
.. code-block:: LAMMPS
|
||||
|
||||
fix 1 all mdi/aimd
|
||||
|
||||
Description
|
||||
"""""""""""
|
||||
|
||||
This command enables LAMMPS to act as a client with another server
|
||||
code to couple the two codes together to perform ab initio MD (AIMD)
|
||||
simulations.
|
||||
|
||||
More specifically, this command causes LAMMPS to begin using the `MDI
|
||||
Library <https://molssi-mdi.github.io/MDI_Library/html/index.html>`_
|
||||
to run as an MDI driver (client), which sends MDI commands to an
|
||||
external MDI engine code (server) which in the case of AIMD is a
|
||||
quantum mechanics (QM) code, or could be LAMMPS itself, acting as a
|
||||
surrogate for a QM code. See the :doc:`Howto mdi <Howto_mdi>` page
|
||||
for more information about how LAMMPS can operate as either an MDI
|
||||
driver or engine.
|
||||
|
||||
The examples/mdi directory contains input scripts performing AIMD in
|
||||
this manner with LAMMPS acting as both a driver and an engine
|
||||
(surrogate for a QM code). The examples/mdi/README file explains how
|
||||
to launch both driver and engine codes so that they communicate using
|
||||
the MDI library via either MPI or sockets. Any QM code that supports
|
||||
MDI could be used in place of LAMMPS acting as a QM surrogate. See
|
||||
the :doc:`Howto mdi <Howto_mdi>` page for a current list (March 2022)
|
||||
of such QM codes.
|
||||
|
||||
The engine code can run either as a stand-alone code, launched at the
|
||||
same time as LAMMPS, or as a plugin library. See the :doc:`mdi plugin
|
||||
<mdi>` command for how to trigger LAMMPS to load the plugin library.
|
||||
Again, the examples/mdi/README file explains how to launch both driver
|
||||
and engine codes so that engine is used in plugin mode.
|
||||
|
||||
----------
|
||||
|
||||
This fix performs the timestepping portion of an AIMD simulation.
|
||||
Both LAMMPS and the engine code (QM or LAMMPS) should define the same
|
||||
system (simulation box, atoms and their types) in their respective
|
||||
input scripts. LAMMPS then begins its timestepping.
|
||||
|
||||
At the point in each timestep when LAMMPS needs the force on each
|
||||
atom, it communicates with the engine code. It sends the current
|
||||
simulation box size and shape (if they change dynamically, e.g. during
|
||||
an NPT simulation), and the current atom coordinates. The engine code
|
||||
computes quantum forces on each atom and returns them to LAMMPS. If
|
||||
LAMMPS also needs the system energy and/or virial, it requests those
|
||||
values from the engine code as well.
|
||||
|
||||
Restrictions
|
||||
""""""""""""
|
||||
|
||||
This command is part of the MDI package. It is only enabled if
|
||||
LAMMPS was built with that package. See the :doc:`Build package
|
||||
<Build_package>` page for more info.
|
||||
|
||||
To use LAMMPS as an MDI driver in conjunction with other MDI-enabled
|
||||
atomistic codes, the :doc:`units <units>` command should be used to
|
||||
specify *real* or *metal* units. This will ensure the correct unit
|
||||
conversions between LAMMPS and MDI units, which the other codes will
|
||||
also perform in their preferred units.
|
||||
|
||||
LAMMPS can also be used as an MDI driver in other unit choices it
|
||||
supports, e.g. *lj*, but then no unit conversion is performed.
|
||||
|
||||
Related commands
|
||||
""""""""""""""""
|
||||
|
||||
:doc:`mdi engine <mdi>`
|
||||
|
||||
Default
|
||||
"""""""
|
||||
|
||||
none
|
||||
276
doc/src/fix_mdi_qm.rst
Normal file
276
doc/src/fix_mdi_qm.rst
Normal file
@ -0,0 +1,276 @@
|
||||
.. index:: fix mdi/qm
|
||||
|
||||
fix mdi/qm command
|
||||
======================
|
||||
|
||||
Syntax
|
||||
""""""
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
fix ID group-ID mdi/qm keyword
|
||||
|
||||
* ID, group-ID are documented in :doc:`fix <fix>` command
|
||||
* mdi/qm = style name of this fix command
|
||||
* zero or more keyword/value pairs may be appended
|
||||
* keyword = *virial* or *add* or *every* or *connect* or *elements*
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
*virial* args = *yes* or *no*
|
||||
yes = request virial tensor from server code
|
||||
no = do not request virial tensor from server code
|
||||
*add* args = *yes* or *no*
|
||||
yes = add returned value from server code to LAMMPS quantities
|
||||
no = do not add returned values to LAMMPS quantities
|
||||
*every* args = Nevery
|
||||
Nevery = request values from server code once every Nevery steps
|
||||
*connect* args = *yes* or *no*
|
||||
yes = perform a one-time connection to the MDI engine code
|
||||
no = do not perform the connection operation
|
||||
*elements* args = N_1 N_2 ... N_ntypes
|
||||
N_1,N_2,...N_ntypes = atomic number for each of ntypes LAMMPS atom types
|
||||
|
||||
Examples
|
||||
""""""""
|
||||
|
||||
.. code-block:: LAMMPS
|
||||
|
||||
fix 1 all mdi/qm
|
||||
fix 1 all mdi/qm virial yes
|
||||
fix 1 all mdi/qm add no every 100 elements 13 29
|
||||
|
||||
Description
|
||||
"""""""""""
|
||||
|
||||
This command enables LAMMPS to act as a client with another server
|
||||
code that will compute the total energy, per-atom forces, and total
|
||||
virial for atom conformations and simulation box size/shapes that
|
||||
LAMMPS sends it.
|
||||
|
||||
Typically the server code will be a quantum mechanics (QM) code, hence
|
||||
the name of the fix. However this is not required, the server code
|
||||
could be another classical molecular dynamics code or LAMMPS itself.
|
||||
The server code must support use of the `MDI Library
|
||||
<https://molssi-mdi.github.io/MDI_Library/html/index.html>`_ as
|
||||
explained below.
|
||||
|
||||
These are example use cases for this fix, discussed further below:
|
||||
|
||||
* perform an ab initio MD (AIMD) simulation with quantum forces
|
||||
* perform an energy minimization with quantum forces
|
||||
* perform a nudged elastic band (NEB) calculation with quantum forces
|
||||
* perform a QM calculation for a series of independent systems which LAMMPS reads or generates
|
||||
|
||||
The code coupling performed by this command is done via the `MDI
|
||||
Library <https://molssi-mdi.github.io/MDI_Library/html/index.html>`_.
|
||||
LAMMPS runs as an MDI driver (client), and sends MDI commands to an
|
||||
external MDI engine code (server), e.g. a QM code which has support
|
||||
for MDI. See the :doc:`Howto mdi <Howto_mdi>` page for more
|
||||
information about how LAMMPS can operate as either an MDI driver or
|
||||
engine.
|
||||
|
||||
The examples/mdi directory contains input scripts using this fix in
|
||||
the various use cases discussed below. In each case, two instances of
|
||||
LAMMPS are used, once as an MDI driver, once as an MDI engine
|
||||
(surrogate for a QM code). The examples/mdi/README file explains how
|
||||
to launch two codes so that they communicate via the MDI library using
|
||||
either MPI or sockets. Any QM code that supports MDI could be used in
|
||||
place of LAMMPS acting as a QM surrogate. See the :doc:`Howto mdi
|
||||
<Howto_mdi>` page for a current list (March 2022) of such QM codes.
|
||||
|
||||
Note that an engine code can support MDI in either or both of two
|
||||
modes. It can be used as a stand-alone code, launched at the same
|
||||
time as LAMMPS. Or it can be used as a plugin library, which LAMMPS
|
||||
loads. See the :doc:`mdi plugin <mdi>` command for how to trigger
|
||||
LAMMPS to load a plugin library. The examples/mdi/README file
|
||||
explains how to launch the two codes in either mode.
|
||||
|
||||
----------
|
||||
|
||||
The *virial* keyword setting of yes or no determines whether
|
||||
LAMMPS will request the QM code to also compute and return
|
||||
a 6-element symmetric virial tensor for the system.
|
||||
|
||||
The *add* keyword setting of *yes* or *no* determines whether the
|
||||
energy and forces and virial returned by the QM code will be added to
|
||||
the LAMMPS internal energy and forces and virial or not. If the
|
||||
setting is *no* then the default :doc:`fix_modify energy <fix_modify>`
|
||||
and :doc:`fix_modify virial <fix_modify>` settings are also set to
|
||||
*no* and your input scripts should not set them to yes. See more
|
||||
details on these fix_modify settings below.
|
||||
|
||||
Whatever the setting for the *add* keyword, the QM energy, forces, and
|
||||
virial will be stored by the fix, so they can be accessed by other
|
||||
commands. See details below.
|
||||
|
||||
The *every* keyword determines how often the QM code will be invoked
|
||||
during a dynamics run with the current LAMMPS simulation box and
|
||||
configuration of atoms. The QM code will be called once every
|
||||
*Nevery* timesteps.
|
||||
|
||||
The *connect* keyword determines whether this fix performs a one-time
|
||||
connection to the QM code. The default is *yes*. The only time a
|
||||
*no* is needed is if this command is used multiple times in an input
|
||||
script. E.g. if it used inside a loop which also uses the :doc:`clear
|
||||
<clear>` command to destroy the system (including any defined fixes).
|
||||
See the examples/mdi/in.series.driver script as an example of this,
|
||||
where LAMMPS is using the QM code to compute energy and forces for a
|
||||
series of system configurations. In this use case *connect no*
|
||||
is used along with the :doc:`mdi connect and exit <mdi>` command
|
||||
to one-time initiate/terminate the connection outside the loop.
|
||||
|
||||
The *elements* keyword allows specification of what element each
|
||||
LAMMPS atom type corresponds to. This is specified by the atomic
|
||||
number of the element, e.g. 13 for Al. An atomic number must be
|
||||
specified for each of the ntypes LAMMPS atom types. Ntypes is
|
||||
typically specified via the create_box command or in the data file
|
||||
read by the read_data command. If this keyword is not specified, then
|
||||
this fix will send the LAMMPS atom type for each atom to the MDI
|
||||
engine. If both the LAMMPS driver and the MDI engine are initialized
|
||||
so that atom type values are consistent in both codes, then the
|
||||
*elements* keyword is not needed. Otherwise the keyword can be used
|
||||
to insure the two codes are consistent in their definition of atomic
|
||||
species.
|
||||
|
||||
----------
|
||||
|
||||
The following 3 example use cases are illustrated in the examples/mdi
|
||||
directory. See its README file for more details.
|
||||
|
||||
(1) To run an ab initio MD (AIMD) dynamics simulation, or an energy
|
||||
minimization with QM forces, or a multi-replica NEB calculation, use
|
||||
*add yes* and *every 1* (the defaults). This is so that every time
|
||||
LAMMPS needs energy and forces, the QM code will be invoked.
|
||||
|
||||
Both LAMMPS and the QM code should define the same system (simulation
|
||||
box, atoms and their types) in their respective input scripts. Note
|
||||
that on this scenario, it may not be necessary for LAMMPS to define a
|
||||
pair style or use a neighbor list.
|
||||
|
||||
LAMMPS will then perform the timestepping or minimization iterations
|
||||
for the simulation. At the point in each timestep or iteration when
|
||||
LAMMPS needs the force on each atom, it communicates with the engine
|
||||
code. It sends the current simulation box size and shape (if they
|
||||
change dynamically, e.g. during an NPT simulation), and the current
|
||||
atom coordinates. The engine code computes quantum forces on each
|
||||
atom and the total energy of the system and returns them to LAMMPS.
|
||||
|
||||
Note that if the AIMD simulation is an NPT or NPH model, or the energy
|
||||
minimization includes :doc:`fix box relax <fix_box_relax>` to
|
||||
equilibrate the box size/shape, then LAMMPS computes a pressure. This
|
||||
means the *virial* keyword should be set to *yes* so that the QM
|
||||
contribution to the pressure can be included.
|
||||
|
||||
(2) To run dynamics with a LAMMPS interatomic potential, and evaluate
|
||||
the QM energy and forces once every 1000 steps, use *add no* and
|
||||
*every 1000*. This could be useful for using an MD run to generate
|
||||
randomized configurations which are then passed to the QM code to
|
||||
produce training data for a machine learning potential. A :doc:`dump
|
||||
custom <dump>` command could be invoked every 1000 steps to dump the
|
||||
atom coordinates and QM forces to a file. Likewise the QM energy and
|
||||
virial could be output with the :doc:`thermo_style custom
|
||||
<thermo_style>` command.
|
||||
|
||||
(3) To do a QM evaluation of energy and forces for a series of *N*
|
||||
independent systems (simulation box and atoms), use *add no* and
|
||||
*every 1*. Write a LAMMPS input script which loops over the *N*
|
||||
systems. See the :doc:`Howto multiple <Howto_multiple>` doc page for
|
||||
details on looping and removing old systems. The series of systems
|
||||
could be initialized by reading them from data files with
|
||||
:doc:`read_data <read_data>` commands. Or, for example, by using the
|
||||
:doc:`lattice <lattice>` , :doc:`create_atoms <create_atoms>`,
|
||||
:doc:`delete_atoms <delete_atoms>`, and/or :doc:`displace_atoms
|
||||
random <displace_atoms>` commands to generate a series of different
|
||||
systems. At the end of the loop perform :doc:`run 0 <run>` and
|
||||
:doc:`write_dump <write_dump>` commands to invoke the QM code and
|
||||
output the QM energy and forces. As in (2) this be useful to produce
|
||||
QM data for training a machine learning potential.
|
||||
|
||||
----------
|
||||
|
||||
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 computed by the QM code 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 yes <fix_modify>`, unless the *add* keyword is
|
||||
set to *no*, in which case the default setting is *no*.
|
||||
|
||||
The :doc:`fix_modify <fix_modify>` *virial* option is supported by
|
||||
this fix to add the contribution computed by the QM code to the global
|
||||
pressure of the system as part of :doc:`thermodynamic output
|
||||
<thermo_style>`. The default setting for this fix is :doc:`fix_modify
|
||||
virial yes <fix_modify>`, unless the *add* keyword is set to *no*, in
|
||||
which case the default setting is *no*.
|
||||
|
||||
This fix computes a global scalar which can be accessed by various
|
||||
:doc:`output commands <Howto_output>`. The scalar is the energy
|
||||
returned by the QM code. The scalar value calculated by this fix is
|
||||
"extensive".
|
||||
|
||||
This fix also computes a global vector with of length 6 which contains
|
||||
the symmetric virial tensor values returned by the QM code. It can
|
||||
likewise be accessed by various :doc:`output commands <Howto_output>`.
|
||||
|
||||
The ordering of values in the symmetric virial tensor is as follows:
|
||||
vxx, vyy, vzz, vxy, vxz, vyz. The values will be in pressure
|
||||
:doc:`units <units>`.
|
||||
|
||||
This fix also computes a peratom array with 3 columns which contains
|
||||
the peratom forces returned by the QM code. It can likewise be
|
||||
accessed 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.
|
||||
|
||||
Assuming the *add* keyword is set to *yes* (the default), the forces
|
||||
computed by the QM code are used during an energy minimization,
|
||||
invoked by the :doc:`minimize <minimize>` command.
|
||||
|
||||
.. note::
|
||||
|
||||
If you want the potential energy associated with the QM forces to
|
||||
be included in the total potential energy of the system (the
|
||||
quantity being minimized), you MUST not disable the
|
||||
:doc:`fix_modify <fix_modify>` *energy* option for this fix, which
|
||||
means the *add* keyword should also be set to *yes* (the default).
|
||||
|
||||
|
||||
Restrictions
|
||||
""""""""""""
|
||||
|
||||
This command is part of the MDI package. It is only enabled if
|
||||
LAMMPS was built with that package. See the :doc:`Build package
|
||||
<Build_package>` page for more info.
|
||||
|
||||
The QM code does not currently compute and return per-atom energy or
|
||||
per-atom virial contributions. So they will not show up as part of
|
||||
the calculations performed by the :doc:`compute pe/atom
|
||||
<compute_pe_atom>` or :doc:`compute stress/atom <compute_stress_atom>`
|
||||
commands.
|
||||
|
||||
To use LAMMPS as an MDI driver in conjunction with other MDI-enabled
|
||||
codes (MD or QM codes), the :doc:`units <units>` command should be
|
||||
used to specify *real* or *metal* units. This will ensure the correct
|
||||
unit conversions between LAMMPS and MDI units. The other code will
|
||||
also perform similar unit conversions into its preferred units.
|
||||
|
||||
LAMMPS can also be used as an MDI driver in other unit choices it
|
||||
supports, e.g. *lj*, but then no unit conversion is performed.
|
||||
|
||||
Related commands
|
||||
""""""""""""""""
|
||||
|
||||
:doc:`mdi plugin <mdi>`, :doc:`mdi engine <mdi>`
|
||||
|
||||
Default
|
||||
"""""""
|
||||
|
||||
The default for the optional keywords are virial = no, add = yes,
|
||||
every = 1, connect = yes.
|
||||
@ -156,27 +156,28 @@ and Boolean operators:
|
||||
Each A and B is a number or string or a variable reference like $a or
|
||||
${abc}, or A or B can be another Boolean expression.
|
||||
|
||||
If a variable is used it can produce a number when evaluated, like an
|
||||
:doc:`equal-style variable <variable>`. Or it can produce a string,
|
||||
like an :doc:`index-style variable <variable>`. For an individual
|
||||
Boolean operator, A and B must both be numbers or must both be
|
||||
strings. You cannot compare a number to a string.
|
||||
Note that all variables used will be substituted for before the
|
||||
Boolean expression in evaluated. A variable can produce a number,
|
||||
like an :doc:`equal-style variable <variable>`. Or it can produce a
|
||||
string, like an :doc:`index-style variable <variable>`.
|
||||
|
||||
The Boolean operators "==" and "!=" can operate on a pair or strings
|
||||
or numbers. They cannot compare a number to a string. All the other
|
||||
Boolean operations can only operate on numbers.
|
||||
|
||||
Expressions are evaluated left to right and have the usual C-style
|
||||
precedence: the unary logical NOT operator "!" has the highest
|
||||
precedence, the 4 relational operators "<", "<=", ">", and ">=" are
|
||||
next; the two remaining relational operators "==" and "!=" are next;
|
||||
then the logical AND operator "&&"; and finally the logical OR
|
||||
operator "\|\|" and logical XOR (exclusive or) operator "\|\^" have the
|
||||
lowest precedence. Parenthesis can be used to group one or more
|
||||
operator "\|\|" and logical XOR (exclusive or) operator "\|\^" have
|
||||
the lowest precedence. Parenthesis can be used to group one or more
|
||||
portions of an expression and/or enforce a different order of
|
||||
evaluation than what would occur with the default precedence.
|
||||
|
||||
When the 6 relational operators (first 6 in list above) compare 2
|
||||
numbers, they return either a 1.0 or 0.0 depending on whether the
|
||||
relationship between A and B is TRUE or FALSE. When the 6 relational
|
||||
operators compare 2 strings, they also return a 1.0 or 0.0 for TRUE or
|
||||
FALSE, but the comparison is done by the C function strcmp().
|
||||
relationship between A and B is TRUE or FALSE.
|
||||
|
||||
When the 3 logical operators (last 3 in list above) compare 2 numbers,
|
||||
they also return either a 1.0 or 0.0 depending on whether the
|
||||
@ -190,8 +191,16 @@ returns 1.0 if its argument is 0.0, else it returns 0.0. The 3
|
||||
logical operators can only be used to operate on numbers, not on
|
||||
strings.
|
||||
|
||||
The overall Boolean expression produces a TRUE result if the result is
|
||||
non-zero. If the result is zero, the expression result is FALSE.
|
||||
The overall Boolean expression produces a TRUE result if the numeric
|
||||
result is non-zero. If the result is zero, the expression result is
|
||||
FALSE.
|
||||
|
||||
.. note::
|
||||
|
||||
If the Boolean expression is a single numeric value with no Boolean
|
||||
operators, it will be FALSE if the value = 0.0, otherwise TRUE. If
|
||||
the Boolean expression is a single string, an error message will be
|
||||
issued.
|
||||
|
||||
----------
|
||||
|
||||
|
||||
113
doc/src/mdi.rst
113
doc/src/mdi.rst
@ -8,21 +8,26 @@ Syntax
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
mdi mode args
|
||||
mdi option args
|
||||
|
||||
* mode = *engine* or *plugin*
|
||||
* option = *engine* or *plugin* or *connect* or *exit*
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
*engine* args = none
|
||||
*plugin* args = name keyword value keyword value
|
||||
*engine* args = zero or more keyword arg pairs
|
||||
keywords = *elements*
|
||||
*elements* args = N_1 N_2 ... N_ntypes
|
||||
N_1,N_2,...N_ntypes = atomic number for each of ntypes LAMMPS atom types
|
||||
*plugin* args = name keyword value keyword value ...
|
||||
name = name of plugin library, e.g. lammps means a liblammps.so library will be loaded
|
||||
keyword/value pairs in any order, some are required, some are optional
|
||||
keywords = *mdi* or *infile* or *extra* or *command*
|
||||
*mdi* value = args passed to MDI for driver to operate with plugins
|
||||
*infile* value = filename the engine will read at start-up
|
||||
*mdi* value = args passed to MDI for driver to operate with plugins (required)
|
||||
*infile* value = filename the engine will read at start-up (optional)
|
||||
*extra* value = aditional command-line args to pass to engine library when loaded
|
||||
*command* value = a LAMMPS input script command to execute
|
||||
|
||||
*command* value = a LAMMPS input script command to execute (required)
|
||||
*connect* args = none
|
||||
*exit* args = none
|
||||
|
||||
Examples
|
||||
""""""""
|
||||
@ -30,26 +35,19 @@ Examples
|
||||
.. code-block:: LAMMPS
|
||||
|
||||
mdi engine
|
||||
mdi engine elements 13 29
|
||||
mdi plugin lammps mdi "-role ENGINE -name lammps -method LINK" &
|
||||
infile in.aimd.engine extra "-log log.aimd.engine.plugin" &
|
||||
command "run 5"
|
||||
mdi connect
|
||||
mdi exit
|
||||
|
||||
Description
|
||||
"""""""""""
|
||||
|
||||
This command implements two high-level operations within LAMMPS to use
|
||||
the `MDI Library
|
||||
<https://molssi-mdi.github.io/MDI_Library/html/index.html>` for
|
||||
coupling to other codes in a client/server protocol.
|
||||
|
||||
The *engine* mode enables LAMMPS to act as an MDI engine (server),
|
||||
responding to requests from an MDI driver (client) code.
|
||||
|
||||
The *plugin* mode enables LAMMPS to act as an MDI driver (client), and
|
||||
load the MDI engine (server) code as a library plugin. In this case
|
||||
the MDI engine is a library plugin. It can also be a stand-alone
|
||||
code, launched separately from LAMMPS, in which case the mdi plugin
|
||||
command is not used.
|
||||
This command implements operations within LAMMPS to use the `MDI
|
||||
Library <https://molssi-mdi.github.io/MDI_Library/html/index.html>`
|
||||
for coupling to other codes in a client/server protocol.
|
||||
|
||||
See the Howto MDI doc page for a discussion of all the different ways
|
||||
2 or more codes can interact via MDI.
|
||||
@ -61,6 +59,22 @@ stand-alone code or as a plugin. The README file in that directory
|
||||
shows how to launch and couple codes for all the 4 usage modes, and so
|
||||
they communicate via the MDI library using either MPI or sockets.
|
||||
|
||||
The scripts in that directory illustrate the use of all the options
|
||||
for this command.
|
||||
|
||||
The *engine* option enables LAMMPS to act as an MDI engine (server),
|
||||
responding to requests from an MDI driver (client) code.
|
||||
|
||||
The *plugin* option enables LAMMPS to act as an MDI driver (client),
|
||||
and load the MDI engine (server) code as a library plugin. In this
|
||||
case the MDI engine is a library plugin. An MDI engine can also be a
|
||||
stand-alone code, launched separately from LAMMPS, in which case the
|
||||
mdi plugin command is not used.
|
||||
|
||||
The *connect* and *exit* options are only used when LAMMPS is acting
|
||||
as an MDI driver. As explained below, these options are normally not
|
||||
needed, except for a specific kind of use case.
|
||||
|
||||
----------
|
||||
|
||||
The *mdi engine* command is used to make LAMMPS operate as an MDI
|
||||
@ -100,6 +114,8 @@ commands, which are described further below.
|
||||
- Send/request charge on each atom (N values)
|
||||
* - >COORDS or <COORDS
|
||||
- Send/request coordinates of each atom (3N values)
|
||||
* - >ELEMENTS
|
||||
- Send elements (atomic numbers) for each atom (N values)
|
||||
* - <ENERGY
|
||||
- Request total energy (potential + kinetic) of the system (1 value)
|
||||
* - >FORCES or <FORCES
|
||||
@ -121,11 +137,11 @@ commands, which are described further below.
|
||||
* - <PE
|
||||
- Request potential energy of the system (1 value)
|
||||
* - <STRESS
|
||||
- Request stress tensor (virial) of the system (6 values)
|
||||
- Request symmetric stress tensor (virial) of the system (9 values)
|
||||
* - >TOLERANCE
|
||||
- Send 4 tolerance parameters for next MD minimization via OPTG command
|
||||
* - >TYPES or <TYPES
|
||||
- Send/request the numeric type of each atom (N values)
|
||||
- Send/request the LAMMPS atom type for each atom (N values)
|
||||
* - >VELOCITIES or <VELOCITIES
|
||||
- Send/request the velocity of each atom (3N values)
|
||||
* - @INIT_MD or @INIT_OPTG
|
||||
@ -145,9 +161,25 @@ commands, which are described further below.
|
||||
builds. If the change in atom positions is large (since the
|
||||
previous >COORDS command), then LAMMPS will do a more expensive
|
||||
operation to migrate atoms to new processors as needed and
|
||||
re-neighbor. If the >NATOMS or >TYPES commands have been sent
|
||||
(since the previous >COORDS command), then LAMMPS assumes the
|
||||
system is new and re-initializes an entirely new simulation.
|
||||
re-neighbor. If the >NATOMS or >TYPES or >ELEMENTS commands have
|
||||
been sent (since the previous >COORDS command), then LAMMPS assumes
|
||||
the system is new and re-initializes an entirely new simulation.
|
||||
|
||||
.. note::
|
||||
|
||||
The >TYPES or >ELEMENTS commands are how the MDI driver tells the
|
||||
LAMMPS engine which LAMMPS atom type to assign to each atom. If
|
||||
both the MDI driver and the LAMMPS engine are initialized so that
|
||||
atom type values are consistent in both codes, then the >TYPES
|
||||
command can be used. If not, the optional *elements* keyword can
|
||||
be used to specify what element each LAMMPS atom type corresponds
|
||||
to. This is specified by the atomic number of the element, e.g. 13
|
||||
for Al. An atomic number must be specified for each of the ntypes
|
||||
LAMMPS atom types. Ntypes is typically specified via the
|
||||
create_box command or in the data file read by the read_data
|
||||
command. In this has been done, the MDI driver can send an
|
||||
>ELEMENTS command to the LAMMPS driver with the atomic number of
|
||||
each atom.
|
||||
|
||||
The MD and OPTG commands perform an entire MD simulation or energy
|
||||
minimization (to convergence) with no communication from the driver
|
||||
@ -270,7 +302,7 @@ The *command* keyword is required. It specifies a LAMMPS input script
|
||||
command (as a single argument in quotes if it is multiple words).
|
||||
Once the plugin library is launched, LAMMPS will execute this command.
|
||||
Other previously-defined commands in the input script, such as the
|
||||
:doc:`fix mdi/aimd <fix_mdi_aimd>` command, should perform MDI
|
||||
:doc:`fix mdi/qm <fix_mdi_qm>` command, should perform MDI
|
||||
communication with the engine, while the specified *command* executes.
|
||||
Note that if *command* is an :doc:`include <include>` command, then it
|
||||
could specify a filename with multiple LAMMPS commands.
|
||||
@ -284,6 +316,31 @@ could specify a filename with multiple LAMMPS commands.
|
||||
"mdi plugin" command could then load the same library plugin or
|
||||
a different one if desired.
|
||||
|
||||
----------
|
||||
|
||||
The *mdi connect* and *mdi exit* commands are only used when LAMMPS is
|
||||
operating as an MDI driver. And when other LAMMPS command(s) which
|
||||
send MDI commands and associated data to/from the MDI engine are not
|
||||
able to initiate and terminate the connection to the engine code.
|
||||
|
||||
The only current MDI driver command in LAMMPS is the :doc:`fix mdi/qm
|
||||
<fix_mdi_qm>` command. If it is only used once in an input script
|
||||
then it can initiate and terminate the connection. But if it is being
|
||||
issued multiple times, e.g. in a loop that issues a :doc:`clear
|
||||
<clear>` command, then it cannot initiate or terminate the connection
|
||||
multiple times. Instead, the *mdi connect* and *mdi exit* commands
|
||||
should be used outside the loop to initiate or terminate the connection.
|
||||
|
||||
See the examples/mdi/in.series.driver script for an example of how
|
||||
this is done. The LOOP in that script is reading a series of data
|
||||
file configurations and passing them to an MDI engine (e.g. quantum
|
||||
code) for energy and force evaluation. A *clear* command inside the
|
||||
loop wipes out the current system so a new one can be defined. This
|
||||
operation also destroys all fixes. So the :doc:`fix mdi/qm
|
||||
<fix_mdi_qm>` command is issued once per loop iteration. Note that it
|
||||
includes a "connect no" option which disables the initiate/terminate
|
||||
logic within that fix.
|
||||
|
||||
|
||||
Restrictions
|
||||
""""""""""""
|
||||
@ -304,7 +361,7 @@ supports, e.g. *lj*, but then no unit conversion is performed.
|
||||
Related commands
|
||||
""""""""""""""""
|
||||
|
||||
:doc:`fix mdi/aimd <fix_mdi_aimd>`
|
||||
:doc:`fix mdi/qm <fix_mdi_qm>`
|
||||
|
||||
Default
|
||||
"""""""
|
||||
|
||||
@ -71,7 +71,7 @@ Syntax
|
||||
*no_affinity* values = none
|
||||
*kokkos* args = keyword value ...
|
||||
zero or more keyword/value pairs may be appended
|
||||
keywords = *neigh* or *neigh/qeq* or *neigh/thread* or *newton* or *binsize* or *comm* or *comm/exchange* or *comm/forward* *comm/pair/forward* *comm/fix/forward* or *comm/reverse* or *gpu/aware* or *pair/only*
|
||||
keywords = *neigh* or *neigh/qeq* or *neigh/thread* or *newton* or *binsize* or *comm* or *comm/exchange* or *comm/forward* *comm/pair/forward* *comm/fix/forward* or *comm/reverse* or *comm/pair/reverse* or *gpu/aware* or *pair/only*
|
||||
*neigh* value = *full* or *half*
|
||||
full = full neighbor list
|
||||
half = half neighbor list built in thread-safe manner
|
||||
@ -96,6 +96,7 @@ Syntax
|
||||
*comm/pair/forward* value = *no* or *device*
|
||||
*comm/fix/forward* value = *no* or *device*
|
||||
*comm/reverse* value = *no* or *host* or *device*
|
||||
*comm/pair/reverse* value = *no* or *device*
|
||||
no = perform communication pack/unpack in non-KOKKOS mode
|
||||
host = perform pack/unpack on host (e.g. with OpenMP threading)
|
||||
device = perform pack/unpack on device (e.g. on GPU)
|
||||
@ -500,7 +501,7 @@ rule of thumb may give too large a binsize and the default should be
|
||||
overridden with a smaller value.
|
||||
|
||||
The *comm* and *comm/exchange* and *comm/forward* and *comm/pair/forward*
|
||||
and *comm/fix/forward* and comm/reverse*
|
||||
and *comm/fix/forward* and *comm/reverse* and *comm/pair/reverse*
|
||||
keywords determine whether the host or device performs the packing and
|
||||
unpacking of data when communicating per-atom data between processors.
|
||||
"Exchange" communication happens only on timesteps that neighbor lists
|
||||
@ -521,9 +522,16 @@ packing/unpacking data for the communication. A value of *host* means to
|
||||
use the host, typically a multi-core CPU, and perform the
|
||||
packing/unpacking in parallel with threads. A value of *device* means to
|
||||
use the device, typically a GPU, to perform the packing/unpacking
|
||||
operation. If a value of *host* is used for the *comm/pair/forward* or
|
||||
*comm/fix/forward* keyword, it will be automatically be changed to *no*
|
||||
since these keywords don't support *host* mode.
|
||||
operation.
|
||||
|
||||
For the *comm/pair/forward* or *comm/fix/forward* or *comm/pair/reverse*
|
||||
keywords, if a value of *host* is used it will be automatically
|
||||
be changed to *no* since these keywords don't support *host* mode. The
|
||||
value of *no* will also always be used when running on the CPU, i.e. setting
|
||||
the value to *device* will have no effect if the pair/fix style is
|
||||
running on the CPU. For the *comm/fix/forward* or *comm/pair/reverse*
|
||||
keywords, not all styles support *device* mode and in that case will run
|
||||
in *no* mode instead.
|
||||
|
||||
The optimal choice for these keywords depends on the input script and
|
||||
the hardware used. The *no* value is useful for verifying that the
|
||||
|
||||
@ -1,8 +1,11 @@
|
||||
.. index:: pair_style meam
|
||||
.. index:: pair_style meam/kk
|
||||
|
||||
pair_style meam command
|
||||
=========================
|
||||
|
||||
Accelerator Variants: *meam/kk*
|
||||
|
||||
Syntax
|
||||
""""""
|
||||
|
||||
@ -347,6 +350,12 @@ Most published MEAM parameter sets use the default values *attrac* = *repulse* =
|
||||
Setting *repuls* = *attrac* = *delta* corresponds to the form used in several
|
||||
recent published MEAM parameter sets, such as :ref:`(Valone) <Valone>`
|
||||
|
||||
----------
|
||||
|
||||
.. include:: accel_styles.rst
|
||||
|
||||
----------
|
||||
|
||||
.. note::
|
||||
|
||||
The default form of the *erose* expression in LAMMPS was corrected
|
||||
|
||||
Reference in New Issue
Block a user