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

Merge remote-tracking branch 'github/develop' into qeqr

Browse Source
This commit is contained in:
Axel Kohlmeyer
2025-03-29 18:41:36 -04:00
parent fc9d7bc181 285baf27b5
commit 367dd4635b
329 changed files with 5931 additions and 7857 deletions
Download Patch File Download Diff File Expand all files Collapse all files

47
.github/release_steps.md vendored
View File

@ -216,7 +216,7 @@ and using the CMake settings:
``` sh
-D CMAKE_OSX_ARCHITECTURES=arm64;x86_64
-D CMAKE_OSX_DEPLOYMENT_TARGER=11.0
-D CMAKE_OSX_DEPLOYMENT_TARGET=11.0
```
This will add the compiler flags `-arch arm64 -arch x86_64
@ -324,6 +324,47 @@ At this point it should be possible to do a fast-forward merge of
### Push branches and tags
## LAMMPS Stable Update Release
After making a stable release, bugfixes from the 'develop' branch
are selectively backported to the 'maintenance' branch. This is
done with "git cherry-pick \<commit hash\>' wherever possible.
The LAMMPS\_UPDATE define in "src/version.h" is set to "Maintenance".
### Prerequesites
When a sufficient number of bugfixes has accumulated or an urgent
or important bugfix needs to be distributed a new stable update
release is made. To make this publicly visible a pull request
is submitted that will merge 'maintenance' into 'stable'. Before
merging, set LAMMPS\_UPDATE in "src/version.h" to "Update #" with
"#" indicating the update count (1, 2, and so on).
Also draft suitable release notes under https://github.com/lammps/lammps/releases
### Fast-forward merge of 'maintenance' into 'stable', apply tag, and publish
Do a fast-forward merge of 'maintenance' to 'stable' and then
apply the stable\_DMmmYYYY\_update# tag and push branch and tag
to GitHub. The corresponding pull request will be automatically
closed. Example:
```
git checkout maintenance
git pull
git checkout stable
git pull
git merge --ff-only maintenance
git tag -s -m 'Update 2 for Stable LAMMPS version 29 August 2024' stable_29Aug2024_update2
git push git@github.com:lammps/lammps.git --tags maintenance stable
```
Associate draft release notes with new tag and publish as "latest release".
On https://ci.lammps.org/ go to "dev", "stable" and manually execute
the "update\_release" task. This will update https://docs.lammps.org/stable
and prepare a stable tarball.
### Build and upload binary packages and source tarball to GitHub
The build procedure is the same as for the feature releases, only
that packages are built from the 'stable' branch.

4
cmake/CMakeLists.txt
View File

@ -431,8 +431,8 @@ else()
target_link_libraries(lammps PUBLIC mpi_stubs)
endif()
set(LAMMPS_SIZES "smallbig" CACHE STRING "LAMMPS integer sizes (smallsmall: all 32-bit, smallbig: 64-bit #atoms #timesteps, bigbig: also 64-bit imageint, 64-bit atom ids)")
set(LAMMPS_SIZES_VALUES smallbig bigbig smallsmall)
set(LAMMPS_SIZES "smallbig" CACHE STRING "LAMMPS integer sizes (smallbig: 64-bit #atoms #timesteps, bigbig: also 64-bit imageint, 64-bit atom ids)")
set(LAMMPS_SIZES_VALUES smallbig bigbig)
set_property(CACHE LAMMPS_SIZES PROPERTY STRINGS ${LAMMPS_SIZES_VALUES})
validate_option(LAMMPS_SIZES LAMMPS_SIZES_VALUES)
string(TOUPPER ${LAMMPS_SIZES} LAMMPS_SIZES)

4
cmake/Modules/LAMMPSInterfacePlugin.cmake
View File

@ -260,8 +260,8 @@ endif()
################
# integer size selection
set(LAMMPS_SIZES "smallbig" CACHE STRING "LAMMPS integer sizes (smallsmall: all 32-bit, smallbig: 64-bit #atoms #timesteps, bigbig: also 64-bit imageint, 64-bit atom ids)")
set(LAMMPS_SIZES_VALUES smallbig bigbig smallsmall)
set(LAMMPS_SIZES "smallbig" CACHE STRING "LAMMPS integer sizes (smallbig: 64-bit #atoms #timesteps, bigbig: also 64-bit imageint, 64-bit atom ids)")
set(LAMMPS_SIZES_VALUES smallbig bigbig)
set_property(CACHE LAMMPS_SIZES PROPERTY STRINGS ${LAMMPS_SIZES_VALUES})
validate_option(LAMMPS_SIZES LAMMPS_SIZES_VALUES)
string(TOUPPER ${LAMMPS_SIZES} LAMMPS_SIZES)

7
doc/src/Build_cmake.rst
View File

@ -119,6 +119,13 @@ configured) and additional files like LAMMPS API headers, manpages,
potential and force field files. The location of the installation tree
defaults to ``${HOME}/.local``.
.. note::
If you have set `-D CMAKE_INSTALL_PREFIX` to install LAMMPS into a
system location on a Linux machine , you may also have to run (as
root) the `ldconfig` program to update the cache file for fast lookup
of system shared libraries.
.. _cmake_options:
Configuration and build options

9
doc/src/Build_extras.rst
View File

@ -255,11 +255,10 @@ Traditional make
Before building LAMMPS, you must build the GPU library in ``lib/gpu``\ .
You can do this manually if you prefer; follow the instructions in
``lib/gpu/README``. Note that the GPU library uses MPI calls, so you must
use the same MPI library (or the STUBS library) settings as the main
LAMMPS code. This also applies to the ``-DLAMMPS_BIGBIG``\ ,
``-DLAMMPS_SMALLBIG``\ , or ``-DLAMMPS_SMALLSMALL`` settings in whichever
Makefile you use.
``lib/gpu/README``. Note that the GPU library uses MPI calls, so you
must use the same MPI library (or the STUBS library) settings as the
main LAMMPS code. This also applies to the ``-DLAMMPS_BIGBIG`` or
``-DLAMMPS_SMALLBIG`` settings in whichever Makefile you use.
You can also build the library in one step from the ``lammps/src`` dir,
using a command like these, which simply invokes the ``lib/gpu/Install.py``

9
doc/src/Build_manual.rst
View File

@ -221,9 +221,10 @@ HTML as a quick-n-dirty way of checking your manual page.
This translation uses `Pandoc <https://pandoc.org>`_ instead of Sphinx
and thus all special Sphinx features (cross-references, advanced tables,
embedding of Python docstring and doxygen documentation, and so on) will
not render correctly. But this is a **very fast** way to check the content
as HTML while writing the documentation.
embedding of Python docstrings or doxygen documentation, and so on) will
not render correctly. Most embedded math should render correctly. This
is a **very fast** way to check the syntax and layout of a documentation
file translated to HTML while writing or updating it.
To translate **all** manual pages, you can type ``make fasthtml`` at the
command line. The translated HTML files are then in the ``fasthtml``
@ -235,7 +236,7 @@ directly translate only individual pages: e.g. to translate only the
After writing the documentation is completed, you will still need
to verify with ``make html`` and ``make pdf`` that it translates
correctly.
correctly in both formats.
Tests for consistency, completeness, and other known issues
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

41
doc/src/Build_settings.rst
View File

@ -13,7 +13,8 @@ explains how to do this for building both with CMake and make.
* `Size of LAMMPS integer types and size limits`_
* `Read or write compressed files`_
* `Output of JPEG, PNG, and movie files`_ via the :doc:`dump image <dump_image>` or :doc:`dump movie <dump_image>` commands
* `Support for downloading files`_
* `Support for downloading files from the input`_
* `Prevent download of large potential files`_
* `Memory allocation alignment`_
* `Workaround for long long integers`_
* `Exception handling when using LAMMPS as a library`_ to capture errors
@ -315,7 +316,7 @@ large counters can become before "rolling over". The default setting of
.. code-block:: bash
-D LAMMPS_SIZES=value # smallbig (default) or bigbig or smallsmall
-D LAMMPS_SIZES=value # smallbig (default) or bigbig
If the variable is not set explicitly, "smallbig" is used.
@ -326,7 +327,7 @@ large counters can become before "rolling over". The default setting of
.. code-block:: make
LMP_INC = -DLAMMPS_SMALLBIG # or -DLAMMPS_BIGBIG or -DLAMMPS_SMALLSMALL
LMP_INC = -DLAMMPS_SMALLBIG # or -DLAMMPS_BIGBIG
The default setting is ``-DLAMMPS_SMALLBIG`` if nothing is specified
@ -335,34 +336,27 @@ LAMMPS system size restrictions
.. list-table::
:header-rows: 1
:widths: 18 27 28 27
:widths: 27 36 37
:align: center
* -
- smallbig
- bigbig
- smallsmall
* - Total atom count
- :math:`2^{63}` atoms (= :math:`9.223 \cdot 10^{18}`)
- :math:`2^{63}` atoms (= :math:`9.223 \cdot 10^{18}`)
- :math:`2^{31}` atoms (= :math:`2.147 \cdot 10^9`)
* - Total timesteps
- :math:`2^{63}` steps (= :math:`9.223 \cdot 10^{18}`)
- :math:`2^{63}` steps (= :math:`9.223 \cdot 10^{18}`)
- :math:`2^{31}` steps (= :math:`2.147 \cdot 10^9`)
* - Atom ID values
- :math:`1 \le i \le 2^{31} (= 2.147 \cdot 10^9)`
- :math:`1 \le i \le 2^{63} (= 9.223 \cdot 10^{18})`
- :math:`1 \le i \le 2^{31} (= 2.147 \cdot 10^9)`
* - Image flag values
- :math:`-512 \le i \le 511`
- :math:`- 1\,048\,576 \le i \le 1\,048\,575`
- :math:`-512 \le i \le 511`
The "bigbig" setting increases the size of image flags and atom IDs over
"smallbig" and the "smallsmall" setting is only needed if your machine
does not support 64-bit integers or incurs performance penalties when
using them.
the default "smallbig" setting.
These are limits for the core of the LAMMPS code, specific features or
some styles may impose additional limits. The :ref:`ATC
@ -516,8 +510,8 @@ during a run.
.. _libcurl:
Support for downloading files
-----------------------------
Support for downloading files from the input
--------------------------------------------
.. versionadded:: 29Aug2024
@ -560,6 +554,25 @@ LAMMPS is compiled accordingly which needs the following settings:
----------
.. _download_pot:
Prevent download of large potential files
-----------------------------------------
.. versionadded:: 8Feb2023
LAMMPS bundles a selection of potential files in the ``potentials``
folder as examples of how those kinds of potential files look like and
for use with the provided input examples in the ``examples`` tree. To
keep the size of the distributed LAMMPS source package small, very large
potential files (> 5 MBytes) are not bundled, but only downloaded on
demand when the :doc:`corresponding package <Packages_list>` is
installed. This automatic download can be prevented when :doc:`building
LAMMPS with CMake <Build_cmake>` by adding the setting `-D
DOWNLOAD_POTENTIALS=off` when configuring.
----------
.. _align:
Memory allocation alignment

712
doc/src/Errors_details.rst
View File

@ -1,12 +1,14 @@
Error and warning details
=========================
Errors and warnings details
===========================
Many errors or warnings are self-explanatory and thus straightforward to
resolve. However, there are also cases, where there is no single cause
and explanation, where LAMMPS can only detect symptoms of an error but
not the exact cause, or where the explanation needs to be more detailed
than what can be fit into a message printed by the program. The
following are discussions of such cases.
Many errors and warnings that LAMMPS outputs are self-explanatory and
thus straightforward to resolve. However, there are also cases where
there is no single cause or simple explanation that can be provided in a
short message printed by LAMMPS. Therefore, more detailed discussions
of such scenarios are provided here; first on a more general level and
then for specific errors. In the latter cases, LAMMPS will output a
short message and then provide a URL that links to a specific section on
this page.
.. contents::
@ -75,13 +77,13 @@ simulation settings. For time critical code paths, LAMMPS will assume
the user has chosen the settings carefully and will not make any checks
to avoid to avoid performance penalties.
A crucial step in resolving a segmentation fault is to identify the exact
location in the code where it happens. Please see `Errors_debug` for
a couple of examples showing how to do this on a Linux machine. With
this information -- a simple way to reproduce the segmentation fault and
the exact :doc:`LAMMPS version <Manual_version>` and platform you are
running on -- you can contact the LAMMPS developers or post in the LAMMPS
forum to get assistance.
A crucial step in resolving a segmentation fault is to identify the
exact location in the code where it happens. Please see `Errors_debug`
for a couple of examples showing how to do this on a Linux machine.
With this information -- a simple way to reproduce the segmentation
fault and the exact :doc:`LAMMPS version <Manual_version>` and platform
you are running on -- you can contact the LAMMPS developers or post in
the LAMMPS forum to get assistance.
.. _hint05:
@ -91,55 +93,57 @@ Fast moving atoms
Fast moving atoms may be "lost" or "missing" when their velocity becomes
so large that they can cross a sub-domain within one timestep. This
often happens when atoms are too close, but atoms may also "move" too
fast from sub-domain to sub-domain if the box changes rapidly. E.g. when
setting a large an initial box with :doc:`shrink-wrap boundary
fast from sub-domain to sub-domain if the box changes rapidly.
E.g. when setting a large an initial box with :doc:`shrink-wrap boundary
conditions <boundary>` that collapses on the first step (in this case
the solution is often using 'm' instead of 's' as a boundary condition).
To reduce the impact of "close contacts", one can remove those atoms or
molecules with something like :doc:`delete_atoms overlap 0.1 all all
<delete_atoms>`. With periodic boundaries, a close contact pair of atoms
may be on opposite sides of the simulation box. Another option would be
to first run a minimization (aka quench) before starting the MD. Reducing
the time step can also help. Many times, one just needs to "ease" the
system into a balanced state and can then switch to more aggressive settings.
<delete_atoms>`. With periodic boundaries, a close contact pair of
atoms may be on opposite sides of the simulation box. Another option
would be to first run a minimization (aka quench) before starting
the MD. Reducing the time step can also help. Many times, one just
needs to "ease" the system into a balanced state and can then switch to
more aggressive settings.
The speed of atoms during an MD run depends on the steepness of the
potential function and their mass. Since the positions and velocities
of atoms are computed with finite timesteps, the timestep needs to be
small enough for stable numeric integration of the trajectory. If the timestep
is too large during initialization (or other instances of extreme dynamics),
using :doc:`fix nve/limit <fix_nve_limit>` or :doc:`fix dt/reset <fix_dt_reset>`
temporarily can help to avoid too large updates or adapt the timestep according
to the displacements.
small enough for stable numeric integration of the trajectory. If the
timestep is too large during initialization (or other instances of
extreme dynamics), using :doc:`fix nve/limit <fix_nve_limit>` or
:doc:`fix dt/reset <fix_dt_reset>` temporarily can help to avoid too
large updates or adapt the timestep according to the displacements.
.. _hint06:
Ignoring lost atoms
^^^^^^^^^^^^^^^^^^^
It is tempting to use the :doc:`thermo_modify lost ignore <thermo_modify>`
to avoid LAMMPS aborting with an error on lost atoms. This setting should,
however, *only* be used when atoms *should* leave the system. In general,
ignoring a problem does not solve it.
It is tempting to use the :doc:`thermo_modify lost ignore
<thermo_modify>` to avoid LAMMPS aborting with an error on lost atoms.
This setting should, however, *only* be used when atoms *should* leave
the system. In general, ignoring a problem does not solve it.
.. _hint07:
Pressure, forces, positions becoming NaN or Inf
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Some potentials can overflow or have a division by zero with close contacts
or bad geometries (for the given force styles in use) leading to forces
that can no longer be represented as numbers. Those will show as "NaN" or
"Inf". On most machines, the program will continue, but there is no way
to recover from it and those NaN or Inf values will propagate. So-called
:doc:`"soft-core" potentials <pair_fep_soft>` or the :doc:`"soft" repulsive-only
pair style <pair_soft>` are less prone for this behavior (depending on the
settings in use) and can be used at the beginning of a simulation. Also,
single precision numbers can overflow much faster, so for the GPU or INTEL
package it may be beneficial to run with double precision initially before
switching to mixed or single precision for faster execution when the system
has relaxed.
Some potentials can overflow or have a division by zero with close
contacts or bad geometries (for the given force styles in use) leading
to forces that can no longer be represented as numbers. Those will show
as "NaN" or "Inf". On most machines, the program will continue, but
there is no way to recover from it and those NaN or Inf values will
propagate. So-called :doc:`"soft-core" potentials <pair_fep_soft>` or
the :doc:`"soft" repulsive-only pair style <pair_soft>` are less prone
for this behavior (depending on the settings in use) and can be used at
the beginning of a simulation. Also, single precision numbers can
overflow much faster, so for the GPU or INTEL package it may be
beneficial to run with double precision initially before switching to
mixed or single precision for faster execution when the system has
relaxed.
.. _hint08:
@ -149,17 +153,17 @@ Communication cutoff
The communication cutoff determines the "overlap" between sub-domains
and atoms in these regions are referred to in LAMMPS as "ghost atoms".
This region has to be large enough to contain all atoms of a bond,
angle, dihedral, or improper with just one atom in the actual sub-domain.
Typically, this cutoff is set to the largest cutoff from the :doc:`pair
style(s) <pair_style>` plus the :doc:`neighbor list skin distance
<neighbor>` and will typically be sufficient for all bonded
angle, dihedral, or improper with just one atom in the actual
sub-domain. Typically, this cutoff is set to the largest cutoff from
the :doc:`pair style(s) <pair_style>` plus the :doc:`neighbor list skin
distance <neighbor>` and will typically be sufficient for all bonded
interactions. But if the pair style cutoff is small, this may not be
enough. LAMMPS will print a warning in this case using some heuristic
based on the equilibrium bond length, but that still may not be sufficient
for cases where the force constants are small and thus bonds may be
stretched very far. The communication cutoff can be adjusted with
:doc:`comm_modify cutoff \<value\> <comm_modify>`, but setting this too
large will waste CPU time and memory.
based on the equilibrium bond length, but that still may not be
sufficient for cases where the force constants are small and thus bonds
may be stretched very far. The communication cutoff can be adjusted
with :doc:`comm_modify cutoff \<value\> <comm_modify>`, but setting this
too large will waste CPU time and memory.
.. _hint09:
@ -204,12 +208,12 @@ In some cases -- especially when running in parallel with MPI -- LAMMPS
may stop without displaying an error. But the fact that nothing was
displayed does not mean there was not an error message. Instead it is
highly likely that the message was written to a buffer and LAMMPS was
aborted before the buffer was output. Usually, output buffers are output
for every line of output, but sometimes this is delayed until 4096 or
8192 bytes of output have been accumulated. This buffering for screen
and logfile output can be disabled by using the :ref:`-nb or -nonbuf
<nonbuf>` command-line flag. This is most often needed when debugging
crashing multi-replica calculations.
aborted before the buffer was output. Usually, output buffers are
output for every line of output, but sometimes this is delayed until
4096 or 8192 bytes of output have been accumulated. This buffering for
screen and logfile output can be disabled by using the :ref:`-nb
or -nonbuf <nonbuf>` command-line flag. This is most often needed when
debugging crashing multi-replica calculations.
.. _hint12:
@ -228,7 +232,7 @@ defined. Very few commands can be used before and after, like
Most LAMMPS commands must be used after the simulation box is created.
Consequently, LAMMPS will stop with an error, if a command is used in
the wrong place. This is not always obvious. So index or string style
the wrong place. This is not always obvious. So index or string style
:doc:`variables <variable>` can be expanded anywhere in the input, but
equal style (or similar) variables can only be expanded before the box
is defined if they do not reference anything that cannot be defined
@ -251,13 +255,14 @@ The header section informs LAMMPS how many entries or lines are expected
in the various sections (like Atoms, Masses, Pair Coeffs, *etc.*\ ) of
the data file. If there is a mismatch, LAMMPS will either keep reading
beyond the end of a section or stop reading before the section has
ended. In that case the next line will not contain a recognized keyword.
ended. In that case the next line will not contain a recognized
keyword.
Such a mismatch can also happen when the first line of the data
is *not* a comment as required by the format, but a line with a valid
header keyword. That would result in LAMMPS expecting, for instance,
0 atoms because the "atoms" header line is the first line and thus
treated as a comment.
Such a mismatch can also happen when the first line of the data is *not*
a comment as required by the format, but a line with a valid header
keyword. That would result in LAMMPS expecting, for instance, 0 atoms
because the "atoms" header line is the first line and thus treated as a
comment.
Another possibility to trigger this error is to have a keyword in the
data file that corresponds to a fix (e.g. :doc:`fix cmap <fix_cmap>`)
@ -273,15 +278,15 @@ Incorrect format in ... section of data file
This error happens when LAMMPS reads the contents of a section of a
:doc:`data file <read_data>` and the number of parameters in the line
differs from what is expected. This most commonly happens when the
atom style is different from what is expected for a specific data file
since changing the atom style usually changes the format of the line.
differs from what is expected. This most commonly happens when the atom
style is different from what is expected for a specific data file since
changing the atom style usually changes the format of the line.
This error can also occur when the number of entries indicated in the
header of a data file (e.g. the number of atoms) is larger than the
number of lines provided (e.g. in the corresponding Atoms section)
causing LAMMPS to continue reading into the next section which has
a completely different format.
causing LAMMPS to continue reading into the next section which has a
completely different format.
.. _err0003:
@ -289,100 +294,114 @@ Illegal variable command: expected X arguments but found Y
----------------------------------------------------------
This error indicates that a variable command has the wrong number of
arguments. A common reason for this is that the variable expression
has whitespace, but is not enclosed in single or double quotes.
arguments. A common reason for this is that the variable expression has
whitespace, but is not enclosed in single or double quotes.
To explain, the LAMMPS input parser reads and processes lines. The
resulting line is broken down into "words". Those are usually
individual commands, labels, names, and values separated by whitespace (a
space or tab character). For "words" that may contain whitespace, they
have to be enclosed in single (') or double (") quotes. The parser will
then remove the outermost pair of quotes and pass that string as
individual commands, labels, names, and values separated by whitespace
(a space or tab character). For "words" that may contain whitespace,
they have to be enclosed in single (') or double (") quotes. The parser
will then remove the outermost pair of quotes and pass that string as
"word" to the variable command.
Thus missing quotes or accidental extra whitespace will trigger this
error because the unquoted whitespace will result in the text being broken
into more "words", i.e. the variable expression being split.
error because the unquoted whitespace will result in the text being
broken into more "words", i.e. the variable expression being split.
.. _err0004:
Out of range atoms - cannot compute ...
---------------------------------------
The PPPM (and also PPPMDisp and MSM) methods need to assemble a grid
of electron density data derived from the (partial) charges assigned to
the atoms. These charges are smeared out across multiple grid points
(see :doc:`kspace_modify order <kspace_modify>`). When running in
parallel with MPI, LAMMPS uses a :doc:`domain decomposition scheme
The PPPM (and also PPPMDisp and MSM) methods need to assemble a grid of
electron density data derived from the (partial) charges assigned to the
atoms. These charges are smeared out across multiple grid points (see
:doc:`kspace_modify order <kspace_modify>`). When running in parallel
with MPI, LAMMPS uses a :doc:`domain decomposition scheme
<Developer_par_part>` where each processor manages a subset of atoms and
thus also a grid representing the density. The processor's grid covers the
actual volume of the sub-domain and some extra space corresponding to the
:doc:`neighbor list skin <neighbor>`. These are then :doc:`combined and
redistributed <Developer_par_long>` for parallel processing of the
long-range component of the Coulomb interaction.
thus also a grid representing the density. The processor's grid covers
the actual volume of the sub-domain and some extra space corresponding
to the :doc:`neighbor list skin <neighbor>`. These are then
:doc:`combined and redistributed <Developer_par_long>` for parallel
processing of the long-range component of the Coulomb interaction.
The ``Out of range atoms`` error can happen when atoms move too fast,
the neighbor list skin is too small, or the neighbor lists are not
updated frequently enough. The smeared charges cannot then be fully
assigned to the density grid for all atoms. LAMMPS checks for this
condition and stops with an error. Most of the time, this is an
indication of a system with very high forces, often at the beginning
of a simulation or when boundary conditions are changed. The
error becomes more likely with more MPI processes.
indication of a system with very high forces, often at the beginning of
a simulation or when boundary conditions are changed. The error becomes
more likely with more MPI processes.
There are multiple options to explore for avoiding the error. The best
choice depends strongly on the individual system, and often a
combination of changes is required. For example, more conservative MD
parameter settings can be used (larger neighbor skin, shorter time step,
more frequent neighbor list updates). Sometimes, it helps to revisit
the system generation and avoid close contacts when building it. Otherwise
one can use the :doc:`delete_atoms overlap<delete_atoms>` command to delete
those close contact atoms or run a minimization before the MD. It can also
help to temporarily use a cutoff-Coulomb pair style and no kspace style
until the system has somewhat equilibrated and then switch to the
long-range solver.
the system generation and avoid close contacts when building it.
Otherwise one can use the :doc:`delete_atoms overlap<delete_atoms>`
command to delete those close contact atoms or run a minimization before
the MD. It can also help to temporarily use a cutoff-Coulomb pair style
and no kspace style until the system has somewhat equilibrated and then
switch to the long-range solver.
.. _err0005:
Bond (or angle, dihedral, or improper) atoms missing
----------------------------------------------------
Bond (or angle, dihedral, improper, cmap, or shake) atoms missing
-----------------------------------------------------------------
The second atom needed to compute a particular bond (or the third or fourth
atom for angle, dihedral, or improper) is missing on the indicated timestep
and processor. Typically, this is because the two bonded atoms have become
too far apart relative to the communication cutoff distance for ghost atoms.
By default, the communication cutoff is set by the pair cutoff. However, to
accommodate larger distances between topologically connected atoms, it can
be manually adjusted using :doc:`comm_modify <comm_modify>` at the cost of
increased communication and more ghost atoms. However, missing bond atoms
may also indicate that there are unstable dynamics which caused the atoms
to blow apart. In this scenario, increasing the communication distance will
not solve the underlying issue. Rather, see :ref:`Fast moving atoms <hint05>`
and :ref:`Neighbor list settings <hint09>` in the general troubleshooting
The second atom needed to compute a particular bond (or the third or
fourth atom for angle, dihedral, or improper) is missing on the
indicated timestep and processor. Typically, this is because the two
bonded atoms have become too far apart relative to the communication
cutoff distance for ghost atoms. By default, the communication cutoff
is set by the pair cutoff. However, to accommodate larger distances
between topologically connected atoms, it can be manually adjusted using
:doc:`comm_modify <comm_modify>` at the cost of increased communication
and more ghost atoms. However, missing bond atoms may also indicate
that there are unstable dynamics which caused the atoms to blow apart.
In this scenario, increasing the communication distance will not solve
the underlying issue. Rather, see :ref:`Fast moving atoms <hint05>` and
:ref:`Neighbor list settings <hint09>` in the general troubleshooting
section above for ideas to fix unstable dynamics.
If atoms are intended to be lost during a simulation (e.g. due to open boundary
conditions or :doc:`fix evaporate <fix_evaporate>`) such that two bonded atoms
may be lost at different times from each other, this error can be converted to a
warning or turned off using the *lost/bond* keyword in the :doc:`thermo_modify
<thermo_modify>` command.
If atoms are intended to be lost during a simulation (e.g. due to open
boundary conditions or :doc:`fix evaporate <fix_evaporate>`) such that
two bonded atoms may be lost at different times from each other, this
error can be converted to a warning or turned off using the *lost/bond*
keyword in the :doc:`thermo_modify <thermo_modify>` command.
.. _err0006:
Non-numeric atom coords - simulation unstable
---------------------------------------------
This error usually occurs due to issues with system geometry or the potential in
use. See :ref:`Pressure, forces, positions becoming NaN or Inf <hint07>` above in the
general troubleshooting section.
Non-numeric atom coords or pressure or box dimensions - simulation unstable
---------------------------------------------------------------------------
.. _err0007:
This error usually occurs due to overly aggressive simulation settings
or issues with the system geometry or the potential. See
:ref:`Pressure, forces, positions becoming NaN or Inf <hint07>` above in
the general troubleshooting section. This error is more likely to
happen during equilibration, so it can help to do a minimization before
or even add a second or third minimization after running a few
equilibration MD steps. It also is more likely when directly using a
Nose-Hoover (or other) barostat, and thus it may be advisable to run
with only a thermostat for a bit until the potential energy has
stabilized.
Non-numeric pressure - simulation unstable
------------------------------------------
This error usually occurs due to issues with system geometry or the potential in
use. See :ref:`Pressure, forces, positions becoming NaN or Inf <hint07>` above in the
general troubleshooting section.
.. _err007:
Fix used in ... not computed at compatible time
-----------------------------------------------
Many fix styles are invoked only every *nevery* timesteps, which means
their data is only valid on those steps. When data from a fix is used
as input for a compute, a dump, another fix, or thermo output, it must
read that data at timesteps when the fix in question was invoked, i.e.
on timesteps that are multiples of its *nevery* setting. If this is not
the case, LAMMPS will stop with an error. To remedy this, it may be
required to change the output frequency or the *nevery* setting of the
fix.
.. _err0008:
@ -390,48 +409,73 @@ Lost atoms ...
--------------
A simulation stopping with an error due to lost atoms can have multiple
causes. In the majority of cases, lost atoms are unexpected and a result
of extremely high velocities causing instabilities in the system, and
those velocities can result from a variety of issues. For ideas on how
to track down issues with unexpected lost atoms, see :ref:`Fast moving
atoms <hint05>` and :ref:`Neighbor list settings <hint09>` in the
general troubleshooting section above. In specific situations however,
losing atoms is expected material behavior (e.g. with sputtering and
surface evaporation simulations) and an unwanted crash can be resolved
by changing the :doc:`thermo_modify lost <thermo_modify>` keyword from
the default 'error' to 'warn' or 'ignore' (though heed the advice in
:ref:`Ignoring lost atoms <hint06>` above!).
causes. By default, LAMMPS checks for whether the total number of atoms
is consistent with the sum of atoms "owned" by MPI processors every time
that thermodynamic output is written. In the majority of cases, lost
atoms are unexpected and a result of extremely high velocities causing
instabilities in the system. Such velocities can result from a variety
of issues. For ideas on how to track down issues with unexpected lost
atoms, see :ref:`Fast moving atoms <hint05>` and :ref:`Neighbor list
settings <hint09>` in the general troubleshooting section above. In
specific situations however, losing atoms is expected material behavior
(e.g. with sputtering and surface evaporation simulations), and an
unwanted crash can be avoided by changing the :doc:`thermo_modify lost
<thermo_modify>` keyword from the default 'error' to 'warn' or 'ignore'
(though heed the advice in :ref:`Ignoring lost atoms <hint06>` above!).
.. _err0009:
Too many neighbor bins
----------------------
The simulation box has become too large relative to the size of a
neighbor bin and LAMMPS is unable to store the needed number of
bins. This typically implies the simulation box has expanded too far.
This can happen when some atoms move rapidly apart with shrink-wrap boundaries
or when a fix (like fix deform or a barostat) excessively grows the simulation
box.
The simulation box is or has become too large relative to the size of a
neighbor bin (which in turn depends on the largest pair-wise cutoff by
default) such that LAMMPS is unable to store the needed number of bins.
This typically implies the simulation box has expanded too far. That
can occur when some atoms move rapidly apart with shrink-wrap boundaries
or when a fix (like fix deform or a barostat) excessively grows the
simulation box. This can also happen if the largest pair-wise cutoff is
small. In this case, the error can be avoided by using the
:doc:`neigh_modify command <neigh_modify>` to set the bin width to a
suitably large value.
.. _err0010:
Unrecognized pair style ... is part of ... package which is not enabled in this LAMMPS binary
---------------------------------------------------------------------------------------------
Unrecognized ... style ... is part of ... package which is not enabled in this LAMMPS binary
--------------------------------------------------------------------------------------------
The LAMMPS executable (binary) being used was not compiled with a package
containing the specified pair style. This indicates that the executable needs to
be re-built after enabling the correct package in the relevant Makefile or CMake
build directory. See :doc:`Section 3. Build LAMMPS <Build>` for more details.
One can check if the expected package and pair style is present in the
executable by running it with the ``-help`` (or ``-h``) flag on the command
line. One common oversight, especially for beginner LAMMPS users, is to enable
the package, but to forget to run commands to rebuild (e.g., to run the final
``make`` or ``cmake`` command).
The LAMMPS executable (binary) being used was not compiled with a
package containing the specified style. This indicates that the
executable needs to be re-built after enabling the correct package in
the relevant Makefile or CMake build directory. See
:doc:`Section 3. Build LAMMPS <Build>` for more details. One can check
if the expected package and pair style is present in the executable by
running it with the ``-help`` (or ``-h``) flag on the command line. One
common oversight, especially for beginner LAMMPS users, is enabling the
package but forgetting to run commands to rebuild (e.g., to run the
final ``make`` or ``cmake`` command).
If this error is occurring with an executable that the user does not control
(e.g., through a module on HPC clusters), the user will need to get in contact
with the relevant person or people who can update the executable.
If this error occurs with an executable that the user does not control
(e.g., through a module on HPC clusters), the user will need to get in
contact with the relevant person or people who can update the
executable.
.. _err011:
Energy or stress was not tallied by pair style
----------------------------------------------
This warning can be printed by computes from the :ref:`TALLY package
<PKG-TALLY>`. Those use a callback mechanism that only work for regular
pair-wise additive pair styles like :doc:`Lennard-Jones <pair_lj>`,
:doc:`Morse <pair_morse>`, :doc:`Born-Meyer-Huggins <pair_born>`, and
similar. Such required callbacks have not been implemented for
many-body potentials so one would have to implement them to add
compatibility with these computes (which may be difficult to do in a
generic fashion). Whether this warning indicates that contributions to
the computed properties are missing depends on the groups used. At any
rate, careful testing of the results is advised when this warning
appears.
.. _err0012:
@ -455,9 +499,10 @@ Substitution for illegal variable
A variable in an input script or a variable expression was not found in
the list of valid variables. The most common reason for this is a typo
somewhere in the input file such that the expression uses an invalid variable
name. The second most common reason is omitting the curly braces for a
direct variable with a name that is not a single letter. For example:
somewhere in the input file such that the expression uses an invalid
variable name. The second most common reason is omitting the curly
braces for a direct variable with a name that is not a single letter.
For example:
.. code-block:: LAMMPS
@ -469,14 +514,13 @@ direct variable with a name that is not a single letter. For example:
Another potential source of this error may be invalid command line
variables (-var or -v argument) used when launching LAMMPS from an
interactive shell or shell scripts. An uncommon source for this error
is using the :doc:`next command <next>` to advance through a list of values
provided by an index style variable. If there is no remaining element in
the list, LAMMPS will delete the variable and any following expansion or
reference attempt will trigger the error.
is using the :doc:`next command <next>` to advance through a list of
values provided by an index style variable. If there is no remaining
element in the list, LAMMPS will delete the variable and any following
expansion or reference attempt will trigger the error.
Users with harder-to-track variable errors might also find reading
:doc:`Section 5.2. Parsing rules for input scripts<Commands_parse>`
helpful.
Users with harder-to-track variable errors might also find reading the
:doc:`Parsing rules for input scripts <Commands_parse>` helpful.
.. _err0014:
@ -489,9 +533,9 @@ of the LAMMPS code where it updates the domain decomposition and before
it builds the neighbor lists. It checks that both atoms of a bond are
within the communication cutoff of a subdomain. It is usually caused by
atoms moving too fast (see the :ref:`paragraph on fast moving atoms
<hint05>`), or by the :doc:`communication cutoff being too
small <comm_modify>`, or by waiting too long between :doc:`sub-domain
and neighbor list updates <neigh_modify>`.
<hint05>`), or by the :doc:`communication cutoff being too small
<comm_modify>`, or by waiting too long between :doc:`sub-domain and
neighbor list updates <neigh_modify>`.
.. _err0015:
@ -499,41 +543,43 @@ Cannot use neighbor bins - box size \<\< cutoff
-----------------------------------------------
LAMMPS is unable to build neighbor bins since the size of the box is
much smaller than an interaction cutoff in at least one of its dimensions.
Typically, this error is triggered when the simulation box has one very
thin dimension. If a cubic neighbor bin had to fit exactly within
the thin dimension, then an inordinate amount of bins would be created to
fill space. This error can be avoided using the generally slower
:doc:`nsq neighbor style <neighbor>` or by increasing the size of the
smallest box lengths.
much smaller than an interaction cutoff in at least one of its
dimensions. Typically, this error is triggered when the simulation box
has one very thin dimension. If a cubic neighbor bin had to fit exactly
within the thin dimension, then an inordinate amount of bins would be
created to fill space. This error can be avoided using the generally
slower :doc:`nsq neighbor style <neighbor>` or by increasing the size of
the smallest box lengths.
.. _err0016:
Did not assign all atoms correctly
----------------------------------
This error happens most commonly when :doc:`reading a data file <read_data>`
under :doc:`non-periodic boundary conditions<boundary>`. Only atoms with
positions **inside** the simulation box will be read and thus any atoms
outside the box will be skipped and the total atom count will not match,
which triggers the error. This does not happen with periodic boundary
conditions where atoms outside the principal box will be "wrapped" into
the principal box and their image flags set accordingly.
This error happens most commonly when :doc:`reading a data file
<read_data>` under :doc:`non-periodic boundary conditions<boundary>`.
Only atoms with positions **inside** the simulation box will be read and
thus any atoms outside the box will be skipped and the total atom count
will not match, which triggers the error. This does not happen with
periodic boundary conditions where atoms outside the principal box will
be "wrapped" into the principal box and their image flags set
accordingly.
Similar errors can happen with the :doc:`replicate command<replicate>` or
the :doc:`read_restart command<read_restart>`. In these cases the cause
may be a problematic geometry, an insufficient communication cutoff, or
a bug in the LAMMPS source code. In these cases it is advisable to set
up :ref:`small test case <hint01>` for testing and debugging. This will
be required in case you need to get help from a LAMMPS developer.
Similar errors can happen with the :doc:`replicate command<replicate>`
or the :doc:`read_restart command<read_restart>`. In these cases the
cause may be a problematic geometry, an insufficient communication
cutoff, or a bug in the LAMMPS source code. In these cases it is
advisable to set up :ref:`small test case <hint01>` for testing and
debugging. This will be required in case you need to get help from a
LAMMPS developer.
.. _err0017:
Domain too large for neighbor bins
----------------------------------
The domain has become extremely large so that neighbor bins cannot
be used. Too many neighbor bins would need to be created to fill space.
The domain has become extremely large so that neighbor bins cannot be
used. Too many neighbor bins would need to be created to fill space.
Most likely, one or more atoms have been blown a great distance out of
the simulation box or a fix (like fix deform or a barostat) has
excessively grown the simulation box.
@ -549,13 +595,13 @@ of bonds and hydrogen bonds can change due to chemical reactions. The
default approach, however, assumes that these changes are not very
large, so it allocates buffers for the current system setup plus a
safety margin. This can be adjusted with the :doc:`safezone, mincap,
and minhbonds settings of the pair style <pair_reaxff>`, but only to some
extent. When equilibrating a new system, or simulating a sparse system
in parallel, this can be difficult to control and become wasteful. A
simple workaround is often to break a simulation down in multiple
chunks. A better approach, however, is to compile and use the KOKKOS
package version of ReaxFF (you do not need a GPU for that, but can also
compile it in serial or OpenMP mode), which uses a more robust
and minhbonds settings of the pair style <pair_reaxff>`, but only to
some extent. When equilibrating a new system, or simulating a sparse
system in parallel, this can be difficult to control and become
wasteful. A simple workaround is often to break a simulation down in
multiple chunks. A better approach, however, is to compile and use the
KOKKOS package version of ReaxFF (you do not need a GPU for that, but
can also compile it in serial or OpenMP mode), which uses a more robust
memory allocation approach.
.. _err0019:
@ -567,17 +613,17 @@ This error most commonly happens when setting force field coefficients
with either the :doc:`pair_coeff <pair_coeff>`, the :doc:`bond_coeff
<bond_coeff>`, the :doc:`angle_coeff <angle_coeff>`, the
:doc:`dihedral_coeff <dihedral_coeff>`, or the :doc:`improper_coeff
<improper_coeff>` command. These commands accept type labels,
explicit numbers, and wildcards for ranges of numbers. If the numeric
value of any of these is outside the valid range (defined by the number
of corresponding types), LAMMPS will stop with this error. A few other
commands and styles also allow ranges of numbers and check
using the same method and thus print the same kind of error.
<improper_coeff>` command. These commands accept type labels, explicit
numbers, and wildcards for ranges of numbers. If the numeric value of
any of these is outside the valid range (defined by the number of
corresponding types), LAMMPS will stop with this error. A few other
commands and styles also allow ranges of numbers and check using the
same method and thus print the same kind of error.
The cause is almost always a typo in the input or a logic error
when defining the values or ranges. So one needs to carefully
review the input. Along with the error, LAMMPS will print the
valid range as a hint.
The cause is almost always a typo in the input or a logic error when
defining the values or ranges. So one needs to carefully review the
input. Along with the error, LAMMPS will print the valid range as a
hint.
.. _err0020:
@ -589,7 +635,7 @@ per-atom vector or array provided by a compute or fix or atom-style or
vector-style variable or data from a specific atom, an index in square
brackets ("[ ]") (or two indices) must be provided to determine which
element to access and it must be in a valid range or else LAMMPS would
access invalid data or crash with a segmentation fault. In the two most
access invalid data or crash with a segmentation fault. In the two most
common cases, where this data is accessed, :doc:`variable expressions
<variable>` and :doc:`thermodynamic output <thermo_style>`, LAMMPS will
check for valid indices and stop with an error otherwise.
@ -607,34 +653,37 @@ properties at every step.
Incorrect args for pair coefficients (also bond/angle/dihedral/improper coefficients)
-------------------------------------------------------------------------------------
The parameters in the :doc:`pair_coeff <pair_coeff>` command for a specified
:doc:`pair_style <pair_style>` have a missing or erroneous argument. The same
applies when seeing this error for :doc:`bond_coeff <bond_coeff>`,
:doc:`angle_coeff <angle_coeff>`, :doc:`dihedral_coeff <dihedral_coeff>`, or
:doc:`improper_coeff <improper_coeff>` and their respective style commands when
using the MOLECULE or EXTRA-MOLECULE packages. The cases below describe
some ways to approach pair coefficient errors, but the same strategies
apply to bonded systems as well.
The parameters in the :doc:`pair_coeff <pair_coeff>` command for a
specified :doc:`pair_style <pair_style>` have a missing or erroneous
argument. The same applies when seeing this error for :doc:`bond_coeff
<bond_coeff>`, :doc:`angle_coeff <angle_coeff>`, :doc:`dihedral_coeff
<dihedral_coeff>`, or :doc:`improper_coeff <improper_coeff>` and their
respective style commands when using the MOLECULE or EXTRA-MOLECULE
packages. The cases below describe some ways to approach pair
coefficient errors, but the same strategies apply to bonded systems as
well.
Outside of normal typos, this error can have several sources. In all cases, the
first step is to compare the command arguments to the expected format found in
the corresponding :doc:`pair_style <pair_style>` page. This can reveal cases
where, for example, a pair style was changed, but the pair coefficients were not
updated. This can happen especially with pair style variants such as
:doc:`pair_style eam <pair_eam>` vs. :doc:`pair_style eam/alloy <pair_style>`
that look very similar but accept different parameters (the latter 'eam/alloy'
variant takes element type names while 'eam' does not).
Outside of normal typos, this error can have several sources. In all
cases, the first step is to compare the command arguments to the
expected format found in the corresponding :doc:`pair_style
<pair_style>` page. This can reveal cases where, for example, a pair
style was changed, but the pair coefficients were not updated. This can
happen especially with pair style variants such as :doc:`pair_style eam
<pair_eam>` vs. :doc:`pair_style eam/alloy <pair_style>` that look very
similar but accept different parameters (the latter 'eam/alloy' variant
takes element type names while 'eam' does not).
Another common source of coefficient errors is when using multiple pair styles
with commands such as :doc:`pair_style hybrid <pair_hybrid>`. Using hybrid pair
styles requires adding an extra "label" argument in the coefficient commands
that designates which pair style the command line refers to. Moreover, if
the same pair style is used multiple times, this label must be followed by
an additional numeric argument. Also, different pair styles may require
different arguments.
Another common source of coefficient errors is when using multiple pair
styles with commands such as :doc:`pair_style hybrid <pair_hybrid>`.
Using hybrid pair styles requires adding an extra "label" argument in
the coefficient commands that designates which pair style the command
line refers to. Moreover, if the same pair style is used multiple
times, this label must be followed by an additional numeric argument.
Also, different pair styles may require different arguments.
This error message might also require a close look at other LAMMPS input files
that are read in by the input script, such as data files or restart files.
This error message might also require a close look at other LAMMPS input
files that are read in by the input script, such as data files or
restart files.
.. _err0022:
@ -647,20 +696,20 @@ LAMMPS does *not* calculate these quantities when the forces are
calculated on every timestep or iteration. Global quantities are only
calculated when they are needed for :doc:`thermo <thermo_style>` output
(at the beginning, end, and at regular intervals specified by the
:doc:`thermo <thermo>` command). Similarly, per-atom quantities are only
calculated if they are needed to write per-atom energy or virial to a
dump file. This system works fine for simple input scripts. However,
:doc:`thermo <thermo>` command). Similarly, per-atom quantities are
only calculated if they are needed to write per-atom energy or virial to
a dump file. This system works fine for simple input scripts. However,
the many user-specified `variable`, `fix`, and `compute` commands that
LAMMPS provides make it difficult to anticipate when a quantity will be
requested. In some use cases, LAMMPS will figure out that a quantity is
requested. In some use cases, LAMMPS will figure out that a quantity is
needed and arrange for it to be calculated on that timestep e.g. if it
is requested by :doc:`fix ave/time <fix_ave_time>` or similar commands.
If that fails, it can be detected by a mismatch between the current
timestep and when a quantity was last calculated, in which case an error
message of this type is generated.
The most common cause of this type of error is requesting a quantity before
the start of the simulation.
The most common cause of this type of error is requesting a quantity
before the start of the simulation.
.. code-block:: LAMMPS
@ -669,13 +718,13 @@ the start of the simulation.
print "Potential energy = $e" # this will generate the error
run 1000 # start of simulation
This situation can be avoided by adding in a "run 0" command, as explained in
more detail in the "Variable Accuracy" section of the
This situation can be avoided by adding in a "run 0" command, as
explained in more detail in the "Variable Accuracy" section of the
:doc:`variable <variable>` doc page.
Another cause is requesting a quantity on a timestep that is not
a thermo or dump output timestep. This can often be
remedied by increasing the frequency of thermo or dump output.
Another cause is requesting a quantity on a timestep that is not a
thermo or dump output timestep. This can often be remedied by
increasing the frequency of thermo or dump output.
.. _err0023:
@ -684,19 +733,19 @@ Molecule auto special bond generation overflow
In order to correctly apply the :doc:`special_bonds <special_bonds>`
settings (also known as "exclusions"), LAMMPS needs to maintain for each
atom a list of atoms that are connected to this atom, either directly with
a bond or indirectly through bonding with an intermediate atom(s). The purpose
is to either remove or tag those pairs of atoms in the neighbor list. This
information is stored with individual
atoms and thus the maximum number of such "special" neighbors is set
when the simulation box is created. When reading (relative) geometry
and topology of a 'molecule' from a :doc:`molecule file <molecule>`,
LAMMPS will build the list of such "special" neighbors for the molecule atom
atom a list of atoms that are connected to this atom, either directly
with a bond or indirectly through bonding with an intermediate atom(s).
The purpose is to either remove or tag those pairs of atoms in the
neighbor list. This information is stored with individual atoms and
thus the maximum number of such "special" neighbors is set when the
simulation box is created. When reading (relative) geometry and
topology of a 'molecule' from a :doc:`molecule file <molecule>`, LAMMPS
will build the list of such "special" neighbors for the molecule atom
(if not given in the molecule file explicitly). The error is triggered
when the resulting list is too long for the space reserved when
creating the simulation box. The solution is to increase the
corresponding setting. Overestimating this value will only consume
more memory, and is thus a safe choice.
when the resulting list is too long for the space reserved when creating
the simulation box. The solution is to increase the corresponding
setting. Overestimating this value will only consume more memory, and
is thus a safe choice.
.. _err0024:
@ -704,14 +753,14 @@ Molecule topology/atom exceeds system topology/atom
---------------------------------------------------
LAMMPS uses :doc:`domain decomposition <Developer_par_part>` to
distribute data (i.e. atoms) across the MPI processes in parallel
runs. This includes topology data about bonds, angles,
dihedrals, impropers and :doc:`"special" neighbors <special_bonds>`.
This information is stored with either one or all atoms involved in such
a topology entry (which of the two option applies depends on the
:doc:`newton <newton>` setting for bonds). When reading a data file,
LAMMPS analyzes the requirements for this file and then the values are
"locked in" and cannot be extended.
distribute data (i.e. atoms) across the MPI processes in parallel runs.
This includes topology data about bonds, angles, dihedrals, impropers
and :doc:`"special" neighbors <special_bonds>`. This information is
stored with either one or all atoms involved in such a topology entry
(which of the two option applies depends on the :doc:`newton <newton>`
setting for bonds). When reading a data file, LAMMPS analyzes the
requirements for this file and then the values are "locked in" and
cannot be extended.
So loading a molecule file that requires more of the topology per atom
storage or adding a data file with such needs will lead to an error. To
@ -727,10 +776,10 @@ Molecule topology type exceeds system topology type
---------------------------------------------------
The total number of atom, bond, angle, dihedral, and improper types is
"locked in" when LAMMPS creates the simulation box. This can happen
"locked in" when LAMMPS creates the simulation box. This can happen
through either the :doc:`create_box <create_box>`, the :doc:`read_data
<read_data>`, or the :doc:`read_restart <read_restart>` command. After
this it is not possible to refer to an additional type. So loading a
this it is not possible to refer to an additional type. So loading a
molecule file that uses additional types or adding a data file that
would require additional types will lead to an error. To avoid the
error, one or more of the `extra/XXX/types` keywords are required to
@ -761,9 +810,10 @@ with periodic boundaries or larger than the box with non-periodic
boundaries. It means that the positions and image flags have become
inconsistent. LAMMPS will still compute bonded interactions based on
the closest periodic images of the atoms and thus in most cases the
results will be correct. Nevertheless, it is good practice to update
the system so that the message does not appear. It will help with
future manipulations of the system.
results will be correct. However they can cause problems when such
atoms are used with the fix rigid or replicate commands. Thus, it is
good practice to update the system so that the message does not appear.
It will help with future manipulations of the system.
There is one case where this warning *must* appear: when you have a
chain of connected bonds that pass through the entire box and connect
@ -778,17 +828,18 @@ beginning of the chain.
No fixes with time integration, atoms won't move
------------------------------------------------
This warning will be issued if LAMMPS encounters a :doc:`run <run>` command that
does not have a preceding :doc:`fix <fix>` command that updates atom/object
positions and velocities per step. In other words, there are no fixes detected
that perform velocity-Verlet time integration, such as :doc:`fix nve <fix_nve>`.
Note that this alert does not mean that there are no active fixes. LAMMPS has a
very wide variety of fixes, many of which do not move objects but also operate
through steps, such as printing outputs (e.g. :doc:`fix print <fix_print>`),
performing calculations (e.g. :doc:`fix ave/time <fix_ave_time>`), or changing
other system parameters (e.g. :doc:`fix dt/reset <fix_dt_reset>`). It is up to
the user to determine whether the lack of a time-integrating fix is intentional
or not.
This warning will be issued if LAMMPS encounters a :doc:`run <run>`
command that does not have a preceding :doc:`fix <fix>` command that
updates atom/object positions and velocities per step. In other words,
there are no fixes detected that perform velocity-Verlet time
integration, such as :doc:`fix nve <fix_nve>`. Note that this alert
does not mean that there are no active fixes. LAMMPS has a very wide
variety of fixes, many of which do not move objects but also operate
through steps, such as printing outputs (e.g. :doc:`fix print
<fix_print>`), performing calculations (e.g. :doc:`fix ave/time
<fix_ave_time>`), or changing other system parameters (e.g. :doc:`fix
dt/reset <fix_dt_reset>`). It is up to the user to determine whether
the lack of a time-integrating fix is intentional or not.
.. _err0029:
@ -796,36 +847,39 @@ or not.
System is not charge neutral, net charge = ...
----------------------------------------------
the sum of charges in the system is not zero. When a system is not
charge-neutral, methods that evolve/manipulate per-atom charges, evaluate
Coulomb interactions, evaluate Coulomb forces, or evaluate/manipulate other
properties relying on per-atom charges may raise this warning. A non-zero
net charge most commonly arises after setting per-atom charges :doc:`set <set>`
such that the sum is non-zero or by reading in a system through :doc:`read_data
<read_data>` where the per-atom charges do not sum to zero. However, a loss of
charge neutrality may occur in other less common ways, like when charge
the sum of charges in the system is not zero. When a system is not
charge-neutral, methods that evolve/manipulate per-atom charges,
evaluate Coulomb interactions, evaluate Coulomb forces, or
evaluate/manipulate other properties relying on per-atom charges may
raise this warning. A non-zero net charge most commonly arises after
setting per-atom charges :doc:`set <set>` such that the sum is non-zero
or by reading in a system through :doc:`read_data <read_data>` where the
per-atom charges do not sum to zero. However, a loss of charge
neutrality may occur in other less common ways, like when charge
equilibration methods (e.g., :doc:`fix qeq <fix_qeq>`) fail.
A similar warning/error may be raised when using certain charge equilibration
methods: :doc:`fix qeq <fix_qeq>`, :doc:`fix qeq/comb <fix_qeq_comb>`, :doc:`fix
qeq/reaxff <fix_qeq_reaxff>`, and :doc:`fix qtpie/reaxff <fix_qtpie_reaxff>`. In
such cases, this warning/error will be raised for the fix :doc:`group <group>`
when the group has a non-zero net charge.
A similar warning/error may be raised when using certain charge
equilibration methods: :doc:`fix qeq <fix_qeq>`, :doc:`fix qeq/comb
<fix_qeq_comb>`, :doc:`fix qeq/reaxff <fix_qeq_reaxff>`, and :doc:`fix
qtpie/reaxff <fix_qtpie_reaxff>`. In such cases, this warning/error
will be raised for the fix :doc:`group <group>` when the group has a
non-zero net charge.
When the system is expected to be charge-neutral, this warning often arises due
to an error in the lammps input (e.g., an incorrect :doc:`set <set>` command,
error in the data file read by :doc:`read_data <read_data>`, incorrectly
grouping atoms with charge, etc.). If the system is NOT expected to be
charge-neutral, the user should make sure that the method(s) used are
appropriate for systems with a non-zero net charge. Some commonly used fixes for
charge equilibration :doc:`fix qeq <fix_qeq>`, pair styles that include charge
interactions :doc:`pair_style coul/XXX <pair_coul>`, and kspace methods
:doc:`kspace_style <kspace_style>` can, in theory, support systems with non-zero
net charge. However, non-zero net charge can lead to spurious artifacts. The
severity of these artifacts depends on the magnitude of total charge, system
size, and methods used. Before running simulations or calculations for systems
with non-zero net charge, users should test for artifacts and convergence of
properties.
When the system is expected to be charge-neutral, this warning often
arises due to an error in the lammps input (e.g., an incorrect :doc:`set
<set>` command, error in the data file read by :doc:`read_data
<read_data>`, incorrectly grouping atoms with charge, etc.). If the
system is NOT expected to be charge-neutral, the user should make sure
that the method(s) used are appropriate for systems with a non-zero net
charge. Some commonly used fixes for charge equilibration :doc:`fix qeq
<fix_qeq>`, pair styles that include charge interactions
:doc:`pair_style coul/XXX <pair_coul>`, and kspace methods
:doc:`kspace_style <kspace_style>` can, in theory, support systems with
non-zero net charge. However, non-zero net charge can lead to spurious
artifacts. The severity of these artifacts depends on the magnitude of
total charge, system size, and methods used. Before running simulations
or calculations for systems with non-zero net charge, users should test
for artifacts and convergence of properties.
.. _err0030:
@ -859,3 +913,41 @@ keyword, LAMMPS stops with the 'Invalid thermo keyword' error. But it
is also possible, that there is just a typo in the name of a valid
variable function. Thus it is recommended to check the failing variable
expression very carefully.
.. _err0032:
One or more atoms are time integrated more than once
----------------------------------------------------
This is probably an error since you typically do not want to advance the
positions or velocities of an atom more than once per timestep. This
typically happens when there are multiple fix commands that advance atom
positions with overlapping groups. Also, for some fix styles it is not
immediately obvious that they include time integration. Please check
the documentation carefully.
.. _err0033:
XXX command before simulation box is defined
--------------------------------------------
This error occurs when trying to execute a LAMMPS command that requires
information about the system dimensions, or the number atom, bond,
angle, dihedral, or improper types, or the number of atoms or similar
data that is only available *after* the simulation box has been created.
See the paragraph on :ref:`errors before or after the simulation box is
created <hint12>` for additional information.
.. _err0034:
XXX command after simulation box is defined
--------------------------------------------
This error occurs when trying to execute a LAMMPS command that changes a
global setting *after* it is locked in when the simulation box is
created (for instance defining the :doc:`atom style <atom_style>`,
:doc:`dimension <dimension>`, :doc:`newton <newton>`, or :doc:`units
<units>` setting). These settings may only be changed *before* the
simulation box has been created. See the paragraph on :ref:`errors
before or after the simulation box is created <hint12>` for additional
information.

3487
doc/src/Errors_messages.rst
View File

File diff suppressed because it is too large Load Diff

169
doc/src/Errors_warnings.rst
View File

@ -1,11 +1,15 @@
Warning messages
================
This is an alphabetic list of the WARNING messages LAMMPS prints out
and the reason why. If the explanation here is not sufficient, the
documentation for the offending command may help. Warning messages
also list the source file and line number where the warning was
generated. For example, a message like this:
This is an alphabetic list of some of the WARNING messages LAMMPS prints
out and the reason why. If the explanation here is not sufficient, the
documentation for the offending command may help. This is a historic
list and no longer updated. Instead the LAMMPS developers are trying
to provide more details right with the error message or link to a
paragraph with :doc:`detailed explanations <Errors_details>`.
Warning messages also list the source file and line number where the
warning was generated. For example, a message like this:
.. parsed-literal::
@ -14,7 +18,7 @@ generated. For example, a message like this:
means that line #187 in the file src/domain.cpp generated the error.
Looking in the source code may help you figure out what went wrong.
Doc page with :doc:`ERROR messages <Errors_messages>`
Please also see the page with :doc:`Error messages <Errors_messages>`
----------
@ -28,16 +32,10 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
cutoff is set too short or the angle has blown apart and an atom is
too far away.
*Angle style in data file differs from currently defined angle style*
Self-explanatory.
*Angles are defined but no angle style is set*
The topology contains angles, but there are no angle forces computed
since there was no angle_style command.
*Atom style in data file differs from currently defined atom style*
Self-explanatory.
*Bond atom missing in box size check*
The second atom needed to compute a particular bond is missing on this
processor. Typically this is because the pairwise cutoff is set too
@ -53,9 +51,6 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
processor. Typically this is because the pairwise cutoff is set too
short or the bond has blown apart and an atom is too far away.
*Bond style in data file differs from currently defined bond style*
Self-explanatory.
*Bonds are defined but no bond style is set*
The topology contains bonds, but there are no bond forces computed
since there was no bond_style command.
@ -68,9 +63,6 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
length, multiplying by the number of bonds in the interaction (e.g. 3
for a dihedral) and adding a small amount of stretch.
*Both groups in compute group/group have a net charge; the Kspace boundary correction to energy will be non-zero*
Self-explanatory.
*Calling write_dump before a full system init.*
The write_dump command is used before the system has been fully
initialized as part of a 'run' or 'minimize' command. Not all dump
@ -86,18 +78,6 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
This means the temperature associated with the rigid bodies may be
incorrect on this timestep.
*Cannot include log terms without 1/r terms; setting flagHI to 1*
Self-explanatory.
*Cannot include log terms without 1/r terms; setting flagHI to 1.*
Self-explanatory.
*Charges are set, but coulombic solver is not used*
Self-explanatory.
*Charges did not converge at step %ld: %lg*
Self-explanatory.
*Communication cutoff is 0.0. No ghost atoms will be generated. Atoms may get lost*
The communication cutoff defaults to the maximum of what is inferred from
pair and bond styles (will be zero, if none are defined) and what is specified
@ -123,9 +103,6 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
is not changed automatically and the warning may be ignored depending
on the specific system being simulated.
*Communication cutoff is too small for SNAP micro load balancing, increased to %lf*
Self-explanatory.
*Compute cna/atom cutoff may be too large to find ghost atom neighbors*
The neighbor cutoff used may not encompass enough ghost atoms
to perform this operation correctly.
@ -158,9 +135,6 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
Conformation of the 4 listed dihedral atoms is extreme; you may want
to check your simulation geometry.
*Dihedral style in data file differs from currently defined dihedral style*
Self-explanatory.
*Dihedrals are defined but no dihedral style is set*
The topology contains dihedrals, but there are no dihedral forces computed
since there was no dihedral_style command.
@ -177,9 +151,6 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
*Estimated error in splitting of dispersion coeffs is %g*
Error is greater than 0.0001 percent.
*Ewald/disp Newton solver failed, using old method to estimate g_ewald*
Self-explanatory. Choosing a different cutoff value may help.
*FENE bond too long*
A FENE bond has stretched dangerously far. It's interaction strength
will be truncated to attempt to prevent the bond from blowing up.
@ -192,9 +163,6 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
A FENE bond has stretched dangerously far. It's interaction strength
will be truncated to attempt to prevent the bond from blowing up.
*Fix halt condition for fix-id %s met on step %ld with value %g*
Self explanatory.
*Fix SRD walls overlap but fix srd overlap not set*
You likely want to set this in your input script.
@ -238,21 +206,12 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
*Fix property/atom mol or charge w/out ghost communication*
A model typically needs these properties defined for ghost atoms.
*Fix qeq CG convergence failed (%g) after %d iterations at %ld step*
Self-explanatory.
*Fix qeq has non-zero lower Taper radius cutoff*
Absolute value must be <= 0.01.
*Fix qeq has very low Taper radius cutoff*
Value should typically be >= 5.0.
*Fix qeq/dynamic tolerance may be too small for damped dynamics*
Self-explanatory.
*Fix qeq/fire tolerance may be too small for damped fires*
Self-explanatory.
*Fix rattle should come after all other integration fixes*
This fix is designed to work after all other integration fixes change
atom positions. Thus it should be the last integration fix specified.
@ -285,9 +244,6 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
The user-specified force accuracy cannot be achieved unless the table
feature is disabled by using 'pair_modify table 0'.
*Geometric mixing assumed for 1/r\^6 coefficients*
Self-explanatory.
*Group for fix_modify temp != fix group*
The fix_modify command is specifying a temperature computation that
computes a temperature on a different group of atoms than the fix
@ -310,46 +266,14 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
Conformation of the 4 listed improper atoms is extreme; you may want
to check your simulation geometry.
*Improper style in data file differs from currently defined improper style*
Self-explanatory.
*Impropers are defined but no improper style is set*
The topology contains impropers, but there are no improper forces computed
since there was no improper_style command.
*Inconsistent image flags*
The image flags for a pair on bonded atoms appear to be inconsistent.
Inconsistent means that when the coordinates of the two atoms are
unwrapped using the image flags, the two atoms are far apart.
Specifically they are further apart than half a periodic box length.
Or they are more than a box length apart in a non-periodic dimension.
This is usually due to the initial data file not having correct image
flags for the two atoms in a bond that straddles a periodic boundary.
They should be different by 1 in that case. This is a warning because
inconsistent image flags will not cause problems for dynamics or most
LAMMPS simulations. However they can cause problems when such atoms
are used with the fix rigid or replicate commands. Note that if you
have an infinite periodic crystal with bonds then it is impossible to
have fully consistent image flags, since some bonds will cross
periodic boundaries and connect two atoms with the same image
flag.
*Increasing communication cutoff for GPU style*
The pair style has increased the communication cutoff to be consistent with
the communication cutoff requirements for this pair style when run on the GPU.
*KIM Model does not provide 'energy'; Potential energy will be zero*
Self-explanatory.
*KIM Model does not provide 'forces'; Forces will be zero*
Self-explanatory.
*KIM Model does not provide 'particleEnergy'; energy per atom will be zero*
Self-explanatory.
*KIM Model does not provide 'particleVirial'; virial per atom will be zero*
Self-explanatory.
*Kspace_modify slab param < 2.0 may cause unphysical behavior*
The kspace_modify slab parameter should be larger to ensure periodic
grids padded with empty space do not overlap.
@ -401,20 +325,10 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
box, or moved further than one processor's subdomain away before
reneighboring.
*MSM mesh too small, increasing to 2 points in each direction*
Self-explanatory.
*Mismatch between velocity and compute groups*
The temperature computation used by the velocity command will not be
on the same group of atoms that velocities are being set for.
*Mixing forced for lj coefficients*
Self-explanatory.
*Molecule attributes do not match system attributes*
An attribute is specified (e.g. diameter, charge) that is
not defined for the specified atom style.
*Molecule has bond topology but no special bond settings*
This means the bonded atoms will not be excluded in pairwise
interactions.
@ -449,9 +363,6 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
*More than one compute damage/atom*
It is not efficient to use compute ke/atom more than once.
*More than one compute dilatation/atom*
Self-explanatory.
*More than one compute erotate/sphere/atom*
It is not efficient to use compute erorate/sphere/atom more than once.
@ -464,24 +375,6 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
*More than one compute orientorder/atom*
It is not efficient to use compute orientorder/atom more than once.
*More than one compute plasticity/atom*
Self-explanatory.
*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.
*More than one compute snav/atom*
Self-explanatory.
*More than one fix poems*
It is not efficient to use fix poems more than once.
@ -557,21 +450,12 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
*Pair COMB charge %.10f with force %.10f hit min barrier*
Something is possibly wrong with your model.
*Pair brownian needs newton pair on for momentum conservation*
Self-explanatory.
*Pair dpd needs newton pair on for momentum conservation*
Self-explanatory.
*Pair dsmc: num_of_collisions > number_of_A*
Collision model in DSMC is breaking down.
*Pair dsmc: num_of_collisions > number_of_B*
Collision model in DSMC is breaking down.
*Pair style in data file differs from currently defined pair style*
Self-explanatory.
*Pair style restartinfo set but has no restart support*
This pair style has a bug, where it does not support reading and
writing information to a restart file, but does not set the member
@ -681,9 +565,6 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
cluster specified by the fix shake command is numerically suspect. LAMMPS
will set it to 0.0 and continue.
*Shell command '%s' failed with error '%s'*
Self-explanatory.
*Shell command returned with non-zero status*
This may indicate the shell command did not operate as expected.
@ -694,15 +575,9 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
This will lead to invalid constraint forces in the SHAKE/RATTLE
computation.
*Simulations might be very slow because of large number of structure factors*
Self-explanatory.
*Slab correction not needed for MSM*
Slab correction is intended to be used with Ewald or PPPM and is not needed by MSM.
*Specifying an 'subset' value of '0' is equivalent to no 'subset' keyword*
Self-explanatory.
*System is not charge neutral, net charge = %g*
The total charge on all atoms on the system is not 0.0.
For some KSpace solvers this is only a warning.
@ -734,9 +609,6 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
assumed to also be for all atoms. Thus the pressure printed by thermo
could be inaccurate.
*The fix ave/spatial command has been replaced by the more flexible fix ave/chunk and compute chunk/atom commands -- fix ave/spatial will be removed in the summer of 2015*
Self-explanatory.
*The minimizer does not re-orient dipoles when using fix efield*
This means that only the atom coordinates will be minimized,
not the orientation of the dipoles.
@ -745,9 +617,6 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
More than the maximum # of neighbors was found multiple times. This
was unexpected.
*Too many inner timesteps in fix ttm*
Self-explanatory.
*Too many neighbors in CNA for %d atoms*
More than the maximum # of neighbors was found multiple times. This
was unexpected.
@ -775,24 +644,6 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
The deformation will heat the SRD particles so this can
be dangerous.
*Using kspace solver on system with no charge*
Self-explanatory.
*Using largest cut-off for lj/long/dipole/long long long*
Self-explanatory.
*Using largest cutoff for buck/long/coul/long*
Self-explanatory.
*Using largest cutoff for lj/long/coul/long*
Self-explanatory.
*Using largest cutoff for pair_style lj/long/tip4p/long*
Self-explanatory.
*Using package gpu without any pair style defined*
Self-explanatory.
*Using pair potential shift with pair_modify compute no*
The shift effects will thus not be computed.

3
doc/src/Fortran.rst
View File

@ -2773,8 +2773,7 @@ Procedures Bound to the :f:type:`lammps` Derived Type
END SUBROUTINE external_callback
END INTERFACE
where ``c_bigint`` is ``c_int`` if ``-DLAMMPS_SMALLSMALL`` was used and
``c_int64_t`` otherwise; and ``c_tagint`` is ``c_int64_t`` if
where ``c_bigint`` is ``c_int64_t`` and ``c_tagint`` is ``c_int64_t`` if
``-DLAMMPS_BIGBIG`` was used and ``c_int`` otherwise.
The argument *caller* to :f:subr:`set_fix_external_callback` is unlimited

1
doc/src/Howto.rst
View File

@ -40,6 +40,7 @@ Settings howto
Howto_walls
Howto_nemd
Howto_dispersion
Howto_bulk2slab
Analysis howto
==============

160
doc/src/Howto_bulk2slab.rst Normal file
View File

@ -0,0 +1,160 @@
===========================
Convert bulk system to slab
===========================
A regularly encountered simulation problem is how to convert a bulk
system that has been run for a while to equilibrate into a slab system
with some vacuum space and free surfaces. The challenge here is that
one cannot just change the box dimensions with the :doc:`change_box
command <change_box>` or edit the box boundaries in a data file because
some atoms will have non-zero image flags from diffusing around.
Changing the box dimensions results in an undesired displacement of
those atoms, since the image flags indicate how many times the box
length in x-, y-, or z-direction needs to be added or subtracted to get
the "unwrapped" coordinates. By changing the box dimension this
distance is changed and thus those atoms move unphysically relative to
their neighbors with zero image flags. Setting image flags forcibly to
zero creates problems because that could break apart molecules by having
one atom of a bond on the top of the system and the other at the bottom.
.. _bulk2slab:
.. figure:: JPG/rhodo-both.jpg
:figwidth: 80%
:figclass: align-center
Snapshots of the bulk Rhodopsin in lipid layer and water system (right)
and the generated slab geometry (left)
.. admonition:: Disclaimer
:class: note
The following workflow will work for many bulk systems, but not all.
Some systems cannot be converted (e.g. polymers with bonds to the
same molecule across periodic boundaries, sometimes called "infinite
polymers"). The amount of vacuum that needs to be added depends on
the length of the molecules where the system is split (the example
here splits where there is water with short molecules). In some
cases, the system may need to be re-centered in the box first using
the :doc:`displace_atoms command <displace_atoms>`. Also, the time
spent on strong thermalization and equilibration will depend on the
specific system and its thermodynamic conditions.
Below is a suggested workflow using the :doc:`Rhodopsin benchmark input
<Speed_bench>` for demonstration. The figure shows the state *before*
the procedure on the left (with unwrapped atoms that have diffused out
of the box) and *after* on the right (with the vacuum added above and
below). The procedure is implemented by modifying a copy of the
``in.rhodo`` input file. The first lines up to and including the
:doc:`read_data command <read_data>` remain unchanged. Then we insert
the following lines to add vacuum to the z direction above and below the
system:
.. code-block:: LAMMPS
variable delta index 10.0
reset_atoms image all
write_dump all custom rhodo-unwrap.lammpstrj id xu yu zu
change_box all z final $(zlo-2.0*v_delta) $(zhi+2.0*v_delta) &
boundary p p f
read_dump rhodo-unwrap.lammpstrj 0 x y z box no replace yes
kspace_modify slab 3.0
Specifically, the :doc:`variable delta <variable>` (set to 10.0)
represents a distance that determines the amount of vacuum added: we add
twice its value in each direction to the z-dimension; thus in total
:math:`40 \AA` get added. The :doc:`reset_atoms image all
<reset_atoms>` command shall reset any image flags to become either 0 or
:math:`\pm 1` and thus have the minimum distance from the center of the
simulation box, but the correct relative distance for bonded atoms.
The :doc:`write_dump command <write_dump>` then writes out the resulting
*unwrapped* coordinates of the system. After expanding the box,
coordinates that were outside the box should now be inside and the
unwrapped coordinates will become "wrapped", while atoms outside the
periodic boundaries will be wrapped back into the box and their image
flags in those directions restored.
The :doc:`change_box command <change_box>` adds the desired
distance to the low and high box boundary in z-direction and then changes
the :doc:`boundary to "p p f" <boundary>` which will force the image
flags in z-direction to zero and create an undesired displacement for
the atoms with non-zero image flags.
With the :doc:`read_dump command <read_dump>` we read back and replace
partially incorrect coordinates with the previously saved, unwrapped
coordinates. It is important to ignore the box dimensions stored in the
dump file. We want to preserve the expanded box. Finally, we turn on
the slab correction for the PPPM long-range solver with the
:doc:`kspace_modify command <kspace_modify>` as required when using a
long range Coulomb solver for non-periodic z-dimension.
Next we replace the :doc:`fix npt command <fix_nh>` with:
.. code-block:: LAMMPS
fix 2 nvt temp 300.0 300.0 10.0
We now have an open system and thus the adjustment of the cell in
z-direction is no longer required. Since splitting the bulk water
region where the vacuum is inserted, creates surface atoms with high
potential energy, we reduce the thermostat time constant from 100.0 to
10.0 to remove excess kinetic energy resulting from that change faster.
Also the high potential energy of the surface atoms can cause that some
of them are ejected from the slab. In order to suppress that, we add
soft harmonic walls to push back any atoms that want to leave the slab.
To determine the position of the wall, we first need to to determine the
extent of the atoms in z-direction and then place the harmonic walls
based on that information:
.. code-block:: LAMMPS
compute zmin all reduce min z
compute zmax all reduce max z
thermo_style custom zlo c_zmin zhi c_zmax
run 0 post no
fix 3 all wall/harmonic zhi $(c_zmax+v_delta) 10.0 0.0 ${delta} &
zlo $(c_zmin-v_delta) 10.0 0.0 ${delta}
The two :doc:`compute reduce <compute_reduce>` command determine the
minimum and maximum z-coordinate across all atoms. In order to trigger
the execution of the compute commands we need to "consume" them. This
is done with the :doc:`thermo_style custom <thermo_style>` command
followed by the :doc:`run 0 <run>` command. This avoids and error
accessing the min/max values determined by the compute commands to
compute the location of the wall in lower and upper direction. This
uses the previously defined *delta* variable to determine the distance
of the wall from the extent of the system and the cutoff for the wall
interaction. This way only atoms that move beyond the min/max values in
z-direction will experience a restoring force, nudging them back to the
slab. The force constant of :math:`10.0 \frac{\mathrm{kcal/mol}}{\AA}`
was determined empirically.
Adding these "restoring" soft walls assist in making the free surfaces
above and below the slab flat, instead of having rugged or ondulated
surfaces. The impact of the walls can be changed by adjusting the force
constant, cutoff, and position of the wall.
Finally, we replace the :doc:`run 100 <run>` of the original input with:
.. code-block:: LAMMPS
run 1000 post no
unfix 3
fix 2 all nvt temp 300.0 300.0 100.0
run 1000 post no
write_data data.rhodo-slab
This runs the system converted to a slab first for 1000 MD steps using
the walls and stronger Nose-Hoover thermostat. Then the walls are
removed with :doc:`unfix 3 <unfix>` and the thermostat time constant
reset to 100.0 and the system run for another 1000 steps. Finally the
resulting slab geometry is written to a new data file
``data.rhodo-slab`` with a :doc:`write_data command <write_data>`. The
number of MD steps required to reach a proper equilibrium state is very
likely larger. The number of 1000 steps (corresponding to 2
picoseconds) was chosen for demonstration purposes, so that the
procedure can be easily and quickly tested.

272
doc/src/Howto_moltemplate.rst
View File

@ -2,14 +2,18 @@ Moltemplate Tutorial
====================
In this tutorial, we are going to use the tool :ref:`Moltemplate
<moltemplate>` to set up a classical molecular dynamic simulation using
the :ref:`OPLS-AA force field <OPLSAA96>`. The first
task is to describe an organic compound and create a complete input deck
for LAMMPS. The second task is to map the OPLS-AA force field to a
molecular sample created with an external tool, e.g. PACKMOL, and
exported as a PDB file. The files used in this tutorial can be found
in the ``tools/moltemplate/tutorial-files`` folder of the LAMMPS
source code distribution.
<Moltemplate1>` from https://moltemplate.org/ to set up a classical
molecular dynamic simulation using the :ref:`OPLS-AA force field
<oplsaa2024>`. The first task is to describe an organic compound and
create a complete input deck for LAMMPS. The second task is to use
moltemplate to build a polymer. The third task is to map the OPLS-AA
force field to a molecular sample created with an external tool,
e.g. PACKMOL, and exported as a PDB file. The files used in this
tutorial can be found in the ``tools/moltemplate/tutorial-files`` folder
of the LAMMPS source code distribution.
Many more examples can be found here: https://moltemplate.org/examples.html
Simulating an organic solvent
"""""""""""""""""""""""""""""
@ -17,14 +21,13 @@ Simulating an organic solvent
This example aims to create a cubic box of the organic solvent
formamide.
The first step is to create a molecular topology in the
LAMMPS-template (LT) file format representing a single molecule, which
will be stored in a Moltemplate object called ``_FAM inherits OPLSAA {}``.
The first step is to create a molecular topology in the LAMMPS-template
(LT) file format representing a single molecule, which will be
stored in a Moltemplate object called ``_FAM inherits OPLSAA {}``.
This command states that the object ``_FAM`` is based on an existing
object called ``OPLSAA``, which contains OPLS-AA parameters, atom type
definitions, partial charges, masses and bond-angle rules for many organic
and biological compounds.
The atomic structure is the starting point to populate the command
``write('Data Atoms') {}``, which will write the ``Atoms`` section in the
LAMMPS data file. The OPLS-AA force field uses the ``atom_style full``,
@ -36,21 +39,23 @@ to the ``molID``, except that the same variable is used for the whole
molecule. The atom types are assigned using ``@``-type variables. The
assignment of atom types (e.g. ``@atom:177``, ``@atom:178``) is done using
the OPLS-AA atom types defined in the "In Charges" section of the file
``oplsaa.lt``, looking for a reasonable match with the description of the atom.
``oplsaa2024.lt``, looking for a reasonable match with the description of the atom.
The resulting file (``formamide.lt``) follows:
.. code-block:: bash
import /usr/local/moltemplate/moltemplate/force_fields/oplsaa2024.lt # defines OPLSAA
_FAM inherits OPLSAA {
# atomID molID atomType charge coordX coordY coordZ
write('Data Atoms') {
$atom:C00 $mol @atom:177 0.00 0.100 0.490 0.0
$atom:O01 $mol @atom:178 0.00 1.091 -0.250 0.0
$atom:N02 $mol @atom:179 0.00 -1.121 -0.181 0.0
$atom:H03 $mol @atom:182 0.00 -2.013 0.272 0.0
$atom:H04 $mol @atom:182 0.00 -1.056 -1.190 0.0
$atom:H05 $mol @atom:221 0.00 0.144 1.570 0.0
$atom:C00 $mol @atom:235 0.00 0.100 0.490 0.0
$atom:O01 $mol @atom:236 0.00 1.091 -0.250 0.0
$atom:N02 $mol @atom:237 0.00 -1.121 -0.181 0.0
$atom:H03 $mol @atom:240 0.00 -2.013 0.272 0.0
$atom:H04 $mol @atom:240 0.00 -1.056 -1.190 0.0
$atom:H05 $mol @atom:279 0.00 0.144 1.570 0.0
}
# A list of the bonds in the molecule:
@ -64,16 +69,17 @@ The resulting file (``formamide.lt``) follows:
}
}
You don't have to specify the charge in this example because they will
be assigned according to the atom type. Analogously, only a
"Data Bond List" section is needed as the atom type will determine the
bond type. The other bonded interactions (e.g. angles,
dihedrals, and impropers) will be automatically generated by
You don't have to specify the charge in this example because the OPLSAA
force-field assigns charge according to the atom type. (This is not true
when using other force fields.) A "Data Bond List" section is needed as
the atom type will determine the bond type. The other bonded interactions
(e.g. angles, dihedrals, and impropers) will be automatically generated by
Moltemplate.
If the simulation is non-neutral, or Moltemplate complains that you have
missing bond, angle, or dihedral types, this means at least one of your
atom types is incorrect.
If the simulation is not charge-neutral, or Moltemplate complains that
you have missing bond, angle, or dihedral types, this probably means that
at least one of your atom types is incorrect (or that perhaps there is no
suitable atom type currently defined in the ``oplsaa2024.lt`` file).
The second step is to create a master file with instructions to build a
starting structure and the LAMMPS commands to run an NPT simulation. The
@ -81,11 +87,9 @@ master file (``solv_01.lt``) follows:
.. code-block:: bash
# Import the force field.
import /usr/local/moltemplate/moltemplate/force_fields/oplsaa.lt
import formamide.lt # after oplsaa.lt, as it depends on it.
import formamide.lt # Defines "_FAM" and OPLSAA
# Create the input sample.
# Distribute the molecules on a 5x5x5 cubic grid with spacing 4.6
solv = new _FAM [5].move( 4.6, 0, 0)
[5].move( 0, 4.6, 0)
[5].move( 0, 0, 4.6)
@ -98,8 +102,11 @@ master file (``solv_01.lt``) follows:
-11.5 11.5 zlo zhi
}
# Create an input deck for LAMMPS.
write_once("In Init"){
# Note: The lines below in the "In Run" section are often omitted.
write_once("In Run"){
# Create an input deck for LAMMPS.
# Run an NPT simulation.
# Input variables.
variable run string solv_01 # output name
variable ts equal 1 # timestep
@ -109,12 +116,6 @@ master file (``solv_01.lt``) follows:
variable equi equal 5000 # Equilibration steps
variable prod equal 30000 # Production steps
# PBC (set them before the creation of the box).
boundary p p p
}
# Run an NPT simulation.
write_once("In Run"){
# Derived variables.
variable tcouple equal \$\{ts\}*100
variable pcouple equal \$\{ts\}*1000
@ -143,7 +144,7 @@ master file (``solv_01.lt``) follows:
unfix NPT
}
The first two commands insert the content of files ``oplsaa.lt`` and
The first two commands insert the content of files ``oplsaa2024.lt`` and
``formamide.lt`` into the master file. At this point, we can use the
command ``solv = new _FAM [N]`` to create N copies of a molecule of type
``_FAM``. In this case, we create an array of 5*5*5 molecules on a cubic
@ -153,21 +154,37 @@ the sample was created from scratch, we also specify the simulation box
size in the "Data Boundary" section.
The LAMMPS setting for the force field are specified in the file
``oplsaa.lt`` and are written automatically in the input deck. We also
``oplsaa2024.lt`` and are written automatically in the input deck. We also
specify the boundary conditions and a set of variables in
the "In Init" section. The remaining commands to run an NPT simulation
the "In Init" section.
The remaining commands to run an NPT simulation
are written in the "In Run" section. Note that in this script, LAMMPS
variables are protected with the escape character ``\`` to distinguish
them from Moltemplate variables, e.g. ``\$\{run\}`` is a LAMMPS
variable that is written in the input deck as ``${run}``.
(Note: Moltemplate can be slow to run, so you need to change you run
settings frequently, I recommended moving those commands (from "In Run")
out of your .lt files and into a separate file. Moltemplate creates a
file named ``run.in.EXAMPLE`` for this purpose. You can put your run
settings and fixes that file and then invoke LAMMPS using
``mpirun -np 4 lmp -in run.in.EXAMPLE`` instead.)
Compile the master file with:
.. code-block:: bash
moltemplate.sh -overlay-all solv_01.lt
moltemplate.sh solv_01.lt
cleanup_moltemplate.sh # <-- optional: see below
And execute the simulation with the following:
(Note: The optional "cleanup_moltemplate.sh" command deletes
unused atom types, which sometimes makes LAMMPS run faster.
But it does not work with many-body pair styles or dreiding-style h-bonds.
Fortunately most force fields, including OPLSAA, don't use those features.)
Then execute the simulation with the following:
.. code-block:: bash
@ -180,15 +197,116 @@ And execute the simulation with the following:
Snapshot of the sample at the beginning and end of the simulation.
Rendered with Ovito.
Building a simple polymer
"""""""""""""""""""""""""
Moltemplate is particularly useful for building polymers (and other molecules
with sub-units). As an simple example, consider butane:
.. figure:: JPG/butane.jpg
The ``butane.lt`` file below defines Butane as a polymer containing
4 monomers (of type ``CH3``, ``CH2``, ``CH2``, ``CH3``).
.. code-block:: bash
import /usr/local/moltemplate/moltemplate/force_fields/oplsaa2024.lt # defines OPLSAA
CH3 inherits OPLSAA {
# atomID molID atomType charge coordX coordY coordZ
write("Data Atoms") {
$atom:c $mol:... @atom:54 0.0 0.000000 0.4431163 0.000000
$atom:h1 $mol:... @atom:60 0.0 0.000000 1.0741603 0.892431
$atom:h2 $mol:... @atom:60 0.0 0.000000 1.0741603 -0.892431
$atom:h3 $mol:... @atom:60 0.0 -0.892431 -0.1879277 0.000000
}
# (Using "$mol:..." indicates this object ("CH3") is part of a larger
# molecule. Moltemplate will share the molecule-ID with that molecule.)
# A list of the bonds within the "CH3" molecular sub-unit:
# BondID AtomID1 AtomID2
write('Data Bond List') {
$bond:ch1 $atom:c $atom:h1
$bond:ch2 $atom:c $atom:h2
$bond:ch3 $atom:c $atom:h3
}
}
CH2 inherits OPLSAA {
# atomID molID atomType charge coordX coordY coordZ
write("Data Atoms") {
$atom:c $mol:... @atom:57 0.0 0.000000 0.4431163 0.000000
$atom:h1 $mol:... @atom:60 0.0 0.000000 1.0741603 0.892431
$atom:h2 $mol:... @atom:60 0.0 0.000000 1.0741603 -0.892431
}
# A list of the bonds within the "CH2" molecular sub-unit:
# BondID AtomID1 AtomID2
write('Data Bond List') {
$bond:ch1 $atom:c $atom:h1
$bond:ch2 $atom:c $atom:h2
}
}
Butane inherits OPLSAA {
create_var {$mol} # optional:force all monomers to share the same molecule-ID
# - Create 4 monomers
# - Move them along the X axis using ".move()",
# - Rotate them 180 degrees with respect to the previous monomer
monomer1 = new CH3
monomer2 = new CH2.rot(180,1,0,0).move(1.2533223,0,0)
monomer3 = new CH2.move(2.5066446,0,0)
monomer4 = new CH3.rot(180,0,0,1).move(3.7599669,0,0)
# A list of the bonds connecting different monomers together:
write('Data Bond List') {
$bond:b1 $atom:monomer1/c $atom:monomer2/c
$bond:b2 $atom:monomer2/c $atom:monomer3/c
$bond:b3 $atom:monomer3/c $atom:monomer4/c
}
}
Again, you don't have to specify the charge in this example because OPLSAA
assigns charges according to the atom type.
This ``Butane`` object is a molecule which can be used anywhere other molecules
can be used. (You can arrange ``Butane`` molecules on a lattice, as we did previously.
You can also modify individual butane molecules by adding or deleting atoms or bonds.
You can add bonds between specific butane molecules or use ``Butane`` as a
subunit to define even larger molecules. See the moltemplate manual for details.)
How to build a complex polymer
""""""""""""""""""""""""""""""""""""""""""
A similar procedure can be used to create more complicated polymers,
such as the NIPAM polymer example shown below. For details, see:
https://github.com/jewettaij/moltemplate/tree/master/examples/all_atom/force_field_OPLSAA/NIPAM_polymer+water+ions
Mapping an existing structure
"""""""""""""""""""""""""""""
Another helpful way to use Moltemplate is mapping an existing molecular
sample to a force field. This is useful when a complex sample is
assembled from different simulations or created with specialized
software (e.g. PACKMOL). As in the previous example, all molecular
species in the sample must be defined using single-molecule Moltemplate
objects. For this example, we use a short polymer in a box containing
sample to a force field. This is useful when a complex sample is assembled
from different simulations or created with specialized software (e.g. PACKMOL).
(Note: The previous link shows how to build this entire system from scratch
using only moltemplate. However here we will assume instead that we obtained
a PDB file for this system using PACKMOL.)
As in the previous examples, all molecular species in the sample
are defined using single-molecule Moltemplate objects.
For this example, we use a short polymer in a box containing
water molecules and ions in the PDB file ``model.pdb``.
It is essential to understand that the order of atoms in the PDB file
@ -246,25 +364,25 @@ The resulting master LT file defining short annealing at a fixed volume
.. code-block:: bash
# Use the OPLS-AA force field for all species.
import /usr/local/moltemplate/moltemplate/force_fields/oplsaa.lt
import /usr/local/moltemplate/moltemplate/force_fields/oplsaa2024.lt
import PolyNIPAM.lt
# Define the SPC water and ions as in the OPLS-AA
Ca inherits OPLSAA {
write("Data Atoms"){
$atom:a1 $mol:. @atom:354 0.0 0.00000 0.00000 0.000000
$atom:a1 $mol:. @atom:412 0.0 0.00000 0.00000 0.000000
}
}
Cl inherits OPLSAA {
write("Data Atoms"){
$atom:a1 $mol:. @atom:344 0.0 0.00000 0.00000 0.000000
$atom:a1 $mol:. @atom:401 0.0 0.00000 0.00000 0.000000
}
}
SPC inherits OPLSAA {
write("Data Atoms"){
$atom:O $mol:. @atom:76 0. 0.0000000 0.00000 0.000000
$atom:H1 $mol:. @atom:77 0. 0.8164904 0.00000 0.5773590
$atom:H2 $mol:. @atom:77 0. -0.8164904 0.00000 0.5773590
$atom:O $mol:. @atom:9991 0. 0.0000000 0.00000 0.0000000
$atom:H1 $mol:. @atom:9990 0. 0.8164904 0.00000 0.5773590
$atom:H2 $mol:. @atom:9990 0. -0.8164904 0.00000 0.5773590
}
write("Data Bond List") {
$bond:OH1 $atom:O $atom:H1
@ -285,8 +403,15 @@ The resulting master LT file defining short annealing at a fixed volume
0 26 zlo zhi
}
# Define the input variables.
write_once("In Init"){
boundary p p p # "p p p" is the default. This line is optional.
neighbor 3 bin # (This line is also optional in this example.)
}
# Note: The lines below in the "In Run" section are often omitted.
# Run an NVT simulation.
write_once("In Run"){
# Input variables.
variable run string sample01 # output name
variable ts equal 2 # timestep
@ -294,13 +419,6 @@ The resulting master LT file defining short annealing at a fixed volume
variable p equal 1. # equilibrium pressure
variable equi equal 30000 # equilibration steps
# PBC (set them before the creation of the box).
boundary p p p
neighbor 3 bin
}
# Run an NVT simulation.
write_once("In Run"){
# Set the output.
thermo 1000
thermo_style custom step etotal evdwl ecoul elong ebond eangle &
@ -314,8 +432,8 @@ The resulting master LT file defining short annealing at a fixed volume
write_data \$\{run\}.min
# Set the constrains.
group watergroup type @atom:76 @atom:77
fix 0 watergroup shake 0.0001 10 0 b @bond:042_043 a @angle:043_042_043
group watergroup type @atom:9991 @atom:9990
fix 0 watergroup shake 0.0001 10 0 b @bond:spcO_spcH a @angle:spcH_spcO_spcH
# Short annealing.
timestep \$\{ts\}
@ -327,7 +445,7 @@ The resulting master LT file defining short annealing at a fixed volume
In this example, the water model is SPC and it is defined in the
``oplsaa.lt`` file with atom types ``@atom:76`` and ``@atom:77``. For
``oplsaa2024.lt`` file with atom types ``@atom:9991`` and ``@atom:9990``. For
water we also use the ``group`` and ``fix shake`` commands with
Moltemplate ``@``-type variables, to ensure consistency with the
numerical values assigned during compilation. To identify the bond and
@ -336,19 +454,20 @@ are:
.. code-block:: bash
replace{ @atom:76 @atom:76_b042_a042_d042_i042 }
replace{ @atom:77 @atom:77_b043_a043_d043_i043 }
replace{ @atom:9991 @atom:9991_bspcO_aspcO_dspcO_ispcO }
replace{ @atom:9990 @atom:9990_bspcH_aspcH_dspcH_ispcH }
From which we can identify the following "Data Bonds By Type":
``@bond:042_043 @atom:*_b042*_a*_d*_i* @atom:*_b043*_a*_d*_i*`` and
"Data Angles By Type": ``@angle:043_042_043 @atom:*_b*_a043*_d*_i*
@atom:*_b*_a042*_d*_i* @atom:*_b*_a043*_d*_i*``
``@bond:spcO_spcH @atom:*_bspcO*_a*_d*_i* @atom:*_bspcH*_a*_d*_i*``
and "Data Angles By Type":
``@angle:spcH_spcO_spcH @atom:*_b*_aspcH*_d*_i* @atom:*_b*_aspcO*_d*_i* @atom:*_b*_aspcH*_d*_i*``
Compile the master file with:
.. code-block:: bash
moltemplate.sh -overlay-all -pdb model.pdb sample01.lt
moltemplate.sh -pdb model.pdb sample01.lt
cleanup_moltemplate.sh
And execute the simulation with the following:
@ -363,8 +482,13 @@ And execute the simulation with the following:
Sample visualized with Ovito loading the trajectory into the DATA
file written after minimization.
------------
.. _OPLSAA96:
.. _oplsaa2024:
**(OPLS-AA)** Jorgensen, Maxwell, Tirado-Rives, J Am Chem Soc, 118(45), 11225-11236 (1996).
**(OPLS-AA)** Jorgensen, W.L., Ghahremanpour, M.M., Saar, A., Tirado-Rives, J., J. Phys. Chem. B, 128(1), 250-262 (2024).
.. _Moltemplate1:
**(Moltemplate)** Jewett et al., J. Mol. Biol., 433(11), 166841 (2021)

31
doc/src/Howto_python.rst
View File

@ -62,17 +62,17 @@ with :ref:`PNG, JPEG and FFMPEG output support <graphics>` enabled.
cd $LAMMPS_DIR/src
# add packages if necessary
# add LAMMPS packages if necessary
make yes-MOLECULE
make yes-PYTHON
# compile shared library using Makefile
make mpi mode=shlib LMP_INC="-DLAMMPS_PNG -DLAMMPS_JPEG -DLAMMPS_FFMPEG" JPG_LIB="-lpng -ljpeg"
Step 2: Installing the LAMMPS Python package
""""""""""""""""""""""""""""""""""""""""""""
Step 2: Installing the LAMMPS Python module
"""""""""""""""""""""""""""""""""""""""""""
Next install the LAMMPS Python package into your current Python installation with:
Next install the LAMMPS Python module into your current Python installation with:
.. code-block:: bash
@ -89,6 +89,29 @@ privileges) or into your personal Python module folder.
Recompiling the shared library requires re-installing the Python
package.
.. _externally_managed:
.. admonition:: Handling an "externally-managed-environment" Error
:class: Hint
Some Python installations made through Linux distributions
(e.g. Ubuntu 24.04LTS or later) will prevent installing the LAMMPS
Python module into a system folder or a corresponding folder of the
individual user as attempted by ``make install-python`` with an error
stating that an *externally managed* python installation must be only
managed by the same package package management tool. This is an
optional setting, so not all Linux distributions follow it currently
(Spring 2025). The reasoning and explanations for this error can be
found in the `Python Packaging User Guide
<https://packaging.python.org/en/latest/specifications/externally-managed-environments/>`_
These guidelines suggest to create a virtual environment and install
the LAMMPS Python module there (see below). This is generally a good
idea and the LAMMPS developers recommend this, too. If, however, you
want to proceed and install the LAMMPS Python module regardless, you
can install the "wheel" file (see above) manually with the ``pip``
command by adding the ``--break-system-packages`` flag.
Installation inside of a virtual environment
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

3
doc/src/Install_mac.rst
View File

@ -5,8 +5,7 @@ LAMMPS can be downloaded, built, and configured for macOS with `Homebrew
<homebrew_>`_. (Alternatively, see the installation instructions for
:doc:`downloading an executable via Conda <Install_conda>`.) The
following LAMMPS packages are unavailable at this time because of
additional requirements not yet met: GPU, KOKKOS, MSCG, POEMS,
VORONOI.
additional requirements not yet met: GPU, KOKKOS.
After installing Homebrew, you can install LAMMPS on your system with
the following commands:

BIN
doc/src/JPG/PolyNIPAM.jpg
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 40 KiB

After

Width:  |  Height:  |  Size: 94 KiB

BIN
doc/src/JPG/butane.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 22 KiB

BIN
doc/src/JPG/rhodo-both.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 568 KiB

6
doc/src/Library_add.rst
View File

@ -19,9 +19,9 @@ there are now a few requirements for including new changes or extensions.
be added.
- New features should also be implemented and documented not just
for the C interface, but also the Python and Fortran interfaces.
- All additions should work and be compatible with ``-DLAMMPS_BIGBIG``,
``-DLAMMPS_SMALLBIG``, ``-DLAMMPS_SMALLSMALL`` as well as when
compiling with and without MPI support.
- All additions should work and be compatible with
``-DLAMMPS_BIGBIG``, ``-DLAMMPS_SMALLBIG`` as well as when compiling
with and without MPI support.
- The ``library.h`` file should be kept compatible to C code at
a level similar to C89. Its interfaces may not reference any
custom data types (e.g. ``bigint``, ``tagint``, and so on) that

6
doc/src/Library_utility.rst
View File

@ -20,6 +20,7 @@ functions. They do not directly call the LAMMPS library.
- :cpp:func:`lammps_force_timeout`
- :cpp:func:`lammps_has_error`
- :cpp:func:`lammps_get_last_error_message`
- :cpp:func:`lammps_set_show_error`
- :cpp:func:`lammps_python_api_version`
The :cpp:func:`lammps_free` function is a clean-up function to free
@ -110,6 +111,11 @@ where such memory buffers were allocated that require the use of
-----------------------
.. doxygenfunction:: lammps_set_show_error
:project: progguide
-----------------------
.. doxygenfunction:: lammps_python_api_version
:project: progguide

13
doc/src/Python_install.rst
View File

@ -110,13 +110,16 @@ folder that the dynamic loader searches or inside of the installed
.. code-block:: bash
python install.py -p <python package> -l <shared library> -v <version.h file> [-n]
python install.py -p <python package> -l <shared library> -v <version.h file> [-n] [-f]
* The ``-p`` flag points to the ``lammps`` Python package folder to be installed,
* the ``-l`` flag points to the LAMMPS shared library file to be installed,
* the ``-v`` flag points to the LAMMPS version header file to extract the version date,
* and the optional ``-n`` instructs the script to only build a wheel file
but not attempt to install it.
* the optional ``-n`` instructs the script to only build a wheel file but not attempt
to install it,
* and the optional ``-f`` argument instructs the script to force installation even if
pip would otherwise refuse installation with an
:ref:`error about externally managed environments <externally_managed>`.
.. tab:: Virtual environment
@ -198,6 +201,10 @@ folder that the dynamic loader searches or inside of the installed
The ``PYTHONPATH`` needs to point to the parent folder that contains the ``lammps`` package!
In case you run into an "externally-managed-environment" error when
trying to install the LAMMPS Python module, please refer to
:ref:`corresponding paragraph <externally_managed>` in the Python HOWTO
page to learn about options for handling this error.
To verify if LAMMPS can be successfully started from Python, start the
Python interpreter, load the ``lammps`` Python module and create a

416
doc/src/Run_formats.rst Normal file
View File

@ -0,0 +1,416 @@
File formats used by LAMMPS
===========================
This page provides a general overview of the kinds of files and file
formats that LAMMPS is reading and writing.
.. contents:: On this page
:depth: 2
:backlinks: top
-------------------
Character Encoding
^^^^^^^^^^^^^^^^^^
For processing text files, the LAMMPS source code assumes `ASCII
character encoding <https://en.wikipedia.org/wiki/ASCII>`_ which
represents the digits 0 to 9, the lower and upper case letters a to z,
some common punctuation and other symbols and a few whitespace
characters including a regular "space character", "line feed", "carriage
return", "tabulator". These characters are all represented by single
bytes with a value smaller than 128 and only 95 of those 128 values
represent printable characters. This list is sufficient to represent
most English text, but misses accented characters or umlauts or Greek
symbols and more.
Modern text often uses `UTF-8 character encoding
<https://en.wikipedia.org/wiki/UTF-8>`_ instead. This encoding is a way
to represent many more different characters as defined by the Unicode
standard. UFT-8 is compatible with ASCII, since the first 128 values
are identical with the ASCII encoding. It is important to note,
however, that there are Unicode characters that *look* similar to ASCII
characters, but have a different binary representation. As a general
rule, these characters may not be correctly recognized by LAMMPS. For
some parts of LAMMPS' text processing, translation tables with known
"lookalike" characters are used. The tables are used to substitute
non-ASCII characters with their ASCII equivalents. Non-ASCII lookalike
characters are often used by web browsers or PDF viewers to improve the
readability of text. Thus, when using copy and paste to transfer text
from such an application to your input file, you may unintentionally
create text that is not exclusively using ASCII encoding and may cause
errors when LAMMPS is trying to read it.
Lines with non-printable and non-ASCII characters in text files can be
detected for example with a (Linux) command like the following:
.. code-block:: bash
env LC_ALL=C grep -n '[^ -~]' some_file.txt
Number Formatting
^^^^^^^^^^^^^^^^^
Different countries and languages have different conventions to format
numbers. While in some regions commas are used for fractions and points
to indicate thousand, million and so on, this is reversed in other
regions. Modern operating systems have facilities to adjust input and
output accordingly that are collectively referred to as "native language
support" (NLS). The exact rules are often applied according to the
value of the ``$LANG`` environment variable (e.g. "en_US.utf8" for
English text in UTF-8 encoding).
For the sake of simplicity of the implementation and transferability of
results, LAMMPS does not support this and instead expects numbers being
formatted in the generic or "C" locale. The "C" locale has no
punctuation for thousand, million and so on and uses a decimal point for
fractions. One thousand would be represented as "1000.0" and not as
"1,000.0" nor as "1.000,0". Having native language support enabled for
a locale other than "C" will result in different behavior when
converting or formatting numbers that can trigger unexpected errors.
LAMMPS also only accepts integer numbers when an integer is required, so
using floating point equivalents like "1.0" are not accepted; you *must*
use "1" instead.
For floating point numbers in scientific notation, the Fortran double
precision notation "1.1d3" is not accepted; you have to use "1100",
"1100.0" or "1.1e3".
Input file
^^^^^^^^^^
A LAMMPS input file is a text file with commands. It is read
line-by-line and each line is processed *immediately*. Before looking
for commands and executing them, there is a pre-processing step where
comments (non-quoted text starting with a pound sign '#') are removed,
``${variable}`` and ``$(expression)`` constructs are expanded or
evaluated, and lines that end in the ampersand character '&' are
combined with the next line (similar to Fortran 90 free-format source
code). After the pre-processing, lines are split into "words" and
evaluated. The first word must be a :doc:`command <Commands_all>` and
all following words are arguments. Below are some example lines:
.. code-block:: LAMMPS
# full line comment
# some global settings
units lj
atom_style atomic
# ^^ command ^^ argument(s)
variable x index 1 # may be overridden from command line with -var x <value>
variable xx equal 20*$x # variable "xx" is always 20 times "x"
lattice fcc 0.8442
# example of a command written across multiple lines
# the "region" command uses spacing from "lattice" command, unless "units box" is specified
region box block 0.0 ${xx} &
0.0 40.0 &
0.0 30.0
# create simulation box and fill with atoms according to lattice setting
create_box 1 box
create_atoms 1 box
# set force field and parameters
mass 1 1.0
pair_style lj/cut 2.5
pair_coeff 1 1 1.0 1.0 2.5
# run simulation
fix 1 all nve
run 1000
The pivotal command in this example input is the :doc:`create_box
command <create_box>`. It defines the simulation system and many
parameters that go with it: units, atom style, number of atom types (and
other types) and more. Those settings are *locked in* after the box is
created. Commands that change these kind of settings are only allowed
**before** a simulation box is created and many other commands are only
allowed **after** the simulation box is defined (e.g. :doc:`pair_coeff
<pair_coeff>`). Very few commands (e.g. :doc:`pair_style <pair_style>`)
may be used in either part of the input. The :doc:`read_data
<read_data>` and :doc:`read_restart <read_restart>` commands also create
the system box and thus have a similar pivotal function.
The LAMMPS input syntax has minimal support for conditionals and loops,
but if more complex operations are required, it is recommended to use
the library interface, e.g. :doc:`from Python using the LAMMPS Python
module <Python_run>`.
There is a frequent misconception about the :doc:`if command <if>`:
this is a command for conditional execution **outside** a run or
minimization. To trigger actions on specific conditions **during**
a run is a non-trivial operation that usually requires adopting one
of the available "fix" commands or creating a new "fix" command.
LAMMPS commands change the internal state and thus the order of commands
matters and reordering them can produce different results. For example,
the region defined by the :doc:`region command <region>` in the example
above depends on the :doc:`lattice setting <lattice>` and thus its
dimensions will be different depending on the order of the two commands.
Each line must have an "end-of-line" character (line feed or carriage
return plus line feed). Some text editors do not automatically insert
one which may cause LAMMPS to ignore the last command. It is thus
recommended to always have an empty line at the end of an input file.
The specific details describing how LAMMPS input is processed and parsed
are explained in :doc:`Commands_parse`.
Data file
^^^^^^^^^
A LAMMPS data file contains a description of a system suitable for
reading with the :doc:`read_data command <read_data>`. Data files are
commonly used for setting up complex molecular systems that can be
difficult to achieve with the commands :doc:`create_box <create_box>`
and :doc:`create_atoms <create_atoms>` alone. Also, data files can be
used as a portable alternatives to a :doc:`binary restart file
<restart>`. A restart file can be converted into a data file from the
:doc:`command line <Run_options>`.
Data files have a header section at the very beginning of the file and
multiple titled sections such as "Atoms", Masses", "Pair Coeffs", and so
on. Header keywords can only be used *before* the first title section.
The data file **always** starts with a "title" line, which will be
**ignored** by LAMMPS. Omitting the title line can lead to unexpected
behavior because a line of the header with an actual setting may be
ignored. In this case, the mistakenly ignored line often contains the
"atoms" keyword, which results in LAMMPS assuming that there are no
atoms in the data file and thus throwing an error on the contents of the
"Atoms" section. The title line may contain some keywords that can be
used by external programs to convey information about the system
(included as comments), that is not required and not read by LAMMPS.
The line following a section title is also **ignored**. An error will
occur if an empty line is not placed after a section title. The number
of lines in titled sections depends on header keywords, like the number
of atom types, the number of atoms, the number of bond types, the number
of bonds, and so on. The data in those sections has to be complete. A
special case are the "Pair Coeffs" and "PairIJ Coeffs" sections; the
former is for force fields and pair styles that use mixing of non-bonded
potential parameters, the latter for pair styles and force fields
requiring explicit coefficients. Thus with *N* being the number of atom
types, the "Pair Coeffs" section has *N* entries while "PairIJ Coeffs"
has :math:`N \cdot (N-1)` entries. Internally, these sections will be
converted to :doc:`pair_coeff <pair_coeff>` commands. Thus the
corresponding :doc:`pair style <pair_style>` must have been set *before*
the :doc:`read_data command <read_data>` reads the data file.
Data files may contain comments, which start with the pound sign '#'.
There must be at least one blank between a valid keyword and the pound
sign. Below is a simple example case of a data file for :doc:`atom style
full <atom_style>`.
.. code-block:: bash
LAMMPS Title line (ignored)
# full line comment
10 atoms # comment
4 atom types
-36.840194 64.211560 xlo xhi
-41.013691 68.385058 ylo yhi
-29.768095 57.139462 zlo zhi
Masses
1 12.0110
2 12.0110
3 15.9990
4 1.0080
Pair Coeffs # this section is optional
1 0.110000 3.563595 0.110000 3.563595
2 0.080000 3.670503 0.010000 3.385415
3 0.120000 3.029056 0.120000 2.494516
4 0.022000 2.351973 0.022000 2.351973
Atoms # full
1 1 1 0.560 43.99993 58.52678 36.78550 0 0 0
2 1 2 -0.270 45.10395 58.23499 35.86693 0 0 0
3 1 3 -0.510 43.81519 59.54928 37.43995 0 0 0
4 1 4 0.090 45.71714 57.34797 36.13434 0 0 0
5 1 4 0.090 45.72261 59.13657 35.67007 0 0 0
6 1 4 0.090 44.66624 58.09539 34.85538 0 0 0
7 1 3 -0.470 43.28193 57.47427 36.91953 0 0 0
8 1 4 0.070 42.07157 57.45486 37.62418 0 0 0
9 1 1 0.510 42.19985 57.57789 39.12163 0 0 0
10 1 1 0.510 41.88641 58.62251 39.70398 0 0 0
# ^^atomID ^^molID ^^type ^^charge ^^xcoord ^^ycoord ^^ycoord ^^image^^flags (optional)
Velocities # this section is optional
1 0.0050731 -0.00398928 0.00391473
2 -0.0175184 0.0173484 -0.00489207
3 0.00597225 -0.00202006 0.00166454
4 -0.010395 -0.0082582 0.00316419
5 -0.00390877 0.00470331 -0.00226911
6 -0.00111157 -0.00374545 -0.0169374
7 0.00209054 -0.00594936 -0.000124563
8 0.00635002 -0.0120093 -0.0110999
9 -0.004955 -0.0123375 0.000403422
10 0.00265028 -0.00189329 -0.00293198
The common problem is processing the "Atoms" section, since its format
depends on the :doc:`atom style <atom_style>` used, and that setting
must be done in the input file *before* reading the data file. To
assist with detecting incompatible data files, a comment is appended to
the "Atoms" title indicating the atom style used (or intended) when
*writing* the data file. For example, below is an "Atoms" section for
:doc:`atom style charge <atom_style>`, which omits the molecule ID
column.
.. code-block:: bash
Atoms # charge
1 1 0.560 43.99993 58.52678 36.78550
2 2 -0.270 45.10395 58.23499 35.86693
3 3 -0.510 43.81519 59.54928 37.43995
4 4 0.090 45.71714 57.34797 36.13434
5 4 0.090 45.72261 59.13657 35.67007
6 4 0.090 44.66624 58.09539 34.85538
7 3 -0.470 43.28193 57.47427 36.91953
8 4 0.070 42.07157 57.45486 37.62418
9 1 0.510 42.19985 57.57789 39.12163
10 1 0.510 41.88641 58.62251 39.70398
# ^^atomID ^^type ^^charge ^^xcoord ^^ycoord ^^ycoord
Another source of confusion about the "Atoms" section format is the
ordering of columns. The three atom style variants `atom_style full`,
`atom_style hybrid charge molecular`, and `atom_style hybrid molecular
charge` all carry the same per-atom information. However, in data files,
the Atoms section has the columns 'Atom-ID Molecule-ID Atom-type Charge
X Y Z' for atom style full, but for hybrid atom styles the first columns
are always 'Atom-ID Atom-type X Y Z' followed by any *additional* data
added by the hybrid styles, for example, 'Charge Molecule-ID' for the
first hybrid style and 'Molecule-ID Charge' in the second hybrid style
variant. Finally, an alternative to a hybrid atom style is to use fix
property/atom, e.g. to add molecule IDs to atom style charge. In this
case the "Atoms" section is formatted according to atom style charge and
a new section, "Molecules" is added that contains lines with 'Atom-ID
Molecule-ID', one for each atom in the system. For adding charges to
atom style molecular with fix property/atom, the "Atoms" section is now
formatted according to the atom style and a "Charges" section is added.
Molecule file
^^^^^^^^^^^^^
Molecule files for use with the :doc:`molecule command <molecule>` look
quite similar to data files but they do not have a compatible format,
i.e., one cannot use a data file as molecule file and vice versa. Below
is a simple example for a water molecule (SPC/E model). Same as a data
file, there is an ignored title line and you can use comments. However,
there is no information about the number of types or the box dimensions.
These parameters are set when the simulation box is created. Thus the
header only has the count of atoms, bonds, and so on.
Molecule files have a header followed by sections (just as in data
files), but the section names are different than those of a data file.
There is no "Atoms" section and the section formats in molecule files is
independent of the atom style. Its information is split across multiple
sections, like "Coords", "Types", and "Charges". Note that no "Masses"
section is needed here. The atom masses are by default tied to the atom
type and set with a data file or the :doc:`mass command <mass>`. A
"Masses" section would only be required for atom styles with per-atom
masses, e.g. atom style sphere, where in data files you would provide
the density and the diameter instead of the mass.
Since the entire file is a 'molecule', LAMMPS will assign a new
molecule-ID (if supported by the atom style) when atoms are instantiated
from a molecule file, e.g. with the :doc:`create_atoms command
<create_atoms>`. It is possible to include a "Molecules" section to
indicate that the atoms belong to multiple 'molecules'. Atom-IDs and
molecule-IDs in the molecule file are relative for the file
(i.e. starting from 1) and will be translated into actual atom-IDs also
when the atoms from the molecule are created.
.. code-block:: bash
# Water molecule. SPC/E model.
3 atoms
2 bonds
1 angles
Coords
1 1.12456 0.09298 1.27452
2 1.53683 0.75606 1.89928
3 0.49482 0.56390 0.65678
Types
1 1
2 2
3 2
Charges
1 -0.8472
2 0.4236
3 0.4236
Bonds
1 1 1 2
2 1 1 3
Angles
1 1 2 1 3
There are also optional sections, e.g. about :doc:`SHAKE <fix_shake>`
and :doc:`special bonds <special_bonds>`. Those sections are only needed
if the molecule command is issued *before* the simulation box is
defined. Otherwise, the molecule command can derive the required
settings internally.
Restart file
^^^^^^^^^^^^
LAMMPS restart files are binary files and not available in text format.
They can be identified by the first few bytes that contain the (C-style)
string ``LammpS RestartT`` as `magic string
<https://en.wikipedia.org/wiki/Magic_string>`_. This string is followed
by a 16-bit integer of the number 1 used for detecting whether the
computer writing the restart has the same `endianness
<https://en.wikipedia.org/wiki/Endianness>`_ as the computer reading it.
If not, the file cannot be read correctly. This integer is followed by
a 32-bit integer indicating the file format revision (currently 3),
which can be used to implement backward compatibility for reading older
revisions.
This information has been added to the `Unix "file" command's
<https://www.darwinsys.com/file/>` "magic" file so that restart files
can be identified without opening them. If you have a fairly recent
version, it should already be included. If you have an older version,
the LAMMPS source package :ref:`contains a file with the necessary
additions <magic>`.
The rest of the file is organized in sections of a 32-bit signed integer
constant indicating the kind of content and the corresponding value (or
values). If those values are arrays (including C-style strings), then
the integer constant is followed by a 32-bit integer indicating the
length of the array. This mechanism will read the data regardless of
the ordering of the sections. Symbolic names of the section constants
are in the ``lmprestart.h`` header file.
LAMMPS restart files are not expected to be portable between platforms
or LAMMPS versions, but changes to the file format are rare.
.. Native Dump file
.. ^^^^^^^^^^^^^^^^
..
.. Potential files
.. ^^^^^^^^^^^^^^^

10
doc/src/Run_head.rst
View File

@ -1,10 +1,11 @@
Run LAMMPS
**********
These pages explain how to run LAMMPS once you have :doc:`installed an executable <Install>` or :doc:`downloaded the source code <Install>`
and :doc:`built an executable <Build>`. The :doc:`Commands <Commands>`
doc page describes how input scripts are structured and the commands
they can contain.
These pages explain how to run LAMMPS once you have :doc:`installed an
executable <Install>` or :doc:`downloaded the source code <Install>` and
:doc:`built an executable <Build>`. The :doc:`Commands <Commands>` doc
page describes how input scripts are structured and the commands they
can contain.
.. toctree::
:maxdepth: 1
@ -12,4 +13,5 @@ they can contain.
Run_basics
Run_options
Run_output
Run_formats
Run_windows

2
doc/src/Tools.rst
View File

@ -930,7 +930,7 @@ dependencies and redirects the download to the local cache.
mkdir build
cd build
cmake -D LAMMPS_DOWNLOADS_URL=${HTTP_CACHE_URL} -C "${LAMMPS_HTTP_CACHE_CONFIG}" -C ../cmake/presets/most.cmake ../cmake
cmake -D LAMMPS_DOWNLOADS_URL=${HTTP_CACHE_URL} -C "${LAMMPS_HTTP_CACHE_CONFIG}" -C ../cmake/presets/most.cmake -D DOWNLOAD_POTENTIALS=off ../cmake
make -j 8
deactivate_caches

17
doc/src/compute_chunk_atom.rst
View File

@ -217,13 +217,16 @@ scaled differently in the two different dimensions to transform them
into ellipses).
The created bins (and hence the chunk IDs) are numbered consecutively
from 1 to the number of bins = *Nchunk*\ . For *bin2d* and *bin3d*, the
numbering varies most rapidly in the first dimension (which could be
*x*, *y*, or *z*), next rapidly in the second dimension, and most slowly in the
third dimension. For *bin/sphere*, the bin with smallest radii is chunk
1 and the bin with largest radii is chunk Nchunk = *ncbin*\ . For
*bin/cylinder*, the numbering varies most rapidly in the dimension
along the cylinder axis and most slowly in the radial direction.
from 1 to the number of bins = *Nchunk*\ . For *bin2d* and *bin3d*, the
numbering varies fastest in the last dimension (which could be
*x*, *y*, or *z*), slower in the second dimension, and slowest in the
first dimension. For *bin/sphere*, the bin with smallest radius is chunk
1 and the bin with largest radius is chunk Nchunk = *ncbin*\ . For
*bin/cylinder*, the numbering varies faster in the dimension
along the cylinder axis and slower in the radial direction.
In all cases, for a given dimension, the numbering increases
with increasing value of the coordinate (Cartesian coordinate,
sphere or cylinder radius, axial position).
Each time this compute is invoked, each atom is mapped to a bin based
on its current position. Note that between reneighboring timesteps,

BIN
doc/utils/sphinx-config/_static/up.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 203 B

10
doc/utils/sphinx-config/_themes/lammps_theme/layout.html
View File

@ -137,6 +137,7 @@
{# the master_doc variable was renamed to root_doc in Sphinx 4 (master_doc still exists in later Sphinx versions) #}
{%- set _logo_url = logo_url|default(pathto('_static/' + (logo or ""), 1)) %}
{%- set _root_doc = root_doc|default(master_doc) %}
<div id="sidebar-top-target"></div>
<a href="{{ pathto(_root_doc) }}"{% if not theme_logo_only %} class="icon icon-home"{% endif %}>
{% if not theme_logo_only %}{{ project }}{% endif %}
{%- if logo or logo_url %}
@ -172,6 +173,15 @@
</div>
{%- endblock %}
</div>
<!-- <div style="padding: 4px;">
<center>
<a href="#sidebar-top-target"><img src="_static/up.png" alt="(Up)"/> Go to top</a>
</center>
</div>
-->
<div style="position: fixed; bottom: 0px; width: 300px; height: 64px; padding: 4px; background-color: #272525; text-align: center">
<a href="#sidebar-top-target" class="fa fa-caret-up" style="color: white"> Go to top</a>
</div>
</nav>
<section data-toggle="wy-nav-shift" class="wy-nav-content-wrap">

2
doc/utils/sphinx-config/conf.py.in
View File

@ -288,7 +288,7 @@ rst_prolog = r"""
.. only:: html
:math:`\renewcommand{\AA}{\textup{\r{A}}`
:math:`\renewcommand{\AA}{\text{Å}}`
.. role:: lammps(code)
:language: LAMMPS

6
doc/utils/sphinx-config/false_positives.txt
View File

@ -737,6 +737,7 @@ dE
De
deallocate
deallocated
deallocation
debye
Debye
Decius
@ -857,7 +858,7 @@ DNi
Dobnikar
Dobson
docenv
docstring
docstrings
Dodds
dodgerblue
dof
@ -1338,6 +1339,7 @@ Gflop
gfortran
ghostneigh
ghostwhite
Ghahremanpour
Giacomo
GiB
gif
@ -2782,6 +2784,7 @@ omegaz
Omelyan
omp
OMP
ondulated
oneAPI
onebody
onelevel
@ -4016,6 +4019,7 @@ username
usleep
usolve
usr
utf
util
utils
utsa

1
examples/COUPLE/plugin/liblammpsplugin.c
View File

@ -204,6 +204,7 @@ liblammpsplugin_t *liblammpsplugin_load(const char *lib)
ADDSYM(has_error);
ADDSYM(get_last_error_message);
}
ADDSYM(set_show_error);
ADDSYM(python_api_version);
return lmp;

8
examples/COUPLE/plugin/liblammpsplugin.h
View File

@ -24,7 +24,7 @@
* Follow the behavior of regular LAMMPS compilation and assume
* -DLAMMPS_SMALLBIG when no define is set.
*/
#if !defined(LAMMPS_BIGBIG) && !defined(LAMMPS_SMALLBIG) && !defined(LAMMPS_SMALLSMALL)
#if !defined(LAMMPS_BIGBIG) && !defined(LAMMPS_SMALLBIG)
#define LAMMPS_SMALLBIG
#endif
@ -100,8 +100,6 @@ extern "C" {
#if defined(LAMMPS_BIGBIG)
typedef void (*FixExternalFnPtr)(void *, int64_t, int, int64_t *, double **, double **);
#elif defined(LAMMPS_SMALLSMALL)
typedef void (*FixExternalFnPtr)(void *, int, int, int *, double **, double **);
#else
typedef void (*FixExternalFnPtr)(void *, int64_t, int, int *, double **, double **);
#endif
@ -111,6 +109,7 @@ struct _liblammpsplugin {
int abiversion;
int has_exceptions;
void *handle;
#if defined(LAMMPS_LIB_MPI)
void *(*open)(int, char **, MPI_Comm, void **);
#else
@ -189,7 +188,7 @@ struct _liblammpsplugin {
* the ifdef ensures they are compatible with rest of LAMMPS
* caller must match to how LAMMPS library is built */
#ifndef LAMMPS_BIGBIG
#if !defined(LAMMPS_BIGBIG)
int (*create_atoms)(void *, int, int *, int *, double *, double *, int *, int);
#else
int (*create_atoms)(void *, int, int64_t *, int *, double *, double *, int64_t *, int);
@ -257,6 +256,7 @@ struct _liblammpsplugin {
int (*has_error)(void *);
int (*get_last_error_message)(void *, char *, int);
int (*set_show_error)(void *, const int);
int (*python_api_version)();
};

12
examples/PACKAGES/dpd-basic/dpd_coul_slater_long/data.dpd_coul_slater_long
View File

@ -15,12 +15,12 @@ Masses
PairIJ Coeffs # dpd/coul/slater/long
1 1 78 4.5 yes 1
1 2 78 4.5 yes 1
1 3 78 4.5 yes 1
2 2 78 4.5 no 1
2 3 78 4.5 no 1
3 3 78 4.5 no 1
1 1 78 4.5 no 1
1 2 78 4.5 no 1
1 3 78 4.5 no 1
2 2 78 4.5 yes 1
2 3 78 4.5 yes 1
3 3 78 4.5 yes 1
Atoms # full

48
examples/PACKAGES/dpd-basic/dpd_coul_slater_long/in.dpd_coul_slater_long
View File

@ -10,49 +10,47 @@ variable cut_coul equal 2.0
# Initialize LAMMPS run for 3-d periodic
#-------------------------------------------------------------------------------
units lj
boundary p p p # periodic at all axes
atom_style full
dimension 3
units lj
boundary p p p # periodic at all axes
atom_style full
dimension 3
bond_style none
angle_style none
dihedral_style none
improper_style none
bond_style none
angle_style none
dihedral_style none
improper_style none
newton on
comm_modify vel yes # store info of ghost atoms btw processors
newton on
comm_modify vel yes # store info of ghost atoms btw processors
#-------------------------------------------------------------------------------
# Box creation and configuration
#-------------------------------------------------------------------------------
# Define pair style and coefficients
pair_style dpd/coul/slater/long ${T} ${cut_DPD} ${seed} ${lambda} ${cut_coul}
read_data data.dpd_coul_slater_long
pair_style dpd/coul/slater/long ${T} ${cut_DPD} ${seed} ${lambda} ${cut_coul}
# Enable long range electrostatics solver
kspace_style pppm 1e-04
kspace_style pppm 1e-04
read_data data.dpd_coul_slater_long
# Construct neighbors every steps
neighbor 1.0 bin
neigh_modify every 1 delay 0 check yes
neighbor 1.0 bin
neigh_modify every 1 delay 0 check yes
#-------------------------------------------------------------------------------
# Run the simulation
#-------------------------------------------------------------------------------
thermo_style custom step temp press vol evdwl ecoul elong pe ke fnorm fmax
thermo_modify norm no
thermo 100
thermo_style custom step temp press vol evdwl ecoul elong pe ke fnorm fmax
thermo_modify norm no
thermo 100
timestep 0.01
run_style verlet
timestep 0.01
run_style verlet
fix 1 all nve
fix 1 all nve
run 1000
unfix 1
run 1000

147
examples/PACKAGES/dpd-basic/dpd_coul_slater_long/log.19Jun24.dpd_coul_slater.g++.1
View File

@ -1,147 +0,0 @@
LAMMPS (17 Apr 2024 - Development - patch_17Apr2024-262-g0aff26705c-modified)
OMP_NUM_THREADS environment is not set. Defaulting to 1 thread. (src/comm.cpp:98)
using 1 OpenMP thread(s) per MPI task
# DPD Ionic Fluid
variable T equal 1.0
variable cut_DPD equal 1.0
variable seed equal 165412
variable lambda equal 0.25
variable cut_coul equal 2.0
#-------------------------------------------------------------------------------
# Initialize LAMMPS run for 3-d periodic
#-------------------------------------------------------------------------------
units lj
boundary p p p # periodic at all axes
atom_style full
dimension 3
bond_style none
angle_style none
dihedral_style none
improper_style none
newton on
comm_modify vel yes # store info of ghost atoms btw processors
#-------------------------------------------------------------------------------
# Box creation and configuration
#-------------------------------------------------------------------------------
# Define pair style and coefficients
pair_style dpd/coul/slater/long ${T} ${cut_DPD} ${seed} ${lambda} ${cut_coul}
pair_style dpd/coul/slater/long 1 ${cut_DPD} ${seed} ${lambda} ${cut_coul}
pair_style dpd/coul/slater/long 1 1 ${seed} ${lambda} ${cut_coul}
pair_style dpd/coul/slater/long 1 1 165412 ${lambda} ${cut_coul}
pair_style dpd/coul/slater/long 1 1 165412 0.25 ${cut_coul}
pair_style dpd/coul/slater/long 1 1 165412 0.25 2
read_data data.dpd_coul_slater_long
Reading data file ...
orthogonal box = (0 0 0) to (5 5 5)
1 by 1 by 1 MPI processor grid
reading atoms ...
375 atoms
reading velocities ...
375 velocities
Finding 1-2 1-3 1-4 neighbors ...
special bond factors lj: 0 0 0
special bond factors coul: 0 0 0
0 = max # of 1-2 neighbors
0 = max # of 1-3 neighbors
0 = max # of 1-4 neighbors
1 = max # of special neighbors
special bonds CPU = 0.000 seconds
read_data CPU = 0.003 seconds
# Enable long range electrostatics solver
kspace_style pppm 1e-04
# Construct neighbors every steps
neighbor 1.0 bin
neigh_modify every 1 delay 0 check yes
#-------------------------------------------------------------------------------
# Run the simulation
#-------------------------------------------------------------------------------
thermo_style custom step temp press vol evdwl ecoul elong pe ke fnorm fmax
thermo_modify norm no
thermo 100
timestep 0.01
run_style verlet
fix 1 all nve
run 1000
PPPM initialization ...
using 12-bit tables for long-range coulomb (src/kspace.cpp:342)
G vector (1/distance) = 1.4828454
grid = 20 20 20
stencil order = 5
estimated absolute RMS force accuracy = 7.7240141e-05
estimated relative force accuracy = 7.7240141e-05
using double precision FFTW3
3d grid and FFT values/proc = 24389 8000
Generated 0 of 3 mixed pair_coeff terms from geometric mixing rule
Neighbor list info ...
update: every = 1 steps, delay = 0 steps, check = yes
max neighbors/atom: 2000, page size: 100000
master list distance cutoff = 3
ghost atom cutoff = 3
binsize = 1.5, bins = 4 4 4
1 neighbor lists, perpetual/occasional/extra = 1 0 0
(1) pair dpd/coul/slater/long, perpetual
attributes: half, newton on
pair build: half/bin/newton
stencil: half/bin/3d
bin: standard
Per MPI rank memory allocation (min/avg/max) = 8.359 | 8.359 | 8.359 Mbytes
Step Temp Press Volume E_vdwl E_coul E_long PotEng KinEng Fnorm Fmax
0 0.9849949 69.271905 125 4673.0443 0 -30.365103 4642.6792 552.58214 646.76798 65.851035
100 1.0614027 69.794624 125 4659.0139 0 -31.906319 4627.1075 595.44692 612.94396 60.338653
200 0.9422517 68.721098 125 4687.8862 0 -33.81531 4654.0709 528.6032 620.25627 62.726994
300 0.8956649 69.323482 125 4721.0824 0 -33.854275 4687.2281 502.46801 670.22699 73.087908
400 0.99584547 69.670416 125 4713.9086 0 -30.783633 4683.125 558.66931 607.65881 59.224652
500 1.0565931 69.497816 125 4701.2584 0 -26.80545 4674.4529 592.74873 646.18907 71.398122
600 1.0071523 70.26222 125 4659.2061 0 -29.98909 4629.217 565.01243 630.00244 58.264115
700 1.0507355 67.920078 125 4695.255 0 -32.649209 4662.6058 589.46259 651.80459 70.573524
800 0.98561942 68.279591 125 4745.7603 0 -28.98491 4716.7754 552.9325 627.14371 67.196483
900 0.96470105 70.742864 125 4706.3605 0 -30.271633 4676.0889 541.19729 644.43036 79.474998
1000 1.0204819 70.164419 125 4654.6077 0 -27.797433 4626.8103 572.49035 624.19728 71.825307
Loop time of 2.10153 on 1 procs for 1000 steps with 375 atoms
Performance: 411128.483 tau/day, 475.843 timesteps/s, 178.441 katom-step/s
99.7% CPU use with 1 MPI tasks x 1 OpenMP threads
MPI task timing breakdown:
Section | min time | avg time | max time |%varavg| %total
---------------------------------------------------------------
Pair | 1.1779 | 1.1779 | 1.1779 | 0.0 | 56.05
Bond | 6.507e-05 | 6.507e-05 | 6.507e-05 | 0.0 | 0.00
Kspace | 0.74636 | 0.74636 | 0.74636 | 0.0 | 35.51
Neigh | 0.12903 | 0.12903 | 0.12903 | 0.0 | 6.14
Comm | 0.039726 | 0.039726 | 0.039726 | 0.0 | 1.89
Output | 0.00027587 | 0.00027587 | 0.00027587 | 0.0 | 0.01
Modify | 0.0037596 | 0.0037596 | 0.0037596 | 0.0 | 0.18
Other | | 0.004451 | | | 0.21
Nlocal: 375 ave 375 max 375 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Nghost: 3613 ave 3613 max 3613 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Neighs: 62354 ave 62354 max 62354 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Total # of neighbors = 62354
Ave neighs/atom = 166.27733
Ave special neighs/atom = 0
Neighbor list builds = 65
Dangerous builds = 0
unfix 1
Total wall time: 0:00:02

147
examples/PACKAGES/dpd-basic/dpd_coul_slater_long/log.19Jun24.dpd_coul_slater.g++.4
View File

@ -1,147 +0,0 @@
LAMMPS (17 Apr 2024 - Development - patch_17Apr2024-262-g0aff26705c-modified)
OMP_NUM_THREADS environment is not set. Defaulting to 1 thread. (src/comm.cpp:98)
using 1 OpenMP thread(s) per MPI task
# DPD Ionic Fluid
variable T equal 1.0
variable cut_DPD equal 1.0
variable seed equal 165412
variable lambda equal 0.25
variable cut_coul equal 2.0
#-------------------------------------------------------------------------------
# Initialize LAMMPS run for 3-d periodic
#-------------------------------------------------------------------------------
units lj
boundary p p p # periodic at all axes
atom_style full
dimension 3
bond_style none
angle_style none
dihedral_style none
improper_style none
newton on
comm_modify vel yes # store info of ghost atoms btw processors
#-------------------------------------------------------------------------------
# Box creation and configuration
#-------------------------------------------------------------------------------
# Define pair style and coefficients
pair_style dpd/coul/slater/long ${T} ${cut_DPD} ${seed} ${lambda} ${cut_coul}
pair_style dpd/coul/slater/long 1 ${cut_DPD} ${seed} ${lambda} ${cut_coul}
pair_style dpd/coul/slater/long 1 1 ${seed} ${lambda} ${cut_coul}
pair_style dpd/coul/slater/long 1 1 165412 ${lambda} ${cut_coul}
pair_style dpd/coul/slater/long 1 1 165412 0.25 ${cut_coul}
pair_style dpd/coul/slater/long 1 1 165412 0.25 2
read_data data.dpd_coul_slater_long
Reading data file ...
orthogonal box = (0 0 0) to (5 5 5)
1 by 2 by 2 MPI processor grid
reading atoms ...
375 atoms
reading velocities ...
375 velocities
Finding 1-2 1-3 1-4 neighbors ...
special bond factors lj: 0 0 0
special bond factors coul: 0 0 0
0 = max # of 1-2 neighbors
0 = max # of 1-3 neighbors
0 = max # of 1-4 neighbors
1 = max # of special neighbors
special bonds CPU = 0.000 seconds
read_data CPU = 0.003 seconds
# Enable long range electrostatics solver
kspace_style pppm 1e-04
# Construct neighbors every steps
neighbor 1.0 bin
neigh_modify every 1 delay 0 check yes
#-------------------------------------------------------------------------------
# Run the simulation
#-------------------------------------------------------------------------------
thermo_style custom step temp press vol evdwl ecoul elong pe ke fnorm fmax
thermo_modify norm no
thermo 100
timestep 0.01
run_style verlet
fix 1 all nve
run 1000
PPPM initialization ...
using 12-bit tables for long-range coulomb (src/kspace.cpp:342)
G vector (1/distance) = 1.4828454
grid = 20 20 20
stencil order = 5
estimated absolute RMS force accuracy = 7.7240141e-05
estimated relative force accuracy = 7.7240141e-05
using double precision FFTW3
3d grid and FFT values/proc = 10469 2000
Generated 0 of 3 mixed pair_coeff terms from geometric mixing rule
Neighbor list info ...
update: every = 1 steps, delay = 0 steps, check = yes
max neighbors/atom: 2000, page size: 100000
master list distance cutoff = 3
ghost atom cutoff = 3
binsize = 1.5, bins = 4 4 4
1 neighbor lists, perpetual/occasional/extra = 1 0 0
(1) pair dpd/coul/slater/long, perpetual
attributes: half, newton on
pair build: half/bin/newton
stencil: half/bin/3d
bin: standard
Per MPI rank memory allocation (min/avg/max) = 7.208 | 7.208 | 7.209 Mbytes
Step Temp Press Volume E_vdwl E_coul E_long PotEng KinEng Fnorm Fmax
0 0.9849949 69.076433 125 4673.0443 0 -30.365103 4642.6792 552.58214 613.18374 70.700582
100 0.95374867 69.110009 125 4681.1097 0 -31.260804 4649.8489 535.053 629.95109 62.05418
200 1.0076152 69.824904 125 4670.7458 0 -28.382203 4642.3636 565.27213 656.8501 72.049813
300 1.0014752 69.666331 125 4696.454 0 -26.943577 4669.5105 561.8276 631.49861 74.737274
400 0.98863876 69.731774 125 4700.7552 0 -23.816077 4676.9391 554.62634 637.74742 68.928573
500 0.95782852 68.588075 125 4698.588 0 -29.249543 4669.3385 537.3418 646.31897 68.800569
600 0.97443232 70.864079 125 4674.8821 0 -26.415644 4648.4664 546.65653 606.50755 78.664429
700 0.98783988 68.908299 125 4692.5536 0 -28.092022 4664.4616 554.17817 638.98401 69.691814
800 0.98000145 69.83977 125 4706.6365 0 -29.648365 4676.9881 549.78082 626.84362 73.133934
900 1.0526251 69.466078 125 4671.9648 0 -30.941117 4641.0237 590.52269 618.1049 62.333546
1000 0.98340746 69.527121 125 4728.2894 0 -31.869907 4696.4195 551.69159 630.14208 61.392611
Loop time of 0.928543 on 4 procs for 1000 steps with 375 atoms
Performance: 930490.137 tau/day, 1076.956 timesteps/s, 403.859 katom-step/s
98.9% CPU use with 4 MPI tasks x 1 OpenMP threads
MPI task timing breakdown:
Section | min time | avg time | max time |%varavg| %total
---------------------------------------------------------------
Pair | 0.30761 | 0.34974 | 0.38864 | 4.9 | 37.67
Bond | 8.4633e-05 | 9.0539e-05 | 9.9184e-05 | 0.0 | 0.01
Kspace | 0.39038 | 0.42976 | 0.47215 | 4.4 | 46.28
Neigh | 0.033986 | 0.035576 | 0.036791 | 0.5 | 3.83
Comm | 0.10247 | 0.10324 | 0.10481 | 0.3 | 11.12
Output | 0.00024145 | 0.00027404 | 0.00036867 | 0.0 | 0.03
Modify | 0.0022402 | 0.0025068 | 0.0026343 | 0.3 | 0.27
Other | | 0.007356 | | | 0.79
Nlocal: 93.75 ave 96 max 93 min
Histogram: 3 0 0 0 0 0 0 0 0 1
Nghost: 2289.75 ave 2317 max 2271 min
Histogram: 1 1 0 0 1 0 0 0 0 1
Neighs: 15590.2 ave 16765 max 14540 min
Histogram: 1 0 1 0 0 1 0 0 0 1
Total # of neighbors = 62361
Ave neighs/atom = 166.296
Ave special neighs/atom = 0
Neighbor list builds = 64
Dangerous builds = 0
unfix 1
Total wall time: 0:00:00

145
examples/PACKAGES/dpd-basic/dpd_coul_slater_long/log.25Mar25.dpd_coul_slater.g++.1 Normal file
View File

@ -0,0 +1,145 @@
LAMMPS (4 Feb 2025 - Development - patch_4Feb2025-468-gd830412228-modified)
OMP_NUM_THREADS environment is not set. Defaulting to 1 thread. (src/comm.cpp:99)
using 1 OpenMP thread(s) per MPI task
# DPD Ionic Fluid
variable T equal 1.0
variable cut_DPD equal 1.0
variable seed equal 165412
variable lambda equal 0.25
variable cut_coul equal 2.0
#-------------------------------------------------------------------------------
# Initialize LAMMPS run for 3-d periodic
#-------------------------------------------------------------------------------
units lj
boundary p p p # periodic at all axes
atom_style full
dimension 3
bond_style none
angle_style none
dihedral_style none
improper_style none
newton on
comm_modify vel yes # store info of ghost atoms btw processors
#-------------------------------------------------------------------------------
# Box creation and configuration
#-------------------------------------------------------------------------------
# Define pair style and coefficients
pair_style dpd/coul/slater/long ${T} ${cut_DPD} ${seed} ${lambda} ${cut_coul}
pair_style dpd/coul/slater/long 1 ${cut_DPD} ${seed} ${lambda} ${cut_coul}
pair_style dpd/coul/slater/long 1 1 ${seed} ${lambda} ${cut_coul}
pair_style dpd/coul/slater/long 1 1 165412 ${lambda} ${cut_coul}
pair_style dpd/coul/slater/long 1 1 165412 0.25 ${cut_coul}
pair_style dpd/coul/slater/long 1 1 165412 0.25 2
# Enable long range electrostatics solver
kspace_style pppm 1e-04
read_data data.dpd_coul_slater_long
Reading data file ...
orthogonal box = (0 0 0) to (5 5 5)
1 by 1 by 1 MPI processor grid
reading atoms ...
375 atoms
reading velocities ...
375 velocities
Finding 1-2 1-3 1-4 neighbors ...
special bond factors lj: 0 0 0
special bond factors coul: 0 0 0
0 = max # of 1-2 neighbors
0 = max # of 1-3 neighbors
0 = max # of 1-4 neighbors
1 = max # of special neighbors
special bonds CPU = 0.001 seconds
read_data CPU = 0.004 seconds
# Construct neighbors every steps
neighbor 1.0 bin
neigh_modify every 1 delay 0 check yes
#-------------------------------------------------------------------------------
# Run the simulation
#-------------------------------------------------------------------------------
thermo_style custom step temp press vol evdwl ecoul elong pe ke fnorm fmax
thermo_modify norm no
thermo 100
timestep 0.01
run_style verlet
fix 1 all nve
run 1000
PPPM initialization ...
using 12-bit tables for long-range coulomb (src/kspace.cpp:342)
G vector (1/distance) = 1.4828454
grid = 20 20 20
stencil order = 5
estimated absolute RMS force accuracy = 7.7240141e-05
estimated relative force accuracy = 7.7240141e-05
using double precision KISS FFT
3d grid and FFT values/proc = 24389 8000
Generated 0 of 3 mixed pair_coeff terms from geometric mixing rule
Neighbor list info ...
update: every = 1 steps, delay = 0 steps, check = yes
max neighbors/atom: 2000, page size: 100000
master list distance cutoff = 3
ghost atom cutoff = 3
binsize = 1.5, bins = 4 4 4
1 neighbor lists, perpetual/occasional/extra = 1 0 0
(1) pair dpd/coul/slater/long, perpetual
attributes: half, newton on
pair build: half/bin/newton
stencil: half/bin/3d
bin: standard
Per MPI rank memory allocation (min/avg/max) = 8.359 | 8.359 | 8.359 Mbytes
Step Temp Press Volume E_vdwl E_coul E_long PotEng KinEng Fnorm Fmax
0 0.9849949 69.242343 125 4673.0443 -3.2653869 -30.365103 4639.4138 552.58214 646.89929 65.851035
100 1.023885 69.716134 125 4676.9465 -4.9878506 -34.092864 4637.8658 574.39949 663.35845 94.350026
200 1.0286646 69.674249 125 4636.201 -4.6314926 -33.406897 4598.1626 577.08087 614.52805 62.295431
300 0.9745797 69.689534 125 4679.9157 -4.3964184 -30.560567 4644.9588 546.73921 603.46282 60.56253
400 0.99487931 69.17085 125 4678.0362 -4.9518269 -34.446596 4638.6378 558.12729 656.99738 88.090014
500 0.97732377 69.551562 125 4684.3709 -5.0851581 -33.863212 4645.4226 548.27864 647.12533 75.851935
600 0.95396337 68.358297 125 4706.824 -4.269168 -33.634096 4668.9207 535.17345 604.31276 63.41042
700 0.99397324 68.365109 125 4669.1062 -4.700146 -35.014001 4629.3921 557.61899 633.29262 74.300913
800 1.0157864 69.263686 125 4664.1398 -4.0142381 -34.372669 4625.7529 569.85616 595.81462 67.046561
900 0.9925779 70.008922 125 4652.3023 -2.7845751 -33.095293 4616.4224 556.8362 620.13154 82.785317
1000 0.97336501 68.973657 125 4688.8002 -5.5239266 -36.42345 4646.8529 546.05777 625.66451 64.948859
Loop time of 0.755094 on 1 procs for 1000 steps with 375 atoms
Performance: 1144228.093 tau/day, 1324.338 timesteps/s, 496.627 katom-step/s
99.5% CPU use with 1 MPI tasks x 1 OpenMP threads
MPI task timing breakdown:
Section | min time | avg time | max time |%varavg| %total
---------------------------------------------------------------
Pair | 0.14421 | 0.14421 | 0.14421 | 0.0 | 19.10
Bond | 3.8885e-05 | 3.8885e-05 | 3.8885e-05 | 0.0 | 0.01
Kspace | 0.53292 | 0.53292 | 0.53292 | 0.0 | 70.58
Neigh | 0.056741 | 0.056741 | 0.056741 | 0.0 | 7.51
Comm | 0.017676 | 0.017676 | 0.017676 | 0.0 | 2.34
Output | 0.00024925 | 0.00024925 | 0.00024925 | 0.0 | 0.03
Modify | 0.0016688 | 0.0016688 | 0.0016688 | 0.0 | 0.22
Other | | 0.001588 | | | 0.21
Nlocal: 375 ave 375 max 375 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Nghost: 3570 ave 3570 max 3570 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Neighs: 19729 ave 19729 max 19729 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Total # of neighbors = 19729
Ave neighs/atom = 52.610667
Ave special neighs/atom = 0
Neighbor list builds = 66
Dangerous builds = 0
Total wall time: 0:00:00

145
examples/PACKAGES/dpd-basic/dpd_coul_slater_long/log.25Mar25.dpd_coul_slater.g++.4 Normal file
View File

@ -0,0 +1,145 @@
LAMMPS (4 Feb 2025 - Development - patch_4Feb2025-468-gd830412228-modified)
OMP_NUM_THREADS environment is not set. Defaulting to 1 thread. (src/comm.cpp:99)
using 1 OpenMP thread(s) per MPI task
# DPD Ionic Fluid
variable T equal 1.0
variable cut_DPD equal 1.0
variable seed equal 165412
variable lambda equal 0.25
variable cut_coul equal 2.0
#-------------------------------------------------------------------------------
# Initialize LAMMPS run for 3-d periodic
#-------------------------------------------------------------------------------
units lj
boundary p p p # periodic at all axes
atom_style full
dimension 3
bond_style none
angle_style none
dihedral_style none
improper_style none
newton on
comm_modify vel yes # store info of ghost atoms btw processors
#-------------------------------------------------------------------------------
# Box creation and configuration
#-------------------------------------------------------------------------------
# Define pair style and coefficients
pair_style dpd/coul/slater/long ${T} ${cut_DPD} ${seed} ${lambda} ${cut_coul}
pair_style dpd/coul/slater/long 1 ${cut_DPD} ${seed} ${lambda} ${cut_coul}
pair_style dpd/coul/slater/long 1 1 ${seed} ${lambda} ${cut_coul}
pair_style dpd/coul/slater/long 1 1 165412 ${lambda} ${cut_coul}
pair_style dpd/coul/slater/long 1 1 165412 0.25 ${cut_coul}
pair_style dpd/coul/slater/long 1 1 165412 0.25 2
# Enable long range electrostatics solver
kspace_style pppm 1e-04
read_data data.dpd_coul_slater_long
Reading data file ...
orthogonal box = (0 0 0) to (5 5 5)
1 by 2 by 2 MPI processor grid
reading atoms ...
375 atoms
reading velocities ...
375 velocities
Finding 1-2 1-3 1-4 neighbors ...
special bond factors lj: 0 0 0
special bond factors coul: 0 0 0
0 = max # of 1-2 neighbors
0 = max # of 1-3 neighbors
0 = max # of 1-4 neighbors
1 = max # of special neighbors
special bonds CPU = 0.000 seconds
read_data CPU = 0.004 seconds
# Construct neighbors every steps
neighbor 1.0 bin
neigh_modify every 1 delay 0 check yes
#-------------------------------------------------------------------------------
# Run the simulation
#-------------------------------------------------------------------------------
thermo_style custom step temp press vol evdwl ecoul elong pe ke fnorm fmax
thermo_modify norm no
thermo 100
timestep 0.01
run_style verlet
fix 1 all nve
run 1000
PPPM initialization ...
using 12-bit tables for long-range coulomb (src/kspace.cpp:342)
G vector (1/distance) = 1.4828454
grid = 20 20 20
stencil order = 5
estimated absolute RMS force accuracy = 7.7240141e-05
estimated relative force accuracy = 7.7240141e-05
using double precision KISS FFT
3d grid and FFT values/proc = 10469 2000
Generated 0 of 3 mixed pair_coeff terms from geometric mixing rule
Neighbor list info ...
update: every = 1 steps, delay = 0 steps, check = yes
max neighbors/atom: 2000, page size: 100000
master list distance cutoff = 3
ghost atom cutoff = 3
binsize = 1.5, bins = 4 4 4
1 neighbor lists, perpetual/occasional/extra = 1 0 0
(1) pair dpd/coul/slater/long, perpetual
attributes: half, newton on
pair build: half/bin/newton
stencil: half/bin/3d
bin: standard
Per MPI rank memory allocation (min/avg/max) = 7.208 | 7.208 | 7.209 Mbytes
Step Temp Press Volume E_vdwl E_coul E_long PotEng KinEng Fnorm Fmax
0 0.9849949 69.04687 125 4673.0443 -3.2653869 -30.365103 4639.4138 552.58214 613.14254 70.700582
100 1.0206537 69.308834 125 4676.3153 -4.5693306 -33.647673 4638.0983 572.58672 630.70953 76.020236
200 0.99990746 68.572978 125 4707.1556 -3.4977853 -33.275671 4670.3821 560.94809 633.00167 77.040049
300 0.91055241 69.390592 125 4685.5268 -2.9764038 -29.986737 4652.5637 510.8199 614.61006 62.799933
400 1.0080135 69.442971 125 4677.3078 -4.8740989 -32.908722 4639.525 565.49557 649.20121 61.033612
500 0.99500653 68.275189 125 4718.6774 -4.2475783 -35.206868 4679.223 558.19867 657.3073 74.738502
600 1.052925 70.601712 125 4703.6749 -2.8511316 -34.085418 4666.7383 590.69094 641.70441 59.043346
700 0.96467445 69.502018 125 4720.4257 -4.3345734 -34.310005 4681.7811 541.18237 656.24965 72.433637
800 1.0657358 70.960958 125 4685.5637 -5.8903418 -35.207202 4644.4661 597.87781 595.54446 61.462159
900 1.0273388 68.735518 125 4693.5106 -2.4175829 -28.602387 4662.4906 576.33707 598.80294 71.747886
1000 0.9702835 69.885576 125 4701.4385 -3.6513555 -29.487331 4668.2999 544.32904 666.55262 73.231425
Loop time of 0.270344 on 4 procs for 1000 steps with 375 atoms
Performance: 3195929.791 tau/day, 3698.993 timesteps/s, 1.387 Matom-step/s
99.3% CPU use with 4 MPI tasks x 1 OpenMP threads
MPI task timing breakdown:
Section | min time | avg time | max time |%varavg| %total
---------------------------------------------------------------
Pair | 0.031268 | 0.035485 | 0.039491 | 1.6 | 13.13
Bond | 3.3378e-05 | 3.4848e-05 | 3.5667e-05 | 0.0 | 0.01
Kspace | 0.18632 | 0.19083 | 0.19556 | 0.8 | 70.59
Neigh | 0.012413 | 0.012991 | 0.013598 | 0.4 | 4.81
Comm | 0.028195 | 0.028407 | 0.028626 | 0.1 | 10.51
Output | 0.00013369 | 0.00015738 | 0.00022498 | 0.0 | 0.06
Modify | 0.00055373 | 0.00059062 | 0.00068807 | 0.0 | 0.22
Other | | 0.001846 | | | 0.68
Nlocal: 93.75 ave 95 max 92 min
Histogram: 1 0 0 0 0 0 2 0 0 1
Nghost: 2286 ave 2307 max 2269 min
Histogram: 1 0 1 0 0 1 0 0 0 1
Neighs: 4945 ave 5443 max 4513 min
Histogram: 1 0 1 0 0 1 0 0 0 1
Total # of neighbors = 19780
Ave neighs/atom = 52.746667
Ave special neighs/atom = 0
Neighbor list builds = 66
Dangerous builds = 0
Total wall time: 0:00:00

4
examples/plugins/LAMMPSInterfaceCXX.cmake
View File

@ -131,8 +131,8 @@ endif()
################
# integer size selection
set(LAMMPS_SIZES "smallbig" CACHE STRING "LAMMPS integer sizes (smallsmall: all 32-bit, smallbig: 64-bit #atoms #timesteps, bigbig: also 64-bit imageint, 64-bit atom ids)")
set(LAMMPS_SIZES_VALUES smallbig bigbig smallsmall)
set(LAMMPS_SIZES "smallbig" CACHE STRING "LAMMPS integer sizes (smallbig: 64-bit #atoms #timesteps, bigbig: also 64-bit imageint, 64-bit atom ids)")
set(LAMMPS_SIZES_VALUES smallbig bigbig)
set_property(CACHE LAMMPS_SIZES PROPERTY STRINGS ${LAMMPS_SIZES_VALUES})
validate_option(LAMMPS_SIZES LAMMPS_SIZES_VALUES)
string(TOUPPER ${LAMMPS_SIZES} LAMMPS_SIZES)

82
fortran/lammps.f90
View File

@ -248,6 +248,7 @@ MODULE LIBLAMMPS
PROCEDURE :: force_timeout => lmp_force_timeout
PROCEDURE :: has_error => lmp_has_error
PROCEDURE :: get_last_error_message => lmp_get_last_error_message
PROCEDURE :: set_show_error => lmp_set_show_error
END TYPE lammps
INTERFACE lammps
@ -334,14 +335,6 @@ MODULE LIBLAMMPS
! Interface templates for fix external callbacks
ABSTRACT INTERFACE
SUBROUTINE external_callback_smallsmall(caller, timestep, ids, x, fexternal)
IMPORT :: c_int, c_double
CLASS(*), INTENT(INOUT) :: caller
INTEGER(c_int), INTENT(IN) :: timestep
INTEGER(c_int), DIMENSION(:), INTENT(IN) :: ids
REAL(c_double), DIMENSION(:,:), INTENT(IN) :: x
REAL(c_double), DIMENSION(:,:), INTENT(OUT) :: fexternal
END SUBROUTINE external_callback_smallsmall
SUBROUTINE external_callback_smallbig(caller, timestep, ids, x, fexternal)
IMPORT :: c_int, c_double, c_int64_t
CLASS(*), INTENT(INOUT) :: caller
@ -363,8 +356,6 @@ MODULE LIBLAMMPS
! Derived type for fix external callback data
TYPE fix_external_data
CHARACTER(LEN=:), ALLOCATABLE :: id
PROCEDURE(external_callback_smallsmall), NOPASS, POINTER :: &
callback_smallsmall => NULL()
PROCEDURE(external_callback_smallbig), NOPASS, POINTER :: &
callback_smallbig => NULL()
PROCEDURE(external_callback_bigbig), NOPASS, POINTER :: &
@ -1051,6 +1042,13 @@ MODULE LIBLAMMPS
INTEGER(c_int), VALUE :: buf_size
END FUNCTION lammps_get_last_error_message
INTEGER(c_int) FUNCTION lammps_set_show_error(handle,flag) BIND(C)
IMPORT :: c_ptr, c_int
IMPLICIT NONE
TYPE(c_ptr), VALUE :: handle
INTEGER(c_int), VALUE :: flag
END FUNCTION lammps_set_show_error
!---------------------------------------------------------------------
! Utility functions imported for convenience (not in library.h)
!---------------------------------------------------------------------
@ -2262,7 +2260,7 @@ CONTAINS
CALL lammps_free(Cname)
END SUBROUTINE lmp_scatter_atoms_subset_double
! equivalent function to lammps_gather_bonds (LAMMPS_SMALLSMALL or SMALLBIG)
! equivalent function to lammps_gather_bonds (LAMMPS_SMALLBIG)
SUBROUTINE lmp_gather_bonds_small(self, data)
CLASS(lammps), INTENT(IN) :: self
INTEGER(c_int), DIMENSION(:), ALLOCATABLE, TARGET, INTENT(OUT) :: data
@ -2304,7 +2302,7 @@ CONTAINS
CALL lammps_gather_bonds(self%handle, Cdata)
END SUBROUTINE lmp_gather_bonds_big
! equivalent function to lammps_gather_angles (LAMMPS_SMALLSMALL or SMALLBIG)
! equivalent function to lammps_gather_angles (LAMMPS_SMALLBIG)
SUBROUTINE lmp_gather_angles_small(self, data)
CLASS(lammps), INTENT(IN) :: self
INTEGER(c_int), DIMENSION(:), ALLOCATABLE, TARGET, INTENT(OUT) :: data
@ -2346,7 +2344,7 @@ CONTAINS
CALL lammps_gather_angles(self%handle, Cdata)
END SUBROUTINE lmp_gather_angles_big
! equivalent function to lammps_gather_dihedrals (LAMMPS_SMALLSMALL or SMALLBIG)
! equivalent function to lammps_gather_dihedrals (LAMMPS_SMALLBIG)
SUBROUTINE lmp_gather_dihedrals_small(self, data)
CLASS(lammps), INTENT(IN) :: self
INTEGER(c_int), DIMENSION(:), ALLOCATABLE, TARGET, INTENT(OUT) :: data
@ -2388,7 +2386,7 @@ CONTAINS
CALL lammps_gather_dihedrals(self%handle, Cdata)
END SUBROUTINE lmp_gather_dihedrals_big
! equivalent function to lammps_gather_impropers (LAMMPS_SMALLSMALL or SMALLBIG)
! equivalent function to lammps_gather_impropers (LAMMPS_SMALLBIG)
SUBROUTINE lmp_gather_impropers_small(self, data)
CLASS(lammps), INTENT(IN) :: self
INTEGER(c_int), DIMENSION(:), ALLOCATABLE, TARGET, INTENT(OUT) :: data
@ -2763,7 +2761,7 @@ CONTAINS
IF (tagint_size /= 4_c_int .AND. (PRESENT(id) .OR. PRESENT(image))) THEN
CALL lmp_error(self, LMP_ERROR_ALL + LMP_ERROR_WORLD, &
'Unable to create_atoms; your id/image array types are incompatible&
& with LAMMPS_SMALLBIG and LAMMPS_SMALLSMALL [Fortran/create_atoms]')
& with LAMMPS_SMALLBIG [Fortran/create_atoms]')
END IF
n = SIZE(type, KIND=c_int)
IF (PRESENT(bexpand)) THEN
@ -3360,7 +3358,7 @@ CONTAINS
construct_fix_external_data%id = ' '
END FUNCTION construct_fix_external_data
! equivalent function to lammps_set_fix_external_callback for -DSMALLSMALL
! equivalent function to lammps_set_fix_external_callback
! note that "caller" is wrapped into a fix_external_data derived type along
! with the fix id and the Fortran calling function.
SUBROUTINE lmp_set_fix_external_callback(self, id, callback, caller)
@ -3394,11 +3392,7 @@ CONTAINS
ext_data(this_fix)%id = id
ext_data(this_fix)%lammps_instance => self
IF (SIZE_TAGINT == 4_c_int .AND. SIZE_BIGINT == 4_c_int) THEN
! -DSMALLSMALL
c_callback = C_FUNLOC(callback_wrapper_smallsmall)
CALL set_fix_external_callback_smallsmall(this_fix, callback)
ELSE IF (SIZE_TAGINT == 8_c_int .AND. SIZE_BIGINT == 8_c_int) THEN
IF (SIZE_TAGINT == 8_c_int .AND. SIZE_BIGINT == 8_c_int) THEN
! -DBIGBIG
c_callback = C_FUNLOC(callback_wrapper_bigbig)
CALL set_fix_external_callback_bigbig(this_fix, callback)
@ -3420,12 +3414,6 @@ CONTAINS
END SUBROUTINE lmp_set_fix_external_callback
! Wrappers to assign callback pointers with explicit interfaces
SUBROUTINE set_fix_external_callback_smallsmall(id, callback)
INTEGER, INTENT(IN) :: id
PROCEDURE(external_callback_smallsmall) :: callback
ext_data(id)%callback_smallsmall => callback
END SUBROUTINE set_fix_external_callback_smallsmall
SUBROUTINE set_fix_external_callback_smallbig(id, callback)
INTEGER, INTENT(IN) :: id
@ -3450,9 +3438,7 @@ CONTAINS
DO i = 1, SIZE(ext_data) - 1
c_id = f2c_string(ext_data(i)%id)
c_caller = C_LOC(ext_data(i))
IF (SIZE_TAGINT == 4_c_int .AND. SIZE_BIGINT == 4_c_int) THEN
c_callback = C_FUNLOC(callback_wrapper_smallsmall)
ELSE IF (SIZE_TAGINT == 8_c_int .AND. SIZE_BIGINT == 8_c_int) THEN
IF (SIZE_TAGINT == 8_c_int .AND. SIZE_BIGINT == 8_c_int) THEN
c_callback = C_FUNLOC(callback_wrapper_bigbig)
ELSE
c_callback = C_FUNLOC(callback_wrapper_smallbig)
@ -3464,34 +3450,6 @@ CONTAINS
END SUBROUTINE rebind_external_callback_data
! companions to lmp_set_fix_external_callback to change interface
SUBROUTINE callback_wrapper_smallsmall(caller, timestep, nlocal, ids, x, &
fexternal) BIND(C)
TYPE(c_ptr), INTENT(IN), VALUE :: caller
INTEGER(c_int), INTENT(IN), VALUE :: timestep
INTEGER(c_int), INTENT(IN), VALUE :: nlocal
TYPE(c_ptr), INTENT(IN), VALUE :: ids, x, fexternal
TYPE(c_ptr), DIMENSION(:), POINTER :: x0, f0
INTEGER(c_int), DIMENSION(:), POINTER :: f_ids => NULL()
REAL(c_double), DIMENSION(:,:), POINTER :: f_x => NULL(), &
f_fexternal => NULL()
TYPE(fix_external_data), POINTER :: f_caller => NULL()
CALL C_F_POINTER(ids, f_ids, [nlocal])
CALL C_F_POINTER(x, x0, [nlocal])
CALL C_F_POINTER(x0(1), f_x, [3, nlocal])
CALL C_F_POINTER(fexternal, f0, [nlocal])
CALL C_F_POINTER(f0(1), f_fexternal, [3, nlocal])
IF (C_ASSOCIATED(caller)) THEN
CALL C_F_POINTER(caller, f_caller)
CALL f_caller%callback_smallsmall(f_caller%caller, timestep, f_ids, &
f_x, f_fexternal)
ELSE
CALL lmp_error(f_caller%lammps_instance, &
LMP_ERROR_ALL + LMP_ERROR_WORLD, &
'Got null pointer from "caller"; this should never happen;&
& please report a bug')
END IF
END SUBROUTINE callback_wrapper_smallsmall
SUBROUTINE callback_wrapper_smallbig(caller, timestep, nlocal, ids, x, &
fexternal) BIND(C)
@ -3716,6 +3674,14 @@ CONTAINS
END IF
END SUBROUTINE lmp_get_last_error_message
! equivalent function to lammps_set_show_error
INTEGER FUNCTION lmp_set_show_error(self, flag)
CLASS(lammps), INTENT(IN) :: self
INTEGER, INTENT(IN) :: flag
lmp_set_show_error = lammps_set_show_error(self%handle, flag)
END FUNCTION lmp_set_show_error
! ----------------------------------------------------------------------
! functions to assign user-space pointers to LAMMPS data
! ----------------------------------------------------------------------

4
lib/gpu/Makefile.aurora
View File

@ -11,8 +11,8 @@ EXTRAMAKE = Makefile.lammps.opencl
# OCL_TUNE = -DCYPRESS_OCL # -- Uncomment for AMD Cypress
OCL_TUNE = -DGENERIC_OCL # -- Uncomment for generic device
# this setting should match LAMMPS Makefile
# one of LAMMPS_SMALLBIG (default), LAMMPS_BIGBIG and LAMMPS_SMALLSMALL
# this setting should match the LAMMPS Makefile
# either LAMMPS_SMALLBIG (default) or LAMMPS_BIGBIG
LMP_INC = -DLAMMPS_SMALLBIG

4
lib/gpu/Makefile.cuda
View File

@ -11,8 +11,8 @@ ifeq ($(CUDA_HOME),)
CUDA_HOME = /usr/local/cuda
endif
# this setting should match LAMMPS Makefile
# one of LAMMPS_SMALLBIG (default), LAMMPS_BIGBIG and LAMMPS_SMALLSMALL
# this setting should match the LAMMPS Makefile
# either LAMMPS_SMALLBIG (default) or LAMMPS_BIGBIG
LMP_INC = -DLAMMPS_SMALLBIG

4
lib/gpu/Makefile.cuda_mps
View File

@ -11,8 +11,8 @@ ifeq ($(CUDA_HOME),)
CUDA_HOME = /usr/local/cuda
endif
# this setting should match LAMMPS Makefile
# one of LAMMPS_SMALLBIG (default), LAMMPS_BIGBIG and LAMMPS_SMALLSMALL
# this setting should match the LAMMPS Makefile
# either LAMMPS_SMALLBIG (default) or LAMMPS_BIGBIG
LMP_INC = -DLAMMPS_SMALLBIG

4
lib/gpu/Makefile.hip
View File

@ -7,8 +7,8 @@
# - change HIP_ARCH for your GPU
# ------------------------------------------------------------------------- */
# this setting should match LAMMPS Makefile
# one of LAMMPS_SMALLBIG (default), LAMMPS_BIGBIG and LAMMPS_SMALLSMALL
# this setting should match the LAMMPS Makefile
# either LAMMPS_SMALLBIG (default) or LAMMPS_BIGBIG
LMP_INC = -DLAMMPS_SMALLBIG

4
lib/gpu/Makefile.linux
View File

@ -51,8 +51,8 @@ CUDA_ARCH = -arch=sm_60
# Hopper hardware
#CUDA_ARCH = -arch=sm_90
# this setting should match LAMMPS Makefile
# one of LAMMPS_SMALLBIG (default), LAMMPS_BIGBIG and LAMMPS_SMALLSMALL
# this setting should match the LAMMPS Makefile
# either LAMMPS_SMALLBIG (default) or LAMMPS_BIGBIG
LMP_INC = -DLAMMPS_SMALLBIG

4
lib/gpu/Makefile.linux_multi
View File

@ -51,8 +51,8 @@ CUDA_CODE = -gencode arch=compute_50,code=[sm_50,compute_50] -gencode arch=compu
CUDA_ARCH += $(CUDA_CODE)
# this setting should match LAMMPS Makefile
# one of LAMMPS_SMALLBIG (default), LAMMPS_BIGBIG and LAMMPS_SMALLSMALL
# this setting should match the LAMMPS Makefile
# either LAMMPS_SMALLBIG (default) or LAMMPS_BIGBIG
LMP_INC = -DLAMMPS_SMALLBIG

4
lib/gpu/Makefile.linux_opencl
View File

@ -6,8 +6,8 @@
EXTRAMAKE = Makefile.lammps.opencl
# this setting should match LAMMPS Makefile
# one of LAMMPS_SMALLBIG (default), LAMMPS_BIGBIG and LAMMPS_SMALLSMALL
# this setting should match the LAMMPS Makefile
# either LAMMPS_SMALLBIG (default) or LAMMPS_BIGBIG
LMP_INC = -DLAMMPS_SMALLBIG

4
lib/gpu/Makefile.oneapi
View File

@ -6,8 +6,8 @@
EXTRAMAKE = Makefile.lammps.opencl
# this setting should match LAMMPS Makefile
# one of LAMMPS_SMALLBIG (default), LAMMPS_BIGBIG and LAMMPS_SMALLSMALL
# this setting should match the LAMMPS Makefile
# either LAMMPS_SMALLBIG (default) or LAMMPS_BIGBIG
LMP_INC = -DLAMMPS_SMALLBIG

4
lib/gpu/Makefile.oneapi_prof
View File

@ -6,8 +6,8 @@
EXTRAMAKE = Makefile.lammps.opencl
# this setting should match LAMMPS Makefile
# one of LAMMPS_SMALLBIG (default), LAMMPS_BIGBIG and LAMMPS_SMALLSMALL
# this setting should match the LAMMPS Makefile
# either LAMMPS_SMALLBIG (default) or LAMMPS_BIGBIG
LMP_INC = -DLAMMPS_SMALLBIG

4
lib/gpu/Makefile.serial
View File

@ -45,8 +45,8 @@ CUDA_ARCH = -arch=sm_60
#CUDA_ARCH = -arch=sm_80
#CUDA_ARCH = -arch=sm_86
# this setting should match LAMMPS Makefile
# one of LAMMPS_SMALLBIG (default), LAMMPS_BIGBIG and LAMMPS_SMALLSMALL
# this setting should match the LAMMPS Makefile
# either LAMMPS_SMALLBIG (default) or LAMMPS_BIGBIG
LMP_INC = -DLAMMPS_SMALLBIG

8
lib/gpu/README
View File

@ -136,10 +136,10 @@ IMPORTANT: If you re-build the library, e.g. for a different precision
Makefile.linux clean, to ensure all previous derived files are removed
before the new build is done.
NOTE: The system-specific setting LAMMPS_SMALLBIG (default), LAMMPS_BIGBIG,
or LAMMPS_SMALLSMALL if specified when building LAMMPS (i.e. in
src/MAKE/Makefile.foo) should be consistent with that specified
when building libgpu.a (i.e. by LMP_INC in the lib/gpu/Makefile.bar).
NOTE: The system-specific setting LAMMPS_SMALLBIG (default) or LAMMPS_BIGBIG
- if specified when building LAMMPS (i.e. in src/MAKE/Makefile.foo) -
should be consistent with that specified when building libgpu.a (i.e.
by LMP_INC in the lib/gpu/Makefile.bar).
------------------------------------------------------------------------------

6
lib/gpu/lal_amoeba.cu
View File

@ -23,9 +23,6 @@
#include "inttypes.h"
#define tagint int64_t
#endif
#ifdef LAMMPS_SMALLSMALL
#define tagint int
#endif
#ifndef _DOUBLE_DOUBLE
_texture( pos_tex,float4);
_texture( q_tex,float);
@ -43,9 +40,6 @@ _texture( q_tex,int2);
#ifdef LAMMPS_BIGBIG
#define tagint long
#endif
#ifdef LAMMPS_SMALLSMALL
#define tagint int
#endif
#endif // defined(NV_KERNEL) || defined(USE_HIP)

22
lib/gpu/lal_dpd_coul_slater_long.cu
View File

@ -287,16 +287,16 @@ __kernel void k_dpd_coul_slater_long(const __global numtyp4 *restrict x_,
// apply Slater electrostatic force if distance below Slater cutoff
// and the two species have a slater coeff
// cutsq[mtype].z -> Coulombic squared cutoff
if ( cutsq[mtype].z != 0.0 && rsq < cutsq[mtype].z){
// cutsq[mtype].z -> Slater cutoff
// extra[j].x -> q[j] ; particle j charge
if ( rsq < cutsq[mtype].z ){
numtyp r2inv=ucl_recip(rsq);
numtyp _erfc;
numtyp grij = g_ewald * r;
numtyp expm2 = ucl_exp(-grij*grij);
numtyp t = ucl_recip((numtyp)1.0 + EWALD_P*grij);
_erfc = t * (A1+t*(A2+t*(A3+t*(A4+t*A5)))) * expm2;
numtyp prefactor = extra[j].x;
prefactor *= qqrd2e * cutsq[mtype].z * qtmp/r;
numtyp prefactor = qqrd2e * extra[j].x * qtmp / r;
numtyp rlamdainv = r * lamdainv;
numtyp exprlmdainv = ucl_exp((numtyp)-2.0*rlamdainv);
numtyp slater_term = exprlmdainv*((numtyp)1.0 + ((numtyp)2.0*rlamdainv*((numtyp)1.0+rlamdainv)));
@ -306,9 +306,9 @@ __kernel void k_dpd_coul_slater_long(const __global numtyp4 *restrict x_,
if (EVFLAG && eflag) {
numtyp e_slater = ((numtyp)1.0 + rlamdainv)*exprlmdainv;
numtyp e = prefactor*(_erfc-e_slater);
if (factor_coul > (numtyp)0) e -= factor_coul*prefactor*((numtyp)1.0 - e_slater);
e_coul += e;
numtyp e_sf = prefactor*(_erfc-e_slater);
if (factor_coul > (numtyp)0) e_sf -= factor_coul*prefactor*((numtyp)1.0 - e_slater);
e_coul += e_sf;
}
} // if cut_coulsq
@ -471,16 +471,16 @@ __kernel void k_dpd_coul_slater_long_fast(const __global numtyp4 *restrict x_,
// apply Slater electrostatic force if distance below Slater cutoff
// and the two species have a slater coeff
// cutsq[mtype].z -> Coulombic squared cutoff
if ( cutsq[mtype].z != 0.0 && rsq < cutsq[mtype].z){
// cutsq[mtype].z -> Slater cutoff
// extra[j].x -> q[j] ; particle j charge
if ( rsq < cutsq[mtype].z ){
numtyp r2inv=ucl_recip(rsq);
numtyp _erfc;
numtyp grij = g_ewald * r;
numtyp expm2 = ucl_exp(-grij*grij);
numtyp t = ucl_recip((numtyp)1.0 + EWALD_P*grij);
_erfc = t * (A1+t*(A2+t*(A3+t*(A4+t*A5)))) * expm2;
numtyp prefactor = extra[j].x;
prefactor *= qqrd2e * cutsq[mtype].z * qtmp/r;
numtyp prefactor = qqrd2e * extra[j].x * qtmp / r;
numtyp rlamdainv = r * lamdainv;
numtyp exprlmdainv = ucl_exp((numtyp)-2.0*rlamdainv);
numtyp slater_term = exprlmdainv*((numtyp)1.0 + ((numtyp)2.0*rlamdainv*((numtyp)1.0+rlamdainv)));

2
lib/gpu/lal_dpd_coul_slater_long.h
View File

@ -65,7 +65,7 @@ class DPDCoulSlaterLong : public BaseDPD<numtyp, acctyp> {
/// coeff.x = a0, coeff.y = gamma, coeff.z = sigma, coeff.w = cut_dpd
UCL_D_Vec<numtyp4> coeff;
/// cutsq.x = cutsq, cutsq.y = cut_dpdsq, cutsq.w = cut_slatersq
/// cutsq.x = cutsq, cutsq.y = cut_dpdsq, cutsq.z = cut_slatersq
UCL_D_Vec<numtyp4> cutsq;
/// Special LJ values

6
lib/gpu/lal_hippo.cu
View File

@ -23,9 +23,6 @@
#include "inttypes.h"
#define tagint int64_t
#endif
#ifdef LAMMPS_SMALLSMALL
#define tagint int
#endif
#ifndef _DOUBLE_DOUBLE
_texture( pos_tex,float4);
_texture( q_tex,float);
@ -43,9 +40,6 @@ _texture( q_tex,int2);
#ifdef LAMMPS_BIGBIG
#define tagint long
#endif
#ifdef LAMMPS_SMALLSMALL
#define tagint int
#endif
#endif // defined(NV_KERNEL) || defined(USE_HIP)

6
lib/gpu/lal_lj_tip4p_long.cu
View File

@ -27,9 +27,6 @@
#define tagint int64_t
#endif
#endif
#ifdef LAMMPS_SMALLSMALL
#define tagint int
#endif
#ifndef _DOUBLE_DOUBLE
_texture( pos_tex,float4);
_texture( q_tex,float);
@ -50,9 +47,6 @@ _texture( q_tex,int2);
#define tagint int64_t
#endif
#endif
#ifdef LAMMPS_SMALLSMALL
#define tagint int
#endif
#define pos_tex x_
#define q_tex q_
#endif

6
lib/gpu/lal_neighbor_gpu.cu
View File

@ -28,9 +28,6 @@
#define tagint int64_t
#endif
#endif
#ifdef LAMMPS_SMALLSMALL
#define tagint int
#endif
#ifndef _DOUBLE_DOUBLE
_texture( pos_tex,float4);
#else
@ -140,9 +137,6 @@ __kernel void kernel_calc_cell_counts(const unsigned *restrict cell_id,
#ifdef LAMMPS_BIGBIG
#define tagint long
#endif
#ifdef LAMMPS_SMALLSMALL
#define tagint int
#endif
#endif
__kernel void transpose(__global tagint *restrict out,

7
lib/gpu/lal_precision.h
View File

@ -150,8 +150,7 @@ enum{SPHERE_SPHERE,SPHERE_ELLIPSE,ELLIPSE_SPHERE,ELLIPSE_ELLIPSE};
// default to 32-bit smallint and other ints, 64-bit bigint:
// same as defined in src/lmptype.h
#if !defined(LAMMPS_SMALLSMALL) && !defined(LAMMPS_BIGBIG) && \
!defined(LAMMPS_SMALLBIG)
#if !defined(LAMMPS_BIGBIG) && !defined(LAMMPS_SMALLBIG)
#define LAMMPS_SMALLBIG
#endif
@ -164,9 +163,5 @@ typedef int tagint;
typedef int64_t tagint;
#define OCL_INT_TYPE "-DLAMMPS_BIGBIG"
#endif
#ifdef LAMMPS_SMALLSMALL
typedef int tagint;
#define OCL_INT_TYPE "-DLAMMPS_SMALLSMALL"
#endif
#endif // LAL_PRECISION_H

3
lib/gpu/lal_preprocessor.h
View File

@ -406,7 +406,6 @@ ucl_inline int sbmask15(int j) { return j >> SBBITS15 & 7; };
// default to 32-bit smallint and other ints, 64-bit bigint:
// same as defined in src/lmptype.h
#if !defined(LAMMPS_SMALLSMALL) && !defined(LAMMPS_BIGBIG) && \
!defined(LAMMPS_SMALLBIG)
#if !defined(LAMMPS_BIGBIG) && !defined(LAMMPS_SMALLBIG)
#define LAMMPS_SMALLBIG
#endif

12
python/install.py
View File

@ -27,6 +27,8 @@ parser.add_argument("-w", "--wheeldir", required=False,
help="path to a directory where the created wheel will be stored")
parser.add_argument("-v", "--versionfile", required=True,
help="path to the LAMMPS version.h source file")
parser.add_argument("-f", "--force", action="store_true", required=False, default=False,
help="force installation of LAMMPS Python package")
args = parser.parse_args()
@ -145,7 +147,10 @@ else:
py_exe = sys.executable
try:
txt = subprocess.check_output([py_exe, '-m', 'pip', 'install', '--force-reinstall', wheel], stderr=subprocess.STDOUT, shell=False)
if args.force:
txt = subprocess.check_output([py_exe, '-m', 'pip', 'install', '--force-reinstall', '--break-system-packages', wheel], stderr=subprocess.STDOUT, shell=False)
else:
txt = subprocess.check_output([py_exe, '-m', 'pip', 'install', '--force-reinstall', wheel], stderr=subprocess.STDOUT, shell=False)
print(txt.decode('UTF-8'))
sys.exit(0)
except subprocess.CalledProcessError as err:
@ -154,7 +159,10 @@ except subprocess.CalledProcessError as err:
sys.exit(errmsg + "You need to uninstall the LAMMPS python module manually first.\n")
try:
print('Installing wheel into system site-packages folder failed. Trying user folder now')
txt = subprocess.check_output([sys.executable, '-m', 'pip', 'install', '--user', '--force-reinstall', wheel], stderr=subprocess.STDOUT, shell=False)
if args.force:
txt = subprocess.check_output([sys.executable, '-m', 'pip', 'install', '--user', '--force-reinstall', '--break-system-packages', wheel], stderr=subprocess.STDOUT, shell=False)
else:
txt = subprocess.check_output([sys.executable, '-m', 'pip', 'install', '--user', '--force-reinstall', wheel], stderr=subprocess.STDOUT, shell=False)
print(txt.decode('UTF-8'))
except:
sys.exit('Failed to install wheel ' + wheel)

2
python/lammps/constants.py
View File

@ -50,6 +50,8 @@ LMP_VAR_ATOM = 1
LMP_VAR_VECTOR = 2
LMP_VAR_STRING = 3
# default buffer size for string buffers
LMP_BUFSIZE = 1024
# -------------------------------------------------------------------------
def get_ctypes_int(size):

57
python/lammps/core.py
View File

@ -29,7 +29,7 @@ from lammps.constants import LAMMPS_AUTODETECT, LAMMPS_STRING, \
LMP_TYPE_SCALAR, LMP_TYPE_VECTOR, LMP_TYPE_ARRAY, \
LMP_SIZE_VECTOR, LMP_SIZE_ROWS, LMP_SIZE_COLS, \
LMP_VAR_EQUAL, LMP_VAR_ATOM, LMP_VAR_VECTOR, LMP_VAR_STRING, \
get_ctypes_int
LMP_BUFSIZE, get_ctypes_int
from lammps.data import NeighList
@ -347,6 +347,8 @@ class lammps(object):
self.lib.lammps_get_last_error_message.argtypes = [c_void_p, c_char_p, c_int]
self.lib.lammps_get_last_error_message.restype = c_int
self.lib.lammps_set_show_error.argtypes = [c_void_p, c_int]
self.lib.lammps_set_show_error.restype = c_int
self.lib.lammps_extract_global.argtypes = [c_void_p, c_char_p]
self.lib.lammps_extract_global_datatype.argtypes = [c_void_p, c_char_p]
@ -704,8 +706,8 @@ class lammps(object):
:rtype: string
"""
sb = create_string_buffer(512)
self.lib.lammps_get_os_info(sb,512)
sb = create_string_buffer(LMP_BUFSIZE)
self.lib.lammps_get_os_info(sb, LMP_BUFSIZE)
return sb.value.decode()
# -------------------------------------------------------------------------
@ -734,8 +736,8 @@ class lammps(object):
@property
def _lammps_exception(self):
sb = create_string_buffer(100)
error_type = self.lib.lammps_get_last_error_message(self.lmp, sb, 100)
sb = create_string_buffer(LMP_BUFSIZE)
error_type = self.lib.lammps_get_last_error_message(self.lmp, sb, LMP_BUFSIZE)
error_msg = sb.value.decode().strip()
if error_type == 2:
@ -2124,6 +2126,27 @@ class lammps(object):
# -------------------------------------------------------------------------
def set_show_error(self, flag):
""" Enable or disable direct printing of error messages in C++ code
.. versionadded:: TBD
This function allows to enable or disable printing of error message directly in
the C++ code. Disabling the printing avoids printing error messages twice when
detecting and re-throwing them in Python code.
This is a wrapper around the :cpp:func:`lammps_set_show_error`
function of the library interface.
:param flag: enable (1) or disable (0) printing of error message
:type flag: int
:return: previous setting of the flag
:rtype: int
"""
self.lib.lammps_set_show_error(self.lmp, flag)
# -------------------------------------------------------------------------
def force_timeout(self):
""" Trigger an immediate timeout, i.e. a "soft stop" of a run.
@ -2300,8 +2323,9 @@ class lammps(object):
:rtype: string
"""
sb = create_string_buffer(8192)
self.lib.lammps_get_gpu_device_info(sb,8192)
BUFSIZE = 8192
sb = create_string_buffer(BUFSIZE)
self.lib.lammps_get_gpu_device_info(sb, BUFSIZE)
return sb.value.decode()
# -------------------------------------------------------------------------
@ -2318,9 +2342,9 @@ class lammps(object):
if self._installed_packages is None:
self._installed_packages = []
npackages = self.lib.lammps_config_package_count()
sb = create_string_buffer(100)
sb = create_string_buffer(LMP_BUFSIZE)
for idx in range(npackages):
self.lib.lammps_config_package_name(idx, sb, 100)
self.lib.lammps_config_package_name(idx, sb, LMP_BUFSIZE)
self._installed_packages.append(sb.value.decode())
return self._installed_packages
@ -2356,6 +2380,7 @@ class lammps(object):
:return: list of style names in given category
:rtype: list
"""
BUFSIZE = 8192
if self._available_styles is None:
self._available_styles = {}
@ -2363,10 +2388,10 @@ class lammps(object):
self._available_styles[category] = []
with ExceptionCheck(self):
nstyles = self.lib.lammps_style_count(self.lmp, category.encode())
sb = create_string_buffer(100)
sb = create_string_buffer(BUFSIZE)
for idx in range(nstyles):
with ExceptionCheck(self):
self.lib.lammps_style_name(self.lmp, category.encode(), idx, sb, 100)
self.lib.lammps_style_name(self.lmp, category.encode(), idx, sb, BUFSIZE)
self._available_styles[category].append(sb.value.decode())
return self._available_styles[category]
@ -2411,9 +2436,9 @@ class lammps(object):
available_ids = []
if category in categories:
num = self.lib.lammps_id_count(self.lmp, category.encode())
sb = create_string_buffer(100)
sb = create_string_buffer(LMP_BUFSIZE)
for idx in range(num):
self.lib.lammps_id_name(self.lmp, category.encode(), idx, sb, 100)
self.lib.lammps_id_name(self.lmp, category.encode(), idx, sb, LMP_BUFSIZE)
available_ids.append(sb.value.decode())
return available_ids
@ -2433,10 +2458,10 @@ class lammps(object):
available_plugins = []
num = self.lib.lammps_plugin_count(self.lmp)
sty = create_string_buffer(100)
nam = create_string_buffer(100)
sty = create_string_buffer(LMP_BUFSIZE)
nam = create_string_buffer(LMP_BUFSIZE)
for idx in range(num):
self.lib.lammps_plugin_name(idx, sty, nam, 100)
self.lib.lammps_plugin_name(idx, sty, nam, LMP_BUFSIZE)
available_plugins.append([sty.value.decode(), nam.value.decode()])
return available_plugins

4
python/setup.py
View File

@ -44,6 +44,7 @@ else:
setup(
name = "lammps",
version = get_lammps_version(),
license = "GPL-2.0-only",
author = "The LAMMPS Developers",
author_email = "developers@lammps.org",
url = "https://www.lammps.org",
@ -57,11 +58,10 @@ setup(
"Programming Language :: Python :: 3",
"Development Status :: 5 - Production/Stable",
"Environment :: Console",
"License :: OSI Approved :: GNU General Public License v2 (GPLv2)",
"Operating System :: OS Independent",
],
license = "GPL",
packages = pkgs,
package_data = pkgdata,
distclass = bdist,
python_requires = '>=3.6',
)

4
src/ADIOS/dump_custom_adios.cpp
View File

@ -273,8 +273,8 @@ void DumpCustomADIOS::init_style()
fix[i] = modify->get_fix_by_id(id_fix[i]);
if (!fix[i]) error->all(FLERR, "Could not find dump custom/adios fix ID {}", id_fix[i]);
if (nevery % fix[i]->peratom_freq)
error->all(FLERR, "dump custom/adios and fix {} with ID {} not computed at compatible times",
fix[i]->style, id_fix[i]);
error->all(FLERR, Error::NOLASTLINE, "dump custom/adios and fix {} with ID {} not "
"computed at compatible times{}", fix[i]->style, id_fix[i], utils::errorurl(7));
}
int ivariable;

16
src/ASPHERE/pair_line_lj.cpp
View File

@ -13,15 +13,17 @@
------------------------------------------------------------------------- */
#include "pair_line_lj.h"
#include <cmath>
#include "atom.h"
#include "atom_vec_line.h"
#include "force.h"
#include "neighbor.h"
#include "neigh_list.h"
#include "memory.h"
#include "error.h"
#include "force.h"
#include "info.h"
#include "memory.h"
#include "neigh_list.h"
#include "neighbor.h"
#include <cmath>
using namespace LAMMPS_NS;
@ -414,7 +416,9 @@ void PairLineLJ::init_style()
double PairLineLJ::init_one(int i, int j)
{
if (setflag[i][j] == 0) error->all(FLERR,"All pair coeffs are not set");
if (setflag[i][j] == 0)
error->all(FLERR, Error::NOLASTLINE,
"All pair coeffs are not set. Status:\n" + Info::get_pair_coeff_status(lmp));
cutsubsq[i][j] = cutsub[i][j] * cutsub[i][j];

4
src/BOCS/fix_bocs.cpp
View File

@ -1089,7 +1089,7 @@ void FixBocs::couple()
}
if (!std::isfinite(p_current[0]) || !std::isfinite(p_current[1]) || !std::isfinite(p_current[2]))
error->all(FLERR,"Non-numeric pressure - simulation unstable");
error->all(FLERR,"Non-numeric pressure - simulation unstable" + utils::errorurl(6));
// switch order from xy-xz-yz to Voigt
@ -1099,7 +1099,7 @@ void FixBocs::couple()
p_current[5] = tensor[3];
if (!std::isfinite(p_current[3]) || !std::isfinite(p_current[4]) || !std::isfinite(p_current[5]))
error->all(FLERR,"Non-numeric pressure - simulation unstable");
error->all(FLERR,"Non-numeric pressure - simulation unstable" + utils::errorurl(6));
}
}

8
src/BPM/bond_bpm_spring_plastic.cpp
View File

@ -296,7 +296,7 @@ void BondBPMSpringPlastic::allocate()
void BondBPMSpringPlastic::coeff(int narg, char **arg)
{
if (narg != 5)
error->all(FLERR, "Incorrect args for bond coefficients");
error->all(FLERR, "Incorrect args for bond coefficients" + utils::errorurl(21));
if (!allocated) allocate();
int ilo, ihi;
@ -319,7 +319,7 @@ void BondBPMSpringPlastic::coeff(int narg, char **arg)
if (1.0 + ecrit[i] > max_stretch) max_stretch = 1.0 + ecrit[i];
}
if (count == 0) error->all(FLERR, "Incorrect args for bond coefficients");
if (count == 0) error->all(FLERR, "Incorrect args for bond coefficients" + utils::errorurl(21));
}
/* ----------------------------------------------------------------------
@ -440,7 +440,7 @@ double BondBPMSpringPlastic::single(int type, double rsq, int i, int j, double &
double r = sqrt(rsq);
double rinv = 1.0 / r;
double e = (r - r0) / r0;
double e = (r0 != 0.0) ? (r - r0) / r0 : 0.0;
if (normalize_flag)
fforce = -k[type] * (e - ep);
@ -460,7 +460,7 @@ double BondBPMSpringPlastic::single(int type, double rsq, int i, int j, double &
fforce *= rinv;
if (smooth_flag) {
double smooth = (r - r0) / (r0 * ecrit[type]);
double smooth = (r0 != 0.0) ? (r - r0) / (r0 * ecrit[type]) : 0.0;
smooth *= smooth;
smooth *= smooth;
smooth *= smooth;

8
src/DIELECTRIC/pppm_dielectric.cpp
View File

@ -306,10 +306,10 @@ void PPPMDielectric::qsum_qsq(int warning_flag)
// so issue warning or error
if (fabs(qsum) > SMALL) {
std::string message = fmt::format("System is not charge neutral, net "
"charge = {:.8}",qsum);
if (!warn_nonneutral) error->all(FLERR,message + utils::errorurl(29));
if (warn_nonneutral == 1 && comm->me == 0) error->warning(FLERR,message + utils::errorurl(29));
std::string message = fmt::format("System is not charge neutral, net charge = {:.8}{}",
qsum, utils::errorurl(29));
if (!warn_nonneutral) error->all(FLERR,message);
if (warn_nonneutral == 1 && comm->me == 0) error->warning(FLERR,message);
warn_nonneutral = 2;
}
}

8
src/DIELECTRIC/pppm_disp_dielectric.cpp
View File

@ -580,10 +580,10 @@ void PPPMDispDielectric::qsum_qsq(int warning_flag)
// so issue warning or error
if (fabs(qsum) > SMALL) {
std::string message = fmt::format("System is not charge neutral, net "
"charge = {:.8}",qsum);
if (!warn_nonneutral) error->all(FLERR,message + utils::errorurl(29));
if (warn_nonneutral == 1 && comm->me == 0) error->warning(FLERR,message + utils::errorurl(29));
std::string message = fmt::format("System is not charge neutral, net charge = {:.8}{}",
qsum, utils::errorurl(29));
if (!warn_nonneutral) error->all(FLERR,message);
if (warn_nonneutral == 1 && comm->me == 0) error->warning(FLERR,message);
warn_nonneutral = 2;
}
}

5
src/DPD-BASIC/pair_dpd.cpp
View File

@ -22,6 +22,7 @@
#include "comm.h"
#include "error.h"
#include "force.h"
#include "info.h"
#include "memory.h"
#include "neigh_list.h"
#include "neighbor.h"
@ -278,7 +279,9 @@ void PairDPD::init_style()
double PairDPD::init_one(int i, int j)
{
if (setflag[i][j] == 0) error->all(FLERR,"All pair coeffs are not set");
if (setflag[i][j] == 0)
error->all(FLERR, Error::NOLASTLINE,
"All pair coeffs are not set. Status:\n" + Info::get_pair_coeff_status(lmp));
sigma[i][j] = sqrt(2.0*force->boltz*temperature*gamma[i][j]);

10
src/DPD-BASIC/pair_dpd_coul_slater_long.cpp
View File

@ -22,6 +22,7 @@
#include "comm.h"
#include "error.h"
#include "force.h"
#include "info.h"
#include "memory.h"
#include "neigh_list.h"
#include "neighbor.h"
@ -353,7 +354,9 @@ void PairDPDCoulSlaterLong::init_style()
double PairDPDCoulSlaterLong::init_one(int i, int j)
{
if (setflag[i][j] == 0) error->all(FLERR,"All pair coeffs are not set");
if (setflag[i][j] == 0)
error->all(FLERR, Error::NOLASTLINE,
"All pair coeffs are not set. Status:\n" + Info::get_pair_coeff_status(lmp));
sigma[i][j] = sqrt(2.0*force->boltz*temperature*gamma[i][j]);
@ -473,7 +476,8 @@ void PairDPDCoulSlaterLong::read_restart_settings(FILE *fp)
void PairDPDCoulSlaterLong::write_data(FILE *fp)
{
for (int i = 1; i <= atom->ntypes; i++)
fprintf(fp,"%d %g %g\n",i,a0[i][i],gamma[i][i]);
fprintf(fp,"%d %g %g %s %g\n",i,a0[i][i],gamma[i][i],
(cut_slatersq[i][i] == 0.0) ? "no" : "yes", cut_dpd[i][i]);
}
/* ----------------------------------------------------------------------
@ -485,7 +489,7 @@ void PairDPDCoulSlaterLong::write_data_all(FILE *fp)
for (int i = 1; i <= atom->ntypes; i++)
for (int j = i; j <= atom->ntypes; j++)
fprintf(fp,"%d %d %g %g %s %g\n",i,j,a0[i][j],gamma[i][j],
(cut_slatersq[i][j] == 0.0) ? "yes" : "no", cut_dpd[i][j]);
(cut_slatersq[i][j] == 0.0) ? "no" : "yes", cut_dpd[i][j]);
}
/* ---------------------------------------------------------------------- */

5
src/DPD-BASIC/pair_dpd_ext.cpp
View File

@ -23,6 +23,7 @@
#include "comm.h"
#include "error.h"
#include "force.h"
#include "info.h"
#include "memory.h"
#include "neigh_list.h"
#include "neighbor.h"
@ -337,7 +338,9 @@ void PairDPDExt::init_style()
double PairDPDExt::init_one(int i, int j)
{
if (setflag[i][j] == 0) error->all(FLERR,"All pair coeffs are not set");
if (setflag[i][j] == 0)
error->all(FLERR, Error::NOLASTLINE,
"All pair coeffs are not set. Status:\n" + Info::get_pair_coeff_status(lmp));
sigma[i][j] = sqrt(2.0*force->boltz*temperature*gamma[i][j]);
sigmaT[i][j] = sqrt(2.0*force->boltz*temperature*gammaT[i][j]);

5
src/DPD-MESO/pair_edpd.cpp
View File

@ -24,6 +24,7 @@
#include "comm.h"
#include "error.h"
#include "force.h"
#include "info.h"
#include "memory.h"
#include "neigh_list.h"
#include "neighbor.h"
@ -387,7 +388,9 @@ void PairEDPD::init_style()
double PairEDPD::init_one(int i, int j)
{
if (setflag[i][j] == 0) error->all(FLERR,"All pair coeffs are not set");
if (setflag[i][j] == 0)
error->all(FLERR, Error::NOLASTLINE,
"All pair coeffs are not set. Status:\n" + Info::get_pair_coeff_status(lmp));
cut[j][i] = cut[i][j];
cutT[j][i] = cutT[i][j];

9
src/DPD-MESO/pair_mdpd.cpp
View File

@ -24,6 +24,7 @@
#include "comm.h"
#include "error.h"
#include "force.h"
#include "info.h"
#include "memory.h"
#include "neigh_list.h"
#include "neighbor.h"
@ -243,7 +244,7 @@ void PairMDPD::settings(int narg, char **arg)
void PairMDPD::coeff(int narg, char **arg)
{
if (narg != 7 ) error->all(FLERR,"Incorrect args for pair coefficients\n itype jtype A B gamma cutA cutB");
if (narg != 7 ) error->all(FLERR,"Incorrect args for pair coefficients" + utils::errorurl(21));
if (!allocated) allocate();
int ilo,ihi,jlo,jhi;
@ -256,7 +257,7 @@ void PairMDPD::coeff(int narg, char **arg)
double cut_one = utils::numeric(FLERR,arg[5],false,lmp);
double cut_two = utils::numeric(FLERR,arg[6],false,lmp);
if (cut_one < cut_two) error->all(FLERR,"Incorrect args for pair coefficients\n cutA should be larger than cutB.");
if (cut_one < cut_two) error->all(FLERR, "Value for cutA should be larger than cutB.");
int count = 0;
for (int i = ilo; i <= ihi; i++) {
@ -300,7 +301,9 @@ void PairMDPD::init_style()
double PairMDPD::init_one(int i, int j)
{
if (setflag[i][j] == 0) error->all(FLERR,"All pair coeffs are not set");
if (setflag[i][j] == 0)
error->all(FLERR, Error::NOLASTLINE,
"All pair coeffs are not set. Status:\n" + Info::get_pair_coeff_status(lmp));
sigma[i][j] = sqrt(2.0*force->boltz*temperature*gamma[i][j]);

9
src/DPD-MESO/pair_mdpd_rhosum.cpp
View File

@ -25,6 +25,7 @@
#include "atom.h"
#include "comm.h"
#include "error.h"
#include "info.h"
#include "memory.h"
#include "neigh_list.h"
#include "neighbor.h"
@ -63,7 +64,7 @@ PairMDPDRhoSum::~PairMDPDRhoSum() {
void PairMDPDRhoSum::init_style()
{
if (!atom->rho_flag)
error->all(FLERR,"Pair style mdpd/rhosum requires atom attribute rho");
error->all(FLERR, Error::NOLASTLINE, "Pair style mdpd/rhosum requires atom attribute rho");
// need a full neighbor list
neighbor->add_request(this, NeighConst::REQ_FULL);
@ -218,9 +219,9 @@ void PairMDPDRhoSum::coeff(int narg, char **arg) {
------------------------------------------------------------------------- */
double PairMDPDRhoSum::init_one(int i, int j) {
if (setflag[i][j] == 0) {
error->all(FLERR,"All pair mdpd/rhosum coeffs are not set");
}
if (setflag[i][j] == 0)
error->all(FLERR, Error::NOLASTLINE, "All pair mdpd/rhosum coeffs are not set. Status:\n"
+ Info::get_pair_coeff_status(lmp));
cut[j][i] = cut[i][j];

5
src/DPD-MESO/pair_tdpd.cpp
View File

@ -24,6 +24,7 @@
#include "comm.h"
#include "error.h"
#include "force.h"
#include "info.h"
#include "memory.h"
#include "neigh_list.h"
#include "neighbor.h"
@ -340,7 +341,9 @@ void PairTDPD::init_style()
double PairTDPD::init_one(int i, int j)
{
if (setflag[i][j] == 0) error->all(FLERR,"All pair coeffs are not set");
if (setflag[i][j] == 0)
error->all(FLERR, Error::NOLASTLINE,
"All pair coeffs are not set. Status:\n" + Info::get_pair_coeff_status(lmp));
sigma[i][j] = sqrt(2.0*force->boltz*temperature*gamma[i][j]);

5
src/DPD-REACT/pair_dpd_fdt.cpp
View File

@ -23,6 +23,7 @@
#include "error.h"
#include "fix.h"
#include "force.h"
#include "info.h"
#include "memory.h"
#include "modify.h"
#include "neigh_list.h"
@ -332,7 +333,9 @@ void PairDPDfdt::init_style()
double PairDPDfdt::init_one(int i, int j)
{
if (setflag[i][j] == 0) error->all(FLERR,"All pair coeffs are not set");
if (setflag[i][j] == 0)
error->all(FLERR, Error::NOLASTLINE,
"All pair coeffs are not set. Status:\n" + Info::get_pair_coeff_status(lmp));
cut[j][i] = cut[i][j];
a0[j][i] = a0[i][j];

5
src/DPD-REACT/pair_dpd_fdt_energy.cpp
View File

@ -23,6 +23,7 @@
#include "error.h"
#include "fix.h"
#include "force.h"
#include "info.h"
#include "memory.h"
#include "modify.h"
#include "neigh_list.h"
@ -430,7 +431,9 @@ void PairDPDfdtEnergy::init_style()
double PairDPDfdtEnergy::init_one(int i, int j)
{
if (setflag[i][j] == 0) error->all(FLERR,"All pair coeffs are not set");
if (setflag[i][j] == 0)
error->all(FLERR, Error::NOLASTLINE,
"All pair coeffs are not set. Status:\n" + Info::get_pair_coeff_status(lmp));
cut[j][i] = cut[i][j];
a0[j][i] = a0[i][j];

5
src/DPD-REACT/pair_exp6_rx.cpp
View File

@ -19,6 +19,7 @@
#include "error.h"
#include "fix.h"
#include "force.h"
#include "info.h"
#include "math_special.h"
#include "memory.h"
#include "modify.h"
@ -695,7 +696,9 @@ void PairExp6rx::coeff(int narg, char **arg)
double PairExp6rx::init_one(int i, int j)
{
if (setflag[i][j] == 0) error->all(FLERR,"All pair coeffs are not set");
if (setflag[i][j] == 0)
error->all(FLERR, Error::NOLASTLINE,
"All pair coeffs are not set. Status:\n" + Info::get_pair_coeff_status(lmp));
return cut[i][j];
}

5
src/DPD-REACT/pair_multi_lucy.cpp
View File

@ -29,6 +29,7 @@
#include "comm.h"
#include "error.h"
#include "force.h"
#include "info.h"
#include "math_const.h"
#include "memory.h"
#include "neigh_list.h"
@ -327,7 +328,9 @@ void PairMultiLucy::coeff(int narg, char **arg)
double PairMultiLucy::init_one(int i, int j)
{
if (setflag[i][j] == 0) error->all(FLERR,"All pair coeffs are not set");
if (setflag[i][j] == 0)
error->all(FLERR, Error::NOLASTLINE,
"All pair coeffs are not set. Status:\n" + Info::get_pair_coeff_status(lmp));
tabindex[j][i] = tabindex[i][j];

5
src/DPD-REACT/pair_multi_lucy_rx.cpp
View File

@ -30,6 +30,7 @@
#include "error.h"
#include "fix.h"
#include "force.h"
#include "info.h"
#include "math_const.h"
#include "memory.h"
#include "modify.h"
@ -461,7 +462,9 @@ void PairMultiLucyRX::coeff(int narg, char **arg)
double PairMultiLucyRX::init_one(int i, int j)
{
if (setflag[i][j] == 0) error->all(FLERR,"All pair coeffs are not set");
if (setflag[i][j] == 0)
error->all(FLERR, Error::NOLASTLINE,
"All pair coeffs are not set. Status:\n" + Info::get_pair_coeff_status(lmp));
tabindex[j][i] = tabindex[i][j];

4
src/DRUDE/fix_tgnh_drude.cpp
View File

@ -1063,7 +1063,7 @@ void FixTGNHDrude::couple()
}
if (!std::isfinite(p_current[0]) || !std::isfinite(p_current[1]) || !std::isfinite(p_current[2]))
error->all(FLERR,"Non-numeric pressure - simulation unstable");
error->all(FLERR,"Non-numeric pressure - simulation unstable" + utils::errorurl(6));
// switch order from xy-xz-yz to Voigt
@ -1073,7 +1073,7 @@ void FixTGNHDrude::couple()
p_current[5] = tensor[3];
if (!std::isfinite(p_current[3]) || !std::isfinite(p_current[4]) || !std::isfinite(p_current[5]))
error->all(FLERR,"Non-numeric pressure - simulation unstable");
error->all(FLERR,"Non-numeric pressure - simulation unstable" + utils::errorurl(6));
}
}

40
src/EXTRA-COMPUTE/compute_slcsa_atom.cpp
View File

@ -81,12 +81,12 @@ ComputeSLCSAAtom::ComputeSLCSAAtom(LAMMPS *lmp, int narg, char **arg) :
int twojmax = utils::inumeric(FLERR, arg[3], false, lmp);
if (twojmax < 0)
error->all(FLERR, "Illegal compute slcsa/atom command: twojmax must be a non-negative integer");
error->all(FLERR, 3, "Illegal compute slcsa/atom command: twojmax must be >= 0");
ncomps = compute_ncomps(twojmax);
nclasses = utils::inumeric(FLERR, arg[4], false, lmp);
if (nclasses < 2)
error->all(FLERR, "Illegal compute slcsa/atom command: nclasses must be greater than 1");
error->all(FLERR, 4, "Illegal compute slcsa/atom command: nclasses must be greater than 1");
database_mean_descriptor_file = arg[5];
lda_scalings_file = arg[6];
@ -116,11 +116,12 @@ ComputeSLCSAAtom::ComputeSLCSAAtom(LAMMPS *lmp, int narg, char **arg) :
val.which = argi.get_type();
val.argindex = argi.get_index1();
val.id = argi.get_name();
if ((val.which == ArgInfo::FIX) || (val.which == ArgInfo::VARIABLE) ||
(val.which == ArgInfo::UNKNOWN) || (val.which == ArgInfo::NONE) || (argi.get_dim() > 1))
error->all(FLERR, "Invalid compute slcsa/atom argument: {}", arg[0]);
error->all(FLERR, 10, "Invalid compute slcsa/atom argument: {}", arg[0]);
// if wildcard expansion occurred, free earg memory from exapnd_args()
// if wildcard expansion occurred, free earg memory from expand_args()
if (expand) {
for (int i = 0; i < nvalues; i++) delete[] earg[i];
@ -128,15 +129,19 @@ ComputeSLCSAAtom::ComputeSLCSAAtom(LAMMPS *lmp, int narg, char **arg) :
}
val.val.c = modify->get_compute_by_id(val.id);
if (!val.val.c) error->all(FLERR, "Compute ID {} for fix slcsa/atom does not exist", val.id);
if (!val.val.c) error->all(FLERR, 10, "Compute ID {} for fix slcsa/atom does not exist", val.id);
if (val.val.c->peratom_flag == 0)
error->all(FLERR, "Compute slcsa/atom compute {} does not calculate per-atom values", val.id);
error->all(FLERR, 10, "Compute slcsa/atom compute {} does not calculate per-atom values",
val.id);
if (val.argindex == 0 && val.val.c->size_peratom_cols != 0)
error->all(FLERR, "Compute slcsa/atom compute {} does not calculate a per-atom vector", val.id);
error->all(FLERR, 10, "Compute slcsa/atom compute {} does not calculate a per-atom vector",
val.id);
if (val.argindex && val.val.c->size_peratom_cols == 0)
error->all(FLERR, "Compute slcsa/atom compute {} does not calculate a per-atom array", val.id);
error->all(FLERR, 10, "Compute slcsa/atom compute {} does not calculate a per-atom array",
val.id);
if (val.argindex && val.argindex > val.val.c->size_peratom_cols)
error->all(FLERR, "Compute slcsa/atom compute {} array is accessed out-of-range", val.id);
error->all(FLERR, 10, "Compute slcsa/atom compute {} array is accessed out-of-range{}", val.id,
utils::errorurl(20));
descriptorval = val;
memory->create(database_mean_descriptor, ncomps, "slcsa/atom:database_mean_descriptor");
memory->create(lda_scalings, ncomps, nclasses - 1, "slcsa/atom:lda_scalings");
@ -150,7 +155,7 @@ ComputeSLCSAAtom::ComputeSLCSAAtom(LAMMPS *lmp, int narg, char **arg) :
if (comm->me == 0) {
if (strcmp(database_mean_descriptor_file, "NULL") == 0) {
error->one(FLERR,
error->one(FLERR, Error::NOLASTLINE,
"Cannot open database mean descriptor file {}: ", database_mean_descriptor_file,
utils::getsyserror());
} else {
@ -165,8 +170,8 @@ ComputeSLCSAAtom::ComputeSLCSAAtom(LAMMPS *lmp, int narg, char **arg) :
}
if (strcmp(lda_scalings_file, "NULL") == 0) {
error->one(FLERR, "Cannot open database linear discriminant analysis scalings file {}: ",
lda_scalings_file, utils::getsyserror());
error->one(FLERR, Error::NOLASTLINE, "Cannot open database linear discriminant analysis "
"scalings file {}: ", lda_scalings_file, utils::getsyserror());
} else {
PotentialFileReader reader(lmp, lda_scalings_file, "lda scalings file");
int nread = 0;
@ -180,8 +185,8 @@ ComputeSLCSAAtom::ComputeSLCSAAtom(LAMMPS *lmp, int narg, char **arg) :
}
if (strcmp(lr_decision_file, "NULL") == 0) {
error->one(FLERR, "Cannot open logistic regression decision file {}: ", lr_decision_file,
utils::getsyserror());
error->one(FLERR, Error::NOLASTLINE, "Cannot open logistic regression decision file {}: ",
lr_decision_file, utils::getsyserror());
} else {
PotentialFileReader reader(lmp, lr_decision_file, "lr decision file");
int nread = 0;
@ -195,8 +200,8 @@ ComputeSLCSAAtom::ComputeSLCSAAtom(LAMMPS *lmp, int narg, char **arg) :
}
if (strcmp(lr_bias_file, "NULL") == 0) {
error->one(FLERR, "Cannot open logistic regression bias file {}: ", lr_bias_file,
utils::getsyserror());
error->one(FLERR, Error::NOLASTLINE, "Cannot open logistic regression bias file {}: ",
lr_bias_file, utils::getsyserror());
} else {
PotentialFileReader reader(lmp, lr_bias_file, "lr bias file");
auto values = reader.next_values(nclasses);
@ -207,7 +212,8 @@ ComputeSLCSAAtom::ComputeSLCSAAtom(LAMMPS *lmp, int narg, char **arg) :
}
if (strcmp(maha_file, "NULL") == 0) {
error->one(FLERR, "Cannot open mahalanobis stats file {}: ", maha_file, utils::getsyserror());
error->one(FLERR, Error::NOLASTLINE, "Cannot open mahalanobis stats file {}: ", maha_file,
utils::getsyserror());
} else {
PotentialFileReader reader(lmp, maha_file, "mahalanobis stats file");
int nvalues = nclasses * ((nclasses - 1) * (nclasses - 1) + nclasses);

6
src/EXTRA-COMPUTE/compute_stress_mop.cpp
View File

@ -882,7 +882,7 @@ void ComputeStressMop::compute_dihedrals()
double x_atom_4[3] = {0.0, 0.0, 0.0};
// initialization
for (int i = 0; i < nvalues; i++) { dihedral_local[i] = 0.0; }
for (int i = 0; i < nvalues; i++) dihedral_local[i] = 0.0;
double local_contribution[3] = {0.0, 0.0, 0.0};
for (atom2 = 0; atom2 < nlocal; atom2++) {
@ -1118,10 +1118,6 @@ void ComputeStressMop::compute_dihedrals()
df[2] = sgn * (f1[2] + f3[2]);
}
// no if matches
else {
df[0] = df[1] = df[2] = 0.0;
}
local_contribution[0] += df[0] / area * nktv2p;
local_contribution[1] += df[1] / area * nktv2p;
local_contribution[2] += df[2] / area * nktv2p;

14
src/EXTRA-FIX/fix_ave_correlate_long.cpp
View File

@ -225,8 +225,8 @@ FixAveCorrelateLong::FixAveCorrelateLong(LAMMPS *lmp, int narg, char **arg) :
"Fix ave/correlate/long compute {} does not calculate a vector", val.id);
if (val.argindex && val.argindex > val.val.c->size_vector)
error->all(FLERR, val.iarg,
"Fix ave/correlate/long compute {} vector is accessed out-of-range",
val.id);
"Fix ave/correlate/long compute {} vector is accessed out-of-range{}",
val.id, utils::errorurl(20));
} else if (val.which == ArgInfo::FIX) {
val.val.f = modify->get_fix_by_id(val.id);
@ -241,11 +241,12 @@ FixAveCorrelateLong::FixAveCorrelateLong(LAMMPS *lmp, int narg, char **arg) :
"Fix ave/correlate/long fix {} does not calculate a vector", val.id);
if (val.argindex && val.argindex > val.val.f->size_vector)
error->all(FLERR, val.iarg,
"Fix ave/correlate/long fix {} vector is accessed out-of-range", val.id);
"Fix ave/correlate/long fix {} vector is accessed out-of-range{}",
val.id, utils::errorurl(20));
if (nevery % val.val.f->global_freq)
error->all(FLERR, val.iarg,
"Fix {} for fix ave/correlate/long not computed at compatible time",
val.id);
"Fix {} for fix ave/correlate/long not computed at compatible time{}",
val.id, utils::errorurl(7));
} else if (val.which == ArgInfo::VARIABLE) {
val.val.v = input->variable->find(val.id.c_str());
@ -257,8 +258,7 @@ FixAveCorrelateLong::FixAveCorrelateLong(LAMMPS *lmp, int narg, char **arg) :
"Fix ave/correlate/long variable {} is not equal-style variable", val.id);
if (val.argindex && input->variable->vectorstyle(val.val.v) == 0)
error->all(FLERR, val.iarg,
"Fix ave/correlate/long variable {} is not vector-style variable",
val.id);
"Fix ave/correlate/long variable {} is not vector-style variable", val.id);
}
}

50
src/EXTRA-FIX/fix_controller.cpp
View File

@ -39,7 +39,7 @@ FixController::FixController(LAMMPS *lmp, int narg, char **arg) :
extvector = 0;
nevery = utils::inumeric(FLERR,arg[3],false,lmp);
if (nevery <= 0) error->all(FLERR,"Illegal fix controller command");
if (nevery <= 0) error->all(FLERR, 3, "Illegal fix controller nevery value {}", nevery);
alpha = utils::numeric(FLERR,arg[4],false,lmp);
kp = utils::numeric(FLERR,arg[5],false,lmp);
@ -52,7 +52,7 @@ FixController::FixController(LAMMPS *lmp, int narg, char **arg) :
if ((argi.get_type() == ArgInfo::UNKNOWN)
|| (argi.get_type() == ArgInfo::NONE)
|| (argi.get_dim() != 0))
error->all(FLERR,"Illegal fix controller command");
error->all(FLERR,8,"Illegal fix controller argument {}", arg[8]);
pvwhich = argi.get_type();
pvindex = argi.get_index1();
@ -60,48 +60,51 @@ FixController::FixController(LAMMPS *lmp, int narg, char **arg) :
// setpoint arg
int iarg=9;
setpoint = utils::numeric(FLERR,arg[iarg],false,lmp);
iarg++;
setpoint = utils::numeric(FLERR,arg[9],false,lmp);
// control variable arg
cvID = utils::strdup(arg[iarg]);
cvID = utils::strdup(arg[10]);
// error check
if (pvwhich == ArgInfo::COMPUTE) {
Compute *c = modify->get_compute_by_id(pvID);
if (!c) error->all(FLERR,"Compute ID {} for fix controller does not exist", pvID);
if (!c) error->all(FLERR, 8, "Compute ID {} for fix controller does not exist", pvID);
int flag = 0;
if (c->scalar_flag && pvindex == 0) flag = 1;
else if (c->vector_flag && pvindex > 0) flag = 1;
if (!flag)
error->all(FLERR,"Fix controller compute does not calculate a global scalar or vector");
error->all(FLERR, 8, "Fix controller compute {} does not calculate a global scalar or "
"vector", pvID);
if (pvindex && pvindex > c->size_vector)
error->all(FLERR,"Fix controller compute vector is accessed out-of-range");
error->all(FLERR, 8, "Fix controller compute {} vector is accessed out-of-range{}",
pvID, utils::errorurl(20));
} else if (pvwhich == ArgInfo::FIX) {
Fix *f = modify->get_fix_by_id(pvID);
if (!f) error->all(FLERR,"Fix ID {} for fix controller does not exist", pvID);
if (!f) error->all(FLERR, 8, "Fix ID {} for fix controller does not exist", pvID);
int flag = 0;
if (f->scalar_flag && pvindex == 0) flag = 1;
else if (f->vector_flag && pvindex > 0) flag = 1;
if (!flag) error->all(FLERR,"Fix controller fix does not calculate a global scalar or vector");
if (!flag)
error->all(FLERR, 8, "Fix controller fix {} does not calculate a global scalar or vector",
pvID);
if (pvindex && pvindex > f->size_vector)
error->all(FLERR,"Fix controller fix vector is accessed out-of-range");
error->all(FLERR, 8, "Fix controller fix {} vector is accessed out-of-range{}", pvID,
utils::errorurl(20));
} else if (pvwhich == ArgInfo::VARIABLE) {
int ivariable = input->variable->find(pvID);
if (ivariable < 0)
error->all(FLERR,"Variable name for fix controller does not exist");
error->all(FLERR, 8, "Variable name {} for fix controller does not exist", pvID);
if (input->variable->equalstyle(ivariable) == 0)
error->all(FLERR,"Fix controller variable is not equal-style variable");
error->all(FLERR, 8, "Fix controller variable {} is not equal-style variable", pvID);
}
int ivariable = input->variable->find(cvID);
if (ivariable < 0)
error->all(FLERR,"Variable name for fix controller does not exist");
error->all(FLERR, 10, "Variable name {} for fix controller does not exist", cvID);
if (input->variable->internalstyle(ivariable) == 0)
error->all(FLERR,"Fix controller variable is not internal-style variable");
error->all(FLERR, 10, "Fix controller variable {} is not internal-style variable", cvID);
control = input->variable->compute_equal(ivariable);
firsttime = 1;
@ -130,19 +133,26 @@ void FixController::init()
{
if (pvwhich == ArgInfo::COMPUTE) {
pcompute = modify->get_compute_by_id(pvID);
if (!pcompute) error->all(FLERR,"Compute ID {} for fix controller does not exist", pvID);
if (!pcompute)
error->all(FLERR, Error::NOLASTLINE,
"Compute ID {} for fix controller does not exist", pvID);
} else if (pvwhich == ArgInfo::FIX) {
pfix = modify->get_fix_by_id(pvID);
if (!pfix) error->all(FLERR,"Fix ID {} for fix controller does not exist", pvID);
if (!pfix)
error->all(FLERR, Error::NOLASTLINE, "Fix ID {} for fix controller does not exist", pvID);
} else if (pvwhich == ArgInfo::VARIABLE) {
pvar = input->variable->find(pvID);
if (pvar < 0) error->all(FLERR,"Variable name for fix controller does not exist");
if (pvar < 0)
error->all(FLERR, Error::NOLASTLINE, "Variable name {} for fix controller does not exist",
pvID);
}
cvar = input->variable->find(cvID);
if (cvar < 0) error->all(FLERR,"Variable name for fix controller does not exist");
if (cvar < 0)
error->all(FLERR, Error::NOLASTLINE, "Variable name {} for fix controller does not exist",
cvID);
// set sampling time

4
src/EXTRA-FIX/fix_npt_cauchy.cpp
View File

@ -1036,7 +1036,7 @@ void FixNPTCauchy::couple()
}
if (!std::isfinite(p_current[0]) || !std::isfinite(p_current[1]) || !std::isfinite(p_current[2]))
error->all(FLERR,"Non-numeric pressure - simulation unstable");
error->all(FLERR,"Non-numeric pressure - simulation unstable" + utils::errorurl(6));
// switch order from xy-xz-yz to Voigt
@ -1046,7 +1046,7 @@ void FixNPTCauchy::couple()
p_current[5] = tensor[3];
if (!std::isfinite(p_current[3]) || !std::isfinite(p_current[4]) || !std::isfinite(p_current[5]))
error->all(FLERR,"Non-numeric pressure - simulation unstable");
error->all(FLERR,"Non-numeric pressure - simulation unstable" + utils::errorurl(6));
}
}

41
src/EXTRA-MOLECULE/improper_cossq.cpp
View File

@ -249,28 +249,29 @@ void ImproperCossq::allocate()
void ImproperCossq::coeff(int narg, char **arg)
{
/* Check whether there exist sufficient number of arguments.
0: type of improper to be applied to
1: energetic constant
2: equilibrium angle in degrees */
if (narg != 3) error->all(FLERR,"Incorrect args for cossq improper coefficients");
if (!allocated) allocate();
/* Check whether there exist sufficient number of arguments.
0: type of improper to be applied to
1: energetic constant
2: equilibrium angle in degrees */
if (narg != 3) error->all(FLERR,"Incorrect args for improper coefficients" + utils::errorurl(21));
if (!allocated) allocate();
int ilo,ihi;
utils::bounds(FLERR,arg[0],1,atom->nimpropertypes,ilo,ihi,error);
int ilo,ihi;
utils::bounds(FLERR,arg[0],1,atom->nimpropertypes,ilo,ihi,error);
double k_one = utils::numeric(FLERR,arg[1],false,lmp);
double chi_one = utils::numeric(FLERR,arg[2],false,lmp);
double k_one = utils::numeric(FLERR,arg[1],false,lmp);
double chi_one = utils::numeric(FLERR,arg[2],false,lmp);
int count = 0;
for (int i = ilo; i <= ihi; i++) {
k[i] = k_one;
chi[i] = ((chi_one * MY_PI)/180.0);
setflag[i] = 1;
count++;
}
int count = 0;
for (int i = ilo; i <= ihi; i++) {
k[i] = k_one;
chi[i] = ((chi_one * MY_PI)/180.0);
setflag[i] = 1;
count++;
}
if (count == 0) error->all(FLERR,"Incorrect args for improper coefficients" + utils::errorurl(21));
if (count == 0)
error->all(FLERR, "Incorrect args for improper coefficients" + utils::errorurl(21));
}
/* ----------------------------------------------------------------------
@ -278,8 +279,8 @@ void ImproperCossq::coeff(int narg, char **arg)
------------------------------------------------------------------------- */
void ImproperCossq::write_restart(FILE *fp)
{
fwrite(&k[1],sizeof(double),atom->nimpropertypes,fp);
fwrite(&chi[1],sizeof(double),atom->nimpropertypes,fp);
fwrite(&k[1],sizeof(double),atom->nimpropertypes,fp);
fwrite(&chi[1],sizeof(double),atom->nimpropertypes,fp);
}
/* ----------------------------------------------------------------------

320
src/EXTRA-MOLECULE/improper_ring.cpp
View File

@ -80,187 +80,176 @@ ImproperRing::~ImproperRing()
void ImproperRing::compute(int eflag, int vflag)
{
/* Be careful!: "chi" is the equilibrium angle in radians. */
int i1,i2,i3,i4,n,type;
/* Be careful!: "chi" is the equilibrium angle in radians. */
int i1,i2,i3,i4,n,type;
double eimproper ;
double eimproper ;
/* Compatibility variables. */
double vb1x,vb1y,vb1z,vb2x,vb2y,vb2z,vb3x,vb3y,vb3z;
double f1[3], f3[3], f4[3];
/* Compatibility variables. */
double vb1x,vb1y,vb1z,vb2x,vb2y,vb2z,vb3x,vb3y,vb3z;
double f1[3], f3[3], f4[3];
/* Actual computation variables. */
int at1[3], at2[3], at3[3], icomb;
double bvec1x[3], bvec1y[3], bvec1z[3],
bvec2x[3], bvec2y[3], bvec2z[3],
bvec1n[3], bvec2n[3], bend_angle[3];
double angle_summer, angfac, cfact1, cfact2, cfact3;
double cjiji, ckjji, ckjkj, fix, fiy, fiz, fjx, fjy, fjz, fkx, fky, fkz;
/* Actual computation variables. */
int at1[3], at2[3], at3[3], icomb;
double bvec1x[3], bvec1y[3], bvec1z[3],
bvec2x[3], bvec2y[3], bvec2z[3],
bvec1n[3], bvec2n[3], bend_angle[3];
double angle_summer, angfac, cfact1, cfact2, cfact3;
double cjiji, ckjji, ckjkj, fix, fiy, fiz, fjx, fjy, fjz, fkx, fky, fkz;
eimproper = 0.0;
ev_init(eflag,vflag);
eimproper = 0.0;
ev_init(eflag,vflag);
/* References to simulation data. */
double **x = atom->x;
double **f = atom->f;
int **improperlist = neighbor->improperlist;
int nimproperlist = neighbor->nimproperlist;
int nlocal = atom->nlocal;
int newton_bond = force->newton_bond;
/* References to simulation data. */
double **x = atom->x;
double **f = atom->f;
int **improperlist = neighbor->improperlist;
int nimproperlist = neighbor->nimproperlist;
int nlocal = atom->nlocal;
int newton_bond = force->newton_bond;
/* A description of the potential can be found in
Macromolecules 35, pp. 1463-1472 (2002). */
for (n = 0; n < nimproperlist; n++)
{
/* Take the ids of the atoms contributing to the improper potential. */
i1 = improperlist[n][0]; /* Atom "1" of Figure 1 from the above reference.*/
i2 = improperlist[n][1]; /* Atom "2" ... */
i3 = improperlist[n][2]; /* Atom "3" ... */
i4 = improperlist[n][3]; /* Atom "9" ... */
type = improperlist[n][4];
/* A description of the potential can be found in
Macromolecules 35, pp. 1463-1472 (2002). */
for (n = 0; n < nimproperlist; n++) {
/* Take the ids of the atoms contributing to the improper potential. */
i1 = improperlist[n][0]; /* Atom "1" of Figure 1 from the above reference.*/
i2 = improperlist[n][1]; /* Atom "2" ... */
i3 = improperlist[n][2]; /* Atom "3" ... */
i4 = improperlist[n][3]; /* Atom "9" ... */
type = improperlist[n][4];
/* Calculate the necessary variables for LAMMPS implementation.
if (evflag) ev_tally(i1,i2,i3,i4,nlocal,newton_bond,eimproper,f1,f3,f4,
vb1x,vb1y,vb1z,vb2x,vb2y,vb2z,vb3x,vb3y,vb3z);
Although, they are irrelevant to the calculation of the potential, we keep
them for maximal compatibility. */
vb1x = x[i1][0] - x[i2][0]; vb1y = x[i1][1] - x[i2][1]; vb1z = x[i1][2] - x[i2][2];
/* Calculate the necessary variables for LAMMPS implementation.
if (evflag) ev_tally(i1,i2,i3,i4,nlocal,newton_bond,eimproper,f1,f3,f4,
vb1x,vb1y,vb1z,vb2x,vb2y,vb2z,vb3x,vb3y,vb3z);
Although, they are irrelevant to the calculation of the potential, we keep
them for maximal compatibility. */
vb1x = x[i1][0] - x[i2][0]; vb1y = x[i1][1] - x[i2][1]; vb1z = x[i1][2] - x[i2][2];
vb2x = x[i3][0] - x[i2][0]; vb2y = x[i3][1] - x[i2][1]; vb2z = x[i3][2] - x[i2][2];
vb2x = x[i3][0] - x[i2][0]; vb2y = x[i3][1] - x[i2][1]; vb2z = x[i3][2] - x[i2][2];
vb3x = x[i4][0] - x[i3][0]; vb3y = x[i4][1] - x[i3][1]; vb3z = x[i4][2] - x[i3][2];
vb3x = x[i4][0] - x[i3][0]; vb3y = x[i4][1] - x[i3][1]; vb3z = x[i4][2] - x[i3][2];
/* Pass the atom tags to form the necessary combinations. */
at1[0] = i1; at2[0] = i2; at3[0] = i4; /* ids: 1-2-9 */
at1[1] = i1; at2[1] = i2; at3[1] = i3; /* ids: 1-2-3 */
at1[2] = i4; at2[2] = i2; at3[2] = i3; /* ids: 9-2-3 */
/* Pass the atom tags to form the necessary combinations. */
at1[0] = i1; at2[0] = i2; at3[0] = i4; /* ids: 1-2-9 */
at1[1] = i1; at2[1] = i2; at3[1] = i3; /* ids: 1-2-3 */
at1[2] = i4; at2[2] = i2; at3[2] = i3; /* ids: 9-2-3 */
/* Initialize the sum of the angles differences. */
angle_summer = 0.0;
/* Take a loop over the three angles, defined by each triad: */
for (icomb = 0; icomb < 3; icomb ++)
/* Initialize the sum of the angles differences. */
angle_summer = 0.0;
/* Take a loop over the three angles, defined by each triad: */
for (icomb = 0; icomb < 3; icomb ++)
{
/* Bond vector connecting the first and the second atom. */
bvec1x[icomb] = x[at2[icomb]][0] - x[at1[icomb]][0];
bvec1y[icomb] = x[at2[icomb]][1] - x[at1[icomb]][1];
bvec1z[icomb] = x[at2[icomb]][2] - x[at1[icomb]][2];
/* also calculate the norm of the vector: */
bvec1n[icomb] = sqrt( bvec1x[icomb]*bvec1x[icomb]
+ bvec1y[icomb]*bvec1y[icomb]
+ bvec1z[icomb]*bvec1z[icomb]);
/* Bond vector connecting the second and the third atom. */
bvec2x[icomb] = x[at3[icomb]][0] - x[at2[icomb]][0];
bvec2y[icomb] = x[at3[icomb]][1] - x[at2[icomb]][1];
bvec2z[icomb] = x[at3[icomb]][2] - x[at2[icomb]][2];
/* also calculate the norm of the vector: */
bvec2n[icomb] = sqrt( bvec2x[icomb]*bvec2x[icomb]
+ bvec2y[icomb]*bvec2y[icomb]
+ bvec2z[icomb]*bvec2z[icomb]);
/* Bond vector connecting the first and the second atom. */
bvec1x[icomb] = x[at2[icomb]][0] - x[at1[icomb]][0];
bvec1y[icomb] = x[at2[icomb]][1] - x[at1[icomb]][1];
bvec1z[icomb] = x[at2[icomb]][2] - x[at1[icomb]][2];
/* also calculate the norm of the vector: */
bvec1n[icomb] = sqrt( bvec1x[icomb]*bvec1x[icomb]
+ bvec1y[icomb]*bvec1y[icomb]
+ bvec1z[icomb]*bvec1z[icomb]);
/* Bond vector connecting the second and the third atom. */
bvec2x[icomb] = x[at3[icomb]][0] - x[at2[icomb]][0];
bvec2y[icomb] = x[at3[icomb]][1] - x[at2[icomb]][1];
bvec2z[icomb] = x[at3[icomb]][2] - x[at2[icomb]][2];
/* also calculate the norm of the vector: */
bvec2n[icomb] = sqrt( bvec2x[icomb]*bvec2x[icomb]
+ bvec2y[icomb]*bvec2y[icomb]
+ bvec2z[icomb]*bvec2z[icomb]);
/* Calculate the bending angle of the atom triad: */
bend_angle[icomb] = ( bvec2x[icomb]*bvec1x[icomb]
+ bvec2y[icomb]*bvec1y[icomb]
+ bvec2z[icomb]*bvec1z[icomb]);
bend_angle[icomb] /= (bvec1n[icomb] * bvec2n[icomb]);
if (bend_angle[icomb] > 1.0) bend_angle[icomb] -= SMALL;
if (bend_angle[icomb] < -1.0) bend_angle[icomb] += SMALL;
/* Calculate the bending angle of the atom triad: */
bend_angle[icomb] = ( bvec2x[icomb]*bvec1x[icomb]
+ bvec2y[icomb]*bvec1y[icomb]
+ bvec2z[icomb]*bvec1z[icomb]);
bend_angle[icomb] /= (bvec1n[icomb] * bvec2n[icomb]);
if (bend_angle[icomb] > 1.0) bend_angle[icomb] -= SMALL;
if (bend_angle[icomb] < -1.0) bend_angle[icomb] += SMALL;
/* Append the current angle to the sum of angle differences. */
angle_summer += (bend_angle[icomb] - chi[type]);
/* Append the current angle to the sum of angle differences. */
angle_summer += (bend_angle[icomb] - chi[type]);
}
if (eflag) eimproper = (1.0/6.0) *k[type] * powint(angle_summer,6);
/*
printf("The tags: %d-%d-%d-%d, of type %d .\n",atom->tag[i1],atom->tag[i2],atom->tag[i3],atom->tag[i4],type);
// printf("The coordinates of the first: %f, %f, %f.\n", x[i1][0], x[i1][1], x[i1][2]);
// printf("The coordinates of the second: %f, %f, %f.\n", x[i2][0], x[i2][1], x[i2][2]);
// printf("The coordinates of the third: %f, %f, %f.\n", x[i3][0], x[i3][1], x[i3][2]);
// printf("The coordinates of the fourth: %f, %f, %f.\n", x[i4][0], x[i4][1], x[i4][2]);
printf("The angles are: %f / %f / %f equilibrium: %f.\n", bend_angle[0], bend_angle[1], bend_angle[2],chi[type]);
printf("The energy of the improper: %f with prefactor %f.\n", eimproper,(1.0/6.0)*k[type]);
printf("The sum of the angles: %f.\n", angle_summer);
*/
if (eflag) eimproper = (1.0/6.0) *k[type] * powint(angle_summer,6);
/* Force calculation acting on all atoms.
Calculate the derivatives of the potential. */
angfac = k[type] * powint(angle_summer,5);
/* Force calculation acting on all atoms.
Calculate the derivatives of the potential. */
angfac = k[type] * powint(angle_summer,5);
f1[0] = 0.0; f1[1] = 0.0; f1[2] = 0.0;
f3[0] = 0.0; f3[1] = 0.0; f3[2] = 0.0;
f4[0] = 0.0; f4[1] = 0.0; f4[2] = 0.0;
f1[0] = 0.0; f1[1] = 0.0; f1[2] = 0.0;
f3[0] = 0.0; f3[1] = 0.0; f3[2] = 0.0;
f4[0] = 0.0; f4[1] = 0.0; f4[2] = 0.0;
/* Take a loop over the three angles, defined by each triad: */
for (icomb = 0; icomb < 3; icomb ++)
/* Take a loop over the three angles, defined by each triad: */
for (icomb = 0; icomb < 3; icomb ++)
{
/* Calculate the squares of the distances. */
cjiji = bvec1n[icomb] * bvec1n[icomb]; ckjkj = bvec2n[icomb] * bvec2n[icomb];
/* Calculate the squares of the distances. */
cjiji = bvec1n[icomb] * bvec1n[icomb]; ckjkj = bvec2n[icomb] * bvec2n[icomb];
ckjji = bvec2x[icomb] * bvec1x[icomb]
+ bvec2y[icomb] * bvec1y[icomb]
+ bvec2z[icomb] * bvec1z[icomb] ;
ckjji = bvec2x[icomb] * bvec1x[icomb]
+ bvec2y[icomb] * bvec1y[icomb]
+ bvec2z[icomb] * bvec1z[icomb] ;
cfact1 = angfac / (sqrt(ckjkj * cjiji));
cfact2 = ckjji / ckjkj;
cfact3 = ckjji / cjiji;
cfact1 = angfac / (sqrt(ckjkj * cjiji));
cfact2 = ckjji / ckjkj;
cfact3 = ckjji / cjiji;
/* Calculate the force acted on the third atom of the angle. */
fkx = cfact2 * bvec2x[icomb] - bvec1x[icomb];
fky = cfact2 * bvec2y[icomb] - bvec1y[icomb];
fkz = cfact2 * bvec2z[icomb] - bvec1z[icomb];
/* Calculate the force acted on the third atom of the angle. */
fkx = cfact2 * bvec2x[icomb] - bvec1x[icomb];
fky = cfact2 * bvec2y[icomb] - bvec1y[icomb];
fkz = cfact2 * bvec2z[icomb] - bvec1z[icomb];
/* Calculate the force acted on the first atom of the angle. */
fix = bvec2x[icomb] - cfact3 * bvec1x[icomb];
fiy = bvec2y[icomb] - cfact3 * bvec1y[icomb];
fiz = bvec2z[icomb] - cfact3 * bvec1z[icomb];
/* Calculate the force acted on the first atom of the angle. */
fix = bvec2x[icomb] - cfact3 * bvec1x[icomb];
fiy = bvec2y[icomb] - cfact3 * bvec1y[icomb];
fiz = bvec2z[icomb] - cfact3 * bvec1z[icomb];
/* Finally, calculate the force acted on the middle atom of the angle.*/
fjx = - fix - fkx; fjy = - fiy - fky; fjz = - fiz - fkz;
/* Finally, calculate the force acted on the middle atom of the angle.*/
fjx = - fix - fkx; fjy = - fiy - fky; fjz = - fiz - fkz;
/* Consider the appropriate scaling of the forces: */
fix *= cfact1; fiy *= cfact1; fiz *= cfact1;
fjx *= cfact1; fjy *= cfact1; fjz *= cfact1;
fkx *= cfact1; fky *= cfact1; fkz *= cfact1;
/* Consider the appropriate scaling of the forces: */
fix *= cfact1; fiy *= cfact1; fiz *= cfact1;
fjx *= cfact1; fjy *= cfact1; fjz *= cfact1;
fkx *= cfact1; fky *= cfact1; fkz *= cfact1;
if (at1[icomb] == i1) {f1[0] += fix; f1[1] += fiy; f1[2] += fiz;}
else if (at2[icomb] == i1) {f1[0] += fjx; f1[1] += fjy; f1[2] += fjz;}
else if (at3[icomb] == i1) {f1[0] += fkx; f1[1] += fky; f1[2] += fkz;}
if (at1[icomb] == i1) {f1[0] += fix; f1[1] += fiy; f1[2] += fiz;}
else if (at2[icomb] == i1) {f1[0] += fjx; f1[1] += fjy; f1[2] += fjz;}
else if (at3[icomb] == i1) {f1[0] += fkx; f1[1] += fky; f1[2] += fkz;}
if (at1[icomb] == i3) {f3[0] += fix; f3[1] += fiy; f3[2] += fiz;}
else if (at2[icomb] == i3) {f3[0] += fjx; f3[1] += fjy; f3[2] += fjz;}
else if (at3[icomb] == i3) {f3[0] += fkx; f3[1] += fky; f3[2] += fkz;}
if (at1[icomb] == i3) {f3[0] += fix; f3[1] += fiy; f3[2] += fiz;}
else if (at2[icomb] == i3) {f3[0] += fjx; f3[1] += fjy; f3[2] += fjz;}
else if (at3[icomb] == i3) {f3[0] += fkx; f3[1] += fky; f3[2] += fkz;}
if (at1[icomb] == i4) {f4[0] += fix; f4[1] += fiy; f4[2] += fiz;}
else if (at2[icomb] == i4) {f4[0] += fjx; f4[1] += fjy; f4[2] += fjz;}
else if (at3[icomb] == i4) {f4[0] += fkx; f4[1] += fky; f4[2] += fkz;}
if (at1[icomb] == i4) {f4[0] += fix; f4[1] += fiy; f4[2] += fiz;}
else if (at2[icomb] == i4) {f4[0] += fjx; f4[1] += fjy; f4[2] += fjz;}
else if (at3[icomb] == i4) {f4[0] += fkx; f4[1] += fky; f4[2] += fkz;}
/* Store the contribution to the global arrays: */
/* Take the id of the atom from the at1[icomb] element, i1 = at1[icomb]. */
if (newton_bond || at1[icomb] < nlocal) {
f[at1[icomb]][0] += fix;
f[at1[icomb]][1] += fiy;
f[at1[icomb]][2] += fiz;
}
/* Take the id of the atom from the at2[icomb] element, i2 = at2[icomb]. */
if (newton_bond || at2[icomb] < nlocal) {
f[at2[icomb]][0] += fjx;
f[at2[icomb]][1] += fjy;
f[at2[icomb]][2] += fjz;
}
/* Take the id of the atom from the at3[icomb] element, i3 = at3[icomb]. */
if (newton_bond || at3[icomb] < nlocal) {
f[at3[icomb]][0] += fkx;
f[at3[icomb]][1] += fky;
f[at3[icomb]][2] += fkz;
}
/* Store the contribution to the global arrays: */
/* Take the id of the atom from the at1[icomb] element, i1 = at1[icomb]. */
if (newton_bond || at1[icomb] < nlocal) {
f[at1[icomb]][0] += fix;
f[at1[icomb]][1] += fiy;
f[at1[icomb]][2] += fiz;
}
/* Take the id of the atom from the at2[icomb] element, i2 = at2[icomb]. */
if (newton_bond || at2[icomb] < nlocal) {
f[at2[icomb]][0] += fjx;
f[at2[icomb]][1] += fjy;
f[at2[icomb]][2] += fjz;
}
/* Take the id of the atom from the at3[icomb] element, i3 = at3[icomb]. */
if (newton_bond || at3[icomb] < nlocal) {
f[at3[icomb]][0] += fkx;
f[at3[icomb]][1] += fky;
f[at3[icomb]][2] += fkz;
}
}
if (evflag) ev_tally(i1,i2,i3,i4,nlocal,newton_bond,eimproper,f1,f3,f4,
vb1x,vb1y,vb1z,vb2x,vb2y,vb2z,vb3x,vb3y,vb3z);
if (evflag) ev_tally(i1,i2,i3,i4,nlocal,newton_bond,eimproper,f1,f3,f4,
vb1x,vb1y,vb1z,vb2x,vb2y,vb2z,vb3x,vb3y,vb3z);
}
}
@ -285,31 +274,32 @@ void ImproperRing::allocate()
void ImproperRing ::coeff(int narg, char **arg)
{
/* Check whether there exist sufficient number of arguments.
0: type of improper to be applied to
1: energetic constant
2: equilibrium angle in degrees */
if (narg != 3) error->all(FLERR,"Incorrect args for RING improper coefficients");
if (!allocated) allocate();
/* Check whether there exist sufficient number of arguments.
0: type of improper to be applied to
1: energetic constant
2: equilibrium angle in degrees */
if (narg != 3) error->all(FLERR,"Incorrect args for improper coefficients" + utils::errorurl(21));
if (!allocated) allocate();
int ilo,ihi;
utils::bounds(FLERR,arg[0],1,atom->nimpropertypes,ilo,ihi,error);
int ilo,ihi;
utils::bounds(FLERR,arg[0],1,atom->nimpropertypes,ilo,ihi,error);
double k_one = utils::numeric(FLERR,arg[1],false,lmp);
double chi_one = utils::numeric(FLERR,arg[2],false,lmp);
double k_one = utils::numeric(FLERR,arg[1],false,lmp);
double chi_one = utils::numeric(FLERR,arg[2],false,lmp);
int count = 0;
for (int i = ilo; i <= ihi; i++) {
/* Read the k parameter in kcal/mol. */
k[i] = k_one;
/* "chi_one" stores the equilibrium angle in degrees.
Convert it to radians and store its cosine. */
chi[i] = cos((chi_one/180.0)*MY_PI);
setflag[i] = 1;
count++;
}
int count = 0;
for (int i = ilo; i <= ihi; i++) {
/* Read the k parameter in kcal/mol. */
k[i] = k_one;
/* "chi_one" stores the equilibrium angle in degrees.
Convert it to radians and store its cosine. */
chi[i] = cos((chi_one/180.0)*MY_PI);
setflag[i] = 1;
count++;
}
if (count == 0) error->all(FLERR,"Incorrect args for improper coefficients" + utils::errorurl(21));
if (count == 0)
error->all(FLERR,"Incorrect args for improper coefficients" + utils::errorurl(21));
}
/* ----------------------------------------------------------------------

5
src/EXTRA-PAIR/pair_beck.cpp
View File

@ -21,6 +21,7 @@
#include "comm.h"
#include "error.h"
#include "force.h"
#include "info.h"
#include "math_special.h"
#include "memory.h"
#include "neigh_list.h"
@ -229,7 +230,9 @@ void PairBeck::coeff(int narg, char **arg)
double PairBeck::init_one(int i, int j)
{
if (setflag[i][j] == 0) error->all(FLERR, "All pair coeffs are not set");
if (setflag[i][j] == 0)
error->all(FLERR, Error::NOLASTLINE,
"All pair coeffs are not set. Status:\n" + Info::get_pair_coeff_status(lmp));
AA[j][i] = AA[i][j];
BB[j][i] = BB[i][j];

9
src/EXTRA-PAIR/pair_born_coul_dsf.cpp
View File

@ -19,10 +19,10 @@
#include "pair_born_coul_dsf.h"
#include <cmath>
#include "atom.h"
#include "comm.h"
#include "force.h"
#include "info.h"
#include "neighbor.h"
#include "neigh_list.h"
#include "math_const.h"
@ -30,6 +30,7 @@
#include "error.h"
#include "math_special.h"
#include <cmath>
using namespace LAMMPS_NS;
using namespace MathConst;
@ -278,7 +279,7 @@ void PairBornCoulDSF::coeff(int narg, char **arg)
void PairBornCoulDSF::init_style()
{
if (!atom->q_flag)
error->all(FLERR,"Pair style born/coul/dsf requires atom attribute q");
error->all(FLERR, Error::NOLASTLINE, "Pair style born/coul/dsf requires atom attribute q");
neighbor->add_request(this);
@ -295,7 +296,9 @@ void PairBornCoulDSF::init_style()
double PairBornCoulDSF::init_one(int i, int j)
{
if (setflag[i][j] == 0) error->all(FLERR,"All pair coeffs are not set");
if (setflag[i][j] == 0)
error->all(FLERR, Error::NOLASTLINE,
"All pair coeffs are not set. Status:\n" + Info::get_pair_coeff_status(lmp));
double cut = MAX(cut_lj[i][j],cut_coul);
cut_ljsq[i][j] = cut_lj[i][j] * cut_lj[i][j];

8
src/EXTRA-PAIR/pair_born_coul_wolf.cpp
View File

@ -18,16 +18,18 @@
#include "pair_born_coul_wolf.h"
#include <cmath>
#include "atom.h"
#include "comm.h"
#include "force.h"
#include "info.h"
#include "neighbor.h"
#include "neigh_list.h"
#include "math_const.h"
#include "memory.h"
#include "error.h"
#include <cmath>
using namespace LAMMPS_NS;
using namespace MathConst;
@ -294,7 +296,9 @@ void PairBornCoulWolf::init_style()
double PairBornCoulWolf::init_one(int i, int j)
{
if (setflag[i][j] == 0) error->all(FLERR,"All pair coeffs are not set");
if (setflag[i][j] == 0)
error->all(FLERR, Error::NOLASTLINE,
"All pair coeffs are not set. Status:\n" + Info::get_pair_coeff_status(lmp));
double cut = MAX(cut_lj[i][j],cut_coul);
cut_ljsq[i][j] = cut_lj[i][j] * cut_lj[i][j];

5
src/EXTRA-PAIR/pair_born_gauss.cpp
View File

@ -19,6 +19,7 @@
#include "comm.h"
#include "error.h"
#include "force.h"
#include "info.h"
#include "memory.h"
#include "neigh_list.h"
@ -215,7 +216,9 @@ void PairBornGauss::coeff(int narg, char **arg)
double PairBornGauss::init_one(int i, int j)
{
if (setflag[i][j] == 0) error->all(FLERR, "All pair coeffs are not set");
if (setflag[i][j] == 0)
error->all(FLERR, Error::NOLASTLINE,
"All pair coeffs are not set. Status:\n" + Info::get_pair_coeff_status(lmp));
if (offset_flag) {
double dr = cut[i][j] - r0[i][j];

9
src/EXTRA-PAIR/pair_buck_mdf.cpp
View File

@ -18,15 +18,16 @@
#include "pair_buck_mdf.h"
#include <cmath>
#include <cstring>
#include "atom.h"
#include "comm.h"
#include "force.h"
#include "info.h"
#include "neigh_list.h"
#include "memory.h"
#include "error.h"
#include <cmath>
#include <cstring>
using namespace LAMMPS_NS;
@ -250,7 +251,9 @@ void PairBuckMDF::coeff(int narg, char **arg)
double PairBuckMDF::init_one(int i, int j)
{
if (setflag[i][j] == 0) error->all(FLERR,"All pair coeffs are not set");
if (setflag[i][j] == 0)
error->all(FLERR, Error::NOLASTLINE,
"All pair coeffs are not set. Status:\n" + Info::get_pair_coeff_status(lmp));
rhoinv[i][j] = 1.0/rho[i][j];
buck1[i][j] = a[i][j]/rho[i][j];

5
src/EXTRA-PAIR/pair_dispersion_d3.cpp
View File

@ -26,6 +26,7 @@
#include "comm.h"
#include "error.h"
#include "force.h"
#include "info.h"
#include "memory.h"
#include "neigh_list.h"
#include "neighbor.h"
@ -1420,7 +1421,9 @@ void PairDispersionD3::set_funcpar(std::string &functional_name)
double PairDispersionD3::init_one(int i, int j)
{
if (setflag[i][j] == 0) error->all(FLERR, "All pair coeffs are not set");
if (setflag[i][j] == 0)
error->all(FLERR, Error::NOLASTLINE,
"All pair coeffs are not set. Status:\n" + Info::get_pair_coeff_status(lmp));
r0ab[j][i] = r0ab[i][j];

5
src/EXTRA-PAIR/pair_e3b.cpp
View File

@ -22,6 +22,7 @@
#include "domain.h"
#include "error.h"
#include "force.h"
#include "info.h"
#include "memory.h"
#include "neigh_list.h"
#include "neighbor.h"
@ -601,7 +602,9 @@ void PairE3B::presetParam(const int flag, bool &repeatFlag, double &bondL)
//pair.cpp::init uses this to set cutsq array, used for neighboring, etc
double PairE3B::init_one(int i, int j)
{
if (setflag[i][j] == 0) error->all(FLERR, "All pair coeffs are not set");
if (setflag[i][j] == 0)
error->all(FLERR, Error::NOLASTLINE,
"All pair coeffs are not set. Status:\n" + Info::get_pair_coeff_status(lmp));
return cutmax;
}

9
src/EXTRA-PAIR/pair_lennard_mdf.cpp
View File

@ -19,15 +19,16 @@
#include "pair_lennard_mdf.h"
#include <cmath>
#include <cstring>
#include "atom.h"
#include "comm.h"
#include "force.h"
#include "info.h"
#include "neigh_list.h"
#include "memory.h"
#include "error.h"
#include <cmath>
#include <cstring>
using namespace LAMMPS_NS;
@ -251,7 +252,9 @@ void PairLennardMDF::coeff(int narg, char **arg)
double PairLennardMDF::init_one(int i, int j)
{
if (setflag[i][j] == 0) error->all(FLERR,"All pair coeffs are not set");
if (setflag[i][j] == 0)
error->all(FLERR, Error::NOLASTLINE,
"All pair coeffs are not set. Status:\n" + Info::get_pair_coeff_status(lmp));
cut_inner_sq[i][j] = cut_inner[i][j]*cut_inner[i][j];

8
src/EXTRA-PAIR/pair_momb.cpp
View File

@ -19,16 +19,18 @@
#include "pair_momb.h"
#include <cmath>
#include "atom.h"
#include "comm.h"
#include "force.h"
#include "info.h"
#include "neigh_list.h"
#include "memory.h"
#include "error.h"
#include "citeme.h"
#include <cmath>
using namespace LAMMPS_NS;
static const char cite_momb[] =
@ -252,7 +254,9 @@ void PairMomb::coeff(int narg, char **arg)
double PairMomb::init_one(int i, int j)
{
if (setflag[i][j] == 0) error->all(FLERR,"All pair coeffs are not set");
if (setflag[i][j] == 0)
error->all(FLERR, Error::NOLASTLINE,
"All pair coeffs are not set. Status:\n" + Info::get_pair_coeff_status(lmp));
morse1[i][j] = 2.0*d0[i][j]*alpha[i][j];

9
src/EXTRA-PAIR/pair_morse_smooth_linear.cpp
View File

@ -14,15 +14,16 @@
#include "pair_morse_smooth_linear.h"
#include <cmath>
#include <cstring>
#include "atom.h"
#include "comm.h"
#include "force.h"
#include "info.h"
#include "neigh_list.h"
#include "memory.h"
#include "error.h"
#include <cmath>
#include <cstring>
using namespace LAMMPS_NS;
@ -217,7 +218,9 @@ void PairMorseSmoothLinear::coeff(int narg, char **arg)
double PairMorseSmoothLinear::init_one(int i, int j)
{
if (setflag[i][j] == 0) error->all(FLERR,"All pair coeffs are not set");
if (setflag[i][j] == 0)
error->all(FLERR, Error::NOLASTLINE,
"All pair coeffs are not set. Status:\n" + Info::get_pair_coeff_status(lmp));
morse1[i][j] = 2.0*d0[i][j]*alpha[i][j];
double alpha_dr = -alpha[i][j] * (cut[i][j] - r0[i][j]);

5
src/EXTRA-PAIR/pair_nm_cut.cpp
View File

@ -21,6 +21,7 @@
#include "atom.h"
#include "comm.h"
#include "force.h"
#include "info.h"
#include "neigh_list.h"
#include "math_const.h"
#include "memory.h"
@ -237,7 +238,9 @@ void PairNMCut::coeff(int narg, char **arg)
double PairNMCut::init_one(int i, int j)
{
if (setflag[i][j] == 0) error->all(FLERR,"All pair coeffs are not set");
if (setflag[i][j] == 0)
error->all(FLERR, Error::NOLASTLINE,
"All pair coeffs are not set. Status\n" + Info::get_pair_coeff_status(lmp));
nm[i][j] = nn[i][j]*mm[i][j];
e0nm[i][j] = e0[i][j]/(nn[i][j]-mm[i][j]);

Some files were not shown because too many files have changed in this diff Show More