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

Merge branch 'master' of github.com:lammps/lammps into coo_opt

Browse Source
This commit is contained in:
Stan Gerald Moore
2021-10-15 10:54:16 -06:00
parent 17316f92c7 ef04f6ca69
commit 23cd143aae
316 changed files with 22880 additions and 1356 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
.github/CODEOWNERS vendored
View File

@ -83,7 +83,7 @@ src/library.* @sjplimp
src/main.cpp @sjplimp
src/min_*.* @sjplimp
src/memory.* @sjplimp
src/modify.* @sjplimp
src/modify.* @sjplimp @stanmoore1
src/molecule.* @sjplimp
src/my_page.h @sjplimp
src/my_pool_chunk.h @sjplimp

2
.github/workflows/codeql-analysis.yml vendored
View File

@ -3,7 +3,7 @@ name: "CodeQL Code Analysis"
on:
push:
branches: [master]
branches: [develop]
jobs:
analyze:

2
.github/workflows/compile-msvc.yml vendored
View File

@ -3,7 +3,7 @@ name: "Native Windows Compilation"
on:
push:
branches: [master]
branches: [develop]
jobs:
build:

2
.github/workflows/unittest-macos.yml vendored
View File

@ -3,7 +3,7 @@ name: "Unittest for MacOS"
on:
push:
branches: [master]
branches: [develop]
jobs:
build:

15
cmake/CMakeLists.txt
View File

@ -617,15 +617,12 @@ foreach(PKG_WITH_INCL CORESHELL QEQ OPENMP DPD-SMOOTH KOKKOS OPT INTEL GPU)
endforeach()
if(PKG_PLUGIN)
if(BUILD_SHARED_LIBS)
target_compile_definitions(lammps PRIVATE -DLMP_PLUGIN)
else()
message(WARNING "Plugin loading will not work unless BUILD_SHARED_LIBS is enabled")
endif()
# link with -ldl or equivalent for plugin loading; except on Windows
if(NOT ${CMAKE_SYSTEM_NAME} STREQUAL "Windows")
target_link_libraries(lammps PRIVATE ${CMAKE_DL_LIBS})
endif()
target_compile_definitions(lammps PRIVATE -DLMP_PLUGIN)
endif()
# link with -ldl or equivalent for plugin loading; except on Windows
if(NOT ${CMAKE_SYSTEM_NAME} STREQUAL "Windows")
target_link_libraries(lammps PRIVATE ${CMAKE_DL_LIBS})
endif()
######################################################################

12
doc/github-development-workflow.md
View File

@ -33,9 +33,9 @@ when necessary.
## Pull Requests
ALL changes to the LAMMPS code and documentation, however trivial, MUST
be submitted as a pull request to GitHub. All changes to the "master"
be submitted as a pull request to GitHub. All changes to the "develop"
branch must be made exclusively through merging pull requests. The
"unstable" and "stable" branches, respectively are only to be updated
"release" and "stable" branches, respectively are only to be updated
upon patch or stable releases with fast-forward merges based on the
associated tags. Pull requests may also be submitted to (long-running)
feature branches created by LAMMPS developers inside the LAMMPS project,
@ -123,16 +123,16 @@ and thus were this comment should be placed.
LAMMPS uses a continuous release development model with incremental
changes, i.e. significant effort is made - including automated pre-merge
testing - that the code in the branch "master" does not get easily
testing - that the code in the branch "develop" does not get easily
broken. These tests are run after every update to a pull request. More
extensive and time consuming tests (including regression testing) are
performed after code is merged to the "master" branch. There are patch
performed after code is merged to the "develop" branch. There are patch
releases of LAMMPS every 3-5 weeks at a point, when the LAMMPS
developers feel, that a sufficient amount of changes have happened, and
the post-merge testing has been successful. These patch releases are
marked with a `patch_<version date>` tag and the "unstable" branch
marked with a `patch_<version date>` tag and the "release" branch
follows only these versions (and thus is always supposed to be of
production quality, unlike "master", which may be temporary broken, in
production quality, unlike "develop", which may be temporary broken, in
the case of larger change sets or unexpected incompatibilities or side
effects.

2
doc/lammps.1
View File

@ -1,4 +1,4 @@
.TH LAMMPS "29 September 2021" "2021-09-29"
.TH LAMMPS "1" "29 September 2021" "2021-09-29"
.SH NAME
.B LAMMPS
\- Molecular Dynamics Simulator.

2
doc/msi2lmp.1
View File

@ -1,4 +1,4 @@
.TH MSI2LMP "v3.9.9" "2018-11-05"
.TH MSI2LMP "1" "v3.9.9" "2018-11-05"
.SH NAME
.B MSI2LMP
\- Converter for Materials Studio files to LAMMPS

2
doc/src/Build_diskspace.rst
View File

@ -14,7 +14,7 @@ environments with restricted disk space capacity it may be needed to
reduce the storage requirements. Here are some suggestions:
- Create a so-called shallow repository by cloning only the last commit
instead of the full project history by using ``git clone git@github.com:lammps/lammps --depth=1 --branch=master``.
instead of the full project history by using ``git clone git@github.com:lammps/lammps --depth=1 --branch=develop``.
This reduces the downloaded size to about half. With ``--depth=1`` it is not possible to check out different
versions/branches of LAMMPS, using ``--depth=1000`` will make multiple recent versions available at little
extra storage needs (the entire git history had nearly 30,000 commits in fall 2021).

15
doc/src/Build_manual.rst
View File

@ -33,12 +33,15 @@ various tools and files. Some of them have to be installed (see below). For
the rest the build process will attempt to download and install them into
a python virtual environment and local folders.
A current version of the manual (latest patch release, aka unstable
branch) is is available online at:
`https://docs.lammps.org/Manual.html <https://docs.lammps.org/Manual.html>`_.
A version of the manual corresponding to the ongoing development (aka master branch)
is available online at: `https://docs.lammps.org/latest/
<https://docs.lammps.org/latest/>`_
A current version of the manual (latest patch release, that is the state
of the *release* branch) is is available online at:
`https://docs.lammps.org/ <https://docs.lammps.org/>`_.
A version of the manual corresponding to the ongoing development (that is
the state of the *develop* branch) is available online at:
`https://docs.lammps.org/latest/ <https://docs.lammps.org/latest/>`_
A version of the manual corresponding to the latest stable LAMMPS release
(that is the state of the *stable* branch) is available online at:
`https://docs.lammps.org/stable/ <https://docs.lammps.org/stable/>`_
Build using GNU make
--------------------

2
doc/src/Commands_fix.rst
View File

@ -23,6 +23,7 @@ OPT.
:columns: 5
* :doc:`accelerate/cos <fix_accelerate_cos>`
* :doc:`acks2/reaxff (k) <fix_acks2_reaxff>`
* :doc:`adapt <fix_adapt>`
* :doc:`adapt/fep <fix_adapt_fep>`
* :doc:`addforce <fix_addforce>`
@ -103,6 +104,7 @@ OPT.
* :doc:`manifoldforce <fix_manifoldforce>`
* :doc:`mdi/engine <fix_mdi_engine>`
* :doc:`meso/move <fix_meso_move>`
* :doc:`mol/swap <fix_mol_swap>`
* :doc:`momentum (k) <fix_momentum>`
* :doc:`momentum/chunk <fix_momentum>`
* :doc:`move <fix_move>`

133
doc/src/Howto_github.rst
View File

@ -7,11 +7,11 @@ LAMMPS GitHub tutorial
This document describes the process of how to use GitHub to integrate
changes or additions you have made to LAMMPS into the official LAMMPS
distribution. It uses the process of updating this very tutorial as
an example to describe the individual steps and options. You need to
be familiar with git and you may want to have a look at the
`git book <http://git-scm.com/book/>`_ to reacquaint yourself with some
of the more advanced git features used below.
distribution. It uses the process of updating this very tutorial as an
example to describe the individual steps and options. You need to be
familiar with git and you may want to have a look at the `git book
<http://git-scm.com/book/>`_ to familiarize yourself with some of the
more advanced git features used below.
As of fall 2016, submitting contributions to LAMMPS via pull requests
on GitHub is the preferred option for integrating contributed features
@ -37,15 +37,15 @@ username or e-mail address and password.
**Forking the repository**
To get changes into LAMMPS, you need to first fork the `lammps/lammps`
repository on GitHub. At the time of writing, *master* is the preferred
repository on GitHub. At the time of writing, *develop* is the preferred
target branch. Thus go to `LAMMPS on GitHub <https://github.com/lammps/lammps>`_
and make sure branch is set to "master", as shown in the figure below.
and make sure branch is set to "develop", as shown in the figure below.
.. image:: JPG/tutorial_branch.png
:align: center
If it is not, use the button to change it to *master*\ . Once it is, use the
fork button to create a fork.
If it is not, use the button to change it to *develop*. Once it is, use
the fork button to create a fork.
.. image:: JPG/tutorial_fork.png
:align: center
@ -64,11 +64,12 @@ LAMMPS development.
**Adding changes to your own fork**
Additions to the upstream version of LAMMPS are handled using *feature
branches*\ . For every new feature, a so-called feature branch is
branches*. For every new feature, a so-called feature branch is
created, which contains only those modification relevant to one specific
feature. For example, adding a single fix would consist of creating a
branch with only the fix header and source file and nothing else. It is
explained in more detail here: `feature branch workflow <https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow>`_.
explained in more detail here: `feature branch workflow
<https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow>`_.
**Feature branches**
@ -94,8 +95,8 @@ The above command copies ("clones") the git repository to your local
machine to a directory with the name you chose. If none is given, it will
default to "lammps". Typical names are "mylammps" or something similar.
You can use this local clone to make changes and
test them without interfering with the repository on GitHub.
You can use this local clone to make changes and test them without
interfering with the repository on GitHub.
To pull changes from upstream into this copy, you can go to the directory
and use git pull:
@ -103,28 +104,45 @@ and use git pull:
.. code-block:: bash
$ cd mylammps
$ git checkout master
$ git pull https://github.com/lammps/lammps
$ git checkout develop
$ git pull https://github.com/lammps/lammps develop
You can also add this URL as a remote:
.. code-block:: bash
$ git remote add lammps_upstream https://www.github.com/lammps/lammps
$ git remote add upstream https://www.github.com/lammps/lammps
At this point, you typically make a feature branch from the updated master
From then on you can update your upstream branches with:
.. code-block:: bash
$ git fetch upstream
and then refer to the upstream repository branches with
`upstream/develop` or `upstream/release` and so on.
At this point, you typically make a feature branch from the updated
branch for the feature you want to work on. This tutorial contains the
workflow that updated this tutorial, and hence we will call the branch
"github-tutorial-update":
.. code-block:: bash
$ git checkout -b github-tutorial-update master
$ git fetch upstream
$ git checkout -b github-tutorial-update upstream/develop
Now that we have changed branches, we can make our changes to our local
repository. Just remember that if you want to start working on another,
unrelated feature, you should switch branches!
.. note::
Committing changes to the *develop*, *release*, or *stable* branches
is strongly discouraged. While it may be convenient initially, it
will create more work in the long run. Various texts and tutorials
on using git effectively discuss the motivation for this.
**After changes are made**
After everything is done, add the files to the branch and commit them:
@ -287,28 +305,32 @@ After each push, the automated checks are run again.
LAMMPS developers may add labels to your pull request to assign it to
categories (mostly for bookkeeping purposes), but a few of them are
important: needs_work, work_in_progress, test-for-regression, and
full-regression-test. The first two indicate, that your pull request
is not considered to be complete. With "needs_work" the burden is on
exclusively on you; while "work_in_progress" can also mean, that a
LAMMPS developer may want to add changes. Please watch the comments
to the pull requests. The two "test" labels are used to trigger
extended tests before the code is merged. This is sometimes done by
LAMMPS developers, if they suspect that there may be some subtle
side effects from your changes. It is not done by default, because
those tests are very time consuming.
important: *needs_work*, *work_in_progress*, *run_tests*,
*test_for_regression*, and *ready_for_merge*. The first two indicate,
that your pull request is not considered to be complete. With
"needs_work" the burden is on exclusively on you; while
"work_in_progress" can also mean, that a LAMMPS developer may want to
add changes. Please watch the comments to the pull requests. The two
"test" labels are used to trigger extended tests before the code is
merged. This is sometimes done by LAMMPS developers, if they suspect
that there may be some subtle side effects from your changes. It is not
done by default, because those tests are very time consuming. The
*ready_for_merge* label is usually attached when the LAMMPS developer
assigned to the pull request considers this request complete and to
trigger a final full test evaluation.
**Reviews**
As of Summer 2018, a pull request needs at least 1 approving review
from a LAMMPS developer with write access to the repository.
In case your changes touch code that certain developers are associated
with, they are auto-requested by the GitHub software. Those associations
are set in the file
`.github/CODEOWNERS <https://github.com/lammps/lammps/blob/master/.github/CODEOWNERS>`_
Thus if you want to be automatically notified to review when anybody
changes files or packages, that you have contributed to LAMMPS, you can
add suitable patterns to that file, or a LAMMPS developer may add you.
As of Fall 2021, a pull request needs to pass all automatic tests and at
least 1 approving review from a LAMMPS developer with write access to
the repository before it is eligible for merging. In case your changes
touch code that certain developers are associated with, they are
auto-requested by the GitHub software. Those associations are set in
the file `.github/CODEOWNERS
<https://github.com/lammps/lammps/blob/develop/.github/CODEOWNERS>`_ Thus
if you want to be automatically notified to review when anybody changes
files or packages, that **you** have contributed to LAMMPS, you can add
suitable patterns to that file, or a LAMMPS developer may add you.
Otherwise, you can also manually request reviews from specific developers,
or LAMMPS developers - in their assessment of your pull request - may
@ -329,7 +351,7 @@ LAMMPS developer (including him/herself) or c) Axel Kohlmeyer (akohlmey).
After the review, the developer can choose to implement changes directly
or suggest them to you.
* Case c) means that the pull request has been assigned to the developer
overseeing the merging of pull requests into the master branch.
overseeing the merging of pull requests into the *develop* branch.
In this case, Axel assigned the tutorial to Steve:
@ -351,11 +373,11 @@ Sometimes, however, you might not feel comfortable having other people
push changes into your own branch, or maybe the maintainers are not sure
their idea was the right one. In such a case, they can make changes,
reassign you as the assignee, and file a "reverse pull request", i.e.
file a pull request in your GitHub repository to include changes in the
branch, that you have submitted as a pull request yourself. In that
case, you can choose to merge their changes back into your branch,
possibly make additional changes or corrections and proceed from there.
It looks something like this:
file a pull request in **your** forked GitHub repository to include
changes in the branch, that you have submitted as a pull request
yourself. In that case, you can choose to merge their changes back into
your branch, possibly make additional changes or corrections and proceed
from there. It looks something like this:
.. image:: JPG/tutorial_reverse_pull_request.png
:align: center
@ -419,7 +441,7 @@ This merge also shows up on the lammps GitHub page:
**After a merge**
When everything is fine, the feature branch is merged into the master branch:
When everything is fine, the feature branch is merged into the *develop* branch:
.. image:: JPG/tutorial_merged.png
:align: center
@ -433,8 +455,8 @@ branch!
.. code-block:: bash
$ git checkout master
$ git pull master
$ git checkout develop
$ git pull https://github.com/lammps/lammps develop
$ git branch -d github-tutorial-update
If you do not pull first, it is not really a problem but git will warn
@ -442,6 +464,7 @@ you at the next statement that you are deleting a local branch that
was not yet fully merged into HEAD. This is because git does not yet
know your branch just got merged into LAMMPS upstream. If you
first delete and then pull, everything should still be fine.
You can display all branches that are fully merged by:
Finally, if you delete the branch locally, you might want to push this
to your remote(s) as well:
@ -453,14 +476,14 @@ to your remote(s) as well:
**Recent changes in the workflow**
Some changes to the workflow are not captured in this tutorial. For
example, in addition to the master branch, to which all new features
should be submitted, there is now also an "unstable" and a "stable"
branch; these have the same content as "master", but are only updated
after a patch release or stable release was made.
Furthermore, the naming of the patches now follow the pattern
"patch_<Day><Month><Year>" to simplify comparisons between releases.
Finally, all patches and submissions are subject to automatic testing
and code checks to make sure they at the very least compile.
example, in addition to the *develop* branch, to which all new features
should be submitted, there is also a *release* and a *stable* branch;
these have the same content as *develop*, but are only updated after a
patch release or stable release was made. Furthermore, the naming of
the patches now follow the pattern "patch_<Day><Month><Year>" to
simplify comparisons between releases. Finally, all patches and
submissions are subject to automatic testing and code checks to make
sure they at the very least compile.
A discussion of the LAMMPS developer GitHub workflow can be found in the file
`doc/github-development-workflow.md <https://github.com/lammps/lammps/blob/master/doc/github-development-workflow.md>`_
`doc/github-development-workflow.md <https://github.com/lammps/lammps/blob/develop/doc/github-development-workflow.md>`_

47
doc/src/Install_git.rst
View File

@ -9,7 +9,8 @@ has several advantages:
command.
* You can create your own development branches to add code to LAMMPS.
* You can submit your new features back to GitHub for inclusion in
LAMMPS.
LAMMPS. For that you should first create your own :doc:`fork on
GitHub <Howto_github>`.
You must have `git <git_>`_ installed on your system to use the
commands explained below to communicate with the git servers on
@ -20,35 +21,53 @@ provides `limited support for subversion clients <svn_>`_.
As of October 2016, the official home of public LAMMPS development is
on GitHub. The previously advertised LAMMPS git repositories on
git.lammps.org and bitbucket.org are now deprecated or offline.
git.lammps.org and bitbucket.org are now offline or deprecated.
.. _git: https://git-scm.com
.. _svn: https://help.github.com/en/github/importing-your-projects-to-github/working-with-subversion-on-github
You can follow LAMMPS development on 3 different git branches:
You can follow the LAMMPS development on 3 different git branches:
* **stable** : this branch is updated with every stable release
* **unstable** : this branch is updated with every patch release
* **master** : this branch continuously follows ongoing development
* **stable** : this branch is updated with every stable release;
updates are always "fast forward" merges from *develop*
* **release** : this branch is updated with every patch release;
updates are always "fast forward" merges from *develop*
* **develop** : this branch follows the ongoing development and
is updated with every merge commit of a pull request
To access the git repositories on your box, use the clone command to
create a local copy of the LAMMPS repository with a command like:
.. code-block:: bash
$ git clone -b unstable https://github.com/lammps/lammps.git mylammps
$ git clone -b release https://github.com/lammps/lammps.git mylammps
where "mylammps" is the name of the directory you wish to create on
your machine and "unstable" is one of the 3 branches listed above.
your machine and "release" is one of the 3 branches listed above.
(Note that you actually download all 3 branches; you can switch
between them at any time using "git checkout <branch name>".)
.. note::
The complete git history of the LAMMPS project is quite large because
it contains the entire commit history of the project since fall 2006,
which includes the time when LAMMPS was managed with subversion. This
also includes commits that have added and removed some large files
(mostly by accident). If you do not need access to the entire commit
history, you can speed up the "cloning" process and reduce local disk
space requirements by using the *--depth* git command line flag thus
create a "shallow clone" of the repository that contains only a
subset of the git history. Using a depth of 1000 is usually sufficient
to include the head commits of the *develop* and the *release* branches.
To include the head commit of the *stable* branch you may need a depth
of up to 10000.
Once the command completes, your directory will contain the same files
as if you unpacked a current LAMMPS tarball, with the exception, that
the HTML documentation files are not included. They can be fetched
from the LAMMPS website by typing ``make fetch`` in the doc directory.
Or they can be generated from the content provided in doc/src by
typing ``make html`` from the doc directory.
Or they can be generated from the content provided in ``doc/src`` by
typing ``make html`` from the ``doc`` directory.
After initial cloning, as bug fixes and new features are added to
LAMMPS you can stay up-to-date by typing the following git commands
@ -56,9 +75,9 @@ from within the "mylammps" directory:
.. code-block:: bash
$ git checkout unstable # not needed if you always stay in this branch
$ git checkout stable # use one of these 3 checkout commands
$ git checkout master # to choose the branch to follow
$ git checkout release # not needed if you always stay in this branch
$ git checkout stable # use one of these 3 checkout commands
$ git checkout develop # to choose the branch to follow
$ git pull
Doing a "pull" will not change any files you have added to the LAMMPS
@ -81,7 +100,7 @@ Stable versions and what tagID to use for a particular stable version
are discussed on `this page <https://www.lammps.org/bug.html#version>`_.
Note that this command will print some warnings, because in order to get
back to the latest revision and to be able to update with ``git pull``
again, you will need to do ``git checkout unstable`` (or
again, you will need to do ``git checkout release`` (or
check out any other desired branch) first.
Once you have updated your local files with a ``git pull`` (or ``git

2
doc/src/Intro_opensource.rst
View File

@ -19,7 +19,7 @@ software and open-source distribution, see `www.gnu.org <gnuorg_>`_
or `www.opensource.org <opensource_>`_. The legal text of the GPL as it
applies to LAMMPS is in the LICENSE file included in the LAMMPS distribution.
.. _gpl: https://github.com/lammps/lammps/blob/master/LICENSE
.. _gpl: https://github.com/lammps/lammps/blob/develop/LICENSE
.. _lgpl: https://www.gnu.org/licenses/old-licenses/lgpl-2.1.html

2
doc/src/Manual_version.rst
View File

@ -7,7 +7,7 @@ correctly and reliably at all times. You can follow its development
in a public `git repository on GitHub <https://github.com/lammps/lammps>`_.
Whenever we fix a bug or update or add a feature, it will be merged into
the `master` branch of the git repository. When a sufficient number of
the *develop* branch of the git repository. When a sufficient number of
changes have accumulated *and* the software passes a set of automated
tests, we release it in the next *patch* release, which are made every
few weeks. Info on patch releases are on `this website page

2
doc/src/Speed.rst
View File

@ -14,7 +14,7 @@ Intel Xeon Phi co-processors.
The `Benchmark page <https://www.lammps.org/bench.html>`_ of the LAMMPS
website gives performance results for the various accelerator
packages discussed on the :doc:`Speed packages <Speed_packages>` doc
packages discussed on the :doc:`Accelerator packages <Speed_packages>`
page, for several of the standard LAMMPS benchmark problems, as a
function of problem size and number of compute nodes, on different
hardware platforms.

4
doc/src/accel_styles.rst
View File

@ -1,7 +1,7 @@
Styles with a *gpu*, *intel*, *kk*, *omp*, or *opt* suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed on the :doc:`Speed packages <Speed_packages>` doc
hardware, as discussed on the :doc:`Accelerator packages <Speed_packages>`
page. The accelerated styles take the same arguments and should
produce the same results, except for round-off and precision issues.
@ -13,5 +13,5 @@ You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the :doc:`-suffix command-line switch <Run_options>` when you invoke LAMMPS, or you can use the
:doc:`suffix <suffix>` command in your input script.
See the :doc:`Speed packages <Speed_packages>` page for more
See the :doc:`Accelerator packages <Speed_packages>` page for more
instructions on how to use the accelerated styles effectively.

18
doc/src/angle_charmm.rst
View File

@ -56,23 +56,7 @@ radian\^2.
----------
Styles with a *gpu*, *intel*, *kk*, *omp*, or *opt* suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed on the :doc:`Speed packages <Speed_packages>` doc
page. The accelerated styles take the same arguments and should
produce the same results, except for round-off and precision issues.
These accelerated styles are part of the GPU, INTEL, KOKKOS,
OPENMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the :doc:`Build package <Build_package>` page for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the :doc:`-suffix command-line switch <Run_options>` when you invoke LAMMPS, or you can use the
:doc:`suffix <suffix>` command in your input script.
See :doc:`Speed packages <Speed_packages>` page for more
instructions on how to use the accelerated styles effectively.
.. include:: accel_styles.rst
----------

23
doc/src/atom_style.rst
View File

@ -319,28 +319,9 @@ styles; see the :doc:`Modify <Modify>` doc page.
----------
Styles with a *kk* suffix are functionally the same as the
corresponding style without the suffix. They have been optimized to
run faster, depending on your available hardware, as discussed in on
the :doc:`Speed packages <Speed_packages>` doc page. The accelerated
styles take the same arguments and should produce the same results,
except for round-off and precision issues.
.. include:: accel_styles.rst
Note that other acceleration packages in LAMMPS, specifically the GPU,
INTEL, OPENMP, and OPT packages do not use accelerated atom
styles.
The accelerated styles are part of the KOKKOS package. They are only
enabled if LAMMPS was built with those packages. See the :doc:`Build
package <Build_package>` page for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the :doc:`-suffix command-line
switch <Run_options>` when you invoke LAMMPS, or you can use the
:doc:`suffix <suffix>` command in your input script.
See the :doc:`Speed packages <Speed_packages>` page for more
instructions on how to use the accelerated styles effectively.
----------
Restrictions
""""""""""""

2
doc/src/fix.rst
View File

@ -166,6 +166,7 @@ page are followed by one or more of (g,i,k,o,t) to indicate which
accelerated styles exist.
* :doc:`accelerate/cos <fix_accelerate_cos>` - apply cosine-shaped acceleration to atoms
* :doc:`acks2/reaxff <fix_acks2_reaxff>` - apply ACKS2 charge equilibration
* :doc:`adapt <fix_adapt>` - change a simulation parameter over time
* :doc:`adapt/fep <fix_adapt_fep>` - enhanced version of fix adapt
* :doc:`addforce <fix_addforce>` - add a force to each atom
@ -246,6 +247,7 @@ accelerated styles exist.
* :doc:`manifoldforce <fix_manifoldforce>` - restrain atoms to a manifold during minimization
* :doc:`mdi/engine <fix_mdi_engine>` - connect LAMMPS to external programs via the MolSSI Driver Interface (MDI)
* :doc:`meso/move <fix_meso_move>` - move mesoscopic SPH/SDPD particles in a prescribed fashion
* :doc:`mol/swap <fix_mol_swap>` - Monte Carlo atom type swapping with a molecule
* :doc:`momentum <fix_momentum>` - zero the linear and/or angular momentum of a group of atoms
* :doc:`momentum/chunk <fix_momentum>` - zero the linear and/or angular momentum of a chunk of atoms
* :doc:`move <fix_move>` - move atoms in a prescribed fashion

118
doc/src/fix_acks2_reaxff.rst Normal file
View File

@ -0,0 +1,118 @@
.. index:: fix acks2/reaxff
.. index:: fix acks2/reaxff/kk
fix acks2/reaxff command
========================
Accelerator Variants: *acks2/reaxff/kk*
Syntax
""""""
.. parsed-literal::
fix ID group-ID acks2/reaxff Nevery cutlo cuthi tolerance params args
* ID, group-ID are documented in :doc:`fix <fix>` command
* acks2/reaxff = style name of this fix command
* Nevery = perform ACKS2 every this many steps
* cutlo,cuthi = lo and hi cutoff for Taper radius
* tolerance = precision to which charges will be equilibrated
* params = reaxff or a filename
Examples
""""""""
.. code-block:: LAMMPS
fix 1 all acks2/reaxff 1 0.0 10.0 1.0e-6 reaxff
fix 1 all acks2/reaxff 1 0.0 10.0 1.0e-6 param.acks2
Description
"""""""""""
Perform the atom-condensed Kohn-Sham DFT to second order (ACKS2) charge
equilibration method as described in :ref:`(Verstraelen) <Verstraelen>`.
ACKS2 impedes unphysical long-range charge transfer sometimes seen with
QEq (e.g. for dissociation of molecules), at increased computational
cost. It is typically used in conjunction with the ReaxFF force field
model as implemented in the :doc:`pair_style reaxff <pair_reaxff>`
command, but it can be used with any potential in LAMMPS, so long as it
defines and uses charges on each atom. For more technical details about
the charge equilibration performed by fix acks2/reaxff, see the
:ref:`(O'Hearn) <O'Hearn>` paper.
The ACKS2 method minimizes the electrostatic energy of the system by
adjusting the partial charge on individual atoms based on interactions
with their neighbors. It requires some parameters for each atom type.
If the *params* setting above is the word "reaxff", then these are
extracted from the :doc:`pair_style reaxff <pair_reaxff>` command and
the ReaxFF force field file it reads in. If a file name is specified
for *params*\ , then the parameters are taken from the specified file
and the file must contain one line for each atom type. The latter form
must be used when performing QeQ with a non-ReaxFF potential. The lines
should be formatted as follows:
.. parsed-literal::
bond_softness
itype chi eta gamma bcut
where the first line is the global parameter *bond_softness*. The
remaining 1 to Ntypes lines include *itype*, the atom type from 1 to
Ntypes, *chi*, the electronegativity in eV, *eta*, the self-Coulomb
potential in eV, *gamma*, the valence orbital exponent, and *bcut*, the
bond cutoff distance. Note that these 4 quantities are also in the
ReaxFF potential file, except that eta is defined here as twice the eta
value in the ReaxFF file. Note that unlike the rest of LAMMPS, the units
of this fix are hard-coded to be A, eV, and electronic charge.
**Restart, fix_modify, output, run start/stop, minimize info:**
No information about this fix is written to :doc:`binary restart files
<restart>`. No global scalar or vector or per-atom quantities are
stored by this fix for access by various :doc:`output commands
<Howto_output>`. No parameter of this fix can be used with the
*start/stop* keywords of the :doc:`run <run>` command.
This fix is invoked during :doc:`energy minimization <minimize>`.
----------
.. include:: accel_styles.rst
----------
Restrictions
""""""""""""
This fix is part of the REAXFF package. It is only enabled if LAMMPS
was built with that package. See the :doc:`Build package
<Build_package>` doc page for more info.
This fix does not correctly handle interactions involving multiple
periodic images of the same atom. Hence, it should not be used for
periodic cell dimensions less than 10 angstroms.
This fix may be used in combination with :doc:`fix efield <fix_efield>`
and will apply the external electric field during charge equilibration,
but there may be only one fix efield instance used, it may only use a
constant electric field, and the electric field vector may only have
components in non-periodic directions.
Related commands
""""""""""""""""
:doc:`pair_style reaxff <pair_reaxff>`, :doc:`fix qeq/reaxff <fix_qeq_reaxff>`
**Default:** none
----------
.. _O'Hearn:
**(O'Hearn)** O'Hearn, Alperen, Aktulga, SIAM J. Sci. Comput., 42(1), C1-C22 (2020).
.. _Verstraelen:
**(Verstraelen)** Verstraelen, Ayers, Speybroeck, Waroquier, J. Chem. Phys. 138, 074108 (2013).

103
doc/src/fix_atom_swap.rst
View File

@ -73,51 +73,51 @@ is the same after the swap as it was before the swap, even though the
atom masses have changed.
The *semi-grand* keyword can be set to *yes* to switch to the
semi-grand canonical ensemble as discussed in :ref:`(Sadigh) <Sadigh>`. This
means that the total number of each particle type does not need to be
conserved. The default is *no*, which means that the only kind of swap
allowed exchanges an atom of one type with an atom of a different
given type. In other words, the relative mole fractions of the swapped
atoms remains constant. Whereas in the semi-grand canonical ensemble,
the composition of the system can change. Note that when using
*semi-grand*, atoms in the fix group whose type is not listed
in the *types* keyword are ineligible for attempted
conversion. An attempt is made to switch
the selected atom (if eligible) to one of the other listed types
with equal probability. Acceptance of each attempt depends upon the Metropolis criterion.
semi-grand canonical ensemble as discussed in :ref:`(Sadigh)
<Sadigh>`. This means that the total number of each particle type does
not need to be conserved. The default is *no*, which means that the
only kind of swap allowed exchanges an atom of one type with an atom
of a different given type. In other words, the relative mole fractions
of the swapped atoms remains constant. Whereas in the semi-grand
canonical ensemble, the composition of the system can change. Note
that when using *semi-grand*, atoms in the fix group whose type is not
listed in the *types* keyword are ineligible for attempted
conversion. An attempt is made to switch the selected atom (if
eligible) to one of the other listed types with equal
probability. Acceptance of each attempt depends upon the Metropolis
criterion.
The *mu* keyword allows users to specify chemical
potentials. This is required and allowed only when using *semi-grand*\ .
All chemical potentials are absolute, so there is one for
each swap type listed following the *types* keyword.
In semi-grand canonical ensemble simulations the chemical composition
of the system is controlled by the difference in these values. So
shifting all values by a constant amount will have no effect
on the simulation.
The *mu* keyword allows users to specify chemical potentials. This is
required and allowed only when using *semi-grand*\ . All chemical
potentials are absolute, so there is one for each swap type listed
following the *types* keyword. In semi-grand canonical ensemble
simulations the chemical composition of the system is controlled by
the difference in these values. So shifting all values by a constant
amount will have no effect on the simulation.
This command may optionally use the *region* keyword to define swap
volume. The specified region must have been previously defined with a
:doc:`region <region>` command. It must be defined with side = *in*\ .
Swap attempts occur only between atoms that are both within the
:doc:`region <region>` command. It must be defined with side = *in*\
. Swap attempts occur only between atoms that are both within the
specified region. Swaps are not otherwise attempted.
You should ensure you do not swap atoms belonging to a molecule, or
LAMMPS will soon generate an error when it tries to find those atoms.
LAMMPS will warn you if any of the atoms eligible for swapping have a
non-zero molecule ID, but does not check for this at the time of
LAMMPS will eventually generate an error when it tries to find those
atoms. LAMMPS will warn you if any of the atoms eligible for swapping
have a non-zero molecule ID, but does not check for this at the time of
swapping.
If not using *semi-grand* this fix checks to ensure all atoms of the
given types have the same atomic charge. LAMMPS does not enforce this
in general, but it is needed for this fix to simplify the
swapping procedure. Successful swaps will swap the atom type and charge
of the swapped atoms. Conversely, when using *semi-grand*, it is assumed that all the atom
types involved in switches have the same charge. Otherwise, charge
would not be conserved. As a consequence, no checks on atomic charges are
performed, and successful switches update the atom type but not the
atom charge. While it is possible to use *semi-grand* with groups of
atoms that have different charges, these charges will not be changed when the
atom types change.
in general, but it is needed for this fix to simplify the swapping
procedure. Successful swaps will swap the atom type and charge of the
swapped atoms. Conversely, when using *semi-grand*, it is assumed that
all the atom types involved in switches have the same
charge. Otherwise, charge would not be conserved. As a consequence, no
checks on atomic charges are performed, and successful switches update
the atom type but not the atom charge. While it is possible to use
*semi-grand* with groups of atoms that have different charges, these
charges will not be changed when the atom types change.
Since this fix computes total potential energies before and after
proposed swaps, so even complicated potential energy calculations are
@ -133,23 +133,24 @@ OK, including the following:
Some fixes have an associated potential energy. Examples of such fixes
include: :doc:`efield <fix_efield>`, :doc:`gravity <fix_gravity>`,
:doc:`addforce <fix_addforce>`, :doc:`langevin <fix_langevin>`,
:doc:`restrain <fix_restrain>`, :doc:`temp/berendsen <fix_temp_berendsen>`,
:doc:`temp/rescale <fix_temp_rescale>`, and :doc:`wall fixes <fix_wall>`.
For that energy to be included in the total potential energy of the
system (the quantity used when performing GCMC moves),
you MUST enable the :doc:`fix_modify <fix_modify>` *energy* option for
that fix. The doc pages for individual :doc:`fix <fix>` commands
specify if this should be done.
:doc:`restrain <fix_restrain>`, :doc:`temp/berendsen
<fix_temp_berendsen>`, :doc:`temp/rescale <fix_temp_rescale>`, and
:doc:`wall fixes <fix_wall>`. For that energy to be included in the
total potential energy of the system (the quantity used when
performing GCMC moves), you MUST enable the :doc:`fix_modify
<fix_modify>` *energy* option for that fix. The doc pages for
individual :doc:`fix <fix>` commands specify if this should be done.
Restart, fix_modify, output, run start/stop, minimize info
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
This fix writes the state of the fix to :doc:`binary restart files <restart>`. This includes information about the random
number generator seed, the next timestep for MC exchanges, the number
of exchange attempts and successes etc. See
the :doc:`read_restart <read_restart>` command for info on how to
re-specify a fix in an input script that reads a restart file, so that
the operation of the fix continues in an uninterrupted fashion.
This fix writes the state of the fix to :doc:`binary restart files
<restart>`. This includes information about the random number
generator seed, the next timestep for MC exchanges, the number of
exchange attempts and successes etc. See the :doc:`read_restart
<read_restart>` command for info on how to re-specify a fix in an
input script that reads a restart file, so that the operation of the
fix continues in an uninterrupted fashion.
.. note::
@ -165,12 +166,13 @@ by various :doc:`output commands <Howto_output>`. The vector values are
the following global cumulative quantities:
* 1 = swap attempts
* 2 = swap successes
* 2 = swap accepts
The vector values calculated by this fix are "extensive".
No parameter of this fix can be used with the *start/stop* keywords of
the :doc:`run <run>` command. This fix is not invoked during :doc:`energy minimization <minimize>`.
the :doc:`run <run>` command. This fix is not invoked during
:doc:`energy minimization <minimize>`.
Restrictions
""""""""""""
@ -184,7 +186,8 @@ Related commands
:doc:`fix nvt <fix_nh>`, :doc:`neighbor <neighbor>`,
:doc:`fix deposit <fix_deposit>`, :doc:`fix evaporate <fix_evaporate>`,
:doc:`delete_atoms <delete_atoms>`, :doc:`fix gcmc <fix_gcmc>`
:doc:`delete_atoms <delete_atoms>`, :doc:`fix gcmc <fix_gcmc>`,
:doc:`fix mol/swap <fix_mol_swap>`
Default
"""""""

170
doc/src/fix_mol_swap.rst Normal file
View File

@ -0,0 +1,170 @@
.. index:: fix mol/swap
fix mol/swap command
=====================
Syntax
""""""
.. parsed-literal::
fix ID group-ID mol/swap N X itype jtype seed T keyword value ...
* ID, group-ID are documented in :doc:`fix <fix>` command
* atom/swap = style name of this fix command
* N = invoke this fix every N steps
* X = number of swaps to attempt every N steps
* itype,jtype = two atom types to swap with each other
* seed = random # seed (positive integer)
* T = scaling temperature of the MC swaps (temperature units)
* zero or more keyword/value pairs may be appended to args
* keyword = *ke*
.. parsed-literal::
*ke* value = *no* or *yes*
*no* = no conservation of kinetic energy after atom swaps
*yes* = kinetic energy is conserved after atom swaps
Examples
""""""""
.. code-block:: LAMMPS
fix 2 all mol/swap 100 1 2 3 29494 300.0 ke no
fix mySwap fluid mol/swap 500 10 1 2 482798 1.0
Description
"""""""""""
This fix performs Monte Carlo swaps of two specified atom types within
a randomly selected molecule. Two possible use cases are as follows.
First, consider a mixture of some molecules with atoms of itype and
other molecules with atoms of jtype. The fix will select a random
molecule and attempt to swap all the itype atoms to jtype for the
first kind of molecule, or all the jtype atoms to itype for the second
kind. Because the swap will only take place if it is energetically
favorable, the fix can be used to determine the miscibility of 2
different kinds of molecules much more quickly than just dynamics
would do it.
Second, consider diblock co-polymers with two types of monomers itype
and jtype. The fix will select a random molecule and attempt to do a
itype <--> jtype swap of all those monomers within the molecule. Thus
the fix can be used to find the energetically favorable fractions of
two flavors of diblock co-polymers.
Intra-molecular swaps of atom types are attempted every N timesteps. On
that timestep, X swaps are attempted. For each attempt a single
molecule ID is randomly selected. The range of possible molecule IDs
from loID to hiID is pre-computed before each run begins. The
loID/hiID is set for the molecule with the smallest/largest ID which
has any itype or jtype atoms in it. Note that if you define a system
with many molecule IDs between loID and hiID which have no itype or
jtype atoms, then the fix will be inefficient at performing swaps.
Also note that if atoms with molecule ID = 0 exist, they are not
considered molecules by this fix; they are assumed to be solvent atoms
or molecules.
Candidate atoms for swapping must also be in the fix group. Atoms
within the selected molecule which are not itype or jtype are ignored.
When an atom is swapped from itype to jtype (or vice versa), if
charges are defined, the charge values for itype versus jtype atoms
are also swapped. This requires that all itype atoms in the system
have the same charge value. Likewise all jtype atoms in the system
must have the same charge value. If this is not the case, LAMMPS
issues a warning that it cannot swap charge values.
If the *ke* keyword is set to yes, which is the default, and the
masses of itype and jtype atoms are different, then when a swap
occurs, the velocity of the swapped atom is rescaled by the sqrt of
the mass ratio, so as to conserve the kinetic energy of the atom.
----------
The potential energy of the entire system is computed before and after
each swap is performed within a single molecule. The specified
temperature T is used in the Metropolis criterion to accept or reject
the attempted swap. If the swap is rejected all swapped values are
reversed.
The potential energy calculations can include systems and models with
the following features:
* manybody pair styles, including EAM
* hybrid pair styles
* long-range electrostatics (kspace)
* triclinic systems
* potential energy contributions from other fixes
For the last bullet point, fixes can have an associated potential
energy. Examples of such fixes include: :doc:`efield <fix_efield>`,
:doc:`gravity <fix_gravity>`, :doc:`addforce <fix_addforce>`,
:doc:`langevin <fix_langevin>`, :doc:`restrain <fix_restrain>`,
:doc:`temp/berendsen <fix_temp_berendsen>`, :doc:`temp/rescale
<fix_temp_rescale>`, and :doc:`wall fixes <fix_wall>`. For that
energy to be included in the total potential energy of the system (the
quantity used for the swap accept/reject decision), you MUST enable
the :doc:`fix_modify <fix_modify>` *energy* option for that fix. The
doc pages for individual :doc:`fix <fix>` commands specify if this
should be done.
.. note::
One comment on computational efficiency. If the cutoff lengths
defined for the pair style are different for itype versus jtype
atoms (for any of their interactions with any other atom type), then
a new neighbor list needs to be generated for every attempted swap.
This is potentially expensive if N is small or X is large.
Restart, fix_modify, output, run start/stop, minimize info
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
This fix writes the state of the fix to :doc:`binary restart files
<restart>`. This includes information about the random number
generator seed, the next timestep for MC exchanges, the number of
exchange attempts and successes etc. See the :doc:`read_restart
<read_restart>` command for info on how to re-specify a fix in an
input script that reads a restart file, so that the operation of the
fix continues in an uninterrupted fashion.
.. note::
For this to work correctly, the timestep must **not** be changed
after reading the restart with :doc:`reset_timestep <reset_timestep>`.
The fix will try to detect it and stop with an error.
None of the :doc:`fix_modify <fix_modify>` options are relevant to this
fix.
This fix computes a global vector of length 2, which can be accessed
by various :doc:`output commands <Howto_output>`. The vector values are
the following global cumulative quantities:
* 1 = swap attempts
* 2 = swap accepts
The vector values calculated by this fix are "extensive".
No parameter of this fix can be used with the *start/stop* keywords of
the :doc:`run <run>` command. This fix is not invoked during
:doc:`energy minimization <minimize>`.
Restrictions
""""""""""""
This fix is part of the MC package. It is only enabled if LAMMPS was
built with that package. See the :doc:`Build package <Build_package>`
doc page for more info.
Related commands
""""""""""""""""
:doc:`fix atom/swap <fix_atom_swap>`, :doc:`fix gcmc <fix_gcmc>`
Default
"""""""
The option default is ke = yes.

5
doc/src/fix_qeq.rst
View File

@ -230,7 +230,10 @@ These fixes are part of the QEQ package. They are only enabled if
LAMMPS was built with that package. See the :doc:`Build package
<Build_package>` page for more info.
The qeq fixes are not compatible with the GPU and USER-INTEL packages.
These qeq fixes are not compatible with the GPU and USER-INTEL packages.
These qeq fixes will ignore electric field contributions from
:doc:`fix efield <fix_efield>`.
Related commands
""""""""""""""""

6
doc/src/fix_qeq_reaxff.rst
View File

@ -116,6 +116,12 @@ This fix does not correctly handle interactions involving multiple
periodic images of the same atom. Hence, it should not be used for
periodic cell dimensions less than 10 angstroms.
This fix may be used in combination with :doc:`fix efield <fix_efield>`
and will apply the external electric field during charge equilibration,
but there may be only one fix efield instance used, it may only use a
constant electric field, and the electric field vector may only have
components in non-periodic directions.
Related commands
""""""""""""""""

11
doc/src/fix_reaxff_species.rst
View File

@ -56,6 +56,17 @@ number of molecules of each species. In this context, "species" means
a unique molecule. The chemical formula of each species is given in
the first line.
.. warning::
In order to compute averaged data, it is required that there are no
neighbor list rebuilds between the *Nfreq* steps. For that reason, fix
*reaxff/species* may change your neighbor list settings. There will
be a warning message showing the new settings. Having an *Nfreq*
setting that is larger than what is required for correct computation
of the ReaxFF force field interactions can thus lead to incorrect
results. For typical ReaxFF calculations a value of 100 is already
quite large.
If the filename ends with ".gz", the output file is written in gzipped
format. A gzipped dump file will be about 3x smaller than the text version,
but will also take longer to write.

23
doc/src/fix_setforce.rst
View File

@ -89,26 +89,13 @@ precession vectors instead of the forces.
----------
Styles with a *gpu*, *intel*, *kk*, *omp*, or *opt* suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed on the :doc:`Speed packages <Speed_packages>` doc
page. The accelerated styles take the same arguments and should
produce the same results, except for round-off and precision issues.
.. include:: accel_styles.rst
The region keyword is also supported by Kokkos, but a Kokkos-enabled
region must be used. See the region :doc:`region <region>` command for
more information.
.. note::
These accelerated styles are part of the r Kokkos package. They are
only enabled if LAMMPS was built with that package. See the :doc:`Build package <Build_package>` page for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the :doc:`-suffix command-line switch <Run_options>` when you invoke LAMMPS, or you can use the
:doc:`suffix <suffix>` command in your input script.
See the :doc:`Speed packages <Speed_packages>` page for more
instructions on how to use the accelerated styles effectively.
The region keyword is supported by Kokkos, but a Kokkos-enabled
region must be used. See the region :doc:`region <region>` command for
more information.
----------

20
doc/src/improper_harmonic.rst
View File

@ -64,25 +64,7 @@ radian\^2.
----------
Styles with a *gpu*, *intel*, *kk*, *omp*, or *opt* suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed on the :doc:`Speed packages <Speed_packages>` doc
page. The accelerated styles take the same arguments and should
produce the same results, except for round-off and precision issues.
These accelerated styles are part of the GPU, INTEL, KOKKOS,
OPENMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the :doc:`Build package
<Build_package>` page for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the :doc:`-suffix
command-line switch <Run_options>` when you invoke LAMMPS, or you can
use the :doc:`suffix <suffix>` command in your input script.
See the :doc:`Speed packages <Speed_packages>` page for more
instructions on how to use the accelerated styles effectively.
.. include:: accel_styles.rst
----------

39
doc/src/kspace_style.rst
View File

@ -414,33 +414,26 @@ relative RMS error.
----------
Styles with a *gpu*, *intel*, *kk*, *omp*, or *opt* suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed on the :doc:`Speed packages <Speed_packages>` doc
page. The accelerated styles take the same arguments and should
produce the same results, except for round-off and precision issues.
.. include:: accel_styles.rst
More specifically, the *pppm/gpu* style performs charge assignment and
force interpolation calculations on the GPU. These processes are
performed either in single or double precision, depending on whether
the -DFFT_SINGLE setting was specified in your low-level Makefile, as
discussed above. The FFTs themselves are still calculated on the CPU.
If *pppm/gpu* is used with a GPU-enabled pair style, part of the PPPM
calculation can be performed concurrently on the GPU while other
calculations for non-bonded and bonded force calculation are performed
on the CPU.
.. note::
The *pppm/kk* style performs charge assignment and force interpolation
calculations, along with the FFTs themselves, on the GPU or (optionally) threaded
on the CPU when using OpenMP and FFTW3.
For the GPU package, the *pppm/gpu* style performs charge assignment
and force interpolation calculations on the GPU. These processes
are performed either in single or double precision, depending on
whether the -DFFT_SINGLE setting was specified in your low-level
Makefile, as discussed above. The FFTs themselves are still
calculated on the CPU. If *pppm/gpu* is used with a GPU-enabled
pair style, part of the PPPM calculation can be performed
concurrently on the GPU while other calculations for non-bonded and
bonded force calculation are performed on the CPU.
These accelerated styles are part of the GPU, INTEL, KOKKOS,
OPENMP, and OPT packages respectively. They are only enabled if
LAMMPS was built with those packages. See the :doc:`Build package <Build_package>` page for more info.
.. note::
See the :doc:`Speed packages <Speed_packages>` page for more
instructions on how to use the accelerated styles effectively.
For the KOKKOS package, the *pppm/kk* style performs charge
assignment and force interpolation calculations, along with the FFTs
themselves, on the GPU or (optionally) threaded on the CPU when
using OpenMP and FFTW3.
----------

2
doc/src/package.rst
View File

@ -166,7 +166,7 @@ intel", or "package omp" command with default settings.
set, either to default values or to specified settings. I.e. settings
from previous invocations do not persist across multiple invocations.
See the :doc:`Speed packages <Speed_packages>` page for more details
See the :doc:`Accelerator packages <Speed_packages>` page for more details
about using the various accelerator packages for speeding up LAMMPS
simulations.

16
doc/src/pair_agni.rst
View File

@ -67,21 +67,7 @@ and input files are provided in the examples/PACKAGES/agni directory.
----------
Styles with *omp* suffix is functionally the same as the corresponding
style without the suffix. They have been optimized to run faster,
depending on your available hardware, as discussed on the :doc:`Speed packages <Speed_packages>` doc page. The accelerated style takes
the same arguments and should produce the same results, except for
round-off and precision issues.
The accelerated style is part of the OPENMP. They are only enabled
if LAMMPS was built with those packages. See the :doc:`Build package <Build_package>` page for more info.
You can specify the accelerated style explicitly in your input script
by including their suffix, or you can use the :doc:`-suffix command-line switch <Run_options>` when you invoke LAMMPS, or you can use the
:doc:`suffix <suffix>` command in your input script.
See the :doc:`Speed packages <Speed_packages>` page for more
instructions on how to use the accelerated styles effectively.
.. include:: accel_styles.rst
----------

33
doc/src/pair_hybrid.rst
View File

@ -383,30 +383,19 @@ coefficients to 0.0.
----------
Styles with a *gpu*, *intel*, *kk*, *omp*, or *opt* suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed on the :doc:`Speed packages <Speed_packages>` doc
page. Pair style *hybrid/scaled* does (currently) not support the
*gpu*, *omp*, *kk*, or *intel* suffix.
.. include:: accel_styles.rst
Since the *hybrid*, *hybrid/overlay*, *hybrid/scaled* styles delegate
computation to the individual sub-styles, the suffix versions of the
*hybrid* and *hybrid/overlay* styles are used to propagate the
corresponding suffix to all sub-styles, if those versions
exist. Otherwise the non-accelerated version will be used.
.. note::
The individual accelerated sub-styles are part of the GPU, KOKKOS,
INTEL, OPENMP, and OPT packages, respectively. They are only
enabled if LAMMPS was built with those packages. See the :doc:`Build
package <Build_package>` page for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the :doc:`-suffix command-line switch <Run_options>` when you invoke LAMMPS, or you can use the
:doc:`suffix <suffix>` command in your input script.
See the :doc:`Speed packages <Speed_packages>` page for more
instructions on how to use the accelerated styles effectively.
Since the *hybrid*, *hybrid/overlay*, *hybrid/scaled* styles
delegate computation to the individual sub-styles, the suffix
versions of the *hybrid* and *hybrid/overlay* styles are used to
propagate the corresponding suffix to all sub-styles, if those
versions exist. Otherwise the non-accelerated version will be used.
The individual accelerated sub-styles are part of the GPU, KOKKOS,
INTEL, OPENMP, and OPT packages, respectively. They are only
enabled if LAMMPS was built with those packages. See the
:doc:`Build package <Build_package>` page for more info.
----------

11
doc/src/pair_reaxff.rst
View File

@ -20,7 +20,7 @@ Syntax
.. parsed-literal::
keyword = *checkqeq* or *lgvdw* or *safezone* or *mincap* or *minhbonds*
*checkqeq* value = *yes* or *no* = whether or not to require qeq/reaxff fix
*checkqeq* value = *yes* or *no* = whether or not to require qeq/reaxff or acks2/reaxff fix
*enobonds* value = *yes* or *no* = whether or not to tally energy of atoms with no bonds
*lgvdw* value = *yes* or *no* = whether or not to use a low gradient vdW correction
*safezone* = factor used for array allocation
@ -119,7 +119,8 @@ The ReaxFF parameter files provided were created using a charge
equilibration (QEq) model for handling the electrostatic interactions.
Therefore, by default, LAMMPS requires that either the
:doc:`fix qeq/reaxff <fix_qeq_reaxff>` or the
:doc:`fix qeq/shielded <fix_qeq>` command be used with
:doc:`fix qeq/shielded <fix_qeq>` or :doc:`fix acks2/reaxff <fix_acks2_reaxff>`
command be used with
*pair_style reaxff* when simulating a ReaxFF model, to equilibrate
the charges each timestep.
@ -128,7 +129,8 @@ for the QEq fixes, allowing a simulation to be run without charge
equilibration. In this case, the static charges you assign to each
atom will be used for computing the electrostatic interactions in
the system. See the :doc:`fix qeq/reaxff <fix_qeq_reaxff>` or
:doc:`fix qeq/shielded <fix_qeq>` command documentation for more details.
:doc:`fix qeq/shielded <fix_qeq>` or :doc:`fix acks2/reaxff <fix_acks2_reaxff>`
command documentation for more details.
Using the optional keyword *lgvdw* with the value *yes* turns on the
low-gradient correction of ReaxFF for long-range London Dispersion,
@ -352,7 +354,8 @@ Related commands
""""""""""""""""
:doc:`pair_coeff <pair_coeff>`, :doc:`fix qeq/reaxff <fix_qeq_reaxff>`,
:doc:`fix reaxff/bonds <fix_reaxff_bonds>`, :doc:`fix reaxff/species <fix_reaxff_species>`
:doc:`fix acks2/reaxff <fix_acks2_reaxff>`, :doc:`fix reaxff/bonds <fix_reaxff_bonds>`,
:doc:`fix reaxff/species <fix_reaxff_species>`
Default
"""""""

26
doc/src/pair_sw.rst
View File

@ -159,28 +159,14 @@ taken from the ij and ik pairs (:math:`\sigma`, *a*, :math:`\gamma`)
----------
Styles with a *gpu*, *intel*, *kk*, *omp*, or *opt* suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed on the :doc:`Speed packages <Speed_packages>` doc
page. The accelerated styles take the same arguments and should
produce the same results, except for round-off and precision issues.
.. include:: accel_styles.rst
These accelerated styles are part of the GPU, INTEL, KOKKOS,
OPENMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the :doc:`Build package <Build_package>` page for more info.
.. note::
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the :doc:`-suffix command-line switch <Run_options>` when you invoke LAMMPS, or you can use the
:doc:`suffix <suffix>` command in your input script.
When using the INTEL package with this style, there is an
additional 5 to 10 percent performance improvement when the
Stillinger-Weber parameters p and q are set to 4 and 0 respectively.
These parameters are common for modeling silicon and water.
See the :doc:`Speed packages <Speed_packages>` page for more
instructions on how to use the accelerated styles effectively.
When using the INTEL package with this style, there is an additional
5 to 10 percent performance improvement when the Stillinger-Weber
parameters p and q are set to 4 and 0 respectively. These
parameters are common for modeling silicon and water.
----------

6
doc/src/plugin.rst
View File

@ -65,10 +65,8 @@ only enabled if LAMMPS was built with that package.
See the :doc:`Build package <Build_package>` page for
more info. Plugins are not available on Windows.
For the loading of plugins to work the LAMMPS library must be
:ref:`compiled as a shared library <library>`. If plugins
access functions or classes from a package, LAMMPS must have
been compiled with that package included.
If plugins access functions or classes from a package, LAMMPS must
have been compiled with that package included.
Plugins are dependent on the LAMMPS binary interface (ABI)
and particularly the MPI library used. So they are not guaranteed

23
doc/src/region.rst
View File

@ -371,26 +371,13 @@ sub-regions can be defined with the *open* keyword.
----------
Styles with a *gpu*, *intel*, *kk*, *omp*, or *opt* suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed on the :doc:`Speed packages <Speed_packages>` doc
page. The accelerated styles take the same arguments and should
produce the same results, except for round-off and precision issues.
.. include:: accel_styles.rst
The code using the region (such as a fix or compute) must also be supported
by Kokkos or no acceleration will occur. Currently, only *block* style
regions are supported by Kokkos.
.. note::
These accelerated styles are part of the Kokkos package. They are
only enabled if LAMMPS was built with that package. See the :doc:`Build package <Build_package>` page for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the :doc:`-suffix command-line switch <Run_options>` when you invoke LAMMPS, or you can use the
:doc:`suffix <suffix>` command in your input script.
See the :doc:`Speed packages <Speed_packages>` page for more
instructions on how to use the accelerated styles effectively.
Currently, only *block* style regions are supported by Kokkos. The
code using the region (such as a fix or compute) must also be
supported by Kokkos or no acceleration will occur.
----------

22
doc/src/run_style.rst
View File

@ -125,12 +125,13 @@ screen.0 by default; see the :doc:`-plog and -pscreen command-line switches <Run
for the second partition will not contain thermodynamic output beyond the
first timestep of the run.
See the :doc:`Speed packages <Speed_packages>` page for performance
details of the speed-up offered by the *verlet/split* style. One
important performance consideration is the assignment of logical
processors in the 2 partitions to the physical cores of a parallel
machine. The :doc:`processors <processors>` command has options to
support this, and strategies are discussed in :doc:`Section 5 <Speed>` of the manual.
See the :doc:`Accelerator packages <Speed_packages>` page for
performance details of the speed-up offered by the *verlet/split*
style. One important performance consideration is the assignment of
logical processors in the 2 partitions to the physical cores of a
parallel machine. The :doc:`processors <processors>` command has
options to support this, and strategies are discussed in :doc:`Section
5 <Speed>` of the manual.
----------
@ -295,10 +296,10 @@ except for round-off and precision issues.
You can specify *respa/omp* explicitly in your input script, or you
can use the :doc:`-suffix command-line switch <Run_options>` when you
invoke LAMMPS, or you can use the :doc:`suffix <suffix>` command in your
input script.
invoke LAMMPS, or you can use the :doc:`suffix <suffix>` command in
your input script.
See the :doc:`Speed packages <Speed_packages>` page for more
See the :doc:`Accelerator packages <Speed_packages>` page for more
instructions on how to use the accelerated styles effectively.
----------
@ -308,7 +309,8 @@ Restrictions
The *verlet/split* style can only be used if LAMMPS was built with the
REPLICA package. Correspondingly the *respa/omp* style is available
only if the OPENMP package was included. See the :doc:`Build package <Build_package>` page for more info.
only if the OPENMP package was included. See the :doc:`Build package
<Build_package>` page for more info.
Whenever using rRESPA, the user should experiment with trade-offs in
speed and accuracy for their system, and verify that they are

4
doc/utils/check-styles.py
View File

@ -254,7 +254,7 @@ for command_type, entries in index.items():
print("Total number of style index entries:", total_index)
skip_fix = ('python', 'NEIGH_HISTORY/omp','qeq/reax','reax/c/bonds','reax/c/species')
skip_fix = ('python', 'NEIGH_HISTORY/omp','acks2/reax','qeq/reax','reax/c/bonds','reax/c/species')
skip_pair = ('meam/c','lj/sf','reax/c')
counter = 0
@ -282,7 +282,7 @@ if counter:
counter = 0
counter += check_style_index("compute", compute, index["compute"])
counter += check_style_index("fix", fix, index["fix"], skip=['python','qeq/reax','reax/c/bonds','reax/c/species'])
counter += check_style_index("fix", fix, index["fix"], skip=['python','acks2/reax','qeq/reax','reax/c/bonds','reax/c/species'])
counter += check_style_index("angle_style", angle, index["angle_style"])
counter += check_style_index("bond_style", bond, index["bond_style"])
counter += check_style_index("dihedral_style", dihedral, index["dihedral_style"])

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

@ -19,6 +19,7 @@ accuracies
ach
ackland
Ackland
acks
acolor
acos
Acta
@ -77,6 +78,7 @@ allocators
allosws
AlO
Alonso
Alperen
alphak
alphashrink
amap
@ -685,6 +687,7 @@ diagonalized
diagonalizers
diagonalizing
Diallo
diblock
Dickel
diel
differentiable
@ -1254,6 +1257,7 @@ hbond
hcp
hdnnp
HDNNP
Hearn
heatconduction
Hebbeker
Hebenstreit
@ -1280,6 +1284,7 @@ hgrid
hhmrr
Hibbs
Higdon
hiID
Hijazi
Hilger
Hinestrosa
@ -1776,6 +1781,7 @@ Loewen
logfile
logfreq
logicals
loID
Lomdahl
Lond
lookup
@ -3080,6 +3086,7 @@ Spearot
specular
spellcheck
Spellmeyer
Speybroeck
sph
SPH
Spickermann
@ -3493,6 +3500,7 @@ Verlag
verlet
Verlet
versa
Verstraelen
ves
vflag
vhi
@ -3559,6 +3567,7 @@ vzcm
vzi
Waals
Wadley
Waroquier
wallstyle
walltime
Waltham

2
examples/README
View File

@ -75,7 +75,6 @@ eim: NaCl using the EIM potential
ellipse: ellipsoidal particles in spherical solvent, 2d system
flow: Couette and Poiseuille flow in a 2d channel
friction: frictional contact of spherical asperities between 2d surfaces
gcmc: Grand Canonical MC with fix gcmc, Widom insertion with fix widom
gjf: use of fix langevin Gronbech-Jensen/Farago option
granregion: use of fix wall/region/gran as boundary on granular particles
hugoniostat: Hugoniostat shock dynamics
@ -83,6 +82,7 @@ hyper: global and local hyperdynamics of diffusion on Pt surface
indent: spherical indenter into a 2d solid
kim: use of potentials in Knowledge Base for Interatomic Models (KIM)
latte: use of LATTE density-functional tight-binding quantum code
mc: MC package models: GCMC, Widom, fix mol/swap
meam: MEAM test for SiC and shear (same as shear examples)
melt: rapid melt of 3d LJ system
message: client/server coupling of 2 codes

0
examples/gcmc/CO2.txt → examples/mc/CO2.txt
View File

0
examples/gcmc/H2O.txt → examples/mc/H2O.txt
View File

11733
examples/mc/data.bead Normal file
View File

File diff suppressed because it is too large Load Diff

0
examples/gcmc/data.spce → examples/mc/data.spce
View File

0
examples/gcmc/data.widom.lj → examples/mc/data.widom.lj
View File

0
examples/gcmc/in.gcmc.co2 → examples/mc/in.gcmc.co2
View File

0
examples/gcmc/in.gcmc.h2o → examples/mc/in.gcmc.h2o
View File

0
examples/gcmc/in.gcmc.lj → examples/mc/in.gcmc.lj
View File

44
examples/mc/in.mixed Normal file
View File

@ -0,0 +1,44 @@
# test script for fix mol/swap
# initial system is 50/50 chains of type 1 and type 2
# b/c epsilon12 is set to 1.02 (weakly same as 1/1 or 1/2) the
# system will stay in equilibrium as a mix of both chain types
# fix mol/swap helps this happen quickly
# see the last 2 columns of thermo output for counts of 2 chain types
units lj
atom_style angle
neighbor 0.36 bin
neigh_modify delay 0
pair_style lj/cut 1.1224620483
bond_style fene
angle_style cosine
special_bonds lj 0.0 1.0 1.0
read_data data.bead
pair_coeff * * 1.0 1.0 1.1224620483
pair_coeff 1 2 1.02 1.0 1.1224620483
bond_coeff 1 30.0 1.5 1.0 1.0
angle_coeff 1 1.500
pair_modify shift yes
variable vt1 atom type==1
variable vt2 atom type==2
group g1 dynamic all var vt1 every 100
group g2 dynamic all var vt2 every 100
variable count1 equal count(g1)
variable count2 equal count(g2)
timestep 0.010
fix 1 all langevin 1.0 1.0 100.0 702547
fix 2 all nve
fix 3 all mol/swap 100 1 1 2 482794 1.0
compute p all pressure thermo_temp
thermo 1000
thermo_style custom step temp etotal press f_3[1] f_3[2] v_count1 v_count2
run 50000

44
examples/mc/in.pure Normal file
View File

@ -0,0 +1,44 @@
# test script for fix mol/swap
# initial system is 50/50 chains of type 1 and type 2
# b/c epsilon12 is set to 1.1 (stronger than 1/1 or 2/2) the
# system will go to equilibrium as mostly one type or the other
# fix mol/swap helps this happen quickly
# see the last 2 columns of thermo output for counts of 2 chain types
units lj
atom_style angle
neighbor 0.36 bin
neigh_modify delay 0
pair_style lj/cut 1.1224620483
bond_style fene
angle_style cosine
special_bonds lj 0.0 1.0 1.0
read_data data.bead
pair_coeff * * 1.0 1.0 1.1224620483
pair_coeff 1 2 1.1 1.0 1.1224620483
bond_coeff 1 30.0 1.5 1.0 1.0
angle_coeff 1 1.500
pair_modify shift yes
variable vt1 atom type==1
variable vt2 atom type==2
group g1 dynamic all var vt1 every 100
group g2 dynamic all var vt2 every 100
variable count1 equal count(g1)
variable count2 equal count(g2)
timestep 0.010
fix 1 all langevin 1.0 1.0 100.0 702547
fix 2 all nve
fix 3 all mol/swap 100 1 1 2 482794 1.0
compute p all pressure thermo_temp
thermo 1000
thermo_style custom step temp etotal press f_3[1] f_3[2] v_count1 v_count2
run 50000

0
examples/gcmc/in.widom.lj → examples/mc/in.widom.lj
View File

0
examples/gcmc/in.widom.spce → examples/mc/in.widom.spce
View File

164
examples/mc/log.13Oct21.mixed.g++.4 Normal file
View File

@ -0,0 +1,164 @@
LAMMPS (29 Sep 2021)
# test script for fix mol/swap
# initial system is 50/50 chains of type 1 and type 2
# b/c epsilon12 is set to 1.02 (weakly same as 1/1 or 1/2) the
# system will stay in equilibrium as a mix of both chain types
# fix mol/swap helps this happen quickly
# see the last 2 columns of thermo output for counts of 2 chain types
units lj
atom_style angle
neighbor 0.36 bin
neigh_modify delay 0
pair_style lj/cut 1.1224620483
bond_style fene
angle_style cosine
special_bonds lj 0.0 1.0 1.0
read_data data.bead
Reading data file ...
orthogonal box = (-8.2115700 -8.2115700 -8.2115700) to (8.2115700 8.2115700 8.2115700)
1 by 2 by 2 MPI processor grid
reading atoms ...
4000 atoms
scanning bonds ...
1 = max bonds/atom
scanning angles ...
1 = max angles/atom
reading bonds ...
3900 bonds
reading angles ...
3800 angles
Finding 1-2 1-3 1-4 neighbors ...
special bond factors lj: 0 1 1
special bond factors coul: 0 0 0
2 = max # of 1-2 neighbors
2 = max # of 1-3 neighbors
4 = max # of 1-4 neighbors
6 = max # of special neighbors
special bonds CPU = 0.001 seconds
read_data CPU = 0.028 seconds
pair_coeff * * 1.0 1.0 1.1224620483
pair_coeff 1 2 1.02 1.0 1.1224620483
bond_coeff 1 30.0 1.5 1.0 1.0
angle_coeff 1 1.500
pair_modify shift yes
variable vt1 atom type==1
variable vt2 atom type==2
group g1 dynamic all var vt1 every 100
dynamic group g1 defined
group g2 dynamic all var vt2 every 100
dynamic group g2 defined
variable count1 equal count(g1)
variable count2 equal count(g2)
timestep 0.010
fix 1 all langevin 1.0 1.0 100.0 702547
fix 2 all nve
fix 3 all mol/swap 100 1 1 2 482794 1.0
compute p all pressure thermo_temp
thermo 1000
thermo_style custom step temp etotal press f_3[1] f_3[2] v_count1 v_count2
run 50000
Neighbor list info ...
update every 1 steps, delay 0 steps, check yes
max neighbors/atom: 2000, page size: 100000
master list distance cutoff = 1.482462
ghost atom cutoff = 1.482462
binsize = 0.74123102, bins = 23 23 23
1 neighbor lists, perpetual/occasional/extra = 1 0 0
(1) pair lj/cut, perpetual
attributes: half, newton on
pair build: half/bin/newton
stencil: half/bin/3d
bin: standard
WARNING: Communication cutoff 1.4824620483 is shorter than a bond length based estimate of 1.815. This may lead to errors. (../comm.cpp:728)
Per MPI rank memory allocation (min/avg/max) = 5.313 | 5.314 | 5.314 Mbytes
Step Temp TotEng Press f_3[1] f_3[2] v_count1 v_count2
0 0 21.451627 5.079399 0 0 2000 2000
1000 0.49011138 21.59359 4.2337989 10 10 2000 2000
2000 0.55288866 21.724374 4.4596786 20 20 2080 1920
3000 0.59299724 21.844178 4.6112243 30 29 2280 1720
4000 0.64746348 21.964318 4.9463669 40 39 2280 1720
5000 0.67853936 22.053147 5.1950218 50 48 2320 1680
6000 0.70751144 22.147453 5.0636869 60 58 2240 1760
7000 0.73570064 22.233705 5.4872622 70 68 2160 1840
8000 0.7677554 22.312938 5.4283736 80 77 2360 1640
9000 0.78493237 22.383155 5.8547233 90 87 2440 1560
10000 0.80634514 22.449402 5.8785731 100 96 2400 1600
11000 0.82563194 22.475286 5.8193738 110 104 2400 1600
12000 0.81684024 22.527492 6.0323967 120 114 2320 1680
13000 0.84497155 22.567888 6.0488755 130 122 2240 1760
14000 0.85452242 22.606908 6.1983634 140 132 2080 1920
15000 0.88109242 22.654336 6.1408279 150 141 1960 2040
16000 0.88925915 22.707597 6.1560975 160 150 2000 2000
17000 0.91598439 22.762791 6.1071728 170 160 2000 2000
18000 0.92453211 22.778304 6.3330693 180 170 2240 1760
19000 0.92839551 22.797316 6.2917909 190 180 2000 2000
20000 0.93054033 22.819289 6.091701 200 189 2200 1800
21000 0.93955351 22.844135 6.5833013 210 198 2000 2000
22000 0.94454858 22.856272 6.5661753 220 207 2200 1800
23000 0.95446407 22.878735 6.5957294 230 216 2160 1840
24000 0.94748257 22.894539 6.6187447 240 226 1920 2080
25000 0.95732202 22.912292 6.4795471 250 236 1680 2320
26000 0.96970172 22.908988 6.537366 260 245 1720 2280
27000 0.96032166 22.924899 6.6238248 270 255 1960 2040
28000 0.96197769 22.9358 6.8926097 280 264 1920 2080
29000 0.98745595 22.964694 6.5839025 290 271 2040 1960
30000 0.99264869 22.947884 6.3893499 300 280 1920 2080
31000 0.96953069 22.957927 6.6616047 310 289 1800 2200
32000 0.99955117 22.963979 6.5958456 320 298 1680 2320
33000 0.97090103 22.969029 6.9087296 330 307 1800 2200
34000 0.99818457 22.988477 6.6471994 340 316 1920 2080
35000 0.9965288 22.992883 6.9691785 350 325 2040 1960
36000 0.99533174 22.983774 6.6585089 360 334 2000 2000
37000 0.98819278 22.995387 6.618802 370 344 2080 1920
38000 0.99598576 22.991892 6.7536669 380 354 2080 1920
39000 0.99312702 22.989239 6.4028165 390 364 2080 1920
40000 1.0035821 23.001944 6.9307671 400 374 1920 2080
41000 0.99914733 23.00134 6.6251677 410 383 1880 2120
42000 0.98054536 22.981781 6.5918554 420 393 1880 2120
43000 0.99413829 23.008 6.7390795 430 403 1720 2280
44000 0.98867961 23.00521 6.8505543 440 412 1600 2400
45000 0.99626811 23.019995 6.827741 450 421 1640 2360
46000 1.0186043 23.020759 6.6195562 460 430 1680 2320
47000 1.0121335 23.019271 6.6022102 470 439 1800 2200
48000 0.99883756 23.013973 6.5255522 480 448 1920 2080
49000 0.99425223 23.022708 6.609746 490 458 2240 1760
50000 0.99505489 23.012641 6.4592863 500 468 2240 1760
Loop time of 19.4175 on 4 procs for 50000 steps with 4000 atoms
Performance: 2224796.830 tau/day, 2574.996 timesteps/s
95.0% CPU use with 4 MPI tasks x no OpenMP threads
MPI task timing breakdown:
Section | min time | avg time | max time |%varavg| %total
---------------------------------------------------------------
Pair | 2.5467 | 2.6684 | 2.7896 | 6.3 | 13.74
Bond | 2.3037 | 2.4117 | 2.5085 | 5.3 | 12.42
Neigh | 7.3597 | 7.3633 | 7.3673 | 0.1 | 37.92
Comm | 3.0482 | 3.2694 | 3.4997 | 10.2 | 16.84
Output | 0.0014609 | 0.0017069 | 0.0021793 | 0.7 | 0.01
Modify | 2.9624 | 3.0581 | 3.1424 | 4.7 | 15.75
Other | | 0.6447 | | | 3.32
Nlocal: 1000.00 ave 1013 max 986 min
Histogram: 1 0 0 1 0 0 0 1 0 1
Nghost: 1186.25 ave 1198 max 1178 min
Histogram: 2 0 0 0 0 0 1 0 0 1
Neighs: 4927.00 ave 5028 max 4790 min
Histogram: 1 0 0 0 0 1 0 1 0 1
Total # of neighbors = 19708
Ave neighs/atom = 4.9270000
Ave special neighs/atom = 5.7000000
Neighbor list builds = 10721
Dangerous builds = 0
Total wall time: 0:00:19

164
examples/mc/log.13Oct21.pure.g++.4 Normal file
View File

@ -0,0 +1,164 @@
LAMMPS (29 Sep 2021)
# test script for fix mol/swap
# initial system is 50/50 chains of type 1 and type 2
# b/c epsilon12 is set to 1.1 (stronger than 1/1 or 2/2) the
# system will go to equilibrium as mostly one type or the other
# fix mol/swap helps this happen quickly
# see the last 2 columns of thermo output for counts of 2 chain types
units lj
atom_style angle
neighbor 0.36 bin
neigh_modify delay 0
pair_style lj/cut 1.1224620483
bond_style fene
angle_style cosine
special_bonds lj 0.0 1.0 1.0
read_data data.bead
Reading data file ...
orthogonal box = (-8.2115700 -8.2115700 -8.2115700) to (8.2115700 8.2115700 8.2115700)
1 by 2 by 2 MPI processor grid
reading atoms ...
4000 atoms
scanning bonds ...
1 = max bonds/atom
scanning angles ...
1 = max angles/atom
reading bonds ...
3900 bonds
reading angles ...
3800 angles
Finding 1-2 1-3 1-4 neighbors ...
special bond factors lj: 0 1 1
special bond factors coul: 0 0 0
2 = max # of 1-2 neighbors
2 = max # of 1-3 neighbors
4 = max # of 1-4 neighbors
6 = max # of special neighbors
special bonds CPU = 0.001 seconds
read_data CPU = 0.034 seconds
pair_coeff * * 1.0 1.0 1.1224620483
pair_coeff 1 2 1.1 1.0 1.1224620483
bond_coeff 1 30.0 1.5 1.0 1.0
angle_coeff 1 1.500
pair_modify shift yes
variable vt1 atom type==1
variable vt2 atom type==2
group g1 dynamic all var vt1 every 100
dynamic group g1 defined
group g2 dynamic all var vt2 every 100
dynamic group g2 defined
variable count1 equal count(g1)
variable count2 equal count(g2)
timestep 0.010
fix 1 all langevin 1.0 1.0 100.0 702547
fix 2 all nve
fix 3 all mol/swap 100 1 1 2 482794 1.0
compute p all pressure thermo_temp
thermo 1000
thermo_style custom step temp etotal press f_3[1] f_3[2] v_count1 v_count2
run 50000
Neighbor list info ...
update every 1 steps, delay 0 steps, check yes
max neighbors/atom: 2000, page size: 100000
master list distance cutoff = 1.482462
ghost atom cutoff = 1.482462
binsize = 0.74123102, bins = 23 23 23
1 neighbor lists, perpetual/occasional/extra = 1 0 0
(1) pair lj/cut, perpetual
attributes: half, newton on
pair build: half/bin/newton
stencil: half/bin/3d
bin: standard
WARNING: Communication cutoff 1.4824620483 is shorter than a bond length based estimate of 1.815. This may lead to errors. (../comm.cpp:728)
Per MPI rank memory allocation (min/avg/max) = 5.313 | 5.314 | 5.314 Mbytes
Step Temp TotEng Press f_3[1] f_3[2] v_count1 v_count2
0 0 21.4699 5.230121 0 0 2000 2000
1000 0.50228459 21.61044 4.3659303 10 9 1960 2040
2000 0.55721903 21.75955 4.5695439 20 17 1960 2040
3000 0.61139287 21.892943 4.6514755 30 26 2240 1760
4000 0.65767189 22.002303 5.1854503 40 33 2280 1720
5000 0.69383416 22.110271 5.3803498 50 41 2280 1720
6000 0.72692038 22.205887 5.1756569 60 49 2280 1720
7000 0.77151336 22.306777 5.5743555 70 56 2240 1760
8000 0.78606858 22.37036 5.7745208 80 64 2560 1440
9000 0.79363653 22.420931 5.7369418 90 71 2680 1320
10000 0.82352629 22.488759 6.0238896 100 76 2720 1280
11000 0.83867685 22.534887 6.1263771 110 82 2800 1200
12000 0.85335127 22.590281 6.1499954 120 86 2800 1200
13000 0.86430985 22.632068 6.1654016 130 89 2760 1240
14000 0.88057592 22.680253 6.2162735 140 94 2800 1200
15000 0.89326694 22.719731 6.4789839 150 97 2760 1240
16000 0.90667644 22.737367 6.214481 160 101 2760 1240
17000 0.91190336 22.758572 6.2293336 170 105 2600 1400
18000 0.93182455 22.782019 6.2865382 180 111 2680 1320
19000 0.93002139 22.797048 6.5579988 190 117 2600 1400
20000 0.92396243 22.796108 6.6207461 200 122 2800 1200
21000 0.92949808 22.802813 6.3753268 210 125 2920 1080
22000 0.93415719 22.807112 6.4696121 220 130 3040 960
23000 0.9214833 22.82116 6.4146288 230 131 3080 920
24000 0.95693685 22.839738 6.4035728 240 135 2920 1080
25000 0.95421851 22.865199 6.4510751 250 138 2880 1120
26000 0.95476555 22.878082 6.4652888 260 145 3000 1000
27000 0.95773535 22.880671 6.757952 270 149 3000 1000
28000 0.95405332 22.896053 6.7425175 280 155 3080 920
29000 0.95955713 22.904144 6.6672832 290 161 3240 760
30000 0.95521498 22.886699 6.6197941 300 164 3360 640
31000 0.96431176 22.91094 6.6373887 310 168 3440 560
32000 0.96592495 22.903679 6.4245884 320 172 3520 480
33000 0.96457971 22.922681 6.6987987 330 175 3480 520
34000 0.96541889 22.92116 6.5992755 340 178 3600 400
35000 0.96892691 22.923361 6.7973298 350 178 3600 400
36000 0.97267726 22.923431 6.6577403 360 179 3640 360
37000 0.97514714 22.939979 6.4028068 370 183 3640 360
38000 0.98638599 22.952022 6.6518868 380 183 3640 360
39000 0.97864891 22.962534 6.3906837 390 184 3680 320
40000 0.9933016 22.975785 6.6819613 400 185 3720 280
41000 0.9861477 22.977271 6.6747347 410 187 3800 200
42000 0.98157369 22.963129 6.830028 420 187 3800 200
43000 0.98202452 22.966947 6.5257905 430 187 3800 200
44000 0.99540503 22.971262 6.5546513 440 187 3800 200
45000 0.98433653 22.978028 6.4316725 450 189 3800 200
46000 0.97912775 22.981328 6.9139851 460 189 3800 200
47000 0.9791927 22.981131 6.6417971 470 190 3840 160
48000 0.99601024 22.998536 6.6756953 480 191 3880 120
49000 0.99589958 22.998489 6.9262843 490 191 3880 120
50000 0.99294715 23.00399 6.6976013 500 192 3920 80
Loop time of 19.5161 on 4 procs for 50000 steps with 4000 atoms
Performance: 2213556.537 tau/day, 2561.987 timesteps/s
95.0% CPU use with 4 MPI tasks x no OpenMP threads
MPI task timing breakdown:
Section | min time | avg time | max time |%varavg| %total
---------------------------------------------------------------
Pair | 2.6256 | 2.7183 | 2.8265 | 5.2 | 13.93
Bond | 2.3363 | 2.4406 | 2.5197 | 4.8 | 12.51
Neigh | 7.382 | 7.3884 | 7.3936 | 0.2 | 37.86
Comm | 3.014 | 3.2136 | 3.3994 | 9.4 | 16.47
Output | 0.0014574 | 0.0017086 | 0.0020613 | 0.5 | 0.01
Modify | 3.0282 | 3.1295 | 3.2034 | 4.1 | 16.04
Other | | 0.624 | | | 3.20
Nlocal: 1000.00 ave 1011 max 993 min
Histogram: 2 0 0 0 0 1 0 0 0 1
Nghost: 1187.25 ave 1202 max 1179 min
Histogram: 2 0 0 1 0 0 0 0 0 1
Neighs: 4939.25 ave 5067 max 4850 min
Histogram: 1 0 0 2 0 0 0 0 0 1
Total # of neighbors = 19757
Ave neighs/atom = 4.9392500
Ave special neighs/atom = 5.7000000
Neighbor list builds = 10714
Dangerous builds = 0
Total wall time: 0:00:19

0
examples/gcmc/log.27Nov18.gcmc.h2o.g++.1 → examples/mc/log.27Nov18.gcmc.h2o.g++.1
View File

0
examples/gcmc/log.27Nov18.gcmc.lj.g++.1 → examples/mc/log.27Nov18.gcmc.lj.g++.1
View File

0
examples/gcmc/log.27Nov18.gcmc.lj.g++.4 → examples/mc/log.27Nov18.gcmc.lj.g++.4
View File

0
examples/gcmc/log.30Jun20.widom.lj.g++.1 → examples/mc/log.30Jun20.widom.lj.g++.1
View File

0
examples/gcmc/log.30Jun20.widom.lj.g++.4 → examples/mc/log.30Jun20.widom.lj.g++.4
View File

0
examples/gcmc/log.30Jun20.widom.spce.g++.1 → examples/mc/log.30Jun20.widom.spce.g++.1
View File

0
examples/gcmc/log.31Mar21.gcmc.co2.g++.1 → examples/mc/log.31Mar21.gcmc.co2.g++.1
View File

1
examples/reaxff/water/acks2_ff.water Symbolic link
View File

@ -0,0 +1 @@
../../../potentials/acks2_ff.water

3016
examples/reaxff/water/data.water Normal file
View File

File diff suppressed because it is too large Load Diff

29
examples/reaxff/water/in.water.acks2 Normal file
View File

@ -0,0 +1,29 @@
# ACKS2 Water, CITE: Achtyl et al., Nat. Comm., 6 6539 (2015)
boundary p p p
units real
atom_style charge
read_data data.water
variable x index 1
variable y index 1
variable z index 1
replicate $x $y $z
pair_style reaxff NULL safezone 3.0 mincap 150
pair_coeff * * acks2_ff.water O H
neighbor 0.5 bin
neigh_modify every 1 delay 0 check yes
velocity all create 300.0 4928459 rot yes dist gaussian
fix 1 all acks2/reaxff 1 0.0 10.0 1.0e-6 reaxff maxiter 1000
fix 2 all nvt temp 300 300 50.0
timestep 0.5
thermo 10
thermo_style custom step temp press density vol
run 20

31
examples/reaxff/water/in.water.acks2.field Normal file
View File

@ -0,0 +1,31 @@
# ACKS2 Water, CITE: Achtyl et al., Nat. Comm., 6 6539 (2015)
boundary p p s
units real
atom_style charge
read_data data.water
variable x index 1
variable y index 1
variable z index 1
replicate $x $y $z
pair_style reaxff NULL safezone 3.0 mincap 150
pair_coeff * * acks2_ff.water O H
neighbor 0.5 bin
neigh_modify every 1 delay 0 check yes
velocity all create 300.0 4928459 rot yes dist gaussian
fix 1 all acks2/reaxff 1 0.0 10.0 1.0e-6 reaxff maxiter 1000
fix 2 all nvt temp 300 300 50.0
fix 3 all efield 0.0 0.0 1.0
fix 4 all wall/reflect zlo EDGE zhi EDGE
timestep 0.5
thermo 10
thermo_style custom step temp press density vol
run 20

29
examples/reaxff/water/in.water.qeq Normal file
View File

@ -0,0 +1,29 @@
# QEq Water, CITE: Achtyl et al., Nat. Comm., 6 6539 (2015)
boundary p p p
units real
atom_style charge
read_data data.water
variable x index 1
variable y index 1
variable z index 1
replicate $x $y $z
pair_style reaxff NULL safezone 3.0 mincap 150
pair_coeff * * qeq_ff.water O H
neighbor 0.5 bin
neigh_modify every 1 delay 0 check yes
velocity all create 300.0 4928459 rot yes dist gaussian
fix 1 all qeq/reaxff 1 0.0 10.0 1.0e-6 reaxff maxiter 400
fix 2 all nvt temp 300 300 50.0
timestep 0.5
thermo 10
thermo_style custom step temp press density vol
run 20

31
examples/reaxff/water/in.water.qeq.field Normal file
View File

@ -0,0 +1,31 @@
# QEq Water, CITE: Achtyl et al., Nat. Comm., 6 6539 (2015)
boundary p p s
units real
atom_style charge
read_data data.water
variable x index 1
variable y index 1
variable z index 1
replicate $x $y $z
pair_style reaxff NULL safezone 3.0 mincap 150
pair_coeff * * qeq_ff.water O H
neighbor 0.5 bin
neigh_modify every 1 delay 0 check yes
velocity all create 300.0 4928459 rot yes dist gaussian
fix 1 all qeq/reaxff 1 0.0 10.0 1.0e-6 reaxff maxiter 400
fix 2 all nvt temp 300 300 50.0
fix 3 all efield 0.0 0.0 1.0
fix 4 all wall/reflect zlo EDGE zhi EDGE
timestep 0.5
thermo 10
thermo_style custom step temp press density vol
run 20

129
examples/reaxff/water/log.13Oct21.reaxff.water-acks2-field.g++.1 Normal file
View File

@ -0,0 +1,129 @@
LAMMPS (29 Sep 2021)
# ACKS2 Water, CITE: Achtyl et al., Nat. Comm., 6 6539 (2015)
boundary p p s
units real
atom_style charge
read_data data.water
Reading data file ...
orthogonal box = (0.0000000 0.0000000 0.0000000) to (31.043046 31.043046 31.043046)
1 by 1 by 1 MPI processor grid
reading atoms ...
WARNING: Non-zero imageflag(s) in z direction for non-periodic boundary reset to zero (../atom.cpp:1208)
WARNING: Non-zero imageflag(s) in z direction for non-periodic boundary reset to zero (../atom.cpp:1208)
WARNING: Non-zero imageflag(s) in z direction for non-periodic boundary reset to zero (../atom.cpp:1208)
3000 atoms
read_data CPU = 0.010 seconds
variable x index 1
variable y index 1
variable z index 1
replicate $x $y $z
replicate 1 $y $z
replicate 1 1 $z
replicate 1 1 1
Replicating atoms ...
orthogonal box = (0.0000000 0.0000000 0.0012889577) to (31.043046 31.043046 31.045309)
1 by 1 by 1 MPI processor grid
3000 atoms
replicate CPU = 0.001 seconds
pair_style reaxff NULL safezone 3.0 mincap 150
pair_coeff * * acks2_ff.water O H
Reading potential file acks2_ff.water with DATE: 2021-09-21
WARNING: Changed valency_val to valency_boc for X (../reaxff_ffield.cpp:296)
neighbor 0.5 bin
neigh_modify every 1 delay 0 check yes
velocity all create 300.0 4928459 rot yes dist gaussian
fix 1 all acks2/reaxff 1 0.0 10.0 1.0e-6 reaxff maxiter 1000
fix 2 all nvt temp 300 300 50.0
fix 3 all efield 0.0 0.0 1.0
fix 4 all wall/reflect zlo EDGE zhi EDGE
timestep 0.5
thermo 10
thermo_style custom step temp press density vol
run 20
CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE
Your simulation uses code contributions which should be cited:
- pair reaxff command:
@Article{Aktulga12,
author = {H. M. Aktulga, J. C. Fogarty, S. A. Pandit, A. Y. Grama},
title = {Parallel reactive molecular dynamics: Numerical methods and algorithmic techniques},
journal = {Parallel Computing},
year = 2012,
volume = 38,
pages = {245--259}
}
- fix acks2/reaxff command:
@Article{O'Hearn2020,
author = {K. A. O'Hearn, A. Alperen, and H. M. Aktulga},
title = {Fast Solvers for Charge Distribution Models on Shared Memory Platforms},
journal = {SIAM J. Sci. Comput.},
year = 2020,
volume = 42,
pages = {1--22}
}
CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE
Neighbor list info ...
update every 1 steps, delay 0 steps, check yes
max neighbors/atom: 2000, page size: 100000
master list distance cutoff = 10.5
ghost atom cutoff = 10.5
binsize = 5.25, bins = 6 6 6
2 neighbor lists, perpetual/occasional/extra = 2 0 0
(1) pair reaxff, perpetual
attributes: half, newton off, ghost
pair build: half/bin/newtoff/ghost
stencil: full/ghost/bin/3d
bin: standard
(2) fix acks2/reaxff, perpetual, copy from (1)
attributes: half, newton off, ghost
pair build: copy
stencil: none
bin: none
Per MPI rank memory allocation (min/avg/max) = 361.2 | 361.2 | 361.2 Mbytes
Step Temp Press Density Volume
0 300 -20762.954 0.99996859 29916.212
10 396.27588 -18423.747 1.0000143 29914.844
20 518.59361 -10010.691 1.0000209 29914.647
Loop time of 29.8896 on 1 procs for 20 steps with 3000 atoms
Performance: 0.029 ns/day, 830.268 hours/ns, 0.669 timesteps/s
100.0% CPU use with 1 MPI tasks x no OpenMP threads
MPI task timing breakdown:
Section | min time | avg time | max time |%varavg| %total
---------------------------------------------------------------
Pair | 11.611 | 11.611 | 11.611 | 0.0 | 38.85
Neigh | 0.6729 | 0.6729 | 0.6729 | 0.0 | 2.25
Comm | 0.0020791 | 0.0020791 | 0.0020791 | 0.0 | 0.01
Output | 0.00015777 | 0.00015777 | 0.00015777 | 0.0 | 0.00
Modify | 17.602 | 17.602 | 17.602 | 0.0 | 58.89
Other | | 0.001149 | | | 0.00
Nlocal: 3000.00 ave 3000 max 3000 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Nghost: 5438.00 ave 5438 max 5438 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Neighs: 787357.0 ave 787357 max 787357 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Total # of neighbors = 787357
Ave neighs/atom = 262.45233
Neighbor list builds = 7
Dangerous builds = 0
Total wall time: 0:00:32

129
examples/reaxff/water/log.13Oct21.reaxff.water-acks2-field.g++.4 Normal file
View File

@ -0,0 +1,129 @@
LAMMPS (29 Sep 2021)
# ACKS2 Water, CITE: Achtyl et al., Nat. Comm., 6 6539 (2015)
boundary p p s
units real
atom_style charge
read_data data.water
Reading data file ...
orthogonal box = (0.0000000 0.0000000 0.0000000) to (31.043046 31.043046 31.043046)
1 by 2 by 2 MPI processor grid
reading atoms ...
WARNING: Non-zero imageflag(s) in z direction for non-periodic boundary reset to zero (../atom.cpp:1208)
WARNING: Non-zero imageflag(s) in z direction for non-periodic boundary reset to zero (../atom.cpp:1208)
WARNING: Non-zero imageflag(s) in z direction for non-periodic boundary reset to zero (../atom.cpp:1208)
3000 atoms
read_data CPU = 0.011 seconds
variable x index 1
variable y index 1
variable z index 1
replicate $x $y $z
replicate 1 $y $z
replicate 1 1 $z
replicate 1 1 1
Replicating atoms ...
orthogonal box = (0.0000000 0.0000000 0.0012889577) to (31.043046 31.043046 31.045309)
2 by 1 by 2 MPI processor grid
3000 atoms
replicate CPU = 0.001 seconds
pair_style reaxff NULL safezone 3.0 mincap 150
pair_coeff * * acks2_ff.water O H
Reading potential file acks2_ff.water with DATE: 2021-09-21
WARNING: Changed valency_val to valency_boc for X (../reaxff_ffield.cpp:296)
neighbor 0.5 bin
neigh_modify every 1 delay 0 check yes
velocity all create 300.0 4928459 rot yes dist gaussian
fix 1 all acks2/reaxff 1 0.0 10.0 1.0e-6 reaxff maxiter 1000
fix 2 all nvt temp 300 300 50.0
fix 3 all efield 0.0 0.0 1.0
fix 4 all wall/reflect zlo EDGE zhi EDGE
timestep 0.5
thermo 10
thermo_style custom step temp press density vol
run 20
CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE
Your simulation uses code contributions which should be cited:
- pair reaxff command:
@Article{Aktulga12,
author = {H. M. Aktulga, J. C. Fogarty, S. A. Pandit, A. Y. Grama},
title = {Parallel reactive molecular dynamics: Numerical methods and algorithmic techniques},
journal = {Parallel Computing},
year = 2012,
volume = 38,
pages = {245--259}
}
- fix acks2/reaxff command:
@Article{O'Hearn2020,
author = {K. A. O'Hearn, A. Alperen, and H. M. Aktulga},
title = {Fast Solvers for Charge Distribution Models on Shared Memory Platforms},
journal = {SIAM J. Sci. Comput.},
year = 2020,
volume = 42,
pages = {1--22}
}
CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE
Neighbor list info ...
update every 1 steps, delay 0 steps, check yes
max neighbors/atom: 2000, page size: 100000
master list distance cutoff = 10.5
ghost atom cutoff = 10.5
binsize = 5.25, bins = 6 6 6
2 neighbor lists, perpetual/occasional/extra = 2 0 0
(1) pair reaxff, perpetual
attributes: half, newton off, ghost
pair build: half/bin/newtoff/ghost
stencil: full/ghost/bin/3d
bin: standard
(2) fix acks2/reaxff, perpetual, copy from (1)
attributes: half, newton off, ghost
pair build: copy
stencil: none
bin: none
Per MPI rank memory allocation (min/avg/max) = 198.5 | 199.3 | 199.9 Mbytes
Step Temp Press Density Volume
0 300 -20761.724 0.99996859 29916.212
10 396.27588 -18420.441 1.0000144 29914.843
20 518.59146 -10012.622 1.0000207 29914.652
Loop time of 11.3556 on 4 procs for 20 steps with 3000 atoms
Performance: 0.076 ns/day, 315.433 hours/ns, 1.761 timesteps/s
94.3% CPU use with 4 MPI tasks x no OpenMP threads
MPI task timing breakdown:
Section | min time | avg time | max time |%varavg| %total
---------------------------------------------------------------
Pair | 3.7511 | 3.8123 | 3.9245 | 3.4 | 33.57
Neigh | 0.36492 | 0.3767 | 0.39023 | 1.5 | 3.32
Comm | 0.12022 | 0.23202 | 0.29307 | 13.8 | 2.04
Output | 8.0451e-05 | 0.00017452 | 0.00045489 | 0.0 | 0.00
Modify | 6.9172 | 6.9312 | 6.9431 | 0.4 | 61.04
Other | | 0.003189 | | | 0.03
Nlocal: 750.000 ave 758 max 737 min
Histogram: 1 0 0 0 0 0 1 0 1 1
Nghost: 4219.50 ave 4233 max 4198 min
Histogram: 1 0 0 0 1 0 0 0 0 2
Neighs: 230733.0 ave 233431 max 225531 min
Histogram: 1 0 0 0 0 0 0 0 2 1
Total # of neighbors = 922931
Ave neighs/atom = 307.64367
Neighbor list builds = 7
Dangerous builds = 0
Total wall time: 0:00:12

124
examples/reaxff/water/log.13Oct21.reaxff.water-acks2.g++.1 Normal file
View File

@ -0,0 +1,124 @@
LAMMPS (29 Sep 2021)
# ACKS2 Water, CITE: Achtyl et al., Nat. Comm., 6 6539 (2015)
boundary p p p
units real
atom_style charge
read_data data.water
Reading data file ...
orthogonal box = (0.0000000 0.0000000 0.0000000) to (31.043046 31.043046 31.043046)
1 by 1 by 1 MPI processor grid
reading atoms ...
3000 atoms
read_data CPU = 0.010 seconds
variable x index 1
variable y index 1
variable z index 1
replicate $x $y $z
replicate 1 $y $z
replicate 1 1 $z
replicate 1 1 1
Replicating atoms ...
orthogonal box = (0.0000000 0.0000000 0.0000000) to (31.043046 31.043046 31.043046)
1 by 1 by 1 MPI processor grid
3000 atoms
replicate CPU = 0.001 seconds
pair_style reaxff NULL safezone 3.0 mincap 150
pair_coeff * * acks2_ff.water O H
Reading potential file acks2_ff.water with DATE: 2021-09-21
WARNING: Changed valency_val to valency_boc for X (../reaxff_ffield.cpp:296)
neighbor 0.5 bin
neigh_modify every 1 delay 0 check yes
velocity all create 300.0 4928459 rot yes dist gaussian
fix 1 all acks2/reaxff 1 0.0 10.0 1.0e-6 reaxff maxiter 1000
fix 2 all nvt temp 300 300 50.0
timestep 0.5
thermo 10
thermo_style custom step temp press density vol
run 20
CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE
Your simulation uses code contributions which should be cited:
- pair reaxff command:
@Article{Aktulga12,
author = {H. M. Aktulga, J. C. Fogarty, S. A. Pandit, A. Y. Grama},
title = {Parallel reactive molecular dynamics: Numerical methods and algorithmic techniques},
journal = {Parallel Computing},
year = 2012,
volume = 38,
pages = {245--259}
}
- fix acks2/reaxff command:
@Article{O'Hearn2020,
author = {K. A. O'Hearn, A. Alperen, and H. M. Aktulga},
title = {Fast Solvers for Charge Distribution Models on Shared Memory Platforms},
journal = {SIAM J. Sci. Comput.},
year = 2020,
volume = 42,
pages = {1--22}
}
CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE
Neighbor list info ...
update every 1 steps, delay 0 steps, check yes
max neighbors/atom: 2000, page size: 100000
master list distance cutoff = 10.5
ghost atom cutoff = 10.5
binsize = 5.25, bins = 6 6 6
2 neighbor lists, perpetual/occasional/extra = 2 0 0
(1) pair reaxff, perpetual
attributes: half, newton off, ghost
pair build: half/bin/newtoff/ghost
stencil: full/ghost/bin/3d
bin: standard
(2) fix acks2/reaxff, perpetual, copy from (1)
attributes: half, newton off, ghost
pair build: copy
stencil: none
bin: none
Per MPI rank memory allocation (min/avg/max) = 574.5 | 574.5 | 574.5 Mbytes
Step Temp Press Density Volume
0 300 1572.3474 1 29915.273
10 300.61522 8252.7686 1 29915.273
20 294.7387 2502.6624 1 29915.273
Loop time of 25.9579 on 1 procs for 20 steps with 3000 atoms
Performance: 0.033 ns/day, 721.052 hours/ns, 0.770 timesteps/s
100.0% CPU use with 1 MPI tasks x no OpenMP threads
MPI task timing breakdown:
Section | min time | avg time | max time |%varavg| %total
---------------------------------------------------------------
Pair | 14.081 | 14.081 | 14.081 | 0.0 | 54.24
Neigh | 0.34284 | 0.34284 | 0.34284 | 0.0 | 1.32
Comm | 0.0027799 | 0.0027799 | 0.0027799 | 0.0 | 0.01
Output | 0.00012876 | 0.00012876 | 0.00012876 | 0.0 | 0.00
Modify | 11.53 | 11.53 | 11.53 | 0.0 | 44.42
Other | | 0.001007 | | | 0.00
Nlocal: 3000.00 ave 3000 max 3000 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Nghost: 11077.0 ave 11077 max 11077 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Neighs: 971815.0 ave 971815 max 971815 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Total # of neighbors = 971815
Ave neighs/atom = 323.93833
Neighbor list builds = 2
Dangerous builds = 0
Total wall time: 0:00:27

124
examples/reaxff/water/log.13Oct21.reaxff.water-acks2.g++.4 Normal file
View File

@ -0,0 +1,124 @@
LAMMPS (29 Sep 2021)
# ACKS2 Water, CITE: Achtyl et al., Nat. Comm., 6 6539 (2015)
boundary p p p
units real
atom_style charge
read_data data.water
Reading data file ...
orthogonal box = (0.0000000 0.0000000 0.0000000) to (31.043046 31.043046 31.043046)
1 by 2 by 2 MPI processor grid
reading atoms ...
3000 atoms
read_data CPU = 0.013 seconds
variable x index 1
variable y index 1
variable z index 1
replicate $x $y $z
replicate 1 $y $z
replicate 1 1 $z
replicate 1 1 1
Replicating atoms ...
orthogonal box = (0.0000000 0.0000000 0.0000000) to (31.043046 31.043046 31.043046)
1 by 2 by 2 MPI processor grid
3000 atoms
replicate CPU = 0.002 seconds
pair_style reaxff NULL safezone 3.0 mincap 150
pair_coeff * * acks2_ff.water O H
Reading potential file acks2_ff.water with DATE: 2021-09-21
WARNING: Changed valency_val to valency_boc for X (../reaxff_ffield.cpp:296)
neighbor 0.5 bin
neigh_modify every 1 delay 0 check yes
velocity all create 300.0 4928459 rot yes dist gaussian
fix 1 all acks2/reaxff 1 0.0 10.0 1.0e-6 reaxff maxiter 1000
fix 2 all nvt temp 300 300 50.0
timestep 0.5
thermo 10
thermo_style custom step temp press density vol
run 20
CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE
Your simulation uses code contributions which should be cited:
- pair reaxff command:
@Article{Aktulga12,
author = {H. M. Aktulga, J. C. Fogarty, S. A. Pandit, A. Y. Grama},
title = {Parallel reactive molecular dynamics: Numerical methods and algorithmic techniques},
journal = {Parallel Computing},
year = 2012,
volume = 38,
pages = {245--259}
}
- fix acks2/reaxff command:
@Article{O'Hearn2020,
author = {K. A. O'Hearn, A. Alperen, and H. M. Aktulga},
title = {Fast Solvers for Charge Distribution Models on Shared Memory Platforms},
journal = {SIAM J. Sci. Comput.},
year = 2020,
volume = 42,
pages = {1--22}
}
CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE
Neighbor list info ...
update every 1 steps, delay 0 steps, check yes
max neighbors/atom: 2000, page size: 100000
master list distance cutoff = 10.5
ghost atom cutoff = 10.5
binsize = 5.25, bins = 6 6 6
2 neighbor lists, perpetual/occasional/extra = 2 0 0
(1) pair reaxff, perpetual
attributes: half, newton off, ghost
pair build: half/bin/newtoff/ghost
stencil: full/ghost/bin/3d
bin: standard
(2) fix acks2/reaxff, perpetual, copy from (1)
attributes: half, newton off, ghost
pair build: copy
stencil: none
bin: none
Per MPI rank memory allocation (min/avg/max) = 271.9 | 273.6 | 275.1 Mbytes
Step Temp Press Density Volume
0 300 1572.3807 1 29915.273
10 300.6152 8252.4834 1 29915.273
20 294.73868 2502.5661 1 29915.273
Loop time of 11.1133 on 4 procs for 20 steps with 3000 atoms
Performance: 0.078 ns/day, 308.702 hours/ns, 1.800 timesteps/s
92.7% CPU use with 4 MPI tasks x no OpenMP threads
MPI task timing breakdown:
Section | min time | avg time | max time |%varavg| %total
---------------------------------------------------------------
Pair | 4.3609 | 4.7715 | 5.4812 | 19.5 | 42.94
Neigh | 0.15797 | 0.17176 | 0.19405 | 3.5 | 1.55
Comm | 0.21014 | 0.922 | 1.3353 | 44.6 | 8.30
Output | 8.815e-05 | 0.0002 | 0.00030501 | 0.0 | 0.00
Modify | 5.2267 | 5.2468 | 5.2584 | 0.5 | 47.21
Other | | 0.001074 | | | 0.01
Nlocal: 750.000 ave 760 max 735 min
Histogram: 1 0 0 0 1 0 0 0 0 2
Nghost: 6231.50 ave 6255 max 6192 min
Histogram: 1 0 0 0 0 1 0 0 0 2
Neighs: 277006.0 ave 280567 max 271394 min
Histogram: 1 0 0 0 0 1 0 0 0 2
Total # of neighbors = 1108026
Ave neighs/atom = 369.34200
Neighbor list builds = 2
Dangerous builds = 0
Total wall time: 0:00:12

128
examples/reaxff/water/log.13Oct21.reaxff.water-qeq-field.g++.1 Normal file
View File

@ -0,0 +1,128 @@
LAMMPS (29 Sep 2021)
# QEq Water, CITE: Achtyl et al., Nat. Comm., 6 6539 (2015)
boundary p p s
units real
atom_style charge
read_data data.water
Reading data file ...
orthogonal box = (0.0000000 0.0000000 0.0000000) to (31.043046 31.043046 31.043046)
1 by 1 by 1 MPI processor grid
reading atoms ...
WARNING: Non-zero imageflag(s) in z direction for non-periodic boundary reset to zero (../atom.cpp:1208)
WARNING: Non-zero imageflag(s) in z direction for non-periodic boundary reset to zero (../atom.cpp:1208)
WARNING: Non-zero imageflag(s) in z direction for non-periodic boundary reset to zero (../atom.cpp:1208)
3000 atoms
read_data CPU = 0.010 seconds
variable x index 1
variable y index 1
variable z index 1
replicate $x $y $z
replicate 1 $y $z
replicate 1 1 $z
replicate 1 1 1
Replicating atoms ...
orthogonal box = (0.0000000 0.0000000 0.0012889577) to (31.043046 31.043046 31.045309)
1 by 1 by 1 MPI processor grid
3000 atoms
replicate CPU = 0.001 seconds
pair_style reaxff NULL safezone 3.0 mincap 150
pair_coeff * * qeq_ff.water O H
WARNING: Changed valency_val to valency_boc for X (../reaxff_ffield.cpp:296)
neighbor 0.5 bin
neigh_modify every 1 delay 0 check yes
velocity all create 300.0 4928459 rot yes dist gaussian
fix 1 all qeq/reaxff 1 0.0 10.0 1.0e-6 reaxff maxiter 400
fix 2 all nvt temp 300 300 50.0
fix 3 all efield 0.0 0.0 1.0
fix 4 all wall/reflect zlo EDGE zhi EDGE
timestep 0.5
thermo 10
thermo_style custom step temp press density vol
run 20
CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE
Your simulation uses code contributions which should be cited:
- pair reaxff command:
@Article{Aktulga12,
author = {H. M. Aktulga, J. C. Fogarty, S. A. Pandit, A. Y. Grama},
title = {Parallel reactive molecular dynamics: Numerical methods and algorithmic techniques},
journal = {Parallel Computing},
year = 2012,
volume = 38,
pages = {245--259}
}
- fix qeq/reaxff command:
@Article{Aktulga12,
author = {H. M. Aktulga, J. C. Fogarty, S. A. Pandit, A. Y. Grama},
title = {Parallel reactive molecular dynamics: Numerical methods and algorithmic techniques},
journal = {Parallel Computing},
year = 2012,
volume = 38,
pages = {245--259}
}
CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE
Neighbor list info ...
update every 1 steps, delay 0 steps, check yes
max neighbors/atom: 2000, page size: 100000
master list distance cutoff = 10.5
ghost atom cutoff = 10.5
binsize = 5.25, bins = 6 6 6
2 neighbor lists, perpetual/occasional/extra = 2 0 0
(1) pair reaxff, perpetual
attributes: half, newton off, ghost
pair build: half/bin/newtoff/ghost
stencil: full/ghost/bin/3d
bin: standard
(2) fix qeq/reaxff, perpetual, copy from (1)
attributes: half, newton off, ghost
pair build: copy
stencil: none
bin: none
Per MPI rank memory allocation (min/avg/max) = 332.3 | 332.3 | 332.3 Mbytes
Step Temp Press Density Volume
0 300 25015.837 0.99996859 29916.212
10 348.83356 31131.298 0.99964273 29925.965
20 414.67243 27564.999 0.99979791 29921.32
Loop time of 15.4107 on 1 procs for 20 steps with 3000 atoms
Performance: 0.056 ns/day, 428.074 hours/ns, 1.298 timesteps/s
100.0% CPU use with 1 MPI tasks x no OpenMP threads
MPI task timing breakdown:
Section | min time | avg time | max time |%varavg| %total
---------------------------------------------------------------
Pair | 11.413 | 11.413 | 11.413 | 0.0 | 74.06
Neigh | 0.57486 | 0.57486 | 0.57486 | 0.0 | 3.73
Comm | 0.0019709 | 0.0019709 | 0.0019709 | 0.0 | 0.01
Output | 0.00013211 | 0.00013211 | 0.00013211 | 0.0 | 0.00
Modify | 3.4192 | 3.4192 | 3.4192 | 0.0 | 22.19
Other | | 0.001104 | | | 0.01
Nlocal: 3000.00 ave 3000 max 3000 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Nghost: 5439.00 ave 5439 max 5439 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Neighs: 786591.0 ave 786591 max 786591 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Total # of neighbors = 786591
Ave neighs/atom = 262.19700
Neighbor list builds = 6
Dangerous builds = 0
Total wall time: 0:00:16

128
examples/reaxff/water/log.13Oct21.reaxff.water-qeq-field.g++.4 Normal file
View File

@ -0,0 +1,128 @@
LAMMPS (29 Sep 2021)
# QEq Water, CITE: Achtyl et al., Nat. Comm., 6 6539 (2015)
boundary p p s
units real
atom_style charge
read_data data.water
Reading data file ...
orthogonal box = (0.0000000 0.0000000 0.0000000) to (31.043046 31.043046 31.043046)
1 by 2 by 2 MPI processor grid
reading atoms ...
WARNING: Non-zero imageflag(s) in z direction for non-periodic boundary reset to zero (../atom.cpp:1208)
WARNING: Non-zero imageflag(s) in z direction for non-periodic boundary reset to zero (../atom.cpp:1208)
WARNING: Non-zero imageflag(s) in z direction for non-periodic boundary reset to zero (../atom.cpp:1208)
3000 atoms
read_data CPU = 0.017 seconds
variable x index 1
variable y index 1
variable z index 1
replicate $x $y $z
replicate 1 $y $z
replicate 1 1 $z
replicate 1 1 1
Replicating atoms ...
orthogonal box = (0.0000000 0.0000000 0.0012889577) to (31.043046 31.043046 31.045309)
2 by 1 by 2 MPI processor grid
3000 atoms
replicate CPU = 0.002 seconds
pair_style reaxff NULL safezone 3.0 mincap 150
pair_coeff * * qeq_ff.water O H
WARNING: Changed valency_val to valency_boc for X (../reaxff_ffield.cpp:296)
neighbor 0.5 bin
neigh_modify every 1 delay 0 check yes
velocity all create 300.0 4928459 rot yes dist gaussian
fix 1 all qeq/reaxff 1 0.0 10.0 1.0e-6 reaxff maxiter 400
fix 2 all nvt temp 300 300 50.0
fix 3 all efield 0.0 0.0 1.0
fix 4 all wall/reflect zlo EDGE zhi EDGE
timestep 0.5
thermo 10
thermo_style custom step temp press density vol
run 20
CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE
Your simulation uses code contributions which should be cited:
- pair reaxff command:
@Article{Aktulga12,
author = {H. M. Aktulga, J. C. Fogarty, S. A. Pandit, A. Y. Grama},
title = {Parallel reactive molecular dynamics: Numerical methods and algorithmic techniques},
journal = {Parallel Computing},
year = 2012,
volume = 38,
pages = {245--259}
}
- fix qeq/reaxff command:
@Article{Aktulga12,
author = {H. M. Aktulga, J. C. Fogarty, S. A. Pandit, A. Y. Grama},
title = {Parallel reactive molecular dynamics: Numerical methods and algorithmic techniques},
journal = {Parallel Computing},
year = 2012,
volume = 38,
pages = {245--259}
}
CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE
Neighbor list info ...
update every 1 steps, delay 0 steps, check yes
max neighbors/atom: 2000, page size: 100000
master list distance cutoff = 10.5
ghost atom cutoff = 10.5
binsize = 5.25, bins = 6 6 6
2 neighbor lists, perpetual/occasional/extra = 2 0 0
(1) pair reaxff, perpetual
attributes: half, newton off, ghost
pair build: half/bin/newtoff/ghost
stencil: full/ghost/bin/3d
bin: standard
(2) fix qeq/reaxff, perpetual, copy from (1)
attributes: half, newton off, ghost
pair build: copy
stencil: none
bin: none
Per MPI rank memory allocation (min/avg/max) = 188.9 | 189.5 | 190.1 Mbytes
Step Temp Press Density Volume
0 300 25015.837 0.99996859 29916.212
10 348.83356 31131.298 0.99964273 29925.965
20 414.67243 27564.999 0.99979791 29921.32
Loop time of 5.71549 on 4 procs for 20 steps with 3000 atoms
Performance: 0.151 ns/day, 158.764 hours/ns, 3.499 timesteps/s
94.1% CPU use with 4 MPI tasks x no OpenMP threads
MPI task timing breakdown:
Section | min time | avg time | max time |%varavg| %total
---------------------------------------------------------------
Pair | 3.6678 | 3.8126 | 4.1402 | 9.8 | 66.71
Neigh | 0.31449 | 0.34639 | 0.38898 | 5.5 | 6.06
Comm | 0.032125 | 0.35935 | 0.50408 | 31.9 | 6.29
Output | 7.643e-05 | 0.00015959 | 0.00039876 | 0.0 | 0.00
Modify | 1.1534 | 1.1959 | 1.2283 | 3.0 | 20.92
Other | | 0.001099 | | | 0.02
Nlocal: 750.000 ave 757 max 738 min
Histogram: 1 0 0 0 0 1 0 0 0 2
Nghost: 4219.00 ave 4232 max 4198 min
Histogram: 1 0 0 0 0 1 0 0 1 1
Neighs: 230549.0 ave 233374 max 225849 min
Histogram: 1 0 0 0 0 0 1 0 1 1
Total # of neighbors = 922196
Ave neighs/atom = 307.39867
Neighbor list builds = 6
Dangerous builds = 0
Total wall time: 0:00:06

123
examples/reaxff/water/log.13Oct21.reaxff.water-qeq.g++.1 Normal file
View File

@ -0,0 +1,123 @@
LAMMPS (29 Sep 2021)
# QEq Water, CITE: Achtyl et al., Nat. Comm., 6 6539 (2015)
boundary p p p
units real
atom_style charge
read_data data.water
Reading data file ...
orthogonal box = (0.0000000 0.0000000 0.0000000) to (31.043046 31.043046 31.043046)
1 by 1 by 1 MPI processor grid
reading atoms ...
3000 atoms
read_data CPU = 0.010 seconds
variable x index 1
variable y index 1
variable z index 1
replicate $x $y $z
replicate 1 $y $z
replicate 1 1 $z
replicate 1 1 1
Replicating atoms ...
orthogonal box = (0.0000000 0.0000000 0.0000000) to (31.043046 31.043046 31.043046)
1 by 1 by 1 MPI processor grid
3000 atoms
replicate CPU = 0.001 seconds
pair_style reaxff NULL safezone 3.0 mincap 150
pair_coeff * * qeq_ff.water O H
WARNING: Changed valency_val to valency_boc for X (../reaxff_ffield.cpp:296)
neighbor 0.5 bin
neigh_modify every 1 delay 0 check yes
velocity all create 300.0 4928459 rot yes dist gaussian
fix 1 all qeq/reaxff 1 0.0 10.0 1.0e-6 reaxff maxiter 400
fix 2 all nvt temp 300 300 50.0
timestep 0.5
thermo 10
thermo_style custom step temp press density vol
run 20
CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE
Your simulation uses code contributions which should be cited:
- pair reaxff command:
@Article{Aktulga12,
author = {H. M. Aktulga, J. C. Fogarty, S. A. Pandit, A. Y. Grama},
title = {Parallel reactive molecular dynamics: Numerical methods and algorithmic techniques},
journal = {Parallel Computing},
year = 2012,
volume = 38,
pages = {245--259}
}
- fix qeq/reaxff command:
@Article{Aktulga12,
author = {H. M. Aktulga, J. C. Fogarty, S. A. Pandit, A. Y. Grama},
title = {Parallel reactive molecular dynamics: Numerical methods and algorithmic techniques},
journal = {Parallel Computing},
year = 2012,
volume = 38,
pages = {245--259}
}
CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE
Neighbor list info ...
update every 1 steps, delay 0 steps, check yes
max neighbors/atom: 2000, page size: 100000
master list distance cutoff = 10.5
ghost atom cutoff = 10.5
binsize = 5.25, bins = 6 6 6
2 neighbor lists, perpetual/occasional/extra = 2 0 0
(1) pair reaxff, perpetual
attributes: half, newton off, ghost
pair build: half/bin/newtoff/ghost
stencil: full/ghost/bin/3d
bin: standard
(2) fix qeq/reaxff, perpetual, copy from (1)
attributes: half, newton off, ghost
pair build: copy
stencil: none
bin: none
Per MPI rank memory allocation (min/avg/max) = 539.2 | 539.2 | 539.2 Mbytes
Step Temp Press Density Volume
0 300 780.33989 1 29915.273
10 301.29205 5433.7415 1 29915.273
20 297.90652 1572.6111 1 29915.273
Loop time of 17.5765 on 1 procs for 20 steps with 3000 atoms
Performance: 0.049 ns/day, 488.237 hours/ns, 1.138 timesteps/s
100.0% CPU use with 1 MPI tasks x no OpenMP threads
MPI task timing breakdown:
Section | min time | avg time | max time |%varavg| %total
---------------------------------------------------------------
Pair | 13.806 | 13.806 | 13.806 | 0.0 | 78.55
Neigh | 0.34211 | 0.34211 | 0.34211 | 0.0 | 1.95
Comm | 0.0028155 | 0.0028155 | 0.0028155 | 0.0 | 0.02
Output | 0.00012279 | 0.00012279 | 0.00012279 | 0.0 | 0.00
Modify | 3.4248 | 3.4248 | 3.4248 | 0.0 | 19.49
Other | | 0.001008 | | | 0.01
Nlocal: 3000.00 ave 3000 max 3000 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Nghost: 11077.0 ave 11077 max 11077 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Neighs: 971826.0 ave 971826 max 971826 min
Histogram: 1 0 0 0 0 0 0 0 0 0
Total # of neighbors = 971826
Ave neighs/atom = 323.94200
Neighbor list builds = 2
Dangerous builds = 0
Total wall time: 0:00:18

123
examples/reaxff/water/log.13Oct21.reaxff.water-qeq.g++.4 Normal file
View File

@ -0,0 +1,123 @@
LAMMPS (29 Sep 2021)
# QEq Water, CITE: Achtyl et al., Nat. Comm., 6 6539 (2015)
boundary p p p
units real
atom_style charge
read_data data.water
Reading data file ...
orthogonal box = (0.0000000 0.0000000 0.0000000) to (31.043046 31.043046 31.043046)
1 by 2 by 2 MPI processor grid
reading atoms ...
3000 atoms
read_data CPU = 0.010 seconds
variable x index 1
variable y index 1
variable z index 1
replicate $x $y $z
replicate 1 $y $z
replicate 1 1 $z
replicate 1 1 1
Replicating atoms ...
orthogonal box = (0.0000000 0.0000000 0.0000000) to (31.043046 31.043046 31.043046)
1 by 2 by 2 MPI processor grid
3000 atoms
replicate CPU = 0.001 seconds
pair_style reaxff NULL safezone 3.0 mincap 150
pair_coeff * * qeq_ff.water O H
WARNING: Changed valency_val to valency_boc for X (../reaxff_ffield.cpp:296)
neighbor 0.5 bin
neigh_modify every 1 delay 0 check yes
velocity all create 300.0 4928459 rot yes dist gaussian
fix 1 all qeq/reaxff 1 0.0 10.0 1.0e-6 reaxff maxiter 400
fix 2 all nvt temp 300 300 50.0
timestep 0.5
thermo 10
thermo_style custom step temp press density vol
run 20
CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE
Your simulation uses code contributions which should be cited:
- pair reaxff command:
@Article{Aktulga12,
author = {H. M. Aktulga, J. C. Fogarty, S. A. Pandit, A. Y. Grama},
title = {Parallel reactive molecular dynamics: Numerical methods and algorithmic techniques},
journal = {Parallel Computing},
year = 2012,
volume = 38,
pages = {245--259}
}
- fix qeq/reaxff command:
@Article{Aktulga12,
author = {H. M. Aktulga, J. C. Fogarty, S. A. Pandit, A. Y. Grama},
title = {Parallel reactive molecular dynamics: Numerical methods and algorithmic techniques},
journal = {Parallel Computing},
year = 2012,
volume = 38,
pages = {245--259}
}
CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE-CITE
Neighbor list info ...
update every 1 steps, delay 0 steps, check yes
max neighbors/atom: 2000, page size: 100000
master list distance cutoff = 10.5
ghost atom cutoff = 10.5
binsize = 5.25, bins = 6 6 6
2 neighbor lists, perpetual/occasional/extra = 2 0 0
(1) pair reaxff, perpetual
attributes: half, newton off, ghost
pair build: half/bin/newtoff/ghost
stencil: full/ghost/bin/3d
bin: standard
(2) fix qeq/reaxff, perpetual, copy from (1)
attributes: half, newton off, ghost
pair build: copy
stencil: none
bin: none
Per MPI rank memory allocation (min/avg/max) = 260.5 | 262.2 | 263.6 Mbytes
Step Temp Press Density Volume
0 300 780.34006 1 29915.273
10 301.29205 5433.7414 1 29915.273
20 297.90652 1572.6111 1 29915.273
Loop time of 6.79573 on 4 procs for 20 steps with 3000 atoms
Performance: 0.127 ns/day, 188.770 hours/ns, 2.943 timesteps/s
93.0% CPU use with 4 MPI tasks x no OpenMP threads
MPI task timing breakdown:
Section | min time | avg time | max time |%varavg| %total
---------------------------------------------------------------
Pair | 4.4827 | 4.6649 | 4.866 | 6.6 | 68.64
Neigh | 0.16329 | 0.17253 | 0.18074 | 1.6 | 2.54
Comm | 0.44871 | 0.64804 | 0.82827 | 17.5 | 9.54
Output | 9.9269e-05 | 0.00013061 | 0.00022048 | 0.0 | 0.00
Modify | 1.3028 | 1.3091 | 1.3201 | 0.6 | 19.26
Other | | 0.001043 | | | 0.02
Nlocal: 750.000 ave 759 max 735 min
Histogram: 1 0 0 0 0 1 0 0 0 2
Nghost: 6230.50 ave 6256 max 6190 min
Histogram: 1 0 0 0 0 1 0 0 1 1
Neighs: 277008.0 ave 280943 max 271394 min
Histogram: 1 0 0 0 0 1 0 0 1 1
Total # of neighbors = 1108032
Ave neighs/atom = 369.34400
Neighbor list builds = 2
Dangerous builds = 0
Total wall time: 0:00:07

83
examples/reaxff/water/qeq_ff.water Normal file
View File

@ -0,0 +1,83 @@
Reactive MD-force field: QEq Water [CITE: Achtyl et al., Nat. Comm., 6 6539 (2015)]
39 ! Number of general parameters
50.0000 !Overcoordination parameter
9.5469 !Overcoordination parameter
26.5405 !Valency angle conjugation parameter
1.7224 !Triple bond stabilisation parameter
6.8702 !Triple bond stabilisation parameter
60.4850 !C2-correction
1.0588 !Undercoordination parameter
4.6000 !Triple bond stabilisation parameter
12.1176 !Undercoordination parameter
13.3056 !Undercoordination parameter
-70.5044 !Triple bond stabilization energy
0.0000 !Lower Taper-radius
10.0000 !Upper Taper-radius
2.8793 !Not used
33.8667 !Valency undercoordination
6.0891 !Valency angle/lone pair parameter
1.0563 !Valency angle
2.0384 !Valency angle parameter
6.1431 !Not used
6.9290 !Double bond/angle parameter
0.3989 !Double bond/angle parameter: overcoord
3.9954 !Double bond/angle parameter: overcoord
-2.4837 !Not used
5.7796 !Torsion/BO parameter
10.0000 !Torsion overcoordination
1.9487 !Torsion overcoordination
-1.2327 !Conjugation 0 (not used)
2.1645 !Conjugation
1.5591 !vdWaals shielding
0.1000 !Cutoff for bond order (*100)
2.1365 !Valency angle conjugation parameter
0.6991 !Overcoordination parameter
50.0000 !Overcoordination parameter
1.8512 !Valency/lone pair parameter
0.5000 !Not used
20.0000 !Not used
5.0000 !Molecular energy (not used)
0.0000 !Molecular energy (not used)
2.6962 !Valency angle conjugation parameter
3 ! Nr of atoms; cov.r; valency;a.m;Rvdw;Evdw;gammaEEM;cov.r2;#
alfa;gammavdW;valency;Eunder;Eover;chiEEM;etaEEM;n.u.
cov r3;Elp;Heat inc.;n.u.;n.u.;n.u.;n.u.
ov/un;val1;n.u.;val3,vval4
H 0.8930 1.0000 1.0080 1.3550 0.0930 0.8203 -0.1000 1.0000
8.2230 33.2894 1.0000 0.0000 121.1250 3.7248 9.6093 1.0000
-0.1000 0.0000 61.6606 3.0408 2.4197 0.0003 1.0698 0.0000
-19.4571 4.2733 1.0338 1.0000 2.8793 0.0000 0.0000 0.0000
O 1.2450 2.0000 15.9990 2.3890 0.1000 1.0898 1.0548 6.0000
9.7300 13.8449 4.0000 37.5000 116.0768 8.5000 8.3122 2.0000
0.9049 0.4056 59.0626 3.5027 0.7640 0.0021 0.9745 0.0000
-3.5500 2.9000 1.0493 4.0000 2.9225 0.0000 0.0000 0.0000
X -0.1000 2.0000 1.0080 2.0000 0.0000 1.0000 -0.1000 6.0000
10.0000 2.5000 4.0000 0.0000 0.0000 8.5000 1.5000 0.0000
-0.1000 0.0000 -2.3700 8.7410 13.3640 0.6690 0.9745 0.0000
-11.0000 2.7466 1.0338 2.0000 2.8793 0.0000 0.0000 0.0000
3 ! Nr of bonds; Edis1;LPpen;n.u.;pbe1;pbo5;13corr;pbo6
pbe2;pbo3;pbo4;n.u.;pbo1;pbo2;ovcorr
1 1 153.3934 0.0000 0.0000 -0.4600 0.0000 1.0000 6.0000 0.7300
6.2500 1.0000 0.0000 1.0000 -0.0790 6.0552 0.0000 0.0000
2 2 142.2858 145.0000 50.8293 0.2506 -0.1000 1.0000 29.7503 0.6051
0.3451 -0.1055 9.0000 1.0000 -0.1225 5.5000 1.0000 0.0000
1 2 160.0000 0.0000 0.0000 -0.5725 0.0000 1.0000 6.0000 0.5626
1.1150 1.0000 0.0000 0.0000 -0.0920 4.2790 0.0000 0.0000
1 ! Nr of off-diagonal terms; Ediss;Ro;gamma;rsigma;rpi;rpi2
1 2 0.0283 1.2885 10.9190 0.9215 -1.0000 -1.0000
6 ! Nr of angles;at1;at2;at3;Thetao,o;ka;kb;pv1;pv2
1 1 1 0.0000 27.9213 5.8635 0.0000 0.0000 0.0000 1.0400
2 2 2 80.7324 30.4554 0.9953 0.0000 1.6310 50.0000 1.0783
1 2 2 75.6935 50.0000 2.0000 0.0000 1.0000 0.0000 1.1680
1 2 1 85.8000 9.8453 2.2720 0.0000 2.8635 0.0000 1.5800
2 1 2 0.0000 15.0000 2.8900 0.0000 0.0000 0.0000 2.8774
1 1 2 0.0000 8.5744 3.0000 0.0000 0.0000 0.0000 1.0421
6 ! Nr of torsions;at1;at2;at3;at4;;V1;V2;V3;V2(BO);vconj;n.u;n
1 2 2 1 2.5000 -4.0000 0.9000 -2.5000 -1.0000 0.0000 0.0000
1 2 2 2 0.8302 -4.0000 -0.7763 -2.5000 -1.0000 0.0000 0.0000
2 2 2 2 -2.5000 -4.0000 1.0000 -2.5000 -1.0000 0.0000 0.0000
0 1 1 0 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000
0 1 2 0 0.0000 0.1000 0.0200 -2.5415 0.0000 0.0000 0.0000
0 2 2 0 0.5511 25.4150 1.1330 -5.1903 -1.0000 0.0000 0.0000
1 ! Nr of hydrogen bonds;at1;at2;at3;Rhb;Dehb;vhb1
2 1 2 2.1200 -3.5800 1.4500 19.5000

4
lib/awpmd/ivutils/include/vector_3.h
View File

@ -487,7 +487,7 @@ vec_type dist_av(Vector_3 *va1,Vector_3 *va2,int n);
/*e optionally gives the indexes for maximal and minimal difference
va2 can be nullptr, then the norm of va1 is used */
vec_type diff_av(Vector_3 *va1,Vector_3 *va2,int n, int *minind=0, int *maxind=0);
vec_type diff_av(Vector_3 *va1,Vector_3 *va2,int n, int *minind=nullptr, int *maxind=nullptr);
//e finds suitable perpendicular to a vector
Vector_3 FindPerp(const Vector_3 &vAB);
@ -507,7 +507,7 @@ Vector_3 GetIScopei(const Vector_3 *varr,int *indarr,int n,Vector_3* box_min,Vec
// neue Funktionen
//e clears vector array with optional integer index
void clear_vecarri(int n,Vector_3 *vec, int *ind=0);
void clear_vecarri(int n,Vector_3 *vec, int *ind=nullptr);
//e reflects the vector ini+dir*t+0.5*force*t^2 to be inside a box limited by 0 and box sizes
//e changes dir according to the final state

12
lib/gpu/lal_device.cpp
View File

@ -1039,10 +1039,18 @@ Device<PRECISION,ACC_PRECISION> global_device;
using namespace LAMMPS_AL;
bool lmp_has_gpu_device()
// check if a suitable GPU is present.
// for mixed and double precision GPU library compilation
// also the GPU needs to support double precision.
bool lmp_has_compatible_gpu_device()
{
UCL_Device gpu;
return (gpu.num_platforms() > 0);
bool compatible_gpu = gpu.num_platforms() > 0;
#if defined(_SINGLE_DOUBLE) || defined(_DOUBLE_DOUBLE)
if (!gpu.double_precision(0))
compatible_gpu = false;
#endif
return compatible_gpu;
}
std::string lmp_gpu_device_info()

10
lib/poems/SystemProcessor.h
View File

@ -49,9 +49,9 @@ private:
POEMSChain * AddNewChain(POEMSNode * currentNode);
bool setLinkVisited(POEMSNode * firstNode, POEMSNode * secondNode);
public:
SystemProcessor(void);
SystemProcessor();
~SystemProcessor(void) {
~SystemProcessor() {
headsOfSystems.DeleteValues();
for(int i = 0; i < ringsInSystem.GetNumElements(); i++)
{
@ -66,7 +66,7 @@ public:
int getNumberOfHeadChains();
};
SystemProcessor::SystemProcessor(void){
SystemProcessor::SystemProcessor(){
// register callback for deleting auxiliary data from tree nodes.
nodes.SetDeleteAuxData(&POEMSNodeDelete_cb);
}
@ -271,14 +271,14 @@ bool SystemProcessor::setLinkVisited(POEMSNode * firstNode, POEMSNode * secondNo
return true; //return true to indicate that this is the first time the link has been visited
}
List<POEMSChain> * SystemProcessor::getSystemData(void) //Gets the list of POEMSChains that comprise the system. Might eventually only
List<POEMSChain> * SystemProcessor::getSystemData() //Gets the list of POEMSChains that comprise the system. Might eventually only
//return chains linked to the reference plane, but currently returns every chain
//in the system.
{
return &headsOfSystems;
}
int SystemProcessor::getNumberOfHeadChains(void) //This function isnt implemented yet, and might be taken out entirely; this was a holdover
int SystemProcessor::getNumberOfHeadChains() //This function isnt implemented yet, and might be taken out entirely; this was a holdover
//from when I intended to return an array of chain pointers, rather than a list of chains
//It will probably be deleted once I finish figuring out exactly what needs to be returned
{

2
lib/poems/body.cpp
View File

@ -132,6 +132,6 @@ Body* NewBody(int type){
case PARTICLE : // A Particle
return new Particle;
default : // error
return 0;
return nullptr;
}
}

3
lib/poems/body23joint.cpp
View File

@ -30,8 +30,7 @@
Body23Joint::Body23Joint(){
DimQandU(4,2);
}
Body23Joint::~Body23Joint(){
}
Body23Joint::~Body23Joint() = default;
JointType Body23Joint::GetType(){
return BODY23JOINT;

8
lib/poems/colmatmap.cpp
View File

@ -24,7 +24,7 @@ using namespace std;
ColMatMap::ColMatMap(){
numrows = 0;
elements = 0;
elements = nullptr;
}
ColMatMap::~ColMatMap(){
@ -33,7 +33,7 @@ ColMatMap::~ColMatMap(){
ColMatMap::ColMatMap(const ColMatMap& A){ // copy constructor
numrows = 0;
elements = 0;
elements = nullptr;
Dim(A.numrows);
for(int i=0;i<numrows;i++)
elements[i] = A.elements[i];
@ -41,7 +41,7 @@ ColMatMap::ColMatMap(const ColMatMap& A){ // copy constructor
ColMatMap::ColMatMap(ColMatrix& A){ // copy constructor
numrows = 0;
elements = 0;
elements = nullptr;
Dim(A.GetNumRows());
for(int i=0;i<numrows;i++)
elements[i] = A.GetElementPointer(i);
@ -63,7 +63,7 @@ ColMatrix::ColMatrix(const VirtualMatrix& A){ // copy constructor
ColMatMap::ColMatMap(int m){ // size constructor
numrows = 0;
elements = 0;
elements = nullptr;
Dim(m);
}

10
lib/poems/colmatrix.cpp
View File

@ -25,7 +25,7 @@ using namespace std;
ColMatrix::ColMatrix(){
numrows = 0;
elements = 0;
elements = nullptr;
}
ColMatrix::~ColMatrix(){
@ -34,7 +34,7 @@ ColMatrix::~ColMatrix(){
ColMatrix::ColMatrix(const ColMatrix& A){ // copy constructor
numrows = 0;
elements = 0;
elements = nullptr;
Dim(A.numrows);
for(int i=0;i<numrows;i++)
elements[i] = A.elements[i];
@ -42,7 +42,7 @@ ColMatrix::ColMatrix(const ColMatrix& A){ // copy constructor
ColMatrix::ColMatrix(const VirtualColMatrix& A){ // copy constructor
numrows = 0;
elements = 0;
elements = nullptr;
Dim(A.GetNumRows());
for(int i=0;i<numrows;i++)
elements[i] = A.BasicGet(i);
@ -54,7 +54,7 @@ ColMatrix::ColMatrix(const VirtualMatrix& A){ // copy constructor
exit(1);
}
numrows = 0;
elements = 0;
elements = nullptr;
Dim(A.GetNumRows());
for(int i=0;i<numrows;i++)
elements[i] = A.BasicGet(i,0);
@ -62,7 +62,7 @@ ColMatrix::ColMatrix(const VirtualMatrix& A){ // copy constructor
ColMatrix::ColMatrix(int m){ // size constructor
numrows = 0;
elements = 0;
elements = nullptr;
Dim(m);
}

5
lib/poems/fixedpoint.cpp
View File

@ -22,11 +22,6 @@
using namespace std;
FixedPoint::FixedPoint(){
}
FixedPoint::~FixedPoint(){
}
FixedPoint::FixedPoint(double x, double y, double z){
position(1) = x;
position(2) = y;

4
lib/poems/fixedpoint.h
View File

@ -24,8 +24,8 @@
class FixedPoint : public Point {
public:
FixedPoint();
~FixedPoint();
FixedPoint() = default;
~FixedPoint() = default;
FixedPoint(double x, double y, double z);
FixedPoint(Vect3& v);
PointType GetType();

3
lib/poems/freebodyjoint.cpp
View File

@ -30,8 +30,7 @@ FreeBodyJoint::FreeBodyJoint(){
DimQandU(7,6);
}
FreeBodyJoint::~FreeBodyJoint(){
}
FreeBodyJoint::~FreeBodyJoint() = default;
JointType FreeBodyJoint::GetType(){
return FREEBODYJOINT;

3
lib/poems/inertialframe.cpp
View File

@ -33,8 +33,7 @@ InertialFrame::InertialFrame(){
alpha.Zeros();
alpha_t.Zeros();
}
InertialFrame::~InertialFrame(){
}
InertialFrame::~InertialFrame() = default;
BodyType InertialFrame::GetType(){
return INERTIALFRAME;

11
lib/poems/joint.cpp
View File

@ -27,14 +27,13 @@
using namespace std;
Joint::Joint(){
body1 = body2 = 0;
point1 = point2 = 0;
body1 = body2 = nullptr;
point1 = point2 = nullptr;
pk_C_ko.Identity();
pk_C_k.Identity();
}
Joint::~Joint(){
}
Joint::~Joint() = default;
void Joint::SetBodies(Body* b1, Body* b2){
body1 = b1;
@ -165,7 +164,7 @@ Body* Joint::GetBody2(){
Body* Joint::OtherBody(Body* body){
if(body1 == body) return body2;
if(body2 == body) return body1;
return 0;
return nullptr;
}
Vect3* Joint::GetR12(){
@ -243,6 +242,6 @@ Joint* NewJoint(int type){
case SPHERICALJOINT : return new SphericalJoint;
case BODY23JOINT : return new Body23Joint;
case MIXEDJOINT : return new MixedJoint;
default : return 0; // error
default : return nullptr; // error
}
}

2
lib/poems/mat3x3.cpp
View File

@ -24,8 +24,6 @@ using namespace std;
Mat3x3::Mat3x3(){
numrows = numcols = 3;
}
Mat3x3::~Mat3x3(){
}
Mat3x3::Mat3x3(const Mat3x3& A){
numrows = numcols = 3;

2
lib/poems/mat3x3.h
View File

@ -30,7 +30,7 @@ class Mat3x3 : public VirtualMatrix {
double elements[3][3];
public:
Mat3x3();
~Mat3x3();
~Mat3x3() = default;
Mat3x3(const Mat3x3& A); // copy constructor
Mat3x3(const VirtualMatrix& A); // copy constructor

2
lib/poems/mat4x4.cpp
View File

@ -23,8 +23,6 @@ using namespace std;
Mat4x4::Mat4x4(){
numrows = numcols = 4;
}
Mat4x4::~Mat4x4(){
}
Mat4x4::Mat4x4(const Mat4x4& A){
numrows = numcols = 4;

2
lib/poems/mat4x4.h
View File

@ -28,7 +28,7 @@ class Mat4x4 : public VirtualMatrix {
double elements[4][4];
public:
Mat4x4();
~Mat4x4();
~Mat4x4() = default;
Mat4x4(const Mat4x4& A); // copy constructor
Mat4x4(const VirtualMatrix& A); // copy constructor

2
lib/poems/mat6x6.cpp
View File

@ -23,8 +23,6 @@ using namespace std;
Mat6x6::Mat6x6(){
numrows = numcols = 6;
}
Mat6x6::~Mat6x6(){
}
Mat6x6::Mat6x6(const Mat6x6& A){
numrows = numcols = 6;

2
lib/poems/mat6x6.h
View File

@ -29,7 +29,7 @@ class Mat6x6 : public VirtualMatrix {
double elements[6][6];
public:
Mat6x6();
~Mat6x6();
~Mat6x6() = default;
Mat6x6(const Mat6x6& A); // copy constructor
Mat6x6(const VirtualMatrix& A); // copy constructor

16
lib/poems/matrix.cpp
View File

@ -24,8 +24,8 @@ using namespace std;
Matrix::Matrix(){
numrows = numcols = 0;
rows = 0;
elements = 0;
rows = nullptr;
elements = nullptr;
}
Matrix::~Matrix(){
@ -35,8 +35,8 @@ Matrix::~Matrix(){
Matrix::Matrix(const Matrix& A){
numrows = numcols = 0;
rows = 0;
elements = 0;
rows = nullptr;
elements = nullptr;
Dim(A.numrows,A.numcols);
for(int i=0;i<numrows*numcols;i++)
elements[i] = A.elements[i];
@ -44,8 +44,8 @@ Matrix::Matrix(const Matrix& A){
Matrix::Matrix(const VirtualMatrix& A){
numrows = numcols = 0;
rows = 0;
elements = 0;
rows = nullptr;
elements = nullptr;
Dim(A.GetNumRows(),A.GetNumCols());
for(int i=0;i<numrows;i++)
for(int j=0;j<numcols;j++)
@ -54,8 +54,8 @@ Matrix::Matrix(const VirtualMatrix& A){
Matrix::Matrix(int m, int n){
numrows = numcols = 0;
rows = 0;
elements = 0;
rows = nullptr;
elements = nullptr;
this->Dim(m,n);
}

2
lib/poems/matrixfun.cpp
View File

@ -36,7 +36,7 @@ VirtualMatrix* NewMatrix(int type){
case MAT4X4 : return new Mat4x4;
case VECT3 : return new Vect3;
case VECT4 : return new Vect4;
default : return 0; // error!
default : return nullptr; // error!
}
}

6
lib/poems/mixedjoint.cpp
View File

@ -26,11 +26,9 @@
MixedJoint::MixedJoint(){
}
MixedJoint::MixedJoint() = default;
MixedJoint::~MixedJoint(){
}
MixedJoint::~MixedJoint() = default;
JointType MixedJoint::GetType(){
return MIXEDJOINT;

6
lib/poems/onbody.cpp
View File

@ -30,9 +30,9 @@ using namespace std;
OnBody::OnBody(){
system_body = 0;
system_joint = 0;
parent = 0;
system_body = nullptr;
system_joint = nullptr;
parent = nullptr;
// these terms have zeros which are NEVER overwritten
sI.Zeros();

4
lib/poems/onsolver.cpp
View File

@ -28,8 +28,8 @@ using namespace std;
OnSolver::OnSolver(){
numbodies = 0;
bodyarray = 0;
q=0;u=0; qdot=0; udot=0; qdotdot=0;
bodyarray = nullptr;
q=nullptr;u=nullptr; qdot=nullptr; udot=nullptr; qdotdot=nullptr;
type = ONSOLVER;
}

6
lib/poems/particle.cpp
View File

@ -19,11 +19,9 @@
#include "particle.h"
#include "fixedpoint.h"
Particle::Particle(){
}
Particle::Particle() = default;
Particle::~Particle(){
}
Particle::~Particle() = default;
BodyType Particle::GetType(){
return PARTICLE;

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