Merge pull request #2999 from akohlmey/maintenance-2021-09-29

Maintenance fixes for the stable release

.github/CODEOWNERS

@@ -22,42 +22,42 @@ src/MESSAGE/*         @sjplimp
 src/MLIAP/*           @athomps
 src/SNAP/*            @athomps
 src/SPIN/*            @julient31
-src/BROWNIAN/*   @samueljmcameron
-src/CG-DNA/*      @ohenrich
-src/CG-SDK/*      @akohlmey
-src/COLVARS/*    @giacomofiorin
-src/DIELECTRIC/* @ndtrung81
-src/FEP/*        @agiliopadua
-src/ML-HDNNP/*      @singraber
-src/INTEL/*      @wmbrownintel
-src/MANIFOLD/*   @Pakketeretet2
-src/MDI/*        @taylor-a-barnes
-src/MEAM/*      @martok
-src/MESONT/*     @iafoss
-src/MOFFF/*      @hheenen
-src/MOLFILE/*    @akohlmey
-src/NETCDF/*     @pastewka
-src/ML-PACE/*       @yury-lysogorskiy
-src/PLUMED/*     @gtribello
-src/PHONON/*     @lingtikong
-src/PTM/*        @pmla
-src/OPENMP/*        @akohlmey
-src/QMMM/*       @akohlmey
-src/REAXFF/*      @hasanmetin
-src/REACTION/*   @jrgissing
-src/SCAFACOS/*   @rhalver
-src/TALLY/*      @akohlmey
-src/UEF/*        @danicholson
-src/VTK/*        @rbberger
-
+src/BROWNIAN/*        @samueljmcameron
+src/CG-DNA/*          @ohenrich
+src/CG-SDK/*          @akohlmey
+src/COLVARS/*         @giacomofiorin
+src/DIELECTRIC/*      @ndtrung81
+src/FEP/*             @agiliopadua
+src/ML-HDNNP/*        @singraber
+src/INTEL/*           @wmbrownintel
+src/MANIFOLD/*        @Pakketeretet2
+src/MDI/*             @taylor-a-barnes
+src/MEAM/*            @martok
+src/MESONT/*          @iafoss
+src/MOFFF/*           @hheenen
+src/MOLFILE/*         @akohlmey
+src/NETCDF/*          @pastewka
+src/ML-PACE/*         @yury-lysogorskiy
+src/PLUMED/*          @gtribello
+src/PHONON/*          @lingtikong
+src/PTM/*             @pmla
+src/OPENMP/*          @akohlmey
+src/QMMM/*            @akohlmey
+src/REAXFF/*          @hasanmetin @stanmoore1
+src/REACTION/*        @jrgissing
+src/SCAFACOS/*        @rhalver
+src/TALLY/*           @akohlmey
+src/UEF/*             @danicholson
+src/VTK/*             @rbberger
 
 # individual files in packages
 src/GPU/pair_vashishta_gpu.*        @andeplane
 src/KOKKOS/pair_vashishta_kokkos.*  @andeplane
 src/MANYBODY/pair_vashishta_table.* @andeplane
 src/MANYBODY/pair_atm.*             @sergeylishchuk
-src/USER-MISC/*_grem.*              @dstelter92
-src/USER-MISC/compute_stress_mop*.* @RomainVermorel
+src/REPLICA/*_grem.*                @dstelter92
+src/EXTRA-COMPUTE/compute_stress_mop*.* @RomainVermorel
+src/MISC/*_tracker.*                @jtclemm
 
 # core LAMMPS classes
 src/lammps.*              @sjplimp
@@ -81,6 +81,7 @@ src/kspace.*              @sjplimp
 src/lmptyp.h              @sjplimp
 src/library.*             @sjplimp
 src/main.cpp              @sjplimp
+src/min_*.*               @sjplimp
 src/memory.*              @sjplimp
 src/modify.*              @sjplimp
 src/molecule.*            @sjplimp
@@ -109,7 +110,6 @@ src/thermo.*              @sjplimp
 src/universe.*            @sjplimp
 src/update.*              @sjplimp
 src/variable.*            @sjplimp
-src/verlet.*              @sjplimp
 src/velocity.*            @sjplimp
 src/write_data.*          @sjplimp
 src/write_restart.*       @sjplimp
@@ -122,13 +122,14 @@ src/info.*                @akohlmey @rbberger
 src/timer.*               @akohlmey
 src/min*                  @sjplimp @stanmoore1
 src/utils.*               @akohlmey @rbberger
+src/verlet.*              @sjplimp @stanmoore1
 src/math_eigen_impl.h     @jewettaij
 
 # tools
 tools/msi2lmp/*       @akohlmey
 tools/emacs/*         @HaoZeke
 tools/singularity/*   @akohlmey @rbberger
-tools/code_standard/* @rbberger
+tools/coding_standard/* @rbberger
 tools/valgrind/*      @akohlmey
 tools/swig/*          @akohlmey
 tools/offline/*       @rbberger

.github/CONTRIBUTING.md

@@ -5,8 +5,9 @@ Thank your for considering to contribute to the LAMMPS software project.
 The following is a set of guidelines as well as explanations of policies and work flows for contributing to the LAMMPS molecular dynamics software project. These guidelines focus on submitting issues or pull requests on the LAMMPS GitHub project.
 
 Thus please also have a look at:
-* [The Section on submitting new features for inclusion in LAMMPS of the Manual](https://lammps.sandia.gov/doc/Modify_contribute.html)
-* [The LAMMPS GitHub Tutorial in the Manual](http://lammps.sandia.gov/doc/Howto_github.html)
+* [The guide for submitting new features in the LAMMPS manual](https://lammps.sandia.gov/doc/Modify_contribute.html)
+* [The guide on programming style and requirement in the LAMMPS manual](https://lammps.sandia.gov/doc/Modify_contribute.html)
+* [The GitHub tutorial in the LAMMPS manual](http://lammps.sandia.gov/doc/Howto_github.html)
 
 ## Table of Contents
 
@@ -26,11 +27,11 @@ __
 
 ## I don't want to read this whole thing I just have a question!
 
-> **Note:** Please do not file an issue to ask a general question about LAMMPS, its features, how to use specific commands, or how perform simulations or analysis in LAMMPS. Instead post your question to either the ['lammps-users' mailing list](https://lammps.sandia.gov/mail.html) or the [LAMMPS Material Science Discourse forum](https://matsci.org/lammps). You do not need to be subscribed to post to the list (but a mailing list subscription avoids having your post delayed until it is approved by a mailing list moderator). Most posts to the mailing list receive a response within less than 24 hours. Before posting to the mailing list, please read the [mailing list guidelines](https://lammps.sandia.gov/guidelines.html). Following those guidelines will help greatly to get a helpful response. Always mention which LAMMPS version you are using. The LAMMPS forum was recently created as part of a larger effort to build a materials science community and have discussions not just about using LAMMPS. Thus the forum may be also used for discussions that would be off-topic for the mailing list. Those will just have to be moved to a more general category.
+> **Note:** Please do not file an issue to ask a general question about LAMMPS, its features, how to use specific commands, or how perform simulations or analysis in LAMMPS. Instead post your question to either the ['lammps-users' mailing list](https://lammps.sandia.gov/mail.html) or the [LAMMPS Material Science Discourse forum](https://matsci.org/lammps). You do not need to be subscribed to post to the list (but a mailing list subscription avoids having your post delayed until it is approved by a mailing list moderator). Most posts to the mailing list receive a response within less than 24 hours. Before posting to the mailing list, please read the [mailing list guidelines](https://lammps.sandia.gov/guidelines.html). Following those guidelines will help greatly to get a helpful response. Always mention which LAMMPS version you are using. The LAMMPS forum was recently created as part of a larger effort to build a materials science community and have discussions not just about using LAMMPS. Thus the forum may be also used for discussions that would be off-topic for the mailing list. Those will just have to be posted to a more general category.
 
 ## How Can I Contribute?
 
-There are several ways how you can actively contribute to the LAMMPS project: you can discuss compiling and using LAMMPS, and solving LAMMPS related problems with other LAMMPS users on the lammps-users mailing list, you can report bugs or suggest enhancements by creating issues on GitHub (or posting them to the lammps-users mailing list or posting in the LAMMPS Materials Science Discourse forum), and you can contribute by submitting pull requests on GitHub or e-mail your code
+There are several ways how you can actively contribute to the LAMMPS project: you can discuss compiling and using LAMMPS, and solving LAMMPS related problems with other LAMMPS users on the lammps-users mailing list or the forum, you can report bugs or suggest enhancements by creating issues on GitHub (or posting them to the lammps-users mailing list or posting in the LAMMPS Materials Science Discourse forum), and you can contribute by submitting pull requests on GitHub or e-mail your code
 to one of the [LAMMPS core developers](https://lammps.sandia.gov/authors.html). As you may see from the aforementioned developer page, the LAMMPS software package includes the efforts of a very large number of contributors beyond the principal authors and maintainers.
 
 ### Discussing How To Use LAMMPS
@@ -62,37 +63,12 @@ To be able to submit an issue on GitHub, you have to register for an account (fo
 
 ### Contributing Code
 
-We encourage users to submit new features or modifications for LAMMPS to the core developers so they can be added to the LAMMPS distribution. The preferred way to manage and coordinate this is by submitting a pull request at the LAMMPS project on GitHub. For any larger modifications or programming project, you are encouraged to contact the LAMMPS developers ahead of time, in order to discuss implementation strategies and coding guidelines, that will make it easier to integrate your contribution and result in less work for everybody involved. You are also encouraged to search through the list of open issues on GitHub and submit a new issue for a planned feature, so you would not duplicate the work of others (and possibly get scooped by them) or have your work duplicated by others.
+We encourage users to submit new features or modifications for LAMMPS. Instructions, guidelines, requirements,
+and recommendations are in the following sections of the LAMMPS manual:
+* [The guide for submitting new features in the LAMMPS manual](https://lammps.sandia.gov/doc/Modify_contribute.html)
+* [The guide on programming style and requirement in the LAMMPS manual](https://lammps.sandia.gov/doc/Modify_contribute.html)
+* [The GitHub tutorial in the LAMMPS manual](http://lammps.sandia.gov/doc/Howto_github.html)
 
-How quickly your contribution will be integrated depends largely on how much effort it will cause to integrate and test it, how much it requires changes to the core code base, and of how much interest it is to the larger LAMMPS community. Please see below for a checklist of typical requirements. Once you have prepared everything, see [this tutorial](https://lammps.sandia.gov/doc/Howto_github.html)
- for instructions on how to submit your changes or new files through a GitHub pull request
-
-Here is a checklist of steps you need to follow to submit a single file or user package for our consideration. Following these steps will save both you and us time. See existing files in packages in the source directory for examples. If you are uncertain, please ask on the lammps-users mailing list.
-
-* C++ source code must be compatible with the C++-11 standard. Packages may require a later standard, if justified.
-* All source files you provide must compile with the most current version of LAMMPS with multiple configurations. In particular you need to test compiling LAMMPS from scratch with `-DLAMMPS_BIGBIG` set in addition to the default `-DLAMMPS_SMALLBIG` setting. Your code will need to work correctly in serial and in parallel using MPI.
-* For consistency with the rest of LAMMPS and especially, if you want your contribution(s) to be added to main LAMMPS code or one of its standard packages, it needs to be written in a style compatible with other LAMMPS source files. This means: 2-character indentation per level, no tabs, no trailing whitespace, no lines over 80 characters. I/O is done via the C-style stdio library, style class header files should not import any system headers, STL containers should be avoided in headers, and forward declarations used where possible or needed. All added code should be placed into the LAMMPS_NS namespace or a sub-namespace; global or static variables should be avoided, as they conflict with the modular nature of LAMMPS and the C++ class structure. There MUST NOT be any "using namespace XXX;" statements in headers. In the implementation file (<name>.cpp) system includes should be placed in angular brackets (<>) and for c-library functions the C++ style header files should be included (<cstdio> instead of <stdio.h>, or <cstring> instead of <string.h>). This all is so the developers can more easily understand, integrate, and maintain your contribution and reduce conflicts with other parts of LAMMPS. This basically means that the code accesses data structures, performs its operations, and is formatted similar to other LAMMPS source files, including the use of the error class for error and warning messages.
-* Source, style name, and documentation file should follow the following naming convention: style names should be lowercase and words separated by a forward slash; for a new fix style 'foo/bar', the class should be named FixFooBar, the name of the source files should be 'fix_foo_bar.h' and 'fix_foo_bar.cpp' and the corresponding documentation should be in a file 'fix_foo_bar.rst'.
-* If you want your contribution to be added as a user-contributed feature, and it is a single file (actually a `<name>.cpp` and `<name>.h` file) it can be rapidly added to the USER-MISC directory. Include the one-line entry to add to the USER-MISC/README file in that directory, along with the 2 source files. You can do this multiple times if you wish to contribute several individual features.
-* If you want your contribution to be added as a user-contribution and it is several related features, it is probably best to make it a user package directory with a name like FOO. In addition to your new files, the directory should contain a README text file. The README should contain your name and contact information and a brief description of what your new package does. If your files depend on other LAMMPS style files also being installed (e.g. because your file is a derived class from the other LAMMPS class), then an Install.sh file is also needed to check for those dependencies. See other README and Install.sh files in other USER directories as examples. Send us a tarball of this FOO directory.
-* Your new source files need to have the LAMMPS copyright, GPL notice, and your name and email address at the top, like other user-contributed LAMMPS source files. They need to create a class that is inside the LAMMPS namespace. If the file is for one of the USER packages, including USER-MISC, then we are not as picky about the coding style (see above). I.e. the files do not need to be in the same stylistic format and syntax as other LAMMPS files, though that would be nice for developers as well as users who try to read your code.
-* You **must** also create or extend a documentation file for each new command or style you are adding to LAMMPS. For simplicity and convenience, the documentation of groups of closely related commands or styles may be combined into a single file. This will be one file for a single-file feature. For a package, it might be several files. These are files in the [reStructuredText](https://docutils.sourceforge.io/rst.html) markup language, that are then converted to HTML and PDF. The tools for this conversion are included in the source distribution, and the translation can be as simple as doing "make html pdf" in the doc folder. Thus the documentation source files must be in the same format and style as other `<name>.rst` files in the lammps/doc/src directory for similar commands and styles; use one or more of them as a starting point. An introduction to reStructuredText can be found at [https://docutils.sourceforge.io/docs/user/rst/quickstart.html](https://docutils.sourceforge.io/docs/user/rst/quickstart.html). The text files can include mathematical expressions and symbol in ".. math::" sections or ":math:" expressions or figures (see doc/JPG for examples), or even additional PDF files with further details (see doc/PDF for examples). The doc page should also include literature citations as appropriate; see the bottom of doc/fix_nh.rst for examples and the earlier part of the same file for how to format the cite itself. The "Restrictions" section of the doc page should indicate that your command is only available if LAMMPS is built with the appropriate USER-MISC or FOO package. See other user package doc files for examples of how to do this. The prerequisite for building the HTML format files are Python 3.x and virtualenv. Please run at least `make html`, `make pdf` and `make spelling` and carefully inspect and proofread the resulting HTML format doc page as well as the output produced to the screen. Make sure that all spelling errors are fixed or the necessary false positives are added to the `doc/utils/sphinx-config/false_positives.txt` file.  For new styles, those usually also need to be added to lists on the respective overview pages. This can be checked for also with `make style_check`.
-* For a new package (or even a single command) you should include one or more example scripts demonstrating its use. These should run in no more than a couple minutes, even on a single processor, and not require large data files as input. See directories under examples/PACKAGES for examples of input scripts other users provided for their packages. These example inputs are also required for validating memory accesses and testing for memory leaks with valgrind
-* For new utility functions or class (i.e. anything that does not depend on a LAMMPS object), new unit tests should be added to the unittest tree.
-* When adding a new LAMMPS style, a .yaml file with a test configuration and reference data should be added for the styles where a suitable tester program already exists (e.g. pair styles, bond styles, etc.).
-* If there is a paper of yours describing your feature (either the algorithm/science behind the feature itself, or its initial usage, or its implementation in LAMMPS), you can add the citation to the <name>.cpp source file. See src/EFF/atom_vec_electron.cpp for an example. A LaTeX citation is stored in a variable at the top of the file and a single line of code that references the variable is added to the constructor of the class. Whenever a user invokes your feature from their input script, this will cause LAMMPS to output the citation to a log.cite file and prompt the user to examine the file. Note that you should only use this for a paper you or your group authored. E.g. adding a cite in the code for a paper by Nose and Hoover if you write a fix that implements their integrator is not the intended usage. That kind of citation should just be in the doc page you provide.
-
-Finally, as a general rule-of-thumb, the more clear and self-explanatory you make your documentation and README files, and the easier you make it for people to get started, e.g. by providing example scripts, the more likely it is that users will try out your new feature.
-
-If the new features/files are broadly useful we may add them as core files to LAMMPS or as part of a standard package. Else we will add them as a user-contributed file or package. Examples of user packages are in src sub-directories that start with USER. The USER-MISC package is simply a collection of (mostly) unrelated single files, which is the simplest way to have your contribution quickly added to the LAMMPS distribution. You can see a list of the both standard and user packages by typing "make package" in the LAMMPS src directory.
-
-Note that by providing us files to release, you are agreeing to make them open-source, i.e. we can release them under the terms of the GPL, used as a license for the rest of LAMMPS. See Section 1.4 for details.
-
-With user packages and files, all we are really providing (aside from the fame and fortune that accompanies having your name in the source code and on the Authors page of the LAMMPS WWW site), is a means for you to distribute your work to the LAMMPS user community, and a mechanism for others to easily try out your new feature. This may help you find bugs or make contact with new collaborators. Note that you are also implicitly agreeing to support your code which means answer questions, fix bugs, and maintain it if LAMMPS changes in some way that breaks it (an unusual event).
-
-To be able to submit an issue on GitHub, you have to register for an account (for GitHub in general). If you do not want to do that, or have other reservations or difficulties to submit a pull request, you can - as an alternative - contact one or more of the core LAMMPS developers and ask if one of them would be interested in manually merging your code into LAMMPS and send them your source code. Since the effort to merge a pull request is a small fraction of the effort of integrating source code manually (which would usually be done by converting the contribution into a pull request), your chances to have your new code included quickly are the best with a pull request.
-
-If you prefer to submit patches or full files, you should first make certain, that your code works correctly with the latest patch-level version of LAMMPS and contains all bug fixes from it. Then create a gzipped tar file of all changed or added files or a corresponding patch file using 'diff -u' or 'diff -c' and compress it with gzip. Please only use gzip compression, as this works well on all platforms.
 
 ## GitHub Workflows
 
@@ -102,17 +78,17 @@ This section briefly summarizes the steps that will happen **after** you have su
 
 After submitting an issue, one or more of the LAMMPS developers will review it and categorize it by assigning labels. Confirmed bug reports will be labeled `bug`; if the bug report also contains a suggestion for how to fix it, it will be labeled `bugfix`; if the issue is a feature request, it will be labeled `enhancement`. Other labels may be attached as well, depending on which parts of the LAMMPS code are affected. If the assessment is, that the issue does not warrant any changes, the `wontfix` label will be applied and if the submission is incorrect or something that should not be submitted as an issue, the `invalid` label will be applied. In both of the last two cases, the issue will then be closed without further action.
 
-For feature requests, what happens next is that developers may comment on the viability or relevance of the request, discuss and make suggestions for how to implement it. If a LAMMPS developer or user is planning to implement the feature, the issue will be assigned to that developer. For developers, that are not yet listed as LAMMPS project collaborators, they will receive an invitation to be added to the LAMMPS project as a collaborator so they can get assigned. If the requested feature or enhancement is implemented, it will usually be submitted as a pull request, which will contain a reference to the issue number. And once the pull request is reviewed and accepted for inclusion into LAMMPS, the issue will be closed. For details on how pull requests are processed, please see below.
+For feature requests, what happens next is that developers may comment on the viability or relevance of the request, discuss and make suggestions for how to implement it. If a LAMMPS developer or user is planning to implement the feature, the issue will be assigned to that developer. For developers, that are not yet listed as LAMMPS project collaborators, they will receive an invitation to be added to the LAMMPS project as a collaborator so they can get assigned. If the requested feature or enhancement is implemented, it will be submitted as a pull request, which will contain a reference to the issue number. And once the pull request is reviewed and accepted for inclusion into LAMMPS, the issue will be closed. For details on how pull requests are processed, please see below. Feature requests may be labeled with `volunteer_needed` if none of the LAMMPS developers has the time and the required knowledge implement the feature.
 
-For bug reports, the next step is that one of the core LAMMPS developers will self-assign to the issue and try to confirm the bug. If confirmed, the `bug` label and potentially other labels are added to classify the issue and its impact to LAMMPS. Before confirming, further questions may be asked or requests for providing additional input files or details about the steps required to reproduce the issue. Any bugfix is likely to be submitted as a pull request (more about that below) and since most bugs require only local changes, the bugfix may be included in a pull request specifically set up to collect such local bugfixes or small enhancements. Once the bugfix is included in the master branch, the issue will be closed.
+For bug reports, the next step is that one of the core LAMMPS developers will self-assign to the issue and try to confirm the bug. If confirmed, the `bug` label and potentially other labels are added to classify the issue and its impact to LAMMPS. Otherwise the `unconfirmed` label will be applied and some comment about what was tried to confirm the bug added. Before confirming, further questions may be asked or requests for providing additional input files or details about the steps required to reproduce the issue. Any bugfix will be submitted as a pull request (more about that below) and since most bugs require only local changes, the bugfix may be included in a pull request specifically set up to collect such local bugfixes or small enhancements. Once the bugfix is included in the master branch, the issue will be closed.
 
 ### Pull Requests
 
-For submitting pull requests, there is a [detailed tutorial](https://lammps.sandia.gov/doc/Howto_github.html) in the LAMMPS manual. Thus only a brief breakdown of the steps is presented here. Please note, that the LAMMPS developers are still reviewing and trying to improve the process. If you are unsure about something, do not hesitate to post a question on the lammps-users mailing list or contact one fo the core LAMMPS developers.
-Immediately after the submission, the LAMMPS continuing integration server at ci.lammps.org will download your submitted branch and perform a simple compilation test, i.e. will test whether your submitted code can be compiled under various conditions. It will also do a check on whether your included documentation translates cleanly. Whether these tests are successful or fail will be recorded. If a test fails, please inspect the corresponding output on the CI server and take the necessary steps, if needed, so that the code can compile cleanly again. The test will be re-run each the pull request is updated with a push to the remote branch on GitHub.
-Next a LAMMPS core developer will self-assign and do an overall technical assessment of the submission. If you are not yet registered as a LAMMPS collaborator, you will receive an invitation for that. As part of the assessment, the pull request will be categorized with labels. There are two special labels: `needs_work` (indicates that work from the submitter of the pull request is needed) and `work_in_progress` (indicates, that the assigned LAMMPS developer will make changes, if not done by the contributor who made the submit). 
+Pull requests are the **only** way that changes get made to the LAMMPS distribution.  So also the LAMMPS core developers will submit pull requests for their own changes and discuss them on GitHub.  Thus if you submit a pull request it will be treated in a similar fashion. When you submit a pull request you may opt to submit a "Draft" pull request.  That means your changes are visible and will be subject to testing, but reviewers will not be (auto-)assigned and comments will take into account that this is not complete. On the other hand, this is a perfect way to ask the LAMMPS developers for comments on non-obvious changes and get feedback and possible suggestions for improvements or recommendations about what to avoid.
+Immediately after the submission, the LAMMPS continuing integration server at ci.lammps.org will download your submitted branch and perform a number of tests: it will tests whether it compiles cleanly under various conditions, it will also do a check on whether your included documentation translates cleanly and run some unit tests and other checks. Whether these tests are successful or fail will be recorded.  If a test fails, please inspect the corresponding output on the CI server and take the necessary steps, if needed, so that the code can compile cleanly again.  The test will be re-run each time the pull request is updated with a push to the remote branch on GitHub.  If you are unsure about what you need to change, ask a question in the discussion area of the pull request.
+Next a LAMMPS core developer will self-assign and do an overall technical assessment of the submission.  If you submitted a draft pull request, this will not happen unless you mark it "ready for review".  If you are not yet invited as a LAMMPS collaborator, and your contribution seems significant, you may also receive an invitation for collaboration on the LAMMPS repository.  As part of the assessment, the pull request will be categorized with labels. There are two special labels: `needs_work` (indicates that work from the submitter of the pull request is needed) and `work_in_progress` (indicates, that the assigned LAMMPS developer will make changes, if not done by the contributor who made the submit). 
 You may also receive comments and suggestions on the overall submission or specific details and on occasion specific requests for changes as part of the review. If permitted, also additional changes may be pushed into your pull request branch or a pull request may be filed in your LAMMPS fork on GitHub to include those changes.
 The LAMMPS developer may then decide to assign the pull request to another developer (e.g. when that developer is more knowledgeable about the submitted feature or enhancement or has written the modified code). It may also happen, that additional developers are requested to provide a review and approve the changes. For submissions, that may change the general behavior of LAMMPS, or where a possibility of unwanted side effects exists, additional tests may be requested by the assigned developer.
-If the assigned developer is satisfied and considers the submission ready for inclusion into LAMMPS, the pull request will receive approvals and be merged into the master branch by one of the core LAMMPS developers. After the pull request is merged, you may delete the feature branch used for the pull request in your personal LAMMPS fork.
-Since the learning curve for git is quite steep for efficiently managing remote repositories, local and remote branches, pull requests and more, do not hesitate to ask questions, if you are not sure about how to do certain steps that are asked of you. Even if the changes asked of you do not make sense to you, they may be important for the LAMMPS developers. Please also note, that these all are guidelines and nothing set in stone. So depending on the nature of the contribution, the workflow may be adjusted.
+If the assigned developer is satisfied and considers the submission ready for inclusion into LAMMPS, the pull request will receive approvals and be merged into the master branch by one of the core LAMMPS developers. After the pull request is merged, you may delete the feature branch used for the pull request in your personal LAMMPS fork.  The minimum requirement to merge a pull request is that all automated tests have to pass and at least one LAMMPS developer has approved integrating the submitted code. Since the approver will not be the person merging a pull request, you will have at least two LAMMPS developers that looked at your contribution.
+Since the learning curve for git is quite steep for efficiently managing remote repositories, local and remote branches, pull requests and more, do not hesitate to ask questions, if you are not sure about how to do certain steps that are asked of you. Even if the changes asked of you do not make sense to you, they may be important for the LAMMPS developers. Please also note, that these all are guidelines and nothing set in stone. So depending on the nature of the contribution, the work flow may be adjusted.
 

.gitignore

@@ -44,6 +44,8 @@ Thumbs.db
 /build*
 /CMakeCache.txt
 /CMakeFiles/
+/Testing
 /Makefile
+/Testing
 /cmake_install.cmake
 /lmp

cmake/.coveragerc.in

@@ -0,0 +1,10 @@
+[run]
+source = @LAMMPS_PYTHON_DIR@
+parallel=True
+branch=True
+omit=*/install.py
+     */setup.py
+
+[paths]
+sources = python
+          @LAMMPS_PYTHON_DIR@

cmake/CMakeLists.txt

@@ -36,7 +36,11 @@ find_package(Git)
 
 # by default, install into $HOME/.local (not /usr/local), so that no root access (and sudo!!) is needed
 if(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)
-  set(CMAKE_INSTALL_PREFIX "$ENV{HOME}/.local" CACHE PATH "Default install path" FORCE)
+  if((CMAKE_SYSTEM_NAME STREQUAL "Windows") AND (NOT CMAKE_CROSSCOMPILING))
+    set(CMAKE_INSTALL_PREFIX "$ENV{USERPROFILE}/LAMMPS" CACHE PATH "Default install path" FORCE)
+  else()
+    set(CMAKE_INSTALL_PREFIX "$ENV{HOME}/.local" CACHE PATH "Default install path" FORCE)
+  endif()
 endif()
 
 # If enabled, no need to use LD_LIBRARY_PATH / DYLD_LIBRARY_PATH when installed
@@ -77,7 +81,7 @@ check_for_autogen_files(${LAMMPS_SOURCE_DIR})
 include(CheckIncludeFileCXX)
 
 # set required compiler flags and compiler/CPU arch specific optimizations
-if(CMAKE_CXX_COMPILER_ID STREQUAL "Intel")
+if((CMAKE_CXX_COMPILER_ID STREQUAL "Intel") OR (CMAKE_CXX_COMPILER_ID STREQUAL "IntelLLVM"))
   set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -restrict")
   if(CMAKE_CXX_COMPILER_VERSION VERSION_EQUAL 17.3 OR CMAKE_CXX_COMPILER_VERSION VERSION_EQUAL 17.4)
     set(CMAKE_TUNE_DEFAULT "-xCOMMON-AVX512")
@@ -90,6 +94,10 @@ endif()
 set(CMAKE_CXX_STANDARD 11)
 set(CMAKE_CXX_STANDARD_REQUIRED ON)
 set(CMAKE_CXX_EXTENSIONS OFF CACHE BOOL "Use compiler extensions")
+# ugly hack for MSVC which by default always reports an old C++ standard in the __cplusplus macro
+if(MSVC)
+  add_compile_options(/Zc:__cplusplus)
+endif()
 
 # export all symbols when building a .dll file on windows
 if((CMAKE_SYSTEM_NAME STREQUAL "Windows") AND BUILD_SHARED_LIBS)
@@ -161,9 +169,15 @@ set(STANDARD_PACKAGES
   DPD-SMOOTH
   DRUDE
   EFF
+  EXTRA-COMPUTE
+  EXTRA-DUMP
+  EXTRA-FIX
+  EXTRA-MOLECULE
+  EXTRA-PAIR
   FEP
   GRANULAR
   H5MD
+  INTERLAYER
   KIM
   KSPACE
   LATBOLTZ
@@ -190,6 +204,7 @@ set(STANDARD_PACKAGES
   MPIIO
   MSCG
   NETCDF
+  ORIENT
   PERI
   PHONON
   PLUGIN
@@ -212,7 +227,6 @@ set(STANDARD_PACKAGES
   SRD
   TALLY
   UEF
-  USER-MISC
   VORONOI
   VTK
   YAFF)
@@ -238,15 +252,16 @@ if(PKG_ADIOS)
 endif()
 
 if(NOT CMAKE_CROSSCOMPILING)
-  set(MPI_CXX_SKIP_MPICXX TRUE)
   find_package(MPI QUIET)
   option(BUILD_MPI "Build MPI version" ${MPI_FOUND})
 else()
-  set(MPI_CXX_SKIP_MPICXX TRUE)
   option(BUILD_MPI "Build MPI version" OFF)
 endif()
 
 if(BUILD_MPI)
+  # do not include the (obsolete) MPI C++ bindings which makes
+  # for leaner object files and avoids namespace conflicts
+  set(MPI_CXX_SKIP_MPICXX TRUE)
   # We use a non-standard procedure to cross-compile with MPI on Windows
   if((CMAKE_SYSTEM_NAME STREQUAL "Windows") AND CMAKE_CROSSCOMPILING)
     include(MPI4WIN)
@@ -305,6 +320,9 @@ pkg_depends(LATBOLTZ MPI)
 pkg_depends(PHONON KSPACE)
 pkg_depends(SCAFACOS MPI)
 pkg_depends(DIELECTRIC KSPACE)
+pkg_depends(DIELECTRIC EXTRA-PAIR)
+pkg_depends(CG-DNA MOLECULE)
+pkg_depends(CG-DNA ASPHERE)
 
 # detect if we may enable OpenMP support by default
 set(BUILD_OMP_DEFAULT OFF)
@@ -360,6 +378,8 @@ if(PKG_MSCG OR PKG_ATC OR PKG_AWPMD OR PKG_ML-QUIP OR PKG_LATTE)
   endif()
 endif()
 
+# tweak jpeg library names to avoid linker errors with MinGW cross-compilation
+set(JPEG_NAMES libjpeg libjpeg-62)
 find_package(JPEG QUIET)
 option(WITH_JPEG "Enable JPEG support" ${JPEG_FOUND})
 if(WITH_JPEG)
@@ -757,6 +777,13 @@ endif()
 include(Testing)
 include(CodeCoverage)
 include(CodingStandard)
+find_package(ClangFormat 8.0)
+
+if(ClangFormat_FOUND)
+  add_custom_target(format-src
+    COMMAND ${ClangFormat_EXECUTABLE} --verbose -i -style=file *.cpp *.h */*.cpp */*.h
+    WORKING_DIRECTORY ${LAMMPS_SOURCE_DIR})
+endif()
 
 get_target_property(DEFINES lammps COMPILE_DEFINITIONS)
 include(FeatureSummary)

cmake/Modules/CodeCoverage.cmake

@@ -54,6 +54,8 @@ if(ENABLE_COVERAGE)
 
     if(COVERAGE_FOUND)
         set(PYTHON_COVERAGE_HTML_DIR ${CMAKE_BINARY_DIR}/python_coverage_html)
+        configure_file(.coveragerc.in ${CMAKE_BINARY_DIR}/.coveragerc @ONLY)
+
         add_custom_command(
             OUTPUT ${CMAKE_BINARY_DIR}/unittest/python/.coverage
             COMMAND ${COVERAGE_BINARY} combine
@@ -63,16 +65,16 @@ if(ENABLE_COVERAGE)
 
         add_custom_target(
             gen_python_coverage_html
-            COMMAND ${COVERAGE_BINARY} html -d ${PYTHON_COVERAGE_HTML_DIR}
-            DEPENDS ${CMAKE_BINARY_DIR}/unittest/python/.coverage
+            COMMAND ${COVERAGE_BINARY} html --rcfile=${CMAKE_BINARY_DIR}/.coveragerc -d ${PYTHON_COVERAGE_HTML_DIR}
+            DEPENDS ${CMAKE_BINARY_DIR}/unittest/python/.coverage ${CMAKE_BINARY_DIR}/.coveragerc
             WORKING_DIRECTORY ${CMAKE_BINARY_DIR}/unittest/python
             COMMENT "Generating HTML Python coverage report..."
         )
 
         add_custom_target(
             gen_python_coverage_xml
-            COMMAND ${COVERAGE_BINARY} xml -o ${CMAKE_BINARY_DIR}/python_coverage.xml
-            DEPENDS ${CMAKE_BINARY_DIR}/unittest/python/.coverage
+            COMMAND ${COVERAGE_BINARY} xml --rcfile=${CMAKE_BINARY_DIR}/.coveragerc -o ${CMAKE_BINARY_DIR}/python_coverage.xml
+            DEPENDS ${CMAKE_BINARY_DIR}/unittest/python/.coverage ${CMAKE_BINARY_DIR}/.coveragerc
             WORKING_DIRECTORY ${CMAKE_BINARY_DIR}/unittest/python
             COMMENT "Generating XML Python coverage report..."
         )

cmake/Modules/FindFFTW3.cmake

@@ -38,7 +38,7 @@ if(FFTW3_FOUND)
       add_library(FFTW3::FFTW3_OMP UNKNOWN IMPORTED)
       set_target_properties(FFTW3::FFTW3_OMP PROPERTIES
         IMPORTED_LINK_INTERFACE_LANGUAGES "C"
-	IMPORTED_LOCATION "${FFTW3_OMP_LIBRARY}"
+        IMPORTED_LOCATION "${FFTW3_OMP_LIBRARY}"
         INTERFACE_INCLUDE_DIRECTORIES "${FFTW3_INCLUDE_DIRS}")
     endif()
   endif()

cmake/Modules/FindFFTW3F.cmake

@@ -37,7 +37,7 @@ if(FFTW3F_FOUND)
       add_library(FFTW3F::FFTW3F_OMP UNKNOWN IMPORTED)
       set_target_properties(FFTW3F::FFTW3F_OMP PROPERTIES
         IMPORTED_LINK_INTERFACE_LANGUAGES "C"
-	IMPORTED_LOCATION "${FFTW3F_OMP_LIBRARY}"
+        IMPORTED_LOCATION "${FFTW3F_OMP_LIBRARY}"
         INTERFACE_INCLUDE_DIRECTORIES "${FFTW3F_INCLUDE_DIRS}")
     endif()
   endif()

cmake/Modules/OpenCLLoader.cmake

@@ -1,6 +1,6 @@
 message(STATUS "Downloading and building OpenCL loader library")
-set(OPENCL_LOADER_URL "${LAMMPS_THIRDPARTY_URL}/opencl-loader-2021.05.02.tar.gz" CACHE STRING "URL for OpenCL loader tarball")
-set(OPENCL_LOADER_MD5 "29180b05056578afda92f0d394c3a373" CACHE STRING "MD5 checksum of OpenCL loader tarball")
+set(OPENCL_LOADER_URL "${LAMMPS_THIRDPARTY_URL}/opencl-loader-2021.09.18.tar.gz" CACHE STRING "URL for OpenCL loader tarball")
+set(OPENCL_LOADER_MD5 "3b3882627964bd02e5c3b02065daac3c" CACHE STRING "MD5 checksum of OpenCL loader tarball")
 mark_as_advanced(OPENCL_LOADER_URL)
 mark_as_advanced(OPENCL_LOADER_MD5)
 

cmake/Modules/Packages/GPU.cmake

@@ -71,44 +71,47 @@ if(GPU_API STREQUAL "CUDA")
   # build arch/gencode commands for nvcc based on CUDA toolkit version and use choice
   # --arch translates directly instead of JIT, so this should be for the preferred or most common architecture
   set(GPU_CUDA_GENCODE "-arch=${GPU_ARCH}")
-  # Fermi (GPU Arch 2.x) is supported by CUDA 3.2 to CUDA 8.0
-  if((CUDA_VERSION VERSION_GREATER_EQUAL "3.2") AND (CUDA_VERSION VERSION_LESS "9.0"))
-    string(APPEND GPU_CUDA_GENCODE " -gencode arch=compute_20,code=[sm_20,compute_20] ")
-  endif()
-  # Kepler (GPU Arch 3.0) is supported by CUDA 5 to CUDA 10.2
-  if((CUDA_VERSION VERSION_GREATER_EQUAL "5.0") AND (CUDA_VERSION VERSION_LESS "11.0"))
-    string(APPEND GPU_CUDA_GENCODE " -gencode arch=compute_30,code=[sm_30,compute_30] ")
-  endif()
-  # Kepler (GPU Arch 3.5) is supported by CUDA 5 to CUDA 11
-  if((CUDA_VERSION VERSION_GREATER_EQUAL "5.0") AND (CUDA_VERSION VERSION_LESS "12.0"))
-    string(APPEND GPU_CUDA_GENCODE " -gencode arch=compute_35,code=[sm_35,compute_35]")
-  endif()
-  # Maxwell (GPU Arch 5.x) is supported by CUDA 6 and later
-  if(CUDA_VERSION VERSION_GREATER_EQUAL "6.0")
-    string(APPEND GPU_CUDA_GENCODE " -gencode arch=compute_50,code=[sm_50,compute_50] -gencode arch=compute_52,code=[sm_52,compute_52]")
-  endif()
-  # Pascal (GPU Arch 6.x) is supported by CUDA 8 and later
-  if(CUDA_VERSION VERSION_GREATER_EQUAL "8.0")
-    string(APPEND GPU_CUDA_GENCODE " -gencode arch=compute_60,code=[sm_60,compute_60] -gencode arch=compute_61,code=[sm_61,compute_61]")
-  endif()
-  # Volta (GPU Arch 7.0) is supported by CUDA 9 and later
-  if(CUDA_VERSION VERSION_GREATER_EQUAL "9.0")
-    string(APPEND GPU_CUDA_GENCODE " -gencode arch=compute_70,code=[sm_70,compute_70]")
-  endif()
-  # Turing (GPU Arch 7.5) is supported by CUDA 10 and later
-  if(CUDA_VERSION VERSION_GREATER_EQUAL "10.0")
-    string(APPEND GPU_CUDA_GENCODE " -gencode arch=compute_75,code=[sm_75,compute_75]")
-  endif()
-  # Ampere (GPU Arch 8.0) is supported by CUDA 11 and later
-  if(CUDA_VERSION VERSION_GREATER_EQUAL "11.0")
-    string(APPEND GPU_CUDA_GENCODE " -gencode arch=compute_80,code=[sm_80,compute_80]")
-  endif()
-  # Ampere (GPU Arch 8.6) is supported by CUDA 11.1 and later
-  if(CUDA_VERSION VERSION_GREATER_EQUAL "11.1")
-    string(APPEND GPU_CUDA_GENCODE " -gencode arch=compute_86,code=[sm_86,compute_86]")
-  endif()
+
+  # apply the following to build "fat" CUDA binaries only for known CUDA toolkits
   if(CUDA_VERSION VERSION_GREATER_EQUAL "12.0")
-    message(WARNING "Unsupported CUDA version. Use at your own risk.")
+    message(WARNING "Untested CUDA Toolkit version. Use at your own risk")
+  else()
+    # Fermi (GPU Arch 2.x) is supported by CUDA 3.2 to CUDA 8.0
+    if((CUDA_VERSION VERSION_GREATER_EQUAL "3.2") AND (CUDA_VERSION VERSION_LESS "9.0"))
+      string(APPEND GPU_CUDA_GENCODE " -gencode arch=compute_20,code=[sm_20,compute_20] ")
+    endif()
+    # Kepler (GPU Arch 3.0) is supported by CUDA 5 to CUDA 10.2
+    if((CUDA_VERSION VERSION_GREATER_EQUAL "5.0") AND (CUDA_VERSION VERSION_LESS "11.0"))
+      string(APPEND GPU_CUDA_GENCODE " -gencode arch=compute_30,code=[sm_30,compute_30] ")
+    endif()
+    # Kepler (GPU Arch 3.5) is supported by CUDA 5 to CUDA 11
+    if((CUDA_VERSION VERSION_GREATER_EQUAL "5.0") AND (CUDA_VERSION VERSION_LESS "12.0"))
+      string(APPEND GPU_CUDA_GENCODE " -gencode arch=compute_35,code=[sm_35,compute_35]")
+    endif()
+    # Maxwell (GPU Arch 5.x) is supported by CUDA 6 and later
+    if(CUDA_VERSION VERSION_GREATER_EQUAL "6.0")
+      string(APPEND GPU_CUDA_GENCODE " -gencode arch=compute_50,code=[sm_50,compute_50] -gencode arch=compute_52,code=[sm_52,compute_52]")
+    endif()
+    # Pascal (GPU Arch 6.x) is supported by CUDA 8 and later
+    if(CUDA_VERSION VERSION_GREATER_EQUAL "8.0")
+      string(APPEND GPU_CUDA_GENCODE " -gencode arch=compute_60,code=[sm_60,compute_60] -gencode arch=compute_61,code=[sm_61,compute_61]")
+    endif()
+    # Volta (GPU Arch 7.0) is supported by CUDA 9 and later
+    if(CUDA_VERSION VERSION_GREATER_EQUAL "9.0")
+      string(APPEND GPU_CUDA_GENCODE " -gencode arch=compute_70,code=[sm_70,compute_70]")
+    endif()
+    # Turing (GPU Arch 7.5) is supported by CUDA 10 and later
+    if(CUDA_VERSION VERSION_GREATER_EQUAL "10.0")
+      string(APPEND GPU_CUDA_GENCODE " -gencode arch=compute_75,code=[sm_75,compute_75]")
+    endif()
+    # Ampere (GPU Arch 8.0) is supported by CUDA 11 and later
+    if(CUDA_VERSION VERSION_GREATER_EQUAL "11.0")
+      string(APPEND GPU_CUDA_GENCODE " -gencode arch=compute_80,code=[sm_80,compute_80]")
+    endif()
+    # Ampere (GPU Arch 8.6) is supported by CUDA 11.1 and later
+    if(CUDA_VERSION VERSION_GREATER_EQUAL "11.1")
+      string(APPEND GPU_CUDA_GENCODE " -gencode arch=compute_86,code=[sm_86,compute_86]")
+    endif()
   endif()
 
   cuda_compile_fatbin(GPU_GEN_OBJS ${GPU_LIB_CU} OPTIONS ${CUDA_REQUEST_PIC}
@@ -214,13 +217,20 @@ elseif(GPU_API STREQUAL "OPENCL")
 elseif(GPU_API STREQUAL "HIP")
   if(NOT DEFINED HIP_PATH)
       if(NOT DEFINED ENV{HIP_PATH})
-          set(HIP_PATH "/opt/rocm/hip" CACHE PATH "Path to which HIP has been installed")
+          set(HIP_PATH "/opt/rocm/hip" CACHE PATH "Path to HIP installation")
       else()
-          set(HIP_PATH $ENV{HIP_PATH} CACHE PATH "Path to which HIP has been installed")
+          set(HIP_PATH $ENV{HIP_PATH} CACHE PATH "Path to HIP installation")
       endif()
   endif()
-  set(CMAKE_MODULE_PATH "${HIP_PATH}/cmake" ${CMAKE_MODULE_PATH})
-  find_package(HIP REQUIRED)
+  if(NOT DEFINED ROCM_PATH)
+      if(NOT DEFINED ENV{ROCM_PATH})
+          set(ROCM_PATH "/opt/rocm" CACHE PATH "Path to ROCm installation")
+      else()
+          set(ROCM_PATH $ENV{ROCM_PATH} CACHE PATH "Path to ROCm installation")
+      endif()
+  endif()
+  list(APPEND CMAKE_PREFIX_PATH ${HIP_PATH} ${ROCM_PATH})
+  find_package(hip REQUIRED)
   option(HIP_USE_DEVICE_SORT "Use GPU sorting" ON)
 
   if(NOT DEFINED HIP_PLATFORM)
@@ -322,10 +332,11 @@ elseif(GPU_API STREQUAL "HIP")
 
   set_directory_properties(PROPERTIES ADDITIONAL_MAKE_CLEAN_FILES "${LAMMPS_LIB_BINARY_DIR}/gpu/*_cubin.h ${LAMMPS_LIB_BINARY_DIR}/gpu/*.cu.cpp")
 
-  hip_add_library(gpu STATIC ${GPU_LIB_SOURCES})
+  add_library(gpu STATIC ${GPU_LIB_SOURCES})
   target_include_directories(gpu PRIVATE ${LAMMPS_LIB_BINARY_DIR}/gpu)
   target_compile_definitions(gpu PRIVATE -D_${GPU_PREC_SETTING} -DMPI_GERYON -DUCL_NO_EXIT)
   target_compile_definitions(gpu PRIVATE -DUSE_HIP)
+  target_link_libraries(gpu PRIVATE hip::host)
 
   if(HIP_USE_DEVICE_SORT)
     # add hipCUB
@@ -374,8 +385,9 @@ elseif(GPU_API STREQUAL "HIP")
     endif()
   endif()
 
-  hip_add_executable(hip_get_devices ${LAMMPS_LIB_SOURCE_DIR}/gpu/geryon/ucl_get_devices.cpp)
+  add_executable(hip_get_devices ${LAMMPS_LIB_SOURCE_DIR}/gpu/geryon/ucl_get_devices.cpp)
   target_compile_definitions(hip_get_devices PRIVATE -DUCL_HIP)
+  target_link_libraries(hip_get_devices hip::host)
 
   if(HIP_PLATFORM STREQUAL "nvcc")
     target_compile_definitions(gpu PRIVATE -D__HIP_PLATFORM_NVCC__)

cmake/Modules/Packages/INTEL.cmake

@@ -3,7 +3,7 @@ if(NOT FOUND_IMMINTRIN)
   message(FATAL_ERROR "immintrin.h header not found, Intel package won't work without it")
 endif()
 
-target_compile_definitions(lammps PRIVATE -DLMP_USER_INTEL)
+target_compile_definitions(lammps PRIVATE -DLMP_INTEL)
 
 set(INTEL_ARCH "cpu" CACHE STRING "Architectures used by INTEL (cpu or knl)")
 set(INTEL_ARCH_VALUES cpu knl)

cmake/Modules/Packages/KOKKOS.cmake

@@ -1,6 +1,8 @@
 ########################################################################
 # As of version 3.3.0 Kokkos requires C++14
-set(CMAKE_CXX_STANDARD 14)
+if(CMAKE_CXX_STANDARD LESS 14)
+  set(CMAKE_CXX_STANDARD 14)
+endif()
 ########################################################################
 # consistency checks and Kokkos options/settings required by LAMMPS
 if(Kokkos_ENABLE_CUDA)
@@ -74,11 +76,12 @@ else()
   target_link_libraries(lammps PRIVATE kokkos)
   target_link_libraries(lmp PRIVATE kokkos)
 endif()
-target_compile_definitions(lammps PRIVATE -DLMP_KOKKOS)
+target_compile_definitions(lammps PUBLIC $<BUILD_INTERFACE:LMP_KOKKOS>)
 
 set(KOKKOS_PKG_SOURCES_DIR ${LAMMPS_SOURCE_DIR}/KOKKOS)
 set(KOKKOS_PKG_SOURCES ${KOKKOS_PKG_SOURCES_DIR}/kokkos.cpp
                        ${KOKKOS_PKG_SOURCES_DIR}/atom_kokkos.cpp
+                       ${KOKKOS_PKG_SOURCES_DIR}/atom_map_kokkos.cpp
                        ${KOKKOS_PKG_SOURCES_DIR}/atom_vec_kokkos.cpp
                        ${KOKKOS_PKG_SOURCES_DIR}/comm_kokkos.cpp
                        ${KOKKOS_PKG_SOURCES_DIR}/comm_tiled_kokkos.cpp
@@ -126,4 +129,4 @@ endif()
 get_property(KOKKOS_PKG_SOURCES GLOBAL PROPERTY KOKKOS_PKG_SOURCES)
 
 target_sources(lammps PRIVATE ${KOKKOS_PKG_SOURCES})
-target_include_directories(lammps PRIVATE ${KOKKOS_PKG_SOURCES_DIR})
+target_include_directories(lammps PUBLIC $<BUILD_INTERFACE:${KOKKOS_PKG_SOURCES_DIR}>)

cmake/Modules/Packages/LATTE.cmake

@@ -19,6 +19,14 @@ if(DOWNLOAD_LATTE)
   set(LATTE_MD5 "820e73a457ced178c08c71389a385de7" CACHE STRING "MD5 checksum of LATTE tarball")
   mark_as_advanced(LATTE_URL)
   mark_as_advanced(LATTE_MD5)
+
+  # CMake cannot pass BLAS or LAPACK library variable to external project if they are a list
+  list(LENGTH BLAS_LIBRARIES} NUM_BLAS)
+  list(LENGTH LAPACK_LIBRARIES NUM_LAPACK)
+  if((NUM_BLAS GREATER 1) OR (NUM_LAPACK GREATER 1))
+    message(FATAL_ERROR "Cannot compile downloaded LATTE library due to a technical limitation")
+  endif()
+
   include(ExternalProject)
   ExternalProject_Add(latte_build
     URL     ${LATTE_URL}

cmake/Modules/Packages/MACHDYN.cmake

@@ -7,8 +7,9 @@ endif()
 option(DOWNLOAD_EIGEN3 "Download Eigen3 instead of using an already installed one)" ${DOWNLOAD_EIGEN3_DEFAULT})
 if(DOWNLOAD_EIGEN3)
   message(STATUS "Eigen3 download requested - we will build our own")
-  set(EIGEN3_URL "https://gitlab.com/libeigen/eigen/-/archive/3.3.7/eigen-3.3.7.tar.gz" CACHE STRING "URL for Eigen3 tarball")
-  set(EIGEN3_MD5 "9e30f67e8531477de4117506fe44669b" CACHE STRING "MD5 checksum of Eigen3 tarball")
+
+  set(EIGEN3_URL "https://download.lammps.org/thirdparty/eigen-3.4.0.tar.gz" CACHE STRING "URL for Eigen3 tarball")
+  set(EIGEN3_MD5 "4c527a9171d71a72a9d4186e65bea559" CACHE STRING "MD5 checksum of Eigen3 tarball")
   mark_as_advanced(EIGEN3_URL)
   mark_as_advanced(EIGEN3_MD5)
   include(ExternalProject)
@@ -30,3 +31,8 @@ else()
   endif()
   target_link_libraries(lammps PRIVATE Eigen3::Eigen)
 endif()
+
+# PGI/Nvidia compiler internals collide with vector intrinsics support in Eigen3
+if((CMAKE_CXX_COMPILER_ID STREQUAL "PGI") OR (CMAKE_CXX_COMPILER_ID STREQUAL "NVHPC"))
+  target_compile_definitions(lammps PRIVATE -DEIGEN_DONT_VECTORIZE)
+endif()

cmake/Modules/Packages/MDI.cmake

@@ -114,5 +114,5 @@ else()
   target_link_libraries(lmp PRIVATE ${mdi_LIBRARY})
 endif()
 
-target_compile_definitions(lammps PRIVATE -DLMP_USER_MDI)
-target_compile_definitions(lmp PRIVATE -DLMP_USER_MDI)
+target_compile_definitions(lammps PRIVATE -DLMP_MDI)
+target_compile_definitions(lmp PRIVATE -DLMP_MDI)

cmake/Modules/Packages/ML-HDNNP.cmake

@@ -45,12 +45,12 @@ if(DOWNLOAD_N2P2)
     # get path to MPI include directory when cross-compiling to windows
     if((CMAKE_SYSTEM_NAME STREQUAL Windows) AND CMAKE_CROSSCOMPILING)
       get_target_property(N2P2_MPI_INCLUDE MPI::MPI_CXX INTERFACE_INCLUDE_DIRECTORIES)
-      set(N2P2_PROJECT_OPTIONS "-I ${N2P2_MPI_INCLUDE} -DMPICH_SKIP_MPICXX=1")
+      set(N2P2_PROJECT_OPTIONS "-I${N2P2_MPI_INCLUDE}")
       set(MPI_CXX_COMPILER ${CMAKE_CXX_COMPILER})
     endif()
     if(CMAKE_CXX_COMPILER_ID STREQUAL "Intel")
       get_target_property(N2P2_MPI_INCLUDE MPI::MPI_CXX INTERFACE_INCLUDE_DIRECTORIES)
-      set(N2P2_PROJECT_OPTIONS "-I ${N2P2_MPI_INCLUDE} -DMPICH_SKIP_MPICXX=1")
+      set(N2P2_PROJECT_OPTIONS "-I${N2P2_MPI_INCLUDE}")
       set(MPI_CXX_COMPILER ${CMAKE_CXX_COMPILER})
     endif()
   endif()
@@ -69,6 +69,12 @@ if(DOWNLOAD_N2P2)
   # echo final flag for debugging
   message(STATUS "N2P2 BUILD OPTIONS: ${N2P2_BUILD_OPTIONS}")
 
+  # must have "sed" command to compile n2p2 library (for now)
+  find_program(HAVE_SED sed)
+  if(NOT HAVE_SED)
+    message(FATAL_ERROR "Must have 'sed' program installed to compile 'n2p2' library for ML-HDNNP package")
+  endif()
+
   # download compile n2p2 library. much patch MPI calls in LAMMPS interface to accommodate MPI-2 (e.g. for cross-compiling)
   include(ExternalProject)
   ExternalProject_Add(n2p2_build

cmake/Modules/Packages/ML-QUIP.cmake

@@ -1,3 +1,70 @@
 enable_language(Fortran)
-find_package(QUIP REQUIRED)
-target_link_libraries(lammps PRIVATE QUIP::QUIP ${LAPACK_LIBRARIES})
+find_package(QUIP QUIET)
+
+if(QUIP_FOUND)
+  set(DOWNLOAD_QUIP_DEFAULT OFF)
+else()
+  set(DOWNLOAD_QUIP_DEFAULT ON)
+endif()
+option(DOWNLOAD_QUIP "Download the QUIP library instead of using an already installed one" ${DOWNLOAD_QUIP_DEFAULT})
+if(DOWNLOAD_QUIP)
+  string(TOUPPER "${CMAKE_BUILD_TYPE}" BTYPE)
+  set(temp "F77 = ${CMAKE_Fortran_COMPILER}\nF90 = ${CMAKE_Fortran_COMPILER}\nF95 = ${CMAKE_Fortran_COMPILER}\n")
+  set(temp "${temp}CC=${CMAKE_C_COMPILER}\nCPLUSPLUS=${CMAKE_CXX_COMPILER}\nLINKER=${CMAKE_Fortran_COMPILER}\n")
+  if(CMAKE_Fortran_COMPILER_ID STREQUAL Intel)
+    set(temp "${temp}FPP=${CMAKE_Fortran_COMPILER} -E\nOPTIM=${CMAKE_Fortran_FLAGS_${BTYPE}}\n")
+    set(temp "${temp}DEFINES += -DGETARG_F2003 -DFORTRAN_UNDERSCORE\n")
+    set(temp "${temp}F95FLAGS += -fpp -free -fPIC\n")
+    set(temp "${temp}F77FLAGS += -fpp -fixed -fPIC\n")
+  elseif(CMAKE_Fortran_COMPILER_ID STREQUAL GNU)
+    set(temp "${temp}FPP=${CMAKE_Fortran_COMPILER} -E -x f95-cpp-input\nOPTIM=${CMAKE_Fortran_FLAGS_${BTYPE}}\n")
+    set(temp "${temp}DEFINES += -DGETARG_F2003 -DGETENV_F2003 -DGFORTRAN -DFORTRAN_UNDERSCORE\n")
+    set(temp "${temp}F95FLAGS += -x f95-cpp-input -ffree-line-length-none -ffree-form -fno-second-underscore -fPIC\n")
+    set(temp "${temp}F77FLAGS += -x f77-cpp-input -fno-second-underscore -fPIC\n")
+  else()
+    message(FATAL_ERROR "The ${CMAKE_Fortran_COMPILER_ID} Fortran compiler is not (yet) supported for building QUIP")
+  endif()
+  set(temp "${temp}CFLAGS += -fPIC \nCPLUSPLUSFLAGS += -fPIC\nAR_ADD=src\n")
+  set(temp "${temp}MATH_LINKOPTS=")
+  foreach(flag ${BLAS_LIBRARIES})
+    set(temp "${temp} ${flag}")
+  endforeach()
+  foreach(flag ${LAPACK_LIBRARIES})
+    set(temp "${temp} ${flag}")
+  endforeach()
+  set(temp "${temp}\n")
+  set(temp "${temp}PYTHON=python\nPIP=pip\nEXTRA_LINKOPTS=\n")
+  set(temp "${temp}HAVE_CP2K=0\nHAVE_VASP=0\nHAVE_TB=0\nHAVE_PRECON=1\nHAVE_LOTF=0\nHAVE_ONIOM=0\n")
+  set(temp "${temp}HAVE_LOCAL_E_MIX=0\nHAVE_QC=0\nHAVE_GAP=1\nHAVE_DESCRIPTORS_NONCOMMERCIAL=1\n")
+  set(temp "${temp}HAVE_TURBOGAP=0\nHAVE_QR=1\nHAVE_THIRDPARTY=0\nHAVE_FX=0\nHAVE_SCME=0\nHAVE_MTP=0\n")
+  set(temp "${temp}HAVE_MBD=0\nHAVE_TTM_NF=0\nHAVE_CH4=0\nHAVE_NETCDF4=0\nHAVE_MDCORE=0\nHAVE_ASAP=0\n")
+  set(temp "${temp}HAVE_CGAL=0\nHAVE_METIS=0\nHAVE_LMTO_TBE=0\nHAVE_SCALAPACK=0\n")
+  file(WRITE ${CMAKE_BINARY_DIR}/quip.config "${temp}")
+
+  message(STATUS "QUIP download via git requested - we will build our own")
+  # QUIP has no releases (except for a tag marking the end of Python 2 support). We use the current "public" branch
+  # The LAMMPS interface wrapper has a compatibility constant that is being checked at runtime.
+  include(ExternalProject)
+  ExternalProject_Add(quip_build
+    GIT_REPOSITORY "https://github.com/libAtoms/QUIP/"
+    GIT_TAG origin/public
+    GIT_SHALLOW YES
+    GIT_PROGRESS YES
+    PATCH_COMMAND ${CMAKE_COMMAND} -E copy_if_different ${CMAKE_BINARY_DIR}/quip.config <SOURCE_DIR>/arch/Makefile.lammps
+    CONFIGURE_COMMAND env QUIP_ARCH=lammps make config
+    BUILD_COMMAND env QUIP_ARCH=lammps make libquip
+    INSTALL_COMMAND ""
+    BUILD_IN_SOURCE YES
+    BUILD_BYPRODUCTS <SOURCE_DIR>/build/lammps/libquip.a
+  )
+  ExternalProject_get_property(quip_build SOURCE_DIR)
+  add_library(LAMMPS::QUIP UNKNOWN IMPORTED)
+  set_target_properties(LAMMPS::QUIP PROPERTIES
+    IMPORTED_LOCATION "${SOURCE_DIR}/build/lammps/libquip.a"
+    INTERFACE_LINK_LIBRARIES "${LAPACK_LIBRARIES}")
+  target_link_libraries(lammps PRIVATE LAMMPS::QUIP)
+  add_dependencies(LAMMPS::QUIP quip_build)
+else()
+  find_package(QUIP REQUIRED)
+  target_link_libraries(lammps PRIVATE QUIP::QUIP ${LAPACK_LIBRARIES})
+endif()

cmake/Modules/Packages/MSCG.cmake

@@ -12,6 +12,13 @@ if(DOWNLOAD_MSCG)
   mark_as_advanced(MSCG_URL)
   mark_as_advanced(MSCG_MD5)
 
+  # CMake cannot pass BLAS or LAPACK library variable to external project if they are a list
+  list(LENGTH BLAS_LIBRARIES} NUM_BLAS)
+  list(LENGTH LAPACK_LIBRARIES NUM_LAPACK)
+  if((NUM_BLAS GREATER 1) OR (NUM_LAPACK GREATER 1))
+    message(FATAL_ERROR "Cannot compile downloaded MSCG library due to a technical limitation")
+  endif()
+
   include(ExternalProject)
   ExternalProject_Add(mscg_build
     URL     ${MSCG_URL}

cmake/Modules/Packages/OPENMP.cmake

@@ -5,7 +5,7 @@
                        ${OPENMP_SOURCES_DIR}/fix_nh_omp.cpp
                        ${OPENMP_SOURCES_DIR}/fix_nh_sphere_omp.cpp
                        ${OPENMP_SOURCES_DIR}/domain_omp.cpp)
-  target_compile_definitions(lammps PRIVATE -DLMP_USER_OMP)
+  target_compile_definitions(lammps PRIVATE -DLMP_OPENMP)
   set_property(GLOBAL PROPERTY "OMP_SOURCES" "${OPENMP_SOURCES}")
 
   # detects styles which have OPENMP version
@@ -25,15 +25,15 @@
   endif()
 
   if(PKG_REAXFF)
-    list(APPEND OPENMP_SOURCES ${OPENMP_SOURCES_DIR}/reaxc_bond_orders_omp.cpp
-                                 ${OPENMP_SOURCES_DIR}/reaxc_hydrogen_bonds_omp.cpp
-                                 ${OPENMP_SOURCES_DIR}/reaxc_nonbonded_omp.cpp
-                                 ${OPENMP_SOURCES_DIR}/reaxc_bonds_omp.cpp
-                                 ${OPENMP_SOURCES_DIR}/reaxc_init_md_omp.cpp
-                                 ${OPENMP_SOURCES_DIR}/reaxc_torsion_angles_omp.cpp
-                                 ${OPENMP_SOURCES_DIR}/reaxc_forces_omp.cpp
-                                 ${OPENMP_SOURCES_DIR}/reaxc_multi_body_omp.cpp
-                                 ${OPENMP_SOURCES_DIR}/reaxc_valence_angles_omp.cpp)
+    list(APPEND OPENMP_SOURCES ${OPENMP_SOURCES_DIR}/reaxff_bond_orders_omp.cpp
+                                 ${OPENMP_SOURCES_DIR}/reaxff_hydrogen_bonds_omp.cpp
+                                 ${OPENMP_SOURCES_DIR}/reaxff_nonbonded_omp.cpp
+                                 ${OPENMP_SOURCES_DIR}/reaxff_bonds_omp.cpp
+                                 ${OPENMP_SOURCES_DIR}/reaxff_init_md_omp.cpp
+                                 ${OPENMP_SOURCES_DIR}/reaxff_torsion_angles_omp.cpp
+                                 ${OPENMP_SOURCES_DIR}/reaxff_forces_omp.cpp
+                                 ${OPENMP_SOURCES_DIR}/reaxff_multi_body_omp.cpp
+                                 ${OPENMP_SOURCES_DIR}/reaxff_valence_angles_omp.cpp)
   endif()
 
   target_sources(lammps PRIVATE ${OPENMP_SOURCES})

cmake/Modules/Packages/PLUMED.cmake

@@ -54,8 +54,8 @@ if(DOWNLOAD_PLUMED)
     set(PLUMED_BUILD_BYPRODUCTS "<INSTALL_DIR>/lib/libplumedWrapper.a")
   endif()
 
-  set(PLUMED_URL "https://github.com/plumed/plumed2/releases/download/v2.7.1/plumed-src-2.7.1.tgz" CACHE STRING "URL for PLUMED tarball")
-  set(PLUMED_MD5 "4eac6a462ec84dfe0cec96c82421b8e8" CACHE STRING "MD5 checksum of PLUMED tarball")
+  set(PLUMED_URL "https://github.com/plumed/plumed2/releases/download/v2.7.2/plumed-src-2.7.2.tgz" CACHE STRING "URL for PLUMED tarball")
+  set(PLUMED_MD5 "cfa0b4dd90a81c25d3302e8d97bfeaea" CACHE STRING "MD5 checksum of PLUMED tarball")
 
   mark_as_advanced(PLUMED_URL)
   mark_as_advanced(PLUMED_MD5)
@@ -72,7 +72,6 @@ if(DOWNLOAD_PLUMED)
                                              ${PLUMED_CONFIG_OMP}
                                              CXX=${PLUMED_CONFIG_CXX}
                                              CC=${PLUMED_CONFIG_CC}
-    PATCH_COMMAND sed -i "/^#include <algorithm>/a #include <limits>" <SOURCE_DIR>/src/lepton/Operation.h
     BUILD_BYPRODUCTS ${PLUMED_BUILD_BYPRODUCTS}
   )
   ExternalProject_get_property(plumed_build INSTALL_DIR)

cmake/Modules/Packages/SCAFACOS.cmake

@@ -23,6 +23,11 @@ if(DOWNLOAD_SCAFACOS)
   file(DOWNLOAD ${LAMMPS_THIRDPARTY_URL}/scafacos-1.0.1-fix.diff ${CMAKE_CURRENT_BINARY_DIR}/scafacos-1.0.1.fix.diff
           EXPECTED_HASH MD5=4baa1333bb28fcce102d505e1992d032)
 
+  find_program(HAVE_PATCH patch)
+  if(NOT HAVE_PATCH)
+    message(FATAL_ERROR "The 'patch' program is required to build the ScaFaCoS library")
+  endif()
+
   include(ExternalProject)
   ExternalProject_Add(scafacos_build
     URL     ${SCAFACOS_URL}

cmake/Modules/Packages/VORONOI.cmake

@@ -26,6 +26,11 @@ if(DOWNLOAD_VORO)
     set(VORO_BUILD_OPTIONS CXX=${CMAKE_CXX_COMPILER} CFLAGS=${VORO_BUILD_CFLAGS})
   endif()
 
+  find_program(HAVE_PATCH patch)
+  if(NOT HAVE_PATCH)
+    message(FATAL_ERROR "The 'patch' program is required to build the voro++ library")
+  endif()
+
   ExternalProject_Add(voro_build
     URL     ${VORO_URL}
     URL_MD5 ${VORO_MD5}

cmake/Modules/Tools.cmake

@@ -9,14 +9,16 @@ if(BUILD_TOOLS)
     check_language(Fortran)
     if(CMAKE_Fortran_COMPILER)
       enable_language(Fortran)
-      add_executable(chain.x ${LAMMPS_TOOLS_DIR}/chain.f)
+      add_executable(chain.x ${LAMMPS_TOOLS_DIR}/chain.f90)
       target_link_libraries(chain.x PRIVATE ${CMAKE_Fortran_IMPLICIT_LINK_LIBRARIES})
-      install(TARGETS chain.x DESTINATION ${CMAKE_INSTALL_BINDIR})
+      add_executable(micelle2d.x ${LAMMPS_TOOLS_DIR}/micelle2d.f90)
+      target_link_libraries(micelle2d.x PRIVATE ${CMAKE_Fortran_IMPLICIT_LINK_LIBRARIES})
+      install(TARGETS chain.x micelle2d.x DESTINATION ${CMAKE_INSTALL_BINDIR})
     else()
-      message(WARNING "No suitable Fortran compiler found, skipping build of 'chain.x'")
+      message(WARNING "No suitable Fortran compiler found, skipping build of 'chain.x' and 'micelle2d.x'")
     endif()
   else()
-    message(WARNING "CMake build doesn't support fortran, skipping build of 'chain.x'")
+    message(WARNING "CMake build doesn't support Fortran, skipping build of 'chain.x' and 'micelle2d.x'")
   endif()
 
   enable_language(C)

cmake/iwyu/iwyu-extra-map.imp

@@ -1,7 +1,28 @@
 [
-  { include: [ "<bits/types/struct_rusage.h>", private, "<sys/resource.h>", public ] },
-  { include: [ "<bits/exception.h>", public, "<exception>", public ] },
   { include: [ "@<Eigen/.*>", private, "<Eigen/Eigen>", public ] },
   { include: [ "@<gtest/.*>", private, "\"gtest/gtest.h\"", public ] },
   { include: [ "@<gmock/.*>", private, "\"gmock/gmock.h\"", public ] },
+  { include: [ "@<gmock/.*>", private, "\"gmock/gmock.h\"", public ] },
+  { include: [ "@<(cell|c_loops|container).hh>", private, "<voro++.hh>", public ] },
+  { include: [ "@\"atom_vec_.*.h\"", public, "\"style_atom.h\"", public ] },
+  { include: [ "@\"body_.*.h\"", public, "\"style_body.h\"", public ] },
+  { include: [ "@\"compute_.*.h\"", public, "\"style_compute.h\"", public ] },
+  { include: [ "@\"fix_.*.h\"", public, "\"style_fix.h\"", public ] },
+  { include: [ "@\"dump_.*.h\"", public, "\"style_dump.h\"", public ] },
+  { include: [ "@\"min_.*.h\"", public, "\"style_minimize.h\"", public ] },
+  { include: [ "@\"reader_.*.h\"", public, "\"style_reader.h\"", public ] },
+  { include: [ "@\"region_.*.h\"", public, "\"style_region.h\"", public ] },
+  { include: [ "@\"pair_.*.h\"", public, "\"style_pair.h\"", public ] },
+  { include: [ "@\"angle_.*.h\"", public, "\"style_angle.h\"", public ] },
+  { include: [ "@\"bond_.*.h\"", public, "\"style_bond.h\"", public ] },
+  { include: [ "@\"dihedral_.*.h\"", public, "\"style_dihedral.h\"", public ] },
+  { include: [ "@\"improper_.*.h\"", public, "\"style_improper.h\"", public ] },
+  { include: [ "@\"kspace_.*.h\"", public, "\"style_kspace.h\"", public ] },
+  { include: [ "@\"nbin_.*.h\"", public, "\"style_nbin.h\"", public ] },
+  { include: [ "@\"npair_.*.h\"", public, "\"style_npair.h\"", public ] },
+  { include: [ "@\"nstenci_.*.h\"", public, "\"style_nstencil.h\"", public ] },
+  { include: [ "@\"ntopo_.*.h\"", public, "\"style_ntopo.h\"", public ] },
+  { include: [ "<float.h>",   public, "<cfloat>", public ] },
+  { include: [ "<limits.h>",  public, "<climits>", public ] },
+  { include: [ "<bits/types/struct_tm.h>", private, "<ctime>", public ] },
 ]

cmake/presets/all_off.cmake

@@ -25,11 +25,17 @@ set(ALL_PACKAGES
   DPD-SMOOTH
   DRUDE
   EFF
+  EXTRA-COMPUTE
+  EXTRA-DUMP
+  EXTRA-FIX
+  EXTRA-MOLECULE
+  EXTRA-PAIR
   FEP
   GPU
   GRANULAR
   H5MD
   INTEL
+  INTERLAYER
   KIM
   KOKKOS
   KSPACE
@@ -59,6 +65,7 @@ set(ALL_PACKAGES
   NETCDF
   OPENMP
   OPT
+  ORIENT
   PERI
   PHONON
   PLUGIN
@@ -81,7 +88,6 @@ set(ALL_PACKAGES
   SRD
   TALLY
   UEF
-  USER-MISC
   VORONOI
   VTK
   YAFF)

cmake/presets/all_on.cmake

@@ -27,11 +27,17 @@ set(ALL_PACKAGES
   DPD-SMOOTH
   DRUDE
   EFF
+  EXTRA-COMPUTE
+  EXTRA-DUMP
+  EXTRA-FIX
+  EXTRA-MOLECULE
+  EXTRA-PAIR
   FEP
   GPU
   GRANULAR
   H5MD
   INTEL
+  INTERLAYER
   KIM
   KOKKOS
   KSPACE
@@ -61,6 +67,7 @@ set(ALL_PACKAGES
   NETCDF
   OPENMP
   OPT
+  ORIENT
   PERI
   PHONON
   PLUGIN
@@ -83,7 +90,6 @@ set(ALL_PACKAGES
   SRD
   TALLY
   UEF
-  USER-MISC
   VORONOI
   VTK
   YAFF)

cmake/presets/clang.cmake

@@ -10,9 +10,9 @@ set(CMAKE_Fortran_COMPILER ${CLANG_FORTRAN} CACHE STRING "" FORCE)
 set(CMAKE_CXX_FLAGS_DEBUG "-Wall -Wextra -g" CACHE STRING "" FORCE)
 set(CMAKE_CXX_FLAGS_RELWITHDEBINFO "-Wall -Wextra -g -O2 -DNDEBUG" CACHE STRING "" FORCE)
 set(CMAKE_CXX_FLAGS_RELEASE "-O3 -DNDEBUG" CACHE STRING "" FORCE)
-set(CMAKE_Fortran_FLAGS_DEBUG "-Wall -Wextra -g -std=f95" CACHE STRING "" FORCE)
-set(CMAKE_Fortran_FLAGS_RELWITHDEBINFO "-Wall -Wextra -g -O2 -DNDEBUG -std=f95" CACHE STRING "" FORCE)
-set(CMAKE_Fortran_FLAGS_RELEASE "-O3 -DNDEBUG -std=f95" CACHE STRING "" FORCE)
+set(CMAKE_Fortran_FLAGS_DEBUG "-Wall -Wextra -g -std=f2003" CACHE STRING "" FORCE)
+set(CMAKE_Fortran_FLAGS_RELWITHDEBINFO "-Wall -Wextra -g -O2 -DNDEBUG -std=f2003" CACHE STRING "" FORCE)
+set(CMAKE_Fortran_FLAGS_RELEASE "-O3 -DNDEBUG -std=f2003" CACHE STRING "" FORCE)
 set(CMAKE_C_FLAGS_DEBUG "-Wall -Wextra -g" CACHE STRING "" FORCE)
 set(CMAKE_C_FLAGS_RELWITHDEBINFO "-Wall -Wextra -g -O2 -DNDEBUG" CACHE STRING "" FORCE)
 set(CMAKE_C_FLAGS_RELEASE "-O3 -DNDEBUG" CACHE STRING "" FORCE)

cmake/presets/gcc.cmake

@@ -1,4 +1,4 @@
-# preset that will restore gcc/g++ with support for MPI and OpenMP (on Linux boxes)
+# preset that will explicitly request gcc/g++ compilers with support for MPI and OpenMP
 
 set(CMAKE_CXX_COMPILER "g++" CACHE STRING "" FORCE)
 set(CMAKE_C_COMPILER "gcc" CACHE STRING "" FORCE)
@@ -15,9 +15,9 @@ set(CMAKE_C_FLAGS_RELWITHDEBINFO "-g -O2 -DNDEBUG" CACHE STRING "" FORCE)
 set(CMAKE_C_FLAGS_RELEASE "-O3 -DNDEBUG" CACHE STRING "" FORCE)
 set(MPI_Fortran "gfortran" CACHE STRING "" FORCE)
 set(MPI_Fortran_COMPILER "mpifort" CACHE STRING "" FORCE)
-set(CMAKE_Fortran_FLAGS_DEBUG "-Wall -g" CACHE STRING "" FORCE)
-set(CMAKE_Fortran_FLAGS_RELWITHDEBINFO "-g -O2 -DNDEBUG" CACHE STRING "" FORCE)
-set(CMAKE_Fortran_FLAGS_RELEASE "-O3 -DNDEBUG" CACHE STRING "" FORCE)
+set(CMAKE_Fortran_FLAGS_DEBUG "-Wall -g -std=f2003" CACHE STRING "" FORCE)
+set(CMAKE_Fortran_FLAGS_RELWITHDEBINFO "-g -O2 -DNDEBUG -std=f2003" CACHE STRING "" FORCE)
+set(CMAKE_Fortran_FLAGS_RELEASE "-O3 -DNDEBUG -std=f2003" CACHE STRING "" FORCE)
 unset(HAVE_OMP_H_INCLUDE CACHE)
 
 set(OpenMP_C "gcc" CACHE STRING "" FORCE)

cmake/presets/hip.cmake

@@ -1,12 +1,26 @@
-# preset that will enable hipcc plus gcc with support for MPI and OpenMP (on Linux boxes)
+# preset that will enable hipcc plus gcc/gfortran with support for MPI and OpenMP (on Linux boxes)
 
 set(CMAKE_CXX_COMPILER "hipcc" CACHE STRING "" FORCE)
 set(CMAKE_C_COMPILER "gcc" CACHE STRING "" FORCE)
+set(CMAKE_Fortran_COMPILER gfortran CACHE STRING "" FORCE)
 set(CMAKE_CXX_FLAGS_DEBUG "-Wall -Wextra -g" CACHE STRING "" FORCE)
 set(CMAKE_CXX_FLAGS_RELWITHDEBINFO "-Wall -Wextra -g -O2 -DNDEBUG" CACHE STRING "" FORCE)
-unset(HAVE_OMP_H_INCLUDE CACHE)
+set(CMAKE_CXX_FLAGS_RELEASE "-O3 -DNDEBUG" CACHE STRING "" FORCE)
+set(CMAKE_Fortran_FLAGS_DEBUG "-Wall -Wextra -g -std=f2003" CACHE STRING "" FORCE)
+set(CMAKE_Fortran_FLAGS_RELWITHDEBINFO "-Wall -Wextra -g -O2 -DNDEBUG -std=f2003" CACHE STRING "" FORCE)
+set(CMAKE_Fortran_FLAGS_RELEASE "-O3 -DNDEBUG -std=f2003" CACHE STRING "" FORCE)
+set(CMAKE_C_FLAGS_DEBUG "-Wall -Wextra -g" CACHE STRING "" FORCE)
+set(CMAKE_C_FLAGS_RELWITHDEBINFO "-Wall -Wextra -g -O2 -DNDEBUG" CACHE STRING "" FORCE)
+set(CMAKE_C_FLAGS_RELEASE "-O3 -DNDEBUG" CACHE STRING "" FORCE)
 
-set(OpenMP_CXX "hipcc" CACHE STRING "" FORCE)
+set(MPI_CXX "hipcc" CACHE STRING "" FORCE)
+set(MPI_CXX_COMPILER "mpicxx" CACHE STRING "" FORCE)
+
+unset(HAVE_OMP_H_INCLUDE CACHE)
+set(OpenMP_C "gcc" CACHE STRING "" FORCE)
+set(OpenMP_C_FLAGS "-fopenmp" CACHE STRING "" FORCE)
+set(OpenMP_C_LIB_NAMES "gomp" CACHE STRING "" FORCE)
 set(OpenMP_CXX_FLAGS "-fopenmp" CACHE STRING "" FORCE)
+set(OpenMP_CXX "hipcc" CACHE STRING "" FORCE)
 set(OpenMP_CXX_LIB_NAMES "omp" CACHE STRING "" FORCE)
 set(OpenMP_omp_LIBRARY "libomp.so" CACHE PATH "" FORCE)

cmake/presets/hip_amd.cmake

@@ -0,0 +1,30 @@
+# preset that will enable hip (clang/clang++) with support for MPI and OpenMP (on Linux boxes)
+
+# prefer flang over gfortran, if available
+find_program(CLANG_FORTRAN NAMES flang gfortran f95)
+set(ENV{OMPI_FC} ${CLANG_FORTRAN})
+
+set(CMAKE_CXX_COMPILER "hipcc" CACHE STRING "" FORCE)
+set(CMAKE_C_COMPILER "hipcc" CACHE STRING "" FORCE)
+set(CMAKE_Fortran_COMPILER ${CLANG_FORTRAN} CACHE STRING "" FORCE)
+set(CMAKE_CXX_FLAGS_DEBUG "-Wall -Wextra -g" CACHE STRING "" FORCE)
+set(CMAKE_CXX_FLAGS_RELWITHDEBINFO "-Wall -Wextra -g -O2 -DNDEBUG" CACHE STRING "" FORCE)
+set(CMAKE_CXX_FLAGS_RELEASE "-O3 -DNDEBUG" CACHE STRING "" FORCE)
+set(CMAKE_Fortran_FLAGS_DEBUG "-Wall -Wextra -g -std=f2003" CACHE STRING "" FORCE)
+set(CMAKE_Fortran_FLAGS_RELWITHDEBINFO "-Wall -Wextra -g -O2 -DNDEBUG -std=f2003" CACHE STRING "" FORCE)
+set(CMAKE_Fortran_FLAGS_RELEASE "-O3 -DNDEBUG -std=f2003" CACHE STRING "" FORCE)
+set(CMAKE_C_FLAGS_DEBUG "-Wall -Wextra -g" CACHE STRING "" FORCE)
+set(CMAKE_C_FLAGS_RELWITHDEBINFO "-Wall -Wextra -g -O2 -DNDEBUG" CACHE STRING "" FORCE)
+set(CMAKE_C_FLAGS_RELEASE "-O3 -DNDEBUG" CACHE STRING "" FORCE)
+
+set(MPI_CXX "hipcc" CACHE STRING "" FORCE)
+set(MPI_CXX_COMPILER "mpicxx" CACHE STRING "" FORCE)
+
+unset(HAVE_OMP_H_INCLUDE CACHE)
+set(OpenMP_C "hipcc" CACHE STRING "" FORCE)
+set(OpenMP_C_FLAGS "-fopenmp" CACHE STRING "" FORCE)
+set(OpenMP_C_LIB_NAMES "omp" CACHE STRING "" FORCE)
+set(OpenMP_CXX "hipcc" CACHE STRING "" FORCE)
+set(OpenMP_CXX_FLAGS "-fopenmp" CACHE STRING "" FORCE)
+set(OpenMP_CXX_LIB_NAMES "omp" CACHE STRING "" FORCE)
+set(OpenMP_omp_LIBRARY "libomp.so" CACHE PATH "" FORCE)

cmake/presets/mingw-cross.cmake

@@ -21,10 +21,16 @@ set(WIN_PACKAGES
   DPD-SMOOTH
   DRUDE
   EFF
+  EXTRA-COMPUTE
+  EXTRA-DUMP
+  EXTRA-FIX
+  EXTRA-MOLECULE
+  EXTRA-PAIR
   FEP
   GPU
   GRANULAR
   INTEL
+  INTERLAYER
   KSPACE
   LATTE
   MACHDYN
@@ -39,11 +45,13 @@ set(WIN_PACKAGES
   ML-HDNNP
   ML-IAP
   ML-SNAP
+  ML-RANN
   MOFFF
   MOLECULE
   MOLFILE
   OPENMP
   OPT
+  ORIENT
   PERI
   PHONON
   POEMS
@@ -61,7 +69,6 @@ set(WIN_PACKAGES
   SRD
   TALLY
   UEF
-  USER-MISC
   VORONOI
   YAFF)
 

cmake/presets/most.cmake

@@ -23,8 +23,14 @@ set(ALL_PACKAGES
   DPD-SMOOTH
   DRUDE
   EFF
+  EXTRA-COMPUTE
+  EXTRA-DUMP
+  EXTRA-FIX
+  EXTRA-MOLECULE
+  EXTRA-PAIR
   FEP
   GRANULAR
+  INTERLAYER
   KSPACE
   MACHDYN
   MANYBODY
@@ -37,6 +43,7 @@ set(ALL_PACKAGES
   MOLECULE
   OPENMP
   OPT
+  ORIENT
   PERI
   PHONON
   PLUGIN
@@ -51,8 +58,8 @@ set(ALL_PACKAGES
   SPH
   SPIN
   SRD
+  TALLY
   UEF
-  USER-MISC
   VORONOI
   YAFF)
 

doc/Makefile

@@ -230,7 +230,7 @@ $(VENV):
 	)
 
 $(MATHJAX):
-	@git clone -b 3.2.0 -c advice.detachedHead=0 --depth 1 git://github.com/mathjax/MathJax.git $@
+	@git clone -b 3.2.0 -c advice.detachedHead=0 --depth 1 https://github.com/mathjax/MathJax.git $@
 
 $(ANCHORCHECK): $(VENV)
 	@( \

doc/github-development-workflow.md

@@ -6,7 +6,7 @@ choices the LAMMPS developers have agreed on. Git and GitHub provide the
 tools, but do not set policies, so it is up to the developers to come to
 an agreement as to how to define and interpret policies. This document
 is likely to change as our experiences and needs change and we try to
-adapt accordingly. Last change 2018-12-19.
+adapt accordingly. Last change 2021-09-02.
 
 ## Table of Contents
 
@@ -23,10 +23,10 @@ adapt accordingly. Last change 2018-12-19.
 
 In the interest of consistency, ONLY ONE of the core LAMMPS developers
 should doing the merging itself.  This is currently
-[@akohlmey](https://github.com/akohlmey) (Axel Kohlmeyer).
-If this assignment needs to be changed, it shall be done right after a
-stable release.  If the currently assigned developer cannot merge outstanding pull
-requests in a timely manner, or in other extenuating circumstances,
+[@akohlmey](https://github.com/akohlmey) (Axel Kohlmeyer).  If this
+assignment needs to be changed, it shall be done right after a stable
+release.  If the currently assigned developer cannot merge outstanding
+pull requests in a timely manner, or in other extenuating circumstances,
 other core LAMMPS developers with merge rights can merge pull requests,
 when necessary.
 
@@ -55,13 +55,14 @@ the required changes or ask the submitter of the pull request to implement
 them.  Even though, all LAMMPS developers may have write access to pull
 requests (if enabled by the submitter, which is the default), only the
 submitter or the assignee of a pull request may do so.  During this
-period the `work_in_progress` label shall be applied to the pull
+period the `work_in_progress` label may be applied to the pull
 request.  The assignee gets to decide what happens to the pull request
 next, e.g. whether it should be assigned to a different developer for
 additional checks and changes, or is recommended to be merged.  Removing
 the `work_in_progress` label and assigning the pull request to the
 developer tasked with merging signals that a pull request is ready to be
-merged.
+merged. In addition, a `ready_for_merge` label may also be assigned
+to signal urgency to merge this pull request quickly.
 
 ### Pull Request Reviews
 
@@ -97,108 +98,50 @@ rationale behind choices made.  Exceptions to this policy are technical
 discussions, that are centered on tools or policies themselves
 (git, GitHub, c++) rather than on the content of the pull request.
 
-### Checklist for Pull Requests
-
-Here are some items to check:
-  * source and text files should not have CR/LF line endings (use dos2unix to remove)
-  * every new command or style should have documentation. The names of
-  source files (c++ and manual) should follow the name of the style.
-  (example: `src/fix_nve.cpp`, `src/fix_nve.h` for `fix nve` command,
-  implementing the class `FixNVE`, documented in `doc/src/fix_nve.rst`)
-  * all new style names should be lower case, the must be no dashes,
-  blanks, or underscores separating words, only forward slashes.
-  * new style docs should be added to the "overview" files in
-  `doc/src/Commands_*.rst`, `doc/src/{fixes,computes,pairs,bonds,...}.rst`
-  * check whether manual cleanly translates with `make html` and `make pdf`
-  * if documentation is (still) provided as a .txt file, convert to .rst
-  and remove the .txt file. For files in doc/txt the conversion is automatic.
-  * remove all .txt files in `doc/txt` that are out of sync with their .rst counterparts in `doc/src`
-  * check spelling of manual with `make spelling` in doc folder
-  * check style tables and command lists with `make style_check`
-  * new source files in packages should be added to `src/.gitignore`
-  * removed or renamed files in packages should be added to `src/Purge.list`
-  * C++ source files should use C++ style include files for accessing
-  C-library APIs, e.g. `#include <cstdlib>` instead of `#include <stdlib.h>`.
-  And they should use angular brackets instead of double quotes. Full list:
-    * assert.h -> cassert
-    * ctype.h -> cctype
-    * errno.h -> cerrno
-    * float.h -> cfloat
-    * limits.h -> climits
-    * math.h -> cmath
-    * complex.h -> complex
-    * setjmp.h -> csetjmp
-    * signal.h -> csignal
-    * stddef.h -> cstddef
-    * stdint.h -> cstdint
-    * stdio.h -> cstdio
-    * stdlib.h -> cstdlib
-    * string.h -> cstring
-    * time.h -> ctime
-    * Do NOT replace (as they are C++-11): `inttypes.h` and `stdint.h`.
-  * Code must follow the C++-11 standard. C++98-only is no longer accepted
-  * Code should use `nullptr` instead of `NULL` where applicable.
-  in individual special purpose packages
-  * indentation is 2 spaces per level
-  * there should be NO tabs and no trailing whitespace (review the "checkstyle" test on pull requests)
-  * header files, especially of new styles, should not include any
-  other headers, except the header with the base class or cstdio.
-  Forward declarations should be used instead when possible.
-  * iostreams should be avoided. LAMMPS uses stdio from the C-library.
-  * use of STL in headers and class definitions should be avoided.
-  exception is <string>, but it won't need to be explicitly included
-  since pointers.h already includes it. so std::string can be used directly.
-  * there MUST NOT be any "using namespace XXX;" statements in headers.
-  * static class members should be avoided at all cost.
-  * anything storing atom IDs should be using `tagint` and not `int`.
-  This can be flagged by the compiler only for pointers and only when
-  compiling LAMMPS with `-DLAMMPS_BIGBIG`.
-  * when including both `lmptype.h` (and using defines or macros from it)
-  and `mpi.h`, `lmptype.h` must be included first.
-  * see https://github.com/lammps/lammps/blob/master/doc/include-file-conventions.md
-  for general include file conventions and best practices
-  * when pair styles are added, check if settings for flags like
-  `single_enable`, `writedata`, `reinitflag`, `manybody_flag`
-  and others are correctly set and supported.
-
 ## GitHub Issues
 
 The GitHub issue tracker is the location where the LAMMPS developers
 and other contributors or LAMMPS users can report issues or bugs with
-the LAMMPS code or request new features to be added. Feature requests
-are usually indicated by a `[Feature Request]` marker in the subject.
-Issues are assigned to a person, if this person is working on this
-feature or working to resolve an issue. Issues that have nobody working
-on them at the moment, have the label `volunteer needed` attached.
+the LAMMPS code or request new features to be added. Bug reports have
+a `[Bug]` marker in the subject line; suggestions for changes or
+adding new functionality are indicated by a `[Feature Request]`
+marker in the subject. This is automatically done when using the
+corresponding template for submitting an issue.  Issues may be assigned
+to one or more developers, if they are working on this feature or
+working to resolve an issue.  Issues that have nobody working
+on them at the moment or in the near future, have the label
+`volunteer needed` attached.
 
 When an issue, say `#125` is resolved by a specific pull request,
 the comment for the pull request shall contain the text `closes #125`
 or `fixes #125`, so that the issue is automatically deleted when
-the pull request is merged.
+the pull request is merged.  The template for pull requests includes
+a header where connections between pull requests and issues can be listed
+and thus were this comment should be placed.
 
 ## Milestones and Release Planning
 
 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 broken.
-More extensive testing (including regression testing) is performed after
-code is merged to the "master" branch. There are patch releases of
-LAMMPS every 1-3 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 follows only these
-versions (and thus is always supposed to be of production quality,
-unlike "master", which may be temporary broken, in the case of larger
-change sets or unexpected incompatibilities or side effects.
+testing - that the code in the branch "master" 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
+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
+follows only these versions (and thus is always supposed to be of
+production quality, unlike "master", which may be temporary broken, in
+the case of larger change sets or unexpected incompatibilities or side
+effects.
 
-About 3-4 times each year, there are going to be "stable" releases
-of LAMMPS.  These have seen additional, manual testing and review of
+About 1-2 times each year, there are going to be "stable" releases of
+LAMMPS.  These have seen additional, manual testing and review of
 results from testing with instrumented code and static code analysis.
-Also, in the last 2-3 patch releases before a stable release are
-"release candidate" versions which only contain bugfixes and
-documentation updates.  For release planning and the information of
-code contributors, issues and pull requests being actively worked on
-are assigned a "milestone", which corresponds to the next stable
-release or the stable release after that, with a tentative release
-date.
-
+Also, the last 1-3 patch releases before a stable release are "release
+candidate" versions which only contain bugfixes and documentation
+updates.  For release planning and the information of code contributors,
+issues and pull requests being actively worked on are assigned a
+"milestone", which corresponds to the next stable release or the stable
+release after that, with a tentative release date.

doc/include-file-conventions.md

@@ -1,128 +0,0 @@
-# Outline of include file conventions in LAMMPS
-
-This purpose of this document is to provide a point of reference
-for LAMMPS developers and contributors as to what include files
-and definitions to put where into LAMMPS source.
-Last change 2020-08-31
-
-## Table of Contents
-
-  * [Motivation](#motivation)
-  * [Rules](#rules)
-  * [Tools](#tools)
-  * [Legacy Code](#legacy-code)
-
-## Motivation
-
-The conventions outlined in this document are supposed to help make
-maintenance of the LAMMPS software easier.  By trying to achieve
-consistency across files contributed by different developers, it will
-become easier for the code maintainers to modify and adjust files and,
-overall, the chance for errors or portability issues will be reduced.
-The rules employed are supposed to minimize naming conflicts and
-simplify dependencies between files and thus speed up compilation. They
-may, as well, make otherwise hidden dependencies visible.
-
-## Rules
-
-Below are the various rules that are applied.  Not all are enforced
-strictly and automatically.  If there are no significant side effects,
-exceptions may be possible for cases where a full compliance to the
-rules may require a large effort compared to the benefit.
-
-### Core Files Versus Package Files
-
-All rules listed below are most strictly observed for core LAMMPS files,
-which are the files that are not part of a package, and the files of the
-packages MOLECULE, MANYBODY, KSPACE, and RIGID.  On the other end of
-the spectrum are USER packages and legacy packages that predate these
-rules and thus may not be fully compliant.  Also, new contributions
-will be checked more closely, while existing code will be incrementally
-adapted to the rules as time and required effort permits.
-
-### System Versus Local Header Files
-
-All system- or library-provided include files are included with angular
-brackets (examples: `#include <cstring>` or `#include <mpi.h>`) while
-include files provided with LAMMPS are included with double quotes
-(examples: `#include "pointers.h"` or `#include "compute_temp.h"`).
-
-For headers declaring functions of the C-library, the corresponding
-C++ versions should be included (examples: `#include <cstdlib>` or
-`#include <cctypes>` instead of `#include <stdlib.h>` or
-`#include<ctypes.h>` ).
-
-### C++ Standard Compliance
-
-LAMMPS core files use standard conforming C++ compatible with the
-C++11 standard, unless explicitly noted.  Also, LAMMPS uses the C-style
-stdio library for I/O instead of iostreams.  Since using both at the
-same time can cause problems, iostreams should be avoided where possible.
-
-### Lean Header Files
-
-Header files will typically contain the definition of a (single) class.
-These header files should have as few include statements as possible.
-This is particularly important for classes that implement a "style" and
-thus use a macro of the kind `SomeStyle(some/name,SomeName)`. These will
-all be included in the auto-generated `"some_style.h"` files which
-results in a high potential for direct or indirect symbol name clashes.
-
-In the ideal case, the header would only include one file defining the
-parent class. That would typically be either `#include "pointers.h"` for
-the `Pointers` class, or a header of a class derived from it like
-`#include "pair.h"` for the `Pair` class and so on.  References to other
-classes inside the class should be make through pointers, for which forward
-declarations (inside the `LAMMPS_NS` or the new class' namespace) can
-be employed.  The full definition will then be included into the corresponding
-implementation file.  In the given example from above, the header file
-would be called `some_name.h` and the implementation `some_name.cpp` (all
-lower case with underscores, while the class itself would be in camel case
-and no underscores `SomeName`, and the style name with lower case names separated by
-a forward slash).
-
-### Implementation Files
-
-In the implementation files (typically, those would have the same base name
-as the corresponding header with a .cpp extension instead of .h) include
-statements should follow the "include what you use" principle.
-
-### Order of Include Statements
-
-Include files should be included in this order:
-* the header matching the implementation (`some_class.h` for file `some_class.cpp`)
-* mpi.h  (only if needed)
-* LAMMPS local headers (preferably in alphabetical order)
-* system and library headers (anything that is using angular brackets; preferably in alphabetical order)
-* conditional include statements (i.e. anything bracketed with ifdefs)
-
-### Special Cases and Exceptions
-
-#### pointers.h
-
-The `pointer.h` header file also includes (in this order) `lmptype.h`,
-`mpi.h`, `cstddef`, `cstdio`, `string`, `utils.h`, and `fmt/format.h`
-and through `lmptype.h` indirectly also `climits`, `cstdlib`, `cinttypes`.
-This means any header including `pointers.h` can assume that `FILE`,
-`NULL`, `INT_MAX` are defined, and the may freely use the std::string
-for arguments. Corresponding implementation files do not need to include
-those headers.
-
-## Tools
-
-The [Include What You Use tool](https://include-what-you-use.org/)
-can be used to provide supporting information about compliance with
-the rules listed here.  Through setting `-DENABLE_IWYU=on` when running
-CMake, a custom build target is added that will enable recording
-the compilation commands and then run the `iwyu_tool` using the
-recorded compilation commands information when typing `make iwyu`.
-
-## Legacy Code
-
-A lot of code predates the application of the rules in this document
-and the rules themselves are a moving target.  So there are going to be
-significant chunks of code that do not fully comply.  This applies
-for example to the REAXFF, or the ATC package.  The LAMMPS
-developers are dedicated to make an effort to improve the compliance
-and welcome volunteers wanting to help with the process.
-

doc/lammps.1

@@ -1,4 +1,4 @@
-.TH LAMMPS "2 July 2021" "2021-07-2"
+.TH LAMMPS "29 September 2021" "2021-09-29"
 .SH NAME
 .B LAMMPS
 \- Molecular Dynamics Simulator.
@@ -54,7 +54,7 @@ using
 this <machine name> parameter can be chosen arbitrarily at configuration
 time, but more common is to just use
 .B lmp
-without a suffix. In this manpage we will use
+without a suffix. In this man page we will use
 .B lmp
 to represent any of those names.
 
@@ -94,7 +94,7 @@ Enable or disable general KOKKOS support, as provided by the KOKKOS
 package.  Even if LAMMPS is built with this package, this switch must
 be set to \fBon\fR to enable running with KOKKOS-enabled styles. More
 details on this switch and its optional keyword value pairs are discussed
-at: https://lammps.sandia.gov/doc/Run_options.html
+at: https://docs.lammps.org/Run_options.html
 .TP
 \fB\-l <log file>\fR or \fB\-log <log file>\fR
 Specify a log file for LAMMPS to write status information to.
@@ -122,6 +122,38 @@ to perform client/server messaging with another application.
 .B LAMMPS
 can act as either a client or server (or both).
 .TP
+\fB\-mdi '<mdi_flags>'\fR
+This flag is only recognized and used when
+.B LAMMPS
+has support for the MolSSI
+Driver Interface (MDI) included as part of the MDI package.  This flag is
+specific to the MDI library and controls how
+.B LAMMPS
+interacts with MDI.  There are usually multiple flags that have to follow it
+and those have to be placed in quotation marks.  For more information about
+how to launch LAMMPS in MDI client/server mode please refer to the
+MDI How-to at  https://docs.lammps.org/Howto_mdi.html
+.TP
+\fB\-c\fR or \fB\-cite <style or filename>\fR
+Select how and where to output a reminder about citing contributions
+to the
+.B LAMMPS
+code that were used during the run. Available keywords
+for styles are "both", "none", "screen", or "log".  Any other keyword
+will be considered a file name to write the detailed citation info to
+instead of logfile or screen.  Default is the "log" style where there
+is a short summary in the screen output and detailed citations
+in BibTeX format in the logfile.  The option "both" selects the detailed
+output for both, "none", the short output for both, and "screen" will
+write the detailed info to the screen and the short version to the log
+file.  If a dedicated citation info file is requested, the screen and
+log file output will be in the short format (same as with "none").
+
+See https://docs.lammps.org/Intro_citing.html for more details on
+how to correctly reference and cite
+.B LAMMPS
+.
+.TP
 \fB\-nc\fR or \fB\-nocite\fR
 Disable writing the "log.cite" file which is normally written to
 list references for specific cite-able features used during a
@@ -202,7 +234,7 @@ the standard output. If <file name> is "none", (most) screen
 output will be suppressed.  In multi-partition mode only
 some high-level all-partition information is written to the
 screen or "<file name>" file, the remainder is written in a
-per-partition file "screen.N" or "<file name>.N" 
+per-partition file "screen.N" or "<file name>.N"
 with "N" being the respective partition number, and unless
 overridden by the \-pscreen flag (see above).
 .TP
@@ -218,8 +250,19 @@ and then "omp") and thus requires two arguments. Along with the
 "-package" command-line switch, this is a convenient mechanism for
 invoking styles from accelerator packages and setting their options
 without having to edit an input script.
+.TP
+\fB\-sr\fR or \fB\-skiprun\fR
+Insert the command "timer timeout 0 every 1" at the
+beginning of an input file or after a "clear" command.
+This has the effect that the entire
+.B LAMMPS
+input script is processed without executing actual
+"run" or "minimize" or similar commands (their main loops are skipped).
+This can be helpful and convenient to test input scripts of long running
+calculations for correctness to avoid having them crash after a
+long time due to a typo or syntax error in the middle or at the end.
 
-See https://lammps.sandia.gov/doc/Run_options.html for additional
+See https://docs.lammps.org/Run_options.html for additional
 details and discussions on command-line options.
 
 .SH LAMMPS BASICS
@@ -254,7 +297,7 @@ the chapter on errors in the
 manual gives some additional information about error messages, if possible.
 
 .SH COPYRIGHT
-© 2003--2020 Sandia Corporation
+© 2003--2021 Sandia Corporation
 
 This package is free software; you can redistribute it and/or modify
 it under the terms of the GNU General Public License version 2 as

doc/msi2lmp.1

@@ -98,7 +98,7 @@ msi2lmp decane -c 0 -f oplsaa
 
 
 .SH COPYRIGHT
-© 2003--2019 Sandia Corporation
+© 2003--2021 Sandia Corporation
 
 This package is free software; you can redistribute it and/or modify
 it under the terms of the GNU General Public License version 2 as

doc/src/Bibliography.rst

@@ -191,7 +191,7 @@ Bibliography
    A.\  Calhoun, M. Pavese, G. Voth, Chem Phys Letters, 262, 415 (1996).
 
 **(Campana)**
-   C.\  Campana and M. H. Muser, *Practical Green's function approach to the simulation of elastic semi-infinite solids*\ , `Phys. Rev. B [74], 075420 (2006) <https://doi.org/10.1103/PhysRevB.74.075420>`_
+   C.\  Campana and M. H. Muser, *Practical Green's function approach to the simulation of elastic semi-infinite solids*, `Phys. Rev. B [74], 075420 (2006) <https://doi.org/10.1103/PhysRevB.74.075420>`_
 
 **(Cao1)**
    J.\  Cao and B. Berne, J Chem Phys, 99, 2902 (1993).
@@ -767,7 +767,7 @@ Bibliography
    Morris, Fox, Zhu, J Comp Physics, 136, 214-226 (1997).
 
 **(Moustafa)**
-   Sabry G. Moustafa, Andrew J. Schultz, and David A. Kofke, *Very fast averaging of thermal properties of crystals by molecular simulation*\ , `Phys. Rev. E [92], 043303 (2015) <https://link.aps.org/doi/10.1103/PhysRevE.92.043303>`_
+   Sabry G. Moustafa, Andrew J. Schultz, and David A. Kofke, *Very fast averaging of thermal properties of crystals by molecular simulation*, `Phys. Rev. E [92], 043303 (2015) <https://link.aps.org/doi/10.1103/PhysRevE.92.043303>`_
 
 **(Muller-Plathe1)**
    Muller-Plathe, J Chem Phys, 106, 6082 (1997).

doc/src/Build.rst

@@ -22,4 +22,5 @@ page.
    Build_extras
    Build_manual
    Build_windows
+   Build_diskspace
    Build_development

doc/src/Build_development.rst

@@ -1,15 +1,15 @@
-Development build options (CMake only)
-======================================
+Development build options
+=========================
 
-The CMake build procedure of LAMMPS offers a few extra options which are
+The build procedures in LAMMPS offers a few extra options which are
 useful during development, testing or debugging.
 
 ----------
 
 .. _compilation:
 
-Monitor compilation flags
--------------------------
+Monitor compilation flags (CMake only)
+--------------------------------------
 
 Sometimes it is necessary to verify the complete sequence of compilation flags
 generated by the CMake build. To enable a more verbose output during
@@ -30,8 +30,8 @@ variable VERBOSE set to 1:
 
 .. _clang-tidy:
 
-Enable static code analysis with clang-tidy
--------------------------------------------
+Enable static code analysis with clang-tidy (CMake only)
+--------------------------------------------------------
 
 The `clang-tidy tool <https://clang.llvm.org/extra/clang-tidy/>`_ is a
 static code analysis tool to diagnose (and potentially fix) typical
@@ -52,20 +52,22 @@ significantly more time consuming than the compilation itself.
 
 .. _iwyu_processing:
 
-Report missing and unneeded '#include' statements
--------------------------------------------------
+Report missing and unneeded '#include' statements (CMake only)
+--------------------------------------------------------------
 
 The conventions for how and when to use and order include statements in
-LAMMPS are `documented in a separate file <https://github.com/lammps/lammps/blob/master/doc/include-file-conventions.md>`_
-(also included in the source code distribution).  To assist with following
+LAMMPS are documented in :doc:`Modify_style`.  To assist with following
 these conventions one can use the `Include What You Use tool <https://include-what-you-use.org/>`_.
-This is still under development and for large and complex projects like LAMMPS
+This tool is still under development and for large and complex projects like LAMMPS
 there are some false positives, so suggested changes need to be verified manually.
-It is recommended to use at least version 0.14, which has much fewer incorrect
-reports than earlier versions.
+It is recommended to use at least version 0.16, which has much fewer incorrect
+reports than earlier versions.  To install the IWYU toolkit, you need to have
+the clang compiler **and** its development package installed.  Download the IWYU
+version that matches the version of the clang compiler, configure, build, and
+install it.
 
-The necessary steps to generate the report can be enabled via a
-CMake variable:
+The necessary steps to generate the report can be enabled via a CMake variable
+during CMake configuration.
 
 .. code-block:: bash
 
@@ -86,8 +88,8 @@ on recording all commands required to do the compilation.
 
 .. _sanitizer:
 
-Address, Undefined Behavior, and Thread Sanitizer Support
----------------------------------------------------------
+Address, Undefined Behavior, and Thread Sanitizer Support (CMake only)
+----------------------------------------------------------------------
 
 Compilers such as GCC and Clang support generating instrumented binaries
 which use different sanitizer libraries to detect problems in the code
@@ -116,8 +118,8 @@ compilation and linking stages.  This is done through setting the
 
 .. _testing:
 
-Code Coverage and Unit Testing
-------------------------------
+Code Coverage and Unit Testing (CMake only)
+-------------------------------------------
 
 The LAMMPS code is subject to multiple levels of automated testing
 during development: integration testing (i.e. whether the code compiles
@@ -464,7 +466,8 @@ Coding style utilities
 
 To aid with enforcing some of the coding style conventions in LAMMPS
 some additional build targets have been added. These require Python 3.5
-or later and will only work on Unix-like operating and file systems.
+or later and will only work properly on Unix-like operating and file systems.
+
 The following options are available.
 
 .. code-block:: bash
@@ -476,17 +479,43 @@ The following options are available.
    make check-permissions   # search for files with permissions issues
    make fix-permissions     # correct permissions issues in files
 
+These should help to replace all TAB characters with blanks and remove
+any trailing whitespace.  Also all LAMMPS homepage URL references can be
+updated to the location change from Sandia to the lammps.org domain.
+And the permission check can remove executable permissions from non-executable
+files (like source code).
+
+Clang-format support
+--------------------
+
 For the code in the ``unittest`` and ``src`` trees we are transitioning
 to use the `clang-format` tool to assist with having a consistent source
-code style.  The `clang-format` command bundled with Clang version 8.0
-or later is required.  The configuration is in files ``.clang-format``
-in the respective folders.  Since the modifications from `clang-format`
-can be significant and - especially for "legacy style code" - also is
-not always improving readability, a large number of files currently have
-a ``// clang-format off`` at the top, which will disable the processing.
-Over time, files will be refactored and updated to that `clang-format`
-may be applied to them (at least in part).
+code formatting style.  The `clang-format` command bundled with Clang
+version 8.0 or later is required.  The configuration is in files called
+``.clang-format`` in the respective folders.  Since the modifications
+from `clang-format` can be significant and - especially for "legacy
+style code" - they are not always improving readability, a large number
+of files currently have a ``// clang-format off`` at the top, which will
+disable the processing.  As of fall 2021 all files have been either
+"protected" this way or are enabled for full or partial `clang-format`
+processing.  Over time, the "protected" files will be refactored and
+updated so that `clang-format` may be applied to them as well.
 
-If `clang-format` is available, the source code files in the ``unittest``
-tree can be updated to conform to the formatting settings using
-``make format-tests`` and the files in ``src`` with ``make format-src``.
+It is recommended for all newly contributed files to use the clang-format
+processing while writing the code or do the coding style processing
+(including the scripts mentioned in the previous paragraph)
+
+If `clang-format` is available, files can be updated individually with
+commands like the following:
+
+.. code-block:: bash
+
+   $ clang-format -i some_file.cpp
+
+
+The following target are available for both, GNU make and CMake:
+
+.. code-block:: bash
+
+   make format-src       # apply clang-format to all files in src and the package folders
+   make format-tests     # apply clang-format to all files in the unittest tree

doc/src/Build_diskspace.rst

@@ -0,0 +1,45 @@
+Notes for saving disk space when building LAMMPS from source
+------------------------------------------------------------
+
+LAMMPS is a large software project with a large number of source files,
+extensive documentation, and a large collection of example files.
+When downloading LAMMPS by cloning the
+`git repository from GitHub <https://github.com/lammps/lammps>`_ this
+will by default also download the entire commit history since September 2006.
+Compiling LAMMPS will add the storage requirements of the compiled object
+files and libraries to the tally.
+
+In a user account on an HPC cluster with filesystem quotas or in other
+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``.
+  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).
+
+- Download a tar archive from either the `download section on the LAMMPS homepage <https://www.lammps.org/download.html>`_
+  or from the `LAMMPS releases page on GitHub <https://github.com/lammps/lammps/releases>`_ these will not
+  contain the git history at all.
+
+- Build LAMMPS without the debug flag (remove ``-g`` from the machine makefile or use ``-DCMAKE_BUILD_TYPE=Release``)
+  or use the ``strip`` command on the LAMMPS executable when no more debugging would be needed.  The strip command
+  may also be applied to the LAMMPS shared library. The static library may be deleted entirely.
+
+- Delete compiled object files and libraries after copying the LAMMPS executable to a permanent location.
+  When using the traditional build process, one may use ``make clean-<machine>`` or ``make clean-all``
+  to delete object files in the src folder.  For CMake based builds, one may use ``make clean`` or just
+  delete the entire build folder.
+
+- The folders containing the documentation tree (doc), the examples (examples) are not needed to build and
+  run LAMMPS and can be safely deleted.  Some files in the potentials folder are large and may be deleted,
+  if not needed.  The largest of those files (occupying about 120 MBytes combined) will only be downloaded on
+  demand, when the corresponding package is installed.
+
+- When using the CMake build procedure, the compilation can be done on a (local) scratch storage that will not
+  count toward the quota.  A local scratch file system may offer the additional benefit of speeding up creating
+  object files and linking with libraries compared to a networked file system.  Also with CMake (and unlike with
+  the traditional make) it is possible to compile LAMMPS executables with different settings and packages included
+  from the same source tree since all the configuration information is stored in the build folder.  So it is
+  not necessary to have multiple copies of LAMMPS.

doc/src/Build_extras.rst

@@ -31,36 +31,36 @@ This is the list of packages that may require additional steps.
 .. table_from_list::
    :columns: 6
 
-   * :ref:`COMPRESS <compress>`
-   * :ref:`GPU <gpu>`
-   * :ref:`KIM <kim>`
-   * :ref:`KOKKOS <kokkos>`
-   * :ref:`LATTE <latte>`
-   * :ref:`MESSAGE <message>`
-   * :ref:`ML-IAP <mliap>`
-   * :ref:`MSCG <mscg>`
-   * :ref:`OPT <opt>`
-   * :ref:`POEMS <poems>`
-   * :ref:`PYTHON <python>`
-   * :ref:`VORONOI <voronoi>`
    * :ref:`ADIOS <adios>`
    * :ref:`ATC <atc>`
    * :ref:`AWPMD <awpmd>`
    * :ref:`COLVARS <colvars>`
+   * :ref:`COMPRESS <compress>`
+   * :ref:`GPU <gpu>`
    * :ref:`H5MD <h5md>`
-   * :ref:`ML-HDNNP <ml-hdnnp>`
    * :ref:`INTEL <intel>`
+   * :ref:`KIM <kim>`
+   * :ref:`KOKKOS <kokkos>`
+   * :ref:`LATTE <latte>`
+   * :ref:`MACHDYN <machdyn>`
    * :ref:`MDI <mdi>`
    * :ref:`MESONT <mesont>`
-   * :ref:`MOLFILE <molfile>`
-   * :ref:`NETCDF <netcdf>`
+   * :ref:`MESSAGE <message>`
+   * :ref:`ML-HDNNP <ml-hdnnp>`
+   * :ref:`ML-IAP <mliap>`
    * :ref:`ML-PACE <ml-pace>`
-   * :ref:`PLUMED <plumed>`
-   * :ref:`OPENMP <openmp>`
-   * :ref:`QMMM <qmmm>`
    * :ref:`ML-QUIP <ml-quip>`
+   * :ref:`MOLFILE <molfile>`
+   * :ref:`MSCG <mscg>`
+   * :ref:`NETCDF <netcdf>`
+   * :ref:`OPENMP <openmp>`
+   * :ref:`OPT <opt>`
+   * :ref:`PLUMED <plumed>`
+   * :ref:`POEMS <poems>`
+   * :ref:`PYTHON <python>`
+   * :ref:`QMMM <qmmm>`
    * :ref:`SCAFACOS <scafacos>`
-   * :ref:`MACHDYN <machdyn>`
+   * :ref:`VORONOI <voronoi>`
    * :ref:`VTK <vtk>`
 
 ----------
@@ -74,7 +74,8 @@ To build with this package you must have the `zlib compression library
 <https://zlib.net>`_ available on your system to build dump styles with
 a '/gz' suffix.  There are also styles using the
 `Zstandard <https://facebook.github.io/zstd/>`_ library which have a
-'/zstd' suffix.
+'/zstd' suffix.  The zstd library version must be at least 1.4.  Older
+versions use an incompatible API and thus LAMMPS will fail to compile.
 
 .. tabs::
 
@@ -1856,8 +1857,8 @@ ML-QUIP package
 To build with this package, you must download and build the QUIP
 library.  It can be obtained from GitHub.  For support of GAP
 potentials, additional files with specific licensing conditions need
-to be downloaded and configured.  See step 1 and step 1.1 in the
-``lib/quip/README`` file for details on how to do this.
+to be downloaded and configured.  The automatic download will from
+within CMake will download the non-commercial use version.
 
 .. tabs::
 
@@ -1865,11 +1866,14 @@ to be downloaded and configured.  See step 1 and step 1.1 in the
 
       .. code-block:: bash
 
+         -D DOWNLOAD_QUIP=value   # download OpenKIM API v2 for build, value = no (default) or yes
          -D QUIP_LIBRARY=path     # path to libquip.a (only needed if a custom location)
 
-      CMake will **not** download and build the QUIP library.  But once you have
-      done that, a CMake build of LAMMPS with ``-D PKG_ML-QUIP=yes`` should
-      work.  Set the ``QUIP_LIBRARY`` variable if CMake cannot find the QUIP library.
+      CMake will try to download and build the QUIP library from GitHub, if it is not
+      found on the local machine. This requires to have git installed. It will use the same compilers
+      and flags as used for compiling LAMMPS.  Currently this is only supported for the GNU and the
+      Intel compilers. Set the ``QUIP_LIBRARY`` variable if you want to use a previously compiled
+      and installed QUIP library and CMake cannot find it.
 
    .. tab:: Traditional make
 

doc/src/Build_manual.rst

@@ -22,7 +22,6 @@ files. Here is a list with descriptions:
    .gitignore       # list of files and folders to be ignored by git
    doxygen-warn.log # logfile with warnings from running doxygen
    github-development-workflow.md   # notes on the LAMMPS development workflow
-   include-file-conventions.md      # notes on LAMMPS' include file conventions
 
 If you downloaded LAMMPS as a tarball from `the LAMMPS website <lws_>`_,
 the html folder and the PDF files should be included.
@@ -75,8 +74,8 @@ folder.  The following ``make`` commands are available:
 .. code-block:: bash
 
    make html          # generate HTML in html dir using Sphinx
-   make pdf           # generate PDF  as Manual.pdf using Sphinx and pdflatex
-   make fetch         # fetch HTML pages and PDF files from LAMMPS web site
+   make pdf           # generate PDF  as Manual.pdf using Sphinx and PDFLaTeX
+   make fetch         # fetch HTML pages and PDF files from LAMMPS website
                       #  and unpack into the html_www folder and Manual_www.pdf
    make epub          # generate LAMMPS.epub in ePUB format using Sphinx
    make mobi          # generate LAMMPS.mobi in MOBI format using ebook-convert
@@ -204,9 +203,9 @@ be multiple tests run automatically:
 
   .. parsed-literal::
 
-     Found 74 packages
-     Standard package NEWPACKAGE missing in Packages_standard.rst
-     Standard package NEWPACKAGE missing in Packages_details.rst
+     Found 88 packages
+     Package NEWPACKAGE missing in Packages_list.rst
+     Package NEWPACKAGE missing in Packages_details.rst
 
 - A test that only standard, printable ASCII text characters are used.
   This runs the command ``env LC_ALL=C grep -n '[^ -~]' src/*.rst`` and

doc/src/Build_settings.rst

@@ -71,7 +71,8 @@ LAMMPS can use them if they are available on your system.
 
          -D FFTW3_INCLUDE_DIR=path   # path to FFTW3 include files
          -D FFTW3_LIBRARY=path       # path to FFTW3 libraries
-         -D FFT_FFTW_THREADS=on      # enable using threaded FFTW3 libraries
+         -D FFTW3_OMP_LIBRARY=path   # path to FFTW3 OpenMP wrapper libraries
+         -D FFT_FFTW_THREADS=on      # enable using OpenMP threaded FFTW3 libraries
          -D MKL_INCLUDE_DIR=path     # ditto for Intel MKL library
          -D FFT_MKL_THREADS=on       # enable using threaded FFTs with MKL libraries
          -D MKL_LIBRARY=path         # path to MKL libraries

doc/src/Commands_category.rst

@@ -2,7 +2,7 @@ Commands by category
 ====================
 
 This page lists most of the LAMMPS commands, grouped by category.  The
-:doc:`General commands <Commands_all>` doc page lists all general commands
+:doc:`General commands <Commands_all>` page lists all general commands
 alphabetically.  Style options for entries like fix, compute, pair etc.
 have their own pages where they are listed alphabetically.
 

doc/src/Commands_compute.rst

@@ -72,6 +72,7 @@ KOKKOS, o = OPENMP, t = OPT.
    * :doc:`gyration/shape/chunk <compute_gyration_shape_chunk>`
    * :doc:`heat/flux <compute_heat_flux>`
    * :doc:`heat/flux/tally <compute_tally>`
+   * :doc:`heat/flux/virial/tally <compute_tally>`
    * :doc:`hexorder/atom <compute_hexorder_atom>`
    * :doc:`hma <compute_hma>`
    * :doc:`improper <compute_improper>`
@@ -151,7 +152,7 @@ KOKKOS, o = OPENMP, t = OPT.
    * :doc:`temp/chunk <compute_temp_chunk>`
    * :doc:`temp/com <compute_temp_com>`
    * :doc:`temp/cs <compute_temp_cs>`
-   * :doc:`temp/deform <compute_temp_deform>`
+   * :doc:`temp/deform (k) <compute_temp_deform>`
    * :doc:`temp/deform/eff <compute_temp_deform_eff>`
    * :doc:`temp/drude <compute_temp_drude>`
    * :doc:`temp/eff <compute_temp_eff>`

doc/src/Commands_fix.rst

@@ -148,7 +148,7 @@ OPT.
    * :doc:`nvt/body <fix_nvt_body>`
    * :doc:`nvt/eff <fix_nh_eff>`
    * :doc:`nvt/manifold/rattle <fix_nvt_manifold_rattle>`
-   * :doc:`nvt/sllod (io) <fix_nvt_sllod>`
+   * :doc:`nvt/sllod (iko) <fix_nvt_sllod>`
    * :doc:`nvt/sllod/eff <fix_nvt_sllod_eff>`
    * :doc:`nvt/sphere (o) <fix_nvt_sphere>`
    * :doc:`nvt/uef <fix_nh_uef>`
@@ -157,6 +157,7 @@ OPT.
    * :doc:`orient/fcc <fix_orient>`
    * :doc:`orient/eco <fix_orient_eco>`
    * :doc:`pafi <fix_pafi>`
+   * :doc:`pair/tracker <fix_pair_tracker>`
    * :doc:`phonon <fix_phonon>`
    * :doc:`pimd <fix_pimd>`
    * :doc:`planeforce <fix_planeforce>`
@@ -178,14 +179,14 @@ OPT.
    * :doc:`qeq/dynamic <fix_qeq>`
    * :doc:`qeq/fire <fix_qeq>`
    * :doc:`qeq/point <fix_qeq>`
-   * :doc:`qeq/reax (ko) <fix_qeq_reax>`
+   * :doc:`qeq/reaxff (ko) <fix_qeq_reaxff>`
    * :doc:`qeq/shielded <fix_qeq>`
    * :doc:`qeq/slater <fix_qeq>`
    * :doc:`qmmm <fix_qmmm>`
    * :doc:`qtb <fix_qtb>`
    * :doc:`rattle <fix_shake>`
-   * :doc:`reax/c/bonds (k) <fix_reaxc_bonds>`
-   * :doc:`reax/c/species (k) <fix_reaxc_species>`
+   * :doc:`reaxff/bonds (k) <fix_reaxff_bonds>`
+   * :doc:`reaxff/species (k) <fix_reaxff_species>`
    * :doc:`recenter <fix_recenter>`
    * :doc:`restrain <fix_restrain>`
    * :doc:`rhok <fix_rhok>`
@@ -235,6 +236,7 @@ OPT.
    * :doc:`ti/spring <fix_ti_spring>`
    * :doc:`tmd <fix_tmd>`
    * :doc:`ttm <fix_ttm>`
+   * :doc:`ttm/grid <fix_ttm>`
    * :doc:`ttm/mod <fix_ttm>`
    * :doc:`tune/kspace <fix_tune_kspace>`
    * :doc:`vector <fix_vector>`

doc/src/Commands_input.rst

@@ -1,55 +1,75 @@
 LAMMPS input scripts
 ====================
 
-LAMMPS executes by reading commands from a input script (text file),
-one line at a time.  When the input script ends, LAMMPS exits.  Each
-command causes LAMMPS to take some action.  It may set an internal
-variable, read in a file, or run a simulation.  Most commands have
-default settings, which means you only need to use the command if you
-wish to change the default.
+LAMMPS executes calculations by reading commands from a input script (text file), one
+line at a time.  When the input script ends, LAMMPS exits.  This is different
+from programs that read and process the entire input before starting a calculation.
+
+Each command causes LAMMPS to take some immediate action without regard
+for any commands that may be processed later. Commands may set an
+internal variable, read in a file, or run a simulation.  These actions
+can be grouped into three categories:
+
+a) commands that change a global setting (examples: timestep, newton,
+   echo, log, thermo, restart),
+b) commands that add, modify, remove, or replace "styles" that are
+   executed during a "run" (examples: pair_style, fix, compute, dump,
+   thermo_style, pair_modify), and
+c) commands that execute a "run" or perform some other computation or
+   operation (examples: print, run, minimize, temper, write_dump, rerun,
+   read_data, read_restart)
+
+Commands in category a) have default settings, which means you only
+need to use the command if you wish to change the defaults.
 
 In many cases, the ordering of commands in an input script is not
-important.  However the following rules apply:
+important, but can have consequences when the global state is changed
+between commands in the c) category. The following rules apply:
 
 (1) LAMMPS does not read your entire input script and then perform a
-simulation with all the settings.  Rather, the input script is read
-one line at a time and each command takes effect when it is read.
-Thus this sequence of commands:
+    simulation with all the settings.  Rather, the input script is read
+    one line at a time and each command takes effect when it is read.
+    Thus this sequence of commands:
 
-.. code-block:: LAMMPS
+    .. code-block:: LAMMPS
 
-   timestep 0.5
-   run      100
-   run      100
+       timestep 0.5
+       run      100
+       run      100
 
-does something different than this sequence:
+    does something different than this sequence:
 
-.. code-block:: LAMMPS
+    .. code-block:: LAMMPS
 
-   run      100
-   timestep 0.5
-   run      100
+       run      100
+       timestep 0.5
+       run      100
 
-In the first case, the specified timestep (0.5 fs) is used for two
-simulations of 100 timesteps each.  In the second case, the default
-timestep (1.0 fs) is used for the first 100 step simulation and a 0.5 fs
-timestep is used for the second one.
+    In the first case, the specified timestep (0.5 fs) is used for two
+    simulations of 100 timesteps each.  In the second case, the default
+    timestep (1.0 fs) is used for the first 100 step simulation and a
+    0.5 fs timestep is used for the second one.
 
 (2) Some commands are only valid when they follow other commands.  For
-example you cannot set the temperature of a group of atoms until atoms
-have been defined and a group command is used to define which atoms
-belong to the group.
+    example you cannot set the temperature of a group of atoms until
+    atoms have been defined and a group command is used to define which
+    atoms belong to the group.
 
 (3) Sometimes command B will use values that can be set by command A.
-This means command A must precede command B in the input script if it
-is to have the desired effect.  For example, the
-:doc:`read_data <read_data>` command initializes the system by setting
-up the simulation box and assigning atoms to processors.  If default
-values are not desired, the :doc:`processors <processors>` and
-:doc:`boundary <boundary>` commands need to be used before read_data to
-tell LAMMPS how to map processors to the simulation box.
+    This means command A must precede command B in the input script if
+    it is to have the desired effect.  For example, the :doc:`read_data
+    <read_data>` command initializes the system by setting up the
+    simulation box and assigning atoms to processors.  If default values
+    are not desired, the :doc:`processors <processors>` and
+    :doc:`boundary <boundary>` commands need to be used before read_data
+    to tell LAMMPS how to map processors to the simulation box.
 
 Many input script errors are detected by LAMMPS and an ERROR or
-WARNING message is printed.  The :doc:`Errors <Errors>` doc page gives
+WARNING message is printed.  The :doc:`Errors <Errors>` page gives
 more information on what errors mean.  The documentation for each
 command lists restrictions on how the command can be used.
+
+You can use the :ref:`-skiprun <skiprun>` command line flag
+to have LAMMPS skip the execution of any "run", "minimize", or similar
+commands to check the entire input for correct syntax to avoid crashes
+on typos or syntax errors in long runs.

doc/src/Commands_kspace.rst

@@ -24,6 +24,7 @@ OPT.
 
    * :doc:`ewald (o) <kspace_style>`
    * :doc:`ewald/disp <kspace_style>`
+   * :doc:`ewald/disp/dipole <kspace_style>`
    * :doc:`ewald/dipole <kspace_style>`
    * :doc:`ewald/dipole/spin <kspace_style>`
    * :doc:`msm (o) <kspace_style>`
@@ -33,8 +34,10 @@ OPT.
    * :doc:`pppm/cg (o) <kspace_style>`
    * :doc:`pppm/dipole <kspace_style>`
    * :doc:`pppm/dipole/spin <kspace_style>`
+   * :doc:`pppm/dielectric <kspace_style>`
    * :doc:`pppm/disp (io) <kspace_style>`
    * :doc:`pppm/disp/tip4p (o) <kspace_style>`
+   * :doc:`pppm/disp/dielectric <kspace_style>`
    * :doc:`pppm/stagger <kspace_style>`
    * :doc:`pppm/tip4p (o) <kspace_style>`
    * :doc:`pppm/dielectric <kspace_style>`

doc/src/Commands_pair.rst

@@ -29,7 +29,7 @@ OPT.
    * :doc:`hybrid/scaled <pair_hybrid>`
    * :doc:`kim <pair_kim>`
    * :doc:`list <pair_list>`
-   *
+   * :doc:`tracker <pair_tracker>`
    *
    *
    *
@@ -75,6 +75,7 @@ OPT.
    * :doc:`coul/debye (gko) <pair_coul>`
    * :doc:`coul/diel (o) <pair_coul_diel>`
    * :doc:`coul/dsf (gko) <pair_coul>`
+   * :doc:`coul/exclude <pair_coul>`
    * :doc:`coul/long (gko) <pair_coul>`
    * :doc:`coul/long/cs (g) <pair_cs>`
    * :doc:`coul/long/dielectric <pair_dielectric>`
@@ -235,7 +236,7 @@ OPT.
    * :doc:`python <pair_python>`
    * :doc:`quip <pair_quip>`
    * :doc:`rann <pair_rann>`
-   * :doc:`reax/c (ko) <pair_reaxc>`
+   * :doc:`reaxff (ko) <pair_reaxff>`
    * :doc:`rebo (io) <pair_airebo>`
    * :doc:`resquared (go) <pair_resquared>`
    * :doc:`sdpd/taitwater/isothermal <pair_sdpd_taitwater_isothermal>`

doc/src/Commands_parse.rst

@@ -47,7 +47,7 @@ LAMMPS:
    named "x" followed by an "x" character.
 
    How the variable is converted to a text string depends on what style
-   of variable it is; see the :doc:`variable <variable>` doc page for
+   of variable it is; see the :doc:`variable <variable>` page for
    details.  It can be a variable that stores multiple text strings, and
    return one of them.  The returned text string can be multiple "words"
    (space separated) which will then be interpreted as multiple

doc/src/Developer.rst

@@ -11,6 +11,7 @@ of time and requests from the LAMMPS user community.
    :maxdepth: 1
 
    Developer_org
+   Developer_parallel
    Developer_flow
    Developer_write
    Developer_notes

doc/src/Developer_org.rst

@@ -17,7 +17,7 @@ currently supports building with :doc:`conventional makefiles
 differ in how packages are enabled or disabled for inclusion into a
 LAMMPS binary so they cannot be mixed.  The source files for each
 package are in all-uppercase sub-directories of the ``src`` folder, for
-example ``src/MOLECULE`` or ``src/USER-MISC``.  The ``src/STUBS``
+example ``src/MOLECULE`` or ``src/EXTRA-MOLECULE``.  The ``src/STUBS``
 sub-directory is not a package but contains a dummy MPI library, that is
 used when building a serial version of the code. The ``src/MAKE``
 directory and its sub-directories contain makefiles with settings and

doc/src/Developer_par_comm.rst

@@ -0,0 +1,120 @@
+Communication
+^^^^^^^^^^^^^
+
+Following the partitioning scheme in use all per-atom data is
+distributed across the MPI processes, which allows LAMMPS to handle very
+large systems provided it uses a correspondingly large number of MPI
+processes.  Since The per-atom data (atom IDs, positions, velocities,
+types, etc.)  To be able to compute the short-range interactions MPI
+processes need not only access to data of atoms they "own" but also
+information about atoms from neighboring sub-domains, in LAMMPS referred
+to as "ghost" atoms.  These are copies of atoms storing required
+per-atom data for up to the communication cutoff distance. The green
+dashed-line boxes in the :ref:`domain-decomposition` figure illustrate
+the extended ghost-atom sub-domain for one processor.
+
+This approach is also used to implement periodic boundary
+conditions: atoms that lie within the cutoff distance across a periodic
+boundary are also stored as ghost atoms and taken from the periodic
+replication of the sub-domain, which may be the same sub-domain, e.g. if
+running in serial.  As a consequence of this, force computation in
+LAMMPS is not subject to minimum image conventions and thus cutoffs may
+be larger than half the simulation domain.
+
+.. _ghost-atom-comm:
+.. figure:: img/ghost-comm.png
+   :align: center
+
+   ghost atom communication
+
+   This figure shows the ghost atom communication patterns between
+   sub-domains for "brick" (left) and "tiled" communication styles for
+   2d simulations.  The numbers indicate MPI process ranks.  Here the
+   sub-domains are drawn spatially separated for clarity.  The
+   dashed-line box is the extended sub-domain of processor 0 which
+   includes its ghost atoms.  The red- and blue-shaded boxes are the
+   regions of communicated ghost atoms.
+
+Efficient communication patterns are needed to update the "ghost" atom
+data, since that needs to be done at every MD time step or minimization
+step.  The diagrams of the `ghost-atom-comm` figure illustrate how ghost
+atom communication is performed in two stages for a 2d simulation (three
+in 3d) for both a regular and irregular partitioning of the simulation
+box.  For the regular case (left) atoms are exchanged first in the
+*x*-direction, then in *y*, with four neighbors in the grid of processor
+sub-domains.
+
+In the *x* stage, processor ranks 1 and 2 send owned atoms in their
+red-shaded regions to rank 0 (and vice versa).  Then in the *y* stage,
+ranks 3 and 4 send atoms in their blue-shaded regions to rank 0, which
+includes ghost atoms they received in the *x* stage.  Rank 0 thus
+acquires all its ghost atoms; atoms in the solid blue corner regions
+are communicated twice before rank 0 receives them.
+
+For the irregular case (right) the two stages are similar, but a
+processor can have more than one neighbor in each direction.  In the
+*x* stage, MPI ranks 1,2,3 send owned atoms in their red-shaded regions to
+rank 0 (and vice versa).  These include only atoms between the lower
+and upper *y*-boundary of rank 0's sub-domain.  In the *y* stage, ranks
+4,5,6 send atoms in their blue-shaded regions to rank 0.  This may
+include ghost atoms they received in the *x* stage, but only if they
+are needed by rank 0 to fill its extended ghost atom regions in the
++/-*y* directions (blue rectangles).  Thus in this case, ranks 5 and
+6 do not include ghost atoms they received from each other (in the *x*
+stage) in the atoms they send to rank 0.  The key point is that while
+the pattern of communication is more complex in the irregular
+partitioning case, it can still proceed in two stages (three in 3d)
+via atom exchanges with only neighboring processors.
+
+When attributes of owned atoms are sent to neighboring processors to
+become attributes of their ghost atoms, LAMMPS calls this a "forward"
+communication.  On timesteps when atoms migrate to new owning processors
+and neighbor lists are rebuilt, each processor creates a list of its
+owned atoms which are ghost atoms in each of its neighbor processors.
+These lists are used to pack per-atom coordinates (for example) into
+message buffers in subsequent steps until the next reneighboring.
+
+A "reverse" communication is when computed ghost atom attributes are
+sent back to the processor who owns the atom.  This is used (for
+example) to sum partial forces on ghost atoms to the complete force on
+owned atoms.  The order of the two stages described in the
+:ref:`ghost-atom-comm` figure is inverted and the same lists of atoms
+are used to pack and unpack message buffers with per-atom forces.  When
+a received buffer is unpacked, the ghost forces are summed to owned atom
+forces.  As in forward communication, forces on atoms in the four blue
+corners of the diagrams are sent, received, and summed twice (once at
+each stage) before owning processors have the full force.
+
+These two operations are used many places within LAMMPS aside from
+exchange of coordinates and forces, for example by manybody potentials
+to share intermediate per-atom values, or by rigid-body integrators to
+enable each atom in a body to access body properties.  Here are
+additional details about how these communication operations are
+performed in LAMMPS:
+
+- When exchanging data with different processors, forward and reverse
+  communication is done using ``MPI_Send()`` and ``MPI_IRecv()`` calls.
+  If a processor is "exchanging" atoms with itself, only the pack and
+  unpack operations are performed, e.g. to create ghost atoms across
+  periodic boundaries when running on a single processor.
+
+- For forward communication of owned atom coordinates, periodic box
+  lengths are added and subtracted when the receiving processor is
+  across a periodic boundary from the sender.  There is then no need to
+  apply a minimum image convention when calculating distances between
+  atom pairs when building neighbor lists or computing forces.
+
+- The cutoff distance for exchanging ghost atoms is typically equal to
+  the neighbor cutoff.  But it can also chosen to be longer if needed,
+  e.g. half the diameter of a rigid body composed of multiple atoms or
+  over 3x the length of a stretched bond for dihedral interactions.  It
+  can also exceed the periodic box size.  For the regular communication
+  pattern (left), if the cutoff distance extends beyond a neighbor
+  processor's sub-domain, then multiple exchanges are performed in the
+  same direction.  Each exchange is with the same neighbor processor,
+  but buffers are packed/unpacked using a different list of atoms. For
+  forward communication, in the first exchange a processor sends only
+  owned atoms.  In subsequent exchanges, it sends ghost atoms received
+  in previous exchanges.  For the irregular pattern (right) overlaps of
+  a processor's extended ghost-atom sub-domain with all other processors
+  in each dimension are detected.

doc/src/Developer_par_long.rst

@@ -0,0 +1,188 @@
+Long-range interactions
+^^^^^^^^^^^^^^^^^^^^^^^
+
+For charged systems, LAMMPS can compute long-range Coulombic
+interactions via the FFT-based particle-particle/particle-mesh (PPPM)
+method implemented in :doc:`kspace style pppm and its variants
+<kspace_style>`.  For that Coulombic interactions are partitioned into
+short- and long-range components.  The short-ranged portion is computed
+in real space as a loop over pairs of charges within a cutoff distance,
+using neighbor lists.  The long-range portion is computed in reciprocal
+space using a kspace style.  For the PPPM implementation the simulation
+cell is overlaid with a regular FFT grid in 3d. It proceeds in several stages:
+
+a) each atom's point charge is interpolated to nearby FFT grid points,
+b) a forward 3d FFT is performed,
+c) a convolution operation is performed in reciprocal space,
+d) one or more inverse 3d FFTs are performed, and
+e) electric field values from grid points near each atom are interpolated to compute
+   its forces.
+
+For any of the spatial-decomposition partitioning schemes each processor
+owns the brick-shaped portion of FFT grid points contained within its
+sub-domain.  The two interpolation operations use a stencil of grid
+points surrounding each atom.  To accommodate the stencil size, each
+processor also stores a few layers of ghost grid points surrounding its
+brick.  Forward and reverse communication of grid point values is
+performed similar to the corresponding :doc:`atom data communication
+<Developer_par_comm>`.  In this case, electric field values on owned
+grid points are sent to neighboring processors to become ghost point
+values.  Likewise charge values on ghost points are sent and summed to
+values on owned points.
+
+For triclinic simulation boxes, the FFT grid planes are parallel to
+the box faces, but the mapping of charge and electric field values
+to/from grid points is done in reduced coordinates where the tilted
+box is conceptually a unit cube, so that the stencil and FFT
+operations are unchanged.  However the FFT grid size required for a
+given accuracy is larger for triclinic domains than it is for
+orthogonal boxes.
+
+.. _fft-parallel:
+.. figure:: img/fft-decomp-parallel.png
+   :align: center
+
+   parallel FFT in PPPM
+
+   Stages of a parallel FFT for a simulation domain overlaid
+   with an 8x8x8 3d FFT grid, partitioned across 64 processors.
+   Within each of the 4 diagrams, grid cells of the same color are
+   owned by a single processor; for simplicity only cells owned by 4
+   or 8 of the 64 processors are colored.  The two images on the left
+   illustrate brick-to-pencil communication.  The two images on the
+   right illustrate pencil-to-pencil communication, which in this
+   case transposes the *y* and *z* dimensions of the grid.
+
+Parallel 3d FFTs require substantial communication relative to their
+computational cost.  A 3d FFT is implemented by a series of 1d FFTs
+along the *x-*, *y-*, and *z-*\ direction of the FFT grid.  Thus the FFT
+grid cannot be decomposed like atoms into 3 dimensions for parallel
+processing of the FFTs but only in 1 (as planes) or 2 (as pencils)
+dimensions and in between the steps the grid needs to be transposed to
+have the FFT grid portion "owned" by each MPI process complete in the
+direction of the 1d FFTs it has to perform. LAMMPS uses the
+pencil-decomposition algorithm as shown in the :ref:`fft-parallel` figure.
+
+Initially (far left), each processor owns a brick of same-color grid
+cells (actually grid points) contained within in its sub-domain.  A
+brick-to-pencil communication operation converts this layout to 1d
+pencils in the *x*-dimension (center left).  Again, cells of the same
+color are owned by the same processor.  Each processor can then compute
+a 1d FFT on each pencil of data it wholly owns using a call to the
+configured FFT library.  A pencil-to-pencil communication then converts
+this layout to pencils in the *y* dimension (center right) which
+effectively transposes the *x* and *y* dimensions of the grid, followed
+by 1d FFTs in *y*.  A final transpose of pencils from *y* to *z* (far
+right) followed by 1d FFTs in *z* completes the forward FFT.  The data
+is left in a *z*-pencil layout for the convolution operation.  One or
+more inverse FFTs then perform the sequence of 1d FFTs and communication
+steps in reverse order; the final layout of resulting grid values is the
+same as the initial brick layout.
+
+Each communication operation within the FFT (brick-to-pencil or
+pencil-to-pencil or pencil-to-brick) converts one tiling of the 3d grid
+to another, where a tiling in this context means an assignment of a
+small brick-shaped subset of grid points to each processor, the union of
+which comprise the entire grid.  The parallel `fftMPI library
+<https://lammps.github.io/fftmpi/>`_ written for LAMMPS allows arbitrary
+definitions of the tiling so that an irregular partitioning of the
+simulation domain can use it directly.  Transforming data from one
+tiling to another is implemented in `fftMPI` using point-to-point
+communication, where each processor sends data to a few other
+processors, since each tile in the initial tiling overlaps with a
+handful of tiles in the final tiling.
+
+The transformations could also be done using collective communication
+across all $P$ processors with a single call to ``MPI_Alltoall()``, but
+this is typically much slower.  However, for the specialized brick and
+pencil tiling illustrated in :ref:`fft-parallel` figure, collective
+communication across the entire MPI communicator is not required.  In
+the example an :math:`8^3` grid with 512 grid cells is partitioned
+across 64 processors; each processor owns a 2x2x2 3d brick of grid
+cells.  The initial brick-to-pencil communication (upper left to upper
+right) only requires collective communication within subgroups of 4
+processors, as illustrated by the 4 colors.  More generally, a
+brick-to-pencil communication can be performed by partitioning *P*
+processors into :math:`P^{\frac{2}{3}}` subgroups of
+:math:`P^{\frac{1}{3}}` processors each.  Each subgroup performs
+collective communication only within its subgroup.  Similarly,
+pencil-to-pencil communication can be performed by partitioning *P*
+processors into :math:`P^{\frac{1}{2}}` subgroups of
+:math:`P^{\frac{1}{2}}` processors each.  This is illustrated in the
+figure for the :math:`y \Rightarrow z` communication (center).  An
+eight-processor subgroup owns the front *yz* plane of data and performs
+collective communication within the subgroup to transpose from a
+*y*-pencil to *z*-pencil layout.
+
+LAMMPS invokes point-to-point communication by default, but also
+provides the option of partitioned collective communication when using a
+:doc:`kspace_modify collective yes <kspace_modify>` command to switch to
+that mode.  In the latter case, the code detects the size of the
+disjoint subgroups and partitions the single *P*-size communicator into
+multiple smaller communicators, each of which invokes collective
+communication.  Testing on a large IBM Blue Gene/Q machine at Argonne
+National Labs showed a significant improvement in FFT performance for
+large processor counts; partitioned collective communication was faster
+than point-to-point communication or global collective communication
+involving all *P* processors.
+
+Here are some additional details about FFTs for long-range and related
+grid/particle operations that LAMMPS supports:
+
+- The fftMPI library allows each grid dimension to be a multiple of
+  small prime factors (2,3,5), and allows any number of processors to
+  perform the FFT.  The resulting brick and pencil decompositions are
+  thus not always as well-aligned but the size of subgroups of
+  processors for the two modes of communication (brick/pencil and
+  pencil/pencil) still scale as :math:`O(P^{\frac{1}{3}})` and
+  :math:`O(P^{\frac{1}{2}})`.
+
+- For efficiency in performing 1d FFTs, the grid transpose
+  operations illustrated in Figure \ref{fig:fft} also involve
+  reordering the 3d data so that a different dimension is contiguous
+  in memory.  This reordering can be done during the packing or
+  unpacking of buffers for MPI communication.
+
+- For large systems and particularly a large number of MPI processes,
+  the dominant cost for parallel FFTs is often the communication, not
+  the computation of 1d FFTs, even though the latter scales as :math:`N
+  \log(N)` in the number of grid points *N* per grid direction.  This is
+  due to the fact that only a 2d decomposition into pencils is possible
+  while atom data (and their corresponding short-range force and energy
+  computations) can be decomposed efficiently in 3d.
+
+  This can be addressed by reducing the number of MPI processes involved
+  in the MPI communication by using :doc:`hybrid MPI + OpenMP
+  parallelization <Speed_omp>`.  This will use OpenMP parallelization
+  inside the MPI domains and while that may have a lower parallel
+  efficiency, it reduces the communication overhead.
+
+  As an alternative it is also possible to start a :ref:`multi-partition
+  <partition>` calculation and then use the :doc:`verlet/split
+  integrator <run_style>` to perform the PPPM computation on a
+  dedicated, separate partition of MPI processes.  This uses an integer
+  "1:*p*" mapping of *p* sub-domains of the atom decomposition to one
+  sub-domain of the FFT grid decomposition and where pairwise non-bonded
+  and bonded forces and energies are computed on the larger partition
+  and the PPPM kspace computation concurrently on the smaller partition.
+
+- LAMMPS also implements PPPM-based solvers for other long-range
+  interactions, dipole and dispersion (Lennard-Jones), which can be used
+  in conjunction with long-range  Coulombics for point charges.
+
+- LAMMPS implements a ``GridComm`` class which overlays the simulation
+  domain with a regular grid, partitions it across processors in a
+  manner consistent with processor sub-domains, and provides methods for
+  forward and reverse communication of owned and ghost grid point
+  values.  It is used for PPPM as an FFT grid (as outlined above) and
+  also for the MSM algorithm which uses a cascade of grid sizes from
+  fine to coarse to compute long-range Coulombic forces.  The GridComm
+  class is also useful for models where continuum fields interact with
+  particles.  For example, the two-temperature model (TTM) defines heat
+  transfer between atoms (particles) and electrons (continuum gas) where
+  spatial variations in the electron temperature are computed by finite
+  differences of a discretized heat equation on a regular grid.  The
+  :doc:`fix ttm/grid <fix_ttm>` command uses the ``GridComm`` class
+  internally to perform its grid operations on a distributed grid
+  instead of the original :doc:`fix ttm <fix_ttm>` which uses a
+  replicated grid.

doc/src/Developer_par_neigh.rst

@@ -0,0 +1,159 @@
+Neighbor lists
+^^^^^^^^^^^^^^
+
+To compute forces efficiently, each processor creates a Verlet-style
+neighbor list which enumerates all pairs of atoms *i,j* (*i* = owned,
+*j* = owned or ghost) with separation less than the applicable
+neighbor list cutoff distance.  In LAMMPS the neighbor lists are stored
+in a multiple-page data structure; each page is a contiguous chunk of
+memory which stores vectors of neighbor atoms *j* for many *i* atoms.
+This allows pages to be incrementally allocated or deallocated in blocks
+as needed.  Neighbor lists typically consume the most memory of any data
+structure in LAMMPS.  The neighbor list is rebuilt (from scratch) once
+every few timesteps, then used repeatedly each step for force or other
+computations.  The neighbor cutoff distance is :math:`R_n = R_f +
+\Delta_s`, where :math:`R_f` is the (largest) force cutoff defined by
+the interatomic potential for computing short-range pairwise or manybody
+forces and :math:`\Delta_s` is a "skin" distance that allows the list to
+be used for multiple steps assuming that atoms do not move very far
+between consecutive time steps.  Typically the code triggers
+reneighboring when any atom has moved half the skin distance since the
+last reneighboring; this and other options of the neighbor list rebuild
+can be adjusted with the :doc:`neigh_modify <neigh_modify>` command.
+
+On steps when reneighboring is performed, atoms which have moved outside
+their owning processor's sub-domain are first migrated to new processors
+via communication.  Periodic boundary conditions are also (only)
+enforced on these steps to ensure each atom is re-assigned to the
+correct processor.  After migration, the atoms owned by each processor
+are stored in a contiguous vector.  Periodically each processor
+spatially sorts owned atoms within its vector to reorder it for improved
+cache efficiency in force computations and neighbor list building.  For
+that atoms are spatially binned and then reordered so that atoms in the
+same bin are adjacent in the vector.  Atom sorting can be disabled or
+its settings modified with the :doc:`atom_modify <atom_modify>` command.
+
+.. _neighbor-stencil:
+.. figure:: img/neigh-stencil.png
+   :align: center
+
+   neighbor list stencils
+
+   A 2d simulation sub-domain (thick black line) and the corresponding
+   ghost atom cutoff region (dashed blue line) for both orthogonal
+   (left) and triclinic (right) domains.  A regular grid of neighbor
+   bins (thin lines) overlays the entire simulation domain and need not
+   align with sub-domain boundaries; only the portion overlapping the
+   augmented sub-domain is shown.  In the triclinic case it overlaps the
+   bounding box of the tilted rectangle.  The blue- and red-shaded bins
+   represent a stencil of bins searched to find neighbors of a particular
+   atom (black dot).
+
+To build a local neighbor list in linear time, the simulation domain is
+overlaid (conceptually) with a regular 3d (or 2d) grid of neighbor bins,
+as shown in the :ref:`neighbor-stencil` figure for 2d models and a
+single MPI processor's sub-domain.  Each processor stores a set of
+neighbor bins which overlap its sub-domain extended by the neighbor
+cutoff distance :math:`R_n`.  As illustrated, the bins need not align
+with processor boundaries; an integer number in each dimension is fit to
+the size of the entire simulation box.
+
+Most often LAMMPS builds what it calls a "half" neighbor list where
+each *i,j* neighbor pair is stored only once, with either atom *i* or
+*j* as the central atom.  The build can be done efficiently by using a
+pre-computed "stencil" of bins around a central origin bin which
+contains the atom whose neighbors are being searched for.  A stencil
+is simply a list of integer offsets in *x,y,z* of nearby bins
+surrounding the origin bin which are close enough to contain any
+neighbor atom *j* within a distance :math:`R_n` from any atom *i* in the
+origin bin.  Note that for a half neighbor list, the stencil can be
+asymmetric since each atom only need store half its nearby neighbors.
+
+These stencils are illustrated in the figure for a half list and a bin
+size of :math:`\frac{1}{2} R_n`.  There are 13 red+blue stencil bins in
+2d (for the orthogonal case, 15 for triclinic).  In 3d there would be
+63, 13 in the plane of bins that contain the origin bin and 25 in each
+of the two planes above it in the *z* direction (75 for triclinic).  The
+reason the triclinic stencil has extra bins is because the bins tile the
+bounding box of the entire triclinic domain and thus are not periodic
+with respect to the simulation box itself.  The stencil and logic for
+determining which *i,j* pairs to include in the neighbor list are
+altered slightly to account for this.
+
+To build a neighbor list, a processor first loops over its "owned" plus
+"ghost" atoms and assigns each to a neighbor bin.  This uses an integer
+vector to create a linked list of atom indices within each bin.  It then
+performs a triply-nested loop over its owned atoms *i*, the stencil of
+bins surrounding atom *i*'s bin, and the *j* atoms in each stencil bin
+(including ghost atoms).  If the distance :math:`r_{ij} < R_n`, then
+atom *j* is added to the vector of atom *i*'s neighbors.
+
+Here are additional details about neighbor list build options LAMMPS
+supports:
+
+- The choice of bin size is an option; a size half of :math:`R_n` has
+  been found to be optimal for many typical cases.  Smaller bins incur
+  additional overhead to loop over; larger bins require more distance
+  calculations.  Note that for smaller bin sizes, the 2d stencil in the
+  figure would be more semi-circular in shape (hemispherical in 3d),
+  with bins near the corners of the square eliminated due to their
+  distance from the origin bin.
+
+- Depending on the interatomic potential(s) and other commands used in
+  an input script, multiple neighbor lists and stencils with different
+  attributes may be needed.  This includes lists with different cutoff
+  distances, e.g. for force computation versus occasional diagnostic
+  computations such as a radial distribution function, or for the
+  r-RESPA time integrator which can partition pairwise forces by
+  distance into subsets computed at different time intervals.  It
+  includes "full" lists (as opposed to half lists) where each *i,j* pair
+  appears twice, stored once with *i* and *j*, and which use a larger
+  symmetric stencil.  It also includes lists with partial enumeration of
+  ghost atom neighbors.  The full and ghost-atom lists are used by
+  various manybody interatomic potentials.  Lists may also use different
+  criteria for inclusion of a pair interaction.  Typically this simply
+  depends only on the distance between two atoms and the cutoff
+  distance.  But for finite-size coarse-grained particles with
+  individual diameters (e.g. polydisperse granular particles), it can
+  also depend on the diameters of the two particles.
+
+- When using :doc:`pair style hybrid <pair_hybrid>` multiple sub-lists
+  of the master neighbor list for the full system need to be generated,
+  one for each sub-style, which contains only the *i,j* pairs needed to
+  compute interactions between subsets of atoms for the corresponding
+  potential.  This means not all *i* or *j* atoms owned by a processor
+  are included in a particular sub-list.
+
+- Some models use different cutoff lengths for pairwise interactions
+  between different kinds of particles which are stored in a single
+  neighbor list.  One example is a solvated colloidal system with large
+  colloidal particles where colloid/colloid, colloid/solvent, and
+  solvent/solvent interaction cutoffs can be dramatically different.
+  Another is a model of polydisperse finite-size granular particles;
+  pairs of particles interact only when they are in contact with each
+  other.  Mixtures with particle size ratios as high as 10-100x may be
+  used to model realistic systems.  Efficient neighbor list building
+  algorithms for these kinds of systems are available in LAMMPS.  They
+  include a method which uses different stencils for different cutoff
+  lengths and trims the stencil to only include bins that straddle the
+  cutoff sphere surface.  More recently a method which uses both
+  multiple stencils and multiple bin sizes was developed; it builds
+  neighbor lists efficiently for systems with particles of any size
+  ratio, though other considerations (timestep size, force computations)
+  may limit the ability to model systems with huge polydispersity.
+
+- For small and sparse systems and as a fallback method, LAMMPS also
+  supports neighbor list construction without binning by using a full
+  :math:`O(N^2)` loop over all *i,j* atom pairs in a sub-domain when
+  using the :doc:`neighbor nsq <neighbor>` command.
+
+- Dependent on the "pair" setting of the :doc:`newton <newton>` command,
+  the "half" neighbor lists may contain **all** pairs of atoms where
+  atom *j* is a ghost atom (i.e. when the newton pair setting is *off*)
+  For the newton pair *on* setting the atom *j* is only added to the
+  list if its *z* coordinate is larger, or if equal the *y* coordinate
+  is larger, and that is equal, too, the *x* coordinate is larger.  For
+  homogeneously dense systems that will result in picking neighbors from
+  a same size sector in always the same direction relative to the
+  "owned" atom and thus it should lead to similar length neighbor lists
+  and thus reduce the chance of a load imbalance.

doc/src/Developer_par_openmp.rst

@@ -0,0 +1,114 @@
+OpenMP Parallelism
+^^^^^^^^^^^^^^^^^^
+
+The styles in the INTEL, KOKKOS, and OPENMP package offer to use OpenMP
+thread parallelism to predominantly distribute loops over local data
+and thus follow an orthogonal parallelization strategy to the
+decomposition into spatial domains used by the :doc:`MPI partitioning
+<Developer_par_part>`.  For clarity, this section discusses only the
+implementation in the OPENMP package as it is the simplest. The INTEL
+and KOKKOS package offer additional options and are more complex since
+they support more features and different hardware like co-processors
+or GPUs.
+
+One of the key decisions when implementing the OPENMP package was to
+keep the changes to the source code small, so that it would be easier to
+maintain the code and keep it in sync with the non-threaded standard
+implementation.  this is achieved by a) making the OPENMP version a
+derived class from the regular version (e.g. ``PairLJCutOMP`` from
+``PairLJCut``) and overriding only methods that are multi-threaded or
+need to be modified to support multi-threading (similar to what was done
+in the OPT package), b) keeping the structure in the modified code very
+similar so that side-by-side comparisons are still useful, and c)
+offloading additional functionality and multi-thread support functions
+into three separate classes ``ThrOMP``, ``ThrData``, and ``FixOMP``.
+``ThrOMP`` provides additional, multi-thread aware functionality not
+available in the corresponding base class (e.g. ``Pair`` for
+``PairLJCutOMP``) like multi-thread aware variants of the "tally"
+functions. Those functions are made available through multiple
+inheritance so those new functions have to have unique names to avoid
+ambiguities; typically ``_thr`` is appended to the name of the function.
+``ThrData`` is a classes that manages per-thread data structures.
+It is used instead of extending the corresponding storage to per-thread
+arrays to avoid slowdowns due to "false sharing" when multiple threads
+update adjacent elements in an array and thus force the CPU cache lines
+to be reset and re-fetched.  ``FixOMP`` finally manages the "multi-thread
+state" like settings and access to per-thread storage, it is activated
+by the :doc:`package omp <package>` command.
+
+Avoiding data races
+"""""""""""""""""""
+
+A key problem when implementing thread parallelism in an MD code is
+to avoid data races when updating accumulated properties like forces,
+energies, and stresses.  When interactions are computed, they always
+involve multiple atoms and thus there are race conditions when multiple
+threads want to update per-atom data of the same atoms.  Five possible
+strategies have been considered to avoid this:
+
+1) restructure the code so that there is no overlapping access possible
+   when computing in parallel, e.g. by breaking lists into multiple
+   parts and synchronizing threads in between.
+2) have each thread be "responsible" for a specific group of atoms and
+   compute these interactions multiple times, once on each thread that
+   is responsible for a given atom and then have each thread only update
+   the properties of this atom.
+3) use mutexes around functions and regions of code where the data race
+   could happen
+4) use atomic operations when updating per-atom properties
+5) use replicated per-thread data structures to accumulate data without
+   conflicts and then use a reduction to combine those results into the
+   data structures used by the regular style.
+
+Option 5 was chosen for the OPENMP package because it would retain the
+performance for the case of 1 thread and the code would be more
+maintainable.  Option 1 would require extensive code changes,
+particularly to the neighbor list code; options 2 would have incurred a
+2x or more performance penalty for the serial case; option 3 causes
+significant overhead and would enforce serialization of operations in
+inner loops and thus defeat the purpose of multi-threading; option 4
+slows down the serial case although not quite as bad as option 2.  The
+downside of option 5 is that the overhead of the reduction operations
+grows with the number of threads used, so there would be a crossover
+point where options 2 or 4 would result in faster executing.  That is
+why option 2 for example is used in the GPU package because a GPU is a
+processor with a massive number of threads.  However, since the MPI
+parallelization is generally more effective for typical MD systems, the
+expectation is that thread parallelism is only used for a smaller number
+of threads (2-8).  At the time of its implementation, that number was
+equivalent to the number of CPU cores per CPU socket on high-end
+supercomputers.
+
+Thus arrays like the force array are dimensioned to the number of atoms
+times the number of threads when enabling OpenMP support and inside the
+compute functions a pointer to a different chunk is obtained by each thread.
+Similarly, accumulators like potential energy or virial are kept in
+per-thread instances of the ``ThrData`` class and then only reduced and
+stored in their global counterparts at the end of the force computation.
+
+
+Loop scheduling
+"""""""""""""""
+
+Multi-thread parallelization is applied by distributing (outer) loops
+statically across threads.  Typically this would be the loop over local
+atoms *i* when processing *i,j* pairs of atoms from a neighbor list.
+The design of the neighbor list code results in atoms having a similar
+number of neighbors for homogeneous systems and thus load imbalances
+across threads are not common and typically happen for systems where
+also the MPI parallelization would be unbalanced, which would typically
+have a more pronounced impact on the performance.  This same loop
+scheduling scheme can also be applied to the reduction operations on
+per-atom data to try and reduce the overhead of the reduction operation.
+
+Neighbor list parallelization
+"""""""""""""""""""""""""""""
+
+In addition to the parallelization of force computations, also the
+generation of the neighbor lists is parallelized.  As explained
+previously, neighbor lists are built by looping over "owned" atoms and
+storing the neighbors in "pages".  In the OPENMP variants of the
+neighbor list code, each thread operates on a different chunk of "owned"
+atoms and allocates and fills its own set of pages with neighbor list
+data.  This is achieved by each thread keeping its own instance of the
+:cpp:class:`MyPage <LAMMPS_NS::MyPage>` page allocator class.

doc/src/Developer_par_part.rst

@@ -0,0 +1,89 @@
+Partitioning
+^^^^^^^^^^^^
+
+The underlying spatial decomposition strategy used by LAMMPS for
+distributed-memory parallelism is set with the :doc:`comm_style command
+<comm_style>` and can be either "brick" (a regular grid) or "tiled".
+
+.. _domain-decomposition:
+.. figure:: img/domain-decomp.png
+   :align: center
+
+   domain decomposition
+
+   This figure shows the different kinds of domain decomposition used
+   for MPI parallelization: "brick" on the left with an orthogonal
+   (left) and a triclinic (middle) simulation domain, and a "tiled"
+   decomposition (right).  The black lines show the division into
+   sub-domains and the contained atoms are "owned" by the corresponding
+   MPI process. The green dashed lines indicate how sub-domains are
+   extended with "ghost" atoms up to the communication cutoff distance.
+
+The LAMMPS simulation box is a 3d or 2d volume, which can be orthogonal
+or triclinic in shape, as illustrated in the :ref:`domain-decomposition`
+figure for the 2d case.  Orthogonal means the box edges are aligned with
+the *x*, *y*, *z* Cartesian axes, and the box faces are thus all
+rectangular.  Triclinic allows for a more general parallelepiped shape
+in which edges are aligned with three arbitrary vectors and the box
+faces are parallelograms.  In each dimension box faces can be periodic,
+or non-periodic with fixed or shrink-wrapped boundaries.  In the fixed
+case, atoms which move outside the face are deleted; shrink-wrapped
+means the position of the box face adjusts continuously to enclose all
+the atoms.
+
+For distributed-memory MPI parallelism, the simulation box is spatially
+decomposed (partitioned) into non-overlapping sub-domains which fill the
+box. The default partitioning, "brick", is most suitable when atom
+density is roughly uniform, as shown in the left-side images of the
+:ref:`domain-decomposition` figure.  The sub-domains comprise a regular
+grid and all sub-domains are identical in size and shape.  Both the
+orthogonal and triclinic boxes can deform continuously during a
+simulation, e.g. to compress a solid or shear a liquid, in which case
+the processor sub-domains likewise deform.
+
+
+For models with non-uniform density, the number of particles per
+processor can be load-imbalanced with the default partitioning.  This
+reduces parallel efficiency, as the overall simulation rate is limited
+by the slowest processor, i.e. the one with the largest computational
+load.  For such models, LAMMPS supports multiple strategies to reduce
+the load imbalance:
+
+- The processor grid decomposition is by default based on the simulation
+  cell volume and tries to optimize the volume to surface ratio for the sub-domains.
+  This can be changed with the :doc:`processors command <processors>`.
+- The parallel planes defining the size of the sub-domains can be shifted
+  with the :doc:`balance command <balance>`. Which can be done in addition
+  to choosing a more optimal processor grid.
+- The recursive bisectioning algorithm in combination with the "tiled"
+  communication style can produce a partitioning with equal numbers of
+  particles in each sub-domain.
+
+
+.. |decomp1| image:: img/decomp-regular.png
+   :width: 24%
+
+.. |decomp2| image:: img/decomp-processors.png
+   :width: 24%
+
+.. |decomp3| image:: img/decomp-balance.png
+   :width: 24%
+
+.. |decomp4| image:: img/decomp-rcb.png
+   :width: 24%
+
+|decomp1|  |decomp2|  |decomp3|  |decomp4|
+
+The pictures above demonstrate different decompositions for a 2d system
+with 12 MPI ranks.  The atom colors indicate the load imbalance of each
+sub-domain with green being optimal and red the least optimal.
+
+Due to the vacuum in the system, the default decomposition is unbalanced
+with several MPI ranks without atoms (left). By forcing a 1x12x1
+processor grid, every MPI rank does computations now, but number of
+atoms per sub-domain is still uneven and the thin slice shape increases
+the amount of communication between sub-domains (center left). With a
+2x6x1 processor grid and shifting the sub-domain divisions, the load
+imbalance is further reduced and the amount of communication required
+between sub-domains is less (center right).  And using the recursive
+bisectioning leads to further improved decomposition (right).

doc/src/Developer_parallel.rst

@@ -0,0 +1,28 @@
+Parallel algorithms
+-------------------
+
+LAMMPS is designed to enable running simulations in parallel using the
+MPI parallel communication standard with distributed data via domain
+decomposition.  The parallelization aims to be efficient result in good
+strong scaling (= good speedup for the same system) and good weak
+scaling (= the computational cost of enlarging the system is
+proportional to the system size).  Additional parallelization using GPUs
+or OpenMP can also be applied within the sub-domain assigned to an MPI
+process.  For clarity, most of the following illustrations show the 2d
+simulation case. The underlying algorithms in those cases, however,
+apply to both 2d and 3d cases equally well.
+
+.. note::
+
+   The text and most of the figures in this chapter were adapted
+   for the manual from the section on parallel algorithms in the
+   :ref:`new LAMMPS paper <lammps_paper>`.
+
+.. toctree::
+   :maxdepth: 1
+
+   Developer_par_part
+   Developer_par_comm
+   Developer_par_neigh
+   Developer_par_long
+   Developer_par_openmp

doc/src/Developer_utils.rst

@@ -203,9 +203,15 @@ Convenience functions
 .. doxygenfunction:: date2num
    :project: progguide
 
+.. doxygenfunction:: current_date
+   :project: progguide
+
 Customized standard functions
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
+.. doxygenfunction:: binary_search
+   :project: progguide
+
 .. doxygenfunction:: merge_sort
    :project: progguide
 
@@ -334,10 +340,11 @@ arguments of commands in LAMMPS are parsed and to make abstractions of
 repetitive tasks.
 
 The :cpp:class:`LAMMPS_NS::ArgInfo` class provides an abstraction
-for parsing references to compute or fix styles or variables. These
-would start with a "c\_", "f\_", "v\_" followed by the ID or name of
-than instance and may be postfixed with one or two array indices
-"[<number>]" with numbers > 0.
+for parsing references to compute or fix styles, variables or custom
+integer or double properties handled by :doc:`fix property/atom <fix_property_atom>`.
+These would start with a "c\_", "f\_", "v\_", "d\_", "d2\_", "i\_", or "i2\_"
+followed by the ID or name of than instance and may be postfixed with
+one or two array indices "[<number>]" with numbers > 0.
 
 A typical code segment would look like this:
 

doc/src/Errors_bugs.rst

@@ -17,8 +17,9 @@ the steps outlined below:
    if your issue has already been reported and if it is still open.
  * Check the `GitHub Pull Requests page <https://github.com/lammps/lammps/pulls>`_
    to see if there is already a fix for your bug pending.
- * Check the `mailing list archives <https://www.lammps.org/mail.html>`_
-   to see if the issue has been discussed before.
+ * Check the `mailing list archives <https://www.lammps.org/mail.html>`_ or
+   the `LAMMPS forum <https://www.lammps.org/forum.html>`_ to see if the
+   issue has been discussed before.
 
 If none of these steps yields any useful information, please file a new
 bug report on the `GitHub Issue page <https://github.com/lammps/lammps/issues>`_.

doc/src/Errors_debug.rst

@@ -40,11 +40,10 @@ We use it to show how to identify the origin of a segmentation fault.
 
 After recompiling LAMMPS and running the input you should get something like this:
 
-.. code-block:
+.. code-block::
 
    $ ./lmp -in in.melt
    LAMMPS (19 Mar 2020)
-   OMP_NUM_THREADS environment is not set. Defaulting to 1 thread. (src/comm.cpp:94)
      using 1 OpenMP thread(s) per MPI task
    Lattice spacing in x,y,z = 1.6796 1.6796 1.6796
    Created orthogonal box = (0 0 0) to (16.796 16.796 16.796)

doc/src/Errors_messages.rst

@@ -570,10 +570,10 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
    See the region prism command for details.
 
 *Can only use -plog with multiple partitions*
-   Self-explanatory.  See doc page discussion of command-line switches.
+   Self-explanatory.  See page discussion of command-line switches.
 
 *Can only use -pscreen with multiple partitions*
-   Self-explanatory.  See doc page discussion of command-line switches.
+   Self-explanatory.  See page discussion of command-line switches.
 
 *Can only use Kokkos supported regions with Kokkos package*
    Self-explanatory.
@@ -714,7 +714,7 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
 
 *Cannot create/grow a vector/array of pointers for %s*
    LAMMPS code is making an illegal call to the templated memory
-   allocaters, to create a vector or array of pointers.
+   allocators, to create a vector or array of pointers.
 
 *Cannot create_atoms after reading restart file with per-atom info*
    The per-atom info was stored to be used when by a fix that you may
@@ -1154,7 +1154,7 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
    Self-explanatory.
 
 *Cannot use -reorder after -partition*
-   Self-explanatory.  See doc page discussion of command-line switches.
+   Self-explanatory.  See page discussion of command-line switches.
 
 *Cannot use Ewald with 2d simulation*
    The kspace style ewald cannot be used in 2d simulations.  You can use
@@ -2347,14 +2347,14 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
 *Compute used in variable between runs is not current*
    Computes cannot be invoked by a variable in between runs.  Thus they
    must have been evaluated on the last timestep of the previous run in
-   order for their value(s) to be accessed.  See the doc page for the
+   order for their value(s) to be accessed.  See the page for the
    variable command for more info.
 
 *Compute used in variable thermo keyword between runs is not current*
    Some thermo keywords rely on a compute to calculate their value(s).
    Computes cannot be invoked by a variable in between runs.  Thus they
    must have been evaluated on the last timestep of the previous run in
-   order for their value(s) to be accessed.  See the doc page for the
+   order for their value(s) to be accessed.  See the page for the
    variable command for more info.
 
 *Compute vcm/chunk does not use chunk/atom compute*
@@ -3126,7 +3126,7 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
 *Energy was not tallied on needed timestep*
    You are using a thermo keyword that requires potentials to
    have tallied energy, but they did not on this timestep.  See the
-   variable doc page for ideas on how to make this work.
+   variable page for ideas on how to make this work.
 
 *Epsilon or sigma reference not set by pair style in PPPMDisp*
    Self-explanatory.
@@ -4535,10 +4535,10 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
    particles.
 
 *Incorrect # of floating-point values in Bodies section of data file*
-   See doc page for body style.
+   See page for body style.
 
 *Incorrect # of integer values in Bodies section of data file*
-   See doc page for body style.
+   See page for body style.
 
 *Incorrect %s format in data file*
    A section of the data file being read by fix property/atom does
@@ -4573,7 +4573,7 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
    The number of fields per line is not what expected.
 
 *Incorrect bonus data format in data file*
-   See the read_data doc page for a description of how various kinds of
+   See the read_data page for a description of how various kinds of
    bonus data must be formatted for certain atom styles.
 
 *Incorrect boundaries with slab Ewald*
@@ -4641,7 +4641,7 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
    Incorrect number of words per line in the potential file.
 
 *Incorrect integer value in Bodies section of data file*
-   See doc page for body style.
+   See page for body style.
 
 *Incorrect multiplicity arg for dihedral coefficients*
    Self-explanatory.  Check the input script or data file.
@@ -5996,7 +5996,7 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
    Self-explanatory.
 
 *Needed bonus data not in data file*
-   Some atom styles require bonus data.  See the read_data doc page for
+   Some atom styles require bonus data.  See the read_data page for
    details.
 
 *Needed molecular topology not in data file*
@@ -6198,7 +6198,7 @@ keyword to allow for additional bonds to be formed
 
 *One or more atom IDs is too big*
    The limit on atom IDs is set by the SMALLBIG, BIGBIG, SMALLSMALL
-   setting in your LAMMPS build.  See the :doc:`Build settings <Build_settings>` doc page for more info.
+   setting in your LAMMPS build.  See the :doc:`Build settings <Build_settings>` page for more info.
 
 *One or more atom IDs is zero*
    Either all atoms IDs must be zero or none of them.
@@ -6593,7 +6593,7 @@ keyword to allow for additional bonds to be formed
 
 *Pair style bop requires comm ghost cutoff at least 3x larger than %g*
    Use the communicate ghost command to set this.  See the pair bop
-   doc page for more details.
+   page for more details.
 
 *Pair style born/coul/long requires atom attribute q*
    An atom style that defines this attribute must be used.
@@ -6913,7 +6913,7 @@ keyword to allow for additional bonds to be formed
 *Per-atom energy was not tallied on needed timestep*
    You are using a thermo keyword that requires potentials to
    have tallied energy, but they did not on this timestep.  See the
-   variable doc page for ideas on how to make this work.
+   variable page for ideas on how to make this work.
 
 *Per-atom fix in equal-style variable formula*
    Equal-style variables cannot use per-atom quantities.
@@ -6921,7 +6921,7 @@ keyword to allow for additional bonds to be formed
 *Per-atom virial was not tallied on needed timestep*
    You are using a thermo keyword that requires potentials to have
    tallied the virial, but they did not on this timestep.  See the
-   variable doc page for ideas on how to make this work.
+   variable page for ideas on how to make this work.
 
 *Per-processor system is too big*
    The number of owned atoms plus ghost atoms on a single
@@ -7879,19 +7879,19 @@ keyword to allow for additional bonds to be formed
 *Unexpected end of -reorder file*
    Self-explanatory.
 
-*Unexpected empty line in AngleCoeffs section*
+*Unexpected empty line in Angle Coeffs section*
    Read a blank line where there should be coefficient data.
 
-*Unexpected empty line in BondCoeffs section*
+*Unexpected empty line in Bond Coeffs section*
    Read a blank line where there should be coefficient data.
 
-*Unexpected empty line in DihedralCoeffs section*
+*Unexpected empty line in Dihedral Coeffs section*
    Read a blank line where there should be coefficient data.
 
-*Unexpected empty line in ImproperCoeffs section*
+*Unexpected empty line in Improper Coeffs section*
    Read a blank line where there should be coefficient data.
 
-*Unexpected empty line in PairCoeffs section*
+*Unexpected empty line in Pair Coeffs section*
    Read a blank line where there should be coefficient data.
 
 *Unexpected end of custom file*
@@ -8408,7 +8408,7 @@ keyword to allow for additional bonds to be formed
 *Virial was not tallied on needed timestep*
    You are using a thermo keyword that requires potentials to
    have tallied the virial, but they did not on this timestep.  See the
-   variable doc page for ideas on how to make this work.
+   variable page for ideas on how to make this work.
 
 *Voro++ error: narea and neigh have a different size*
    This error is returned by the Voro++ library.

doc/src/Errors_warnings.rst

@@ -213,7 +213,7 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
    in unexpected behavior.
 
 *Fix bond/swap will ignore defined angles*
-   See the doc page for fix bond/swap for more info on this
+   See the page for fix bond/swap for more info on this
    restriction.
 
 *Fix deposit near setting < possible overlap separation %g*
@@ -514,7 +514,7 @@ This will most likely cause errors in kinetic fluctuations.
    will integrate the body motion, but it would be more efficient to use
    fix rigid.
 
-*Not using real units with pair reax*
+*Not using real units with pair reaxff*
    This is most likely an error, unless you have created your own ReaxFF
    parameter file in a different set of units.
 
@@ -805,5 +805,3 @@ This will most likely cause errors in kinetic fluctuations.
 *Using pair tail corrections with pair_modify compute no*
    The tail corrections will thus not be computed.
 
-*pair style reax is now deprecated and will soon be retired. Users should switch to pair_style reax/c*
-   Self-explanatory.

doc/src/Examples.rst

@@ -27,7 +27,7 @@ be quickly post-processed into a movie using commands described on the
 :doc:`dump image <dump_image>` doc page.
 
 Animations of many of the examples can be viewed on the Movies section
-of the `LAMMPS web site <https://www.lammps.org/movies.html>`_.
+of the `LAMMPS website <https://www.lammps.org/movies.html>`_.
 
 There are two kinds of sub-directories in the examples folder.  Lower
 case named directories contain one or a few simple, quick-to-run
@@ -150,6 +150,8 @@ Lowercase directories
 +-------------+------------------------------------------------------------------+
 | threebody   | regression test input for a variety of manybody potentials       |
 +-------------+------------------------------------------------------------------+
+| tracker     | track interactions in LJ melt                                    |
++-------------+------------------------------------------------------------------+
 | vashishta   | use of the Vashishta potential                                   |
 +-------------+------------------------------------------------------------------+
 | voronoi     | Voronoi tesselation via compute voronoi/atom command             |
@@ -167,15 +169,15 @@ Running the simulation produces the files *dump.indent* and
 *log.lammps*\ .  You can visualize the dump file of snapshots with a
 variety of third-party tools highlighted on the
 `Visualization <https://www.lammps.org/viz.html>`_ page of the LAMMPS
-web site.
+website.
 
 If you uncomment the :doc:`dump image <dump_image>` line(s) in the input
 script a series of JPG images will be produced by the run (assuming
 you built LAMMPS with JPG support; see the
-:doc:`Build_settings <Build_settings>` doc page for details).  These can
+:doc:`Build_settings <Build_settings>` page for details).  These can
 be viewed individually or turned into a movie or animated by tools
 like ImageMagick or QuickTime or various Windows-based tools.  See the
-:doc:`dump image <dump_image>` doc page for more details.  E.g. this
+:doc:`dump image <dump_image>` page for more details.  E.g. this
 Imagemagick command would create a GIF file suitable for viewing in a
 browser.
 
@@ -205,14 +207,12 @@ Uppercase directories
 +------------+--------------------------------------------------------------------------------------------------+
 | MC         | using LAMMPS in a Monte Carlo mode to relax the energy of a system                               |
 +------------+--------------------------------------------------------------------------------------------------+
-| PACKAGES   | examples for specific packages and contributed commands in USER-MISC                             |
+| PACKAGES   | examples for specific packages and contributed commands                                          |
 +------------+--------------------------------------------------------------------------------------------------+
 | SPIN       | examples for features of the SPIN package                                                        |
 +------------+--------------------------------------------------------------------------------------------------+
 | UNITS      | examples that run the same simulation in lj, real, metal units                                   |
 +------------+--------------------------------------------------------------------------------------------------+
-| USER-MISC  | examples for commands in the USER-MISC packages                                                  |
-+------------+--------------------------------------------------------------------------------------------------+
 | VISCOSITY  | compute viscosity via several methods                                                            |
 +------------+--------------------------------------------------------------------------------------------------+
 
@@ -226,7 +226,4 @@ of the sub-directories have their own README files which give further
 instructions.  See the :doc:`Packages_details <Packages_details>` doc
 page for more info on specific packages.
 
-Similarly the USER-MISC directory has sub-directories for examples
-corresponding to individual commands or styles in the USER-MISC package.
-
 .. _openkim: https://openkim.org

doc/src/Howto.rst

@@ -54,6 +54,7 @@ Analysis howto
    Howto_kappa
    Howto_viscosity
    Howto_diffusion
+   Howto_structured_data
 
 Force fields howto
 ==================

doc/src/Howto_barostat.rst

@@ -50,7 +50,7 @@ a temperature or pressure compute to a barostatting fix.
 
 Thermodynamic output, which can be setup via the
 :doc:`thermo_style <thermo_style>` command, often includes pressure
-values.  As explained on the doc page for the
+values.  As explained on the page for the
 :doc:`thermo_style <thermo_style>` command, the default pressure is
 setup by the thermo command itself.  It is NOT the pressure associated
 with any barostatting fix you have defined or with any compute you

doc/src/Howto_bioFF.rst

@@ -49,7 +49,7 @@ command's documentation for the formula it computes.
 COMPASS is a general force field for atomistic simulation of common
 organic molecules, inorganic small molecules, and polymers which was
 developed using ab initio and empirical parameterization techniques.
-See the :doc:`Tools <Tools>` doc page for the msi2lmp tool for creating
+See the :doc:`Tools <Tools>` page for the msi2lmp tool for creating
 LAMMPS template input and data files from BIOVIA's Materials Studio
 files.  Please note that the msi2lmp tool is very old and largely
 unmaintained, so it does not support all features of Materials Studio

doc/src/Howto_body.rst

@@ -10,7 +10,7 @@ deformable objects, etc.  Note that other kinds of finite-size
 spherical and aspherical particles are also supported by LAMMPS, such
 as spheres, ellipsoids, line segments, and triangles, but they are
 simpler entities than body particles.  See the :doc:`Howto spherical
-<Howto_spherical>` doc page for a general overview of all these
+<Howto_spherical>` page for a general overview of all these
 particle types.
 
 Body particles are used via the :doc:`atom_style body <atom_style>`
@@ -170,14 +170,14 @@ with this body style to compute body/body and body/non-body interactions.
 The *rounded/polygon* body style represents body particles as a 2d
 polygon with a variable number of N vertices.  This style can only be
 used for 2d models; see the :doc:`boundary <boundary>` command.  See the
-"pair_style body/rounded/polygon" doc page for a diagram of two
+"pair_style body/rounded/polygon" page for a diagram of two
 squares with rounded circles at the vertices.  Special cases for N = 1
 (circle) and N = 2 (rod with rounded ends) can also be specified.
 
 One use of this body style is for 2d discrete element models, as
 described in :ref:`Fraige <body-Fraige>`.
 
-Similar to body style *nparticle*\ , the atom_style body command for
+Similar to body style *nparticle*, the atom_style body command for
 this body style takes two additional arguments:
 
 .. parsed-literal::
@@ -284,7 +284,7 @@ The *rounded/polyhedron* body style represents body particles as a 3d
 polyhedron with a variable number of N vertices, E edges and F faces.
 This style can only be used for 3d models; see the
 :doc:`boundary <boundary>` command.  See the "pair_style
-body/rounded/polygon" doc page for a diagram of a two 2d squares with
+body/rounded/polygon" page for a diagram of a two 2d squares with
 rounded circles at the vertices.  A 3d cube with rounded spheres at
 the 8 vertices and 12 rounded edges would be similar.  Special cases
 for N = 1 (sphere) and N = 2 (rod with rounded ends) can also be
@@ -293,7 +293,7 @@ specified.
 This body style is for 3d discrete element models, as described in
 :ref:`Wang <body-Wang>`.
 
-Similar to body style *rounded/polygon*\ , the atom_style body command
+Similar to body style *rounded/polygon*, the atom_style body command
 for this body style takes two additional arguments:
 
 .. parsed-literal::

doc/src/Howto_chunk.rst

@@ -51,7 +51,7 @@ scales the floating point value to spread it across multiple integers.
 Spatial bins can be of various kinds, e.g. 1d bins = slabs, 2d bins =
 pencils, 3d bins = boxes, spherical bins, cylindrical bins.
 
-This compute also calculates the number of chunks *Nchunk*\ , which is
+This compute also calculates the number of chunks *Nchunk*, which is
 used by other commands to tally per-chunk data.  *Nchunk* can be a
 static value or change over time (e.g. the number of clusters).  The
 chunk ID for an individual atom can also be static (e.g. a molecule

doc/src/Howto_client_server.rst

@@ -119,7 +119,7 @@ server code.  Another code could be substituted for either.
 
 The examples below show launching both codes from the same window (or
 batch script), using the "&" character to launch the first code in the
-background.  For all modes except *mpi/one*\ , you could also launch the
+background.  For all modes except *mpi/one*, you could also launch the
 codes in separate windows on your desktop machine.  It does not
 matter whether you launch the client or server first.
 
@@ -132,7 +132,7 @@ mpirun, even if one or both of them runs on a single processor.  This
 is so that MPI can figure out how to connect both MPI processes
 together to exchange MPI messages between them.
 
-For message exchange in *file*\ , *zmq*\ , or *mpi/two* modes:
+For message exchange in *file*, *zmq*, or *mpi/two* modes:
 
 .. code-block:: bash
 

doc/src/Howto_cmake.rst

@@ -362,7 +362,7 @@ have to be enabled to be included into a LAMMPS executable.  Packages
 are enabled through setting variables of the kind ``PKG_<NAME>`` to
 ``on`` and disabled by setting them to ``off`` (or using ``yes``,
 ``no``, ``1``, ``0`` correspondingly).  ``<NAME>`` has to be replaced by
-the name of the package, e.g. ``MOLECULE`` or ``USER-MISC``.
+the name of the package, e.g. ``MOLECULE`` or ``EXTRA-PAIR``.
 
 
 Using presets

doc/src/Howto_coreshell.rst

@@ -5,7 +5,7 @@ The adiabatic core-shell model by :ref:`Mitchell and Fincham <MitchellFincham>`
 to a system.  In order to mimic the electron shell of an ion, a
 satellite particle is attached to it. This way the ions are split into
 a core and a shell where the latter is meant to react to the
-electrostatic environment inducing polarizability.  See the :doc:`Howto polarizable <Howto_polarizable>` doc page for a discussion of all
+electrostatic environment inducing polarizability.  See the :doc:`Howto polarizable <Howto_polarizable>` page for a discussion of all
 the polarizable models available in LAMMPS.
 
 Technically, shells are attached to the cores by a spring force f =
@@ -78,7 +78,7 @@ satellite particle if desired.
 Since the core/shell model permits distances of r = 0.0 between the
 core and shell, a pair style with a "cs" suffix needs to be used to
 implement a valid long-range Coulombic correction.  Several such pair
-styles are provided in the CORESHELL package.  See :doc:`this doc page <pair_cs>` for details.  All of the core/shell enabled pair
+styles are provided in the CORESHELL package.  See :doc:`this page <pair_cs>` for details.  All of the core/shell enabled pair
 styles require the use of a long-range Coulombic solver, as specified
 by the :doc:`kspace_style <kspace_style>` command.  Either the PPPM or
 Ewald solvers can be used.

doc/src/Howto_couple.rst

@@ -42,7 +42,7 @@ context of your application.
    stand-alone code could communicate with LAMMPS through files that the
    command writes and reads.
 
-   See the :doc:`Modify command <Modify_command>` doc page for info on how
+   See the :doc:`Modify command <Modify_command>` page for info on how
    to add a new command to LAMMPS.
 
 .. spacer

doc/src/Howto_drude2.rst

@@ -91,7 +91,7 @@ DRUDE package) to convert a non-polarizable data file (here
 
 This will automatically insert the new atoms and bonds.
 The masses and charges of DCs and DPs are computed
-from *phenol.dff*\ , as well as the DC-DP bond constants.  The file
+from *phenol.dff*, as well as the DC-DP bond constants.  The file
 *phenol.dff* contains the polarizabilities of the atom types
 and the mass of the Drude particles, for instance:
 
@@ -106,7 +106,7 @@ and the mass of the Drude particles, for instance:
 
 The hydrogen atoms are absent from this file, so they will be treated
 as non-polarizable atoms.  In the non-polarizable data file
-*data.102494.lmp*\ , atom names corresponding to the atom type numbers
+*data.102494.lmp*, atom names corresponding to the atom type numbers
 have to be specified as comments at the end of lines of the *Masses*
 section.  You probably need to edit it to add these names. It should
 look like
@@ -125,7 +125,7 @@ look like
 
 **Basic input file**
 
-The atom style should be set to (or derive from) *full*\ , so that you
+The atom style should be set to (or derive from) *full*, so that you
 can define atomic charges and molecular bonds, angles, dihedrals...
 
 The *polarizer* tool also outputs certain lines related to the input
@@ -143,7 +143,7 @@ and N for non-polarizable atoms.  Here the atom types 1 to 3 (C and O
 atoms) are DC, atom types 4 and 5 (H atoms) are non-polarizable and
 the atom types 6 to 8 are the newly created DPs.
 
-By recognizing the fix *drude*\ , LAMMPS will find and store matching
+By recognizing the fix *drude*, LAMMPS will find and store matching
 DC-DP pairs and will treat DP as equivalent to their DC in the
 *special bonds* relations.  It may be necessary to extend the space
 for storing such special relations.  In this case extra space should
@@ -340,11 +340,11 @@ For the *thole* pair style the coefficients are
 The special neighbors have charge-charge and charge-dipole
 interactions screened by the *coul* factors of the *special_bonds*
 command (0.0, 0.0, and 0.5 in the example above).  Without using the
-pair_style *thole*\ , dipole-dipole interactions are screened by the
-same factor.  By using the pair_style *thole*\ , dipole-dipole
+pair_style *thole*, dipole-dipole interactions are screened by the
+same factor.  By using the pair_style *thole*, dipole-dipole
 interactions are screened by Thole's function, whatever their special
 relationship (except within each DC-DP pair of course).  Consider for
-example 1-2 neighbors: using the pair_style *thole*\ , their dipoles
+example 1-2 neighbors: using the pair_style *thole*, their dipoles
 will see each other (despite the *coul* factor being 0.) and the
 interactions between these dipoles will be damped by Thole's function.
 
@@ -384,7 +384,7 @@ For our phenol example, the groups would be defined as
    group CORES  type 1 2 3     # DCs
    group DRUDES type 6 7 8     # DPs
 
-Note that with the fixes *drude/transform*\ , it is not required to
+Note that with the fixes *drude/transform*, it is not required to
 specify *comm_modify vel yes* because the fixes do it anyway (several
 times and for the forces also).
 

doc/src/Howto_github.rst

@@ -140,8 +140,8 @@ After everything is done, add the files to the branch and commit them:
    flag) will automatically include **all** modified **and** new files
    and that is rarely the behavior you want.  It can easily lead to
    accidentally adding unrelated and unwanted changes into the
-   repository.  Instead it is preferable to explicitly use *git add*\ ,
-   *git rm*\ , *git mv* for adding, removing, renaming individual files,
+   repository.  Instead it is preferable to explicitly use *git add*,
+   *git rm*, *git mv* for adding, removing, renaming individual files,
    respectively, and then *git commit* to finalize the commit.
    Carefully check all pending changes with *git status* before
    committing them.  If you find doing this on the command line too

doc/src/Howto_kappa.rst

@@ -4,7 +4,7 @@ Calculate thermal conductivity
 The thermal conductivity kappa of a material can be measured in at
 least 4 ways using various options in LAMMPS.  See the examples/KAPPA
 directory for scripts that implement the 4 methods discussed here for
-a simple Lennard-Jones fluid model.  Also, see the :doc:`Howto viscosity <Howto_viscosity>` doc page for an analogous discussion
+a simple Lennard-Jones fluid model.  Also, see the :doc:`Howto viscosity <Howto_viscosity>` page for an analogous discussion
 for viscosity.
 
 The thermal conductivity tensor kappa is a measure of the propensity
@@ -58,7 +58,7 @@ between hot and cold regions of the simulation box.
 The :doc:`compute heat/flux <compute_heat_flux>` command can calculate
 the needed heat flux and describes how to implement the Green_Kubo
 formalism using additional LAMMPS commands, such as the :doc:`fix ave/correlate <fix_ave_correlate>` command to calculate the needed
-auto-correlation.  See the doc page for the :doc:`compute heat/flux <compute_heat_flux>` command for an example input script
+auto-correlation.  See the page for the :doc:`compute heat/flux <compute_heat_flux>` command for an example input script
 that calculates the thermal conductivity of solid Ar via the GK
 formalism.
 

doc/src/Howto_manifold.rst

@@ -3,7 +3,7 @@ Manifolds (surfaces)
 
 **Overview:**
 
-This doc page is not about a LAMMPS input script command, but about
+This page is not about a LAMMPS input script command, but about
 manifolds, which are generalized surfaces, as defined and used by the
 MANIFOLD package, to track particle motion on the manifolds.  See
 the src/MANIFOLD/README file for more details about the package

doc/src/Howto_mdi.rst

@@ -3,7 +3,7 @@ Using LAMMPS with the MDI library for code coupling
 
 .. note::
 
-  This Howto doc page will eventually replace the
+  This Howto page will eventually replace the
   :doc:`Howto client/server <Howto_client_server>` doc page.
 
 Client/server coupling of two codes is where one code is the "client"
@@ -120,7 +120,7 @@ input script will continue.  After finishing execution of the input
 script, the instance of LAMMPS will be destroyed.
 
 LAMMPS supports the full set of MD-appropriate engine commands defined
-by the MDI library.  See the :doc:`mdi/engine <mdi_engine>` doc page for
+by the MDI library.  See the :doc:`mdi/engine <mdi_engine>` page for
 a list of these.
 
 If those commands are not sufficient for a user-developed driver to use

doc/src/Howto_output.rst

@@ -268,7 +268,7 @@ Computes that generate values to output
 Every :doc:`compute <compute>` in LAMMPS produces either global or
 per-atom or local values.  The values can be scalars or vectors or
 arrays of data.  These values can be output using the other commands
-described in this section.  The doc page for each compute command
+described in this section.  The page for each compute command
 describes what it produces.  Computes that produce per-atom or local
 values have the word "atom" or "local" in their style name.  Computes
 without the word "atom" or "local" produce global values.
@@ -281,7 +281,7 @@ Fixes that generate values to output
 Some :doc:`fixes <fix>` in LAMMPS produces either global or per-atom or
 local values which can be accessed by other commands.  The values can
 be scalars or vectors or arrays of data.  These values can be output
-using the other commands described in this section.  The doc page for
+using the other commands described in this section.  The page for
 each fix command tells whether it produces any output quantities and
 describes them.
 

doc/src/Howto_replica.rst

@@ -8,34 +8,33 @@ periodically.
 
 These are the relevant commands:
 
-* :doc:`neb <neb>` for nudged elastic band calculations
+* :doc:`hyper <hyper>` for bond boost hyperdynamics (HD)
+* :doc:`neb <neb>` for nudged elastic band calculations (NEB)
 * :doc:`neb_spin <neb_spin>` for magnetic nudged elastic band calculations
-* :doc:`prd <prd>` for parallel replica dynamics
-* :doc:`tad <tad>` for temperature accelerated dynamics
-* :doc:`temper <temper>` for parallel tempering
+* :doc:`prd <prd>` for parallel replica dynamics (PRD)
+* :doc:`tad <tad>` for temperature accelerated dynamics (TAD)
+* :doc:`temper <temper>` for parallel tempering with fixed volume
+* :doc:`temper/npt <temper_npt>` for parallel tempering extended for NPT
+* :doc:`temper/grem <temper_grem>` for parallel tempering with generalized replica exchange (gREM)
 * :doc:`fix pimd <fix_pimd>` for path-integral molecular dynamics (PIMD)
 
-NEB is a method for finding transition states and barrier energies.
-PRD and TAD are methods for performing accelerated dynamics to find
-and perform infrequent events.  Parallel tempering or replica exchange
-runs different replicas at a series of temperature to facilitate
-rare-event sampling.
+NEB is a method for finding transition states and barrier potential energies.
+HD, PRD, and TAD are methods for performing accelerated dynamics to find and
+perform infrequent events.  Parallel tempering or replica exchange runs
+different replicas at a series of temperature to facilitate rare-event
+sampling.  PIMD runs different replicas whose individual particles in different
+replicas are coupled together by springs to model a system of ring-polymers which
+can represent the quantum nature of atom cores.
 
 These commands can only be used if LAMMPS was built with the REPLICA
-package.  See the :doc:`Build package <Build_package>` doc page for more
-info.
-
-PIMD runs different replicas whose individual particles are coupled
-together by springs to model a system or ring-polymers.
-
-This commands can only be used if LAMMPS was built with the USER-MISC
-package.  See the :doc:`Build package <Build_package>` doc page for more
+package.  See the :doc:`Build package <Build_package>` page for more
 info.
 
 In all these cases, you must run with one or more processors per
 replica.  The processors assigned to each replica are determined at
-run-time by using the :doc:`-partition command-line switch <Run_options>` to launch LAMMPS on multiple partitions,
-which in this context are the same as replicas.  E.g.  these commands:
+run-time by using the :doc:`-partition command-line switch
+<Run_options>` to launch LAMMPS on multiple partitions, which in this
+context are the same as replicas.  E.g.  these commands:
 
 .. code-block:: bash
 
@@ -46,9 +45,11 @@ would each run 8 replicas, on either 16 or 8 processors.  Note the use
 of the :doc:`-in command-line switch <Run_options>` to specify the input
 script which is required when running in multi-replica mode.
 
-Also note that with MPI installed on a machine (e.g. your desktop),
-you can run on more (virtual) processors than you have physical
-processors.  Thus the above commands could be run on a
-single-processor (or few-processor) desktop so that you can run
-a multi-replica simulation on more replicas than you have
-physical processors.
+Also note that with MPI installed on a machine (e.g. your desktop), you
+can run on more (virtual) processors than you have physical processors.
+Thus the above commands could be run on a single-processor (or
+few-processor) desktop so that you can run a multi-replica simulation on
+more replicas than you have physical processors. This is useful for
+testing and debugging, since with most modern processors and MPI
+libraries the efficiency of a calculation can severely diminish when
+oversubscribing processors.

doc/src/Howto_structured_data.rst

@@ -0,0 +1,154 @@
+Output structured data from LAMMPS
+##################################
+
+LAMMPS can output structured data with the :doc:`print <print>` and :doc:`fix
+print <fix_print>` command.  This gives you flexibility since you can build
+custom data formats that contain system properties, thermo data, and variables
+values. This output can be directed to the screen and/or to a file for post
+processing.
+
+Writing the current system state, thermo data, variable values
+==============================================================
+
+Use the :doc:`print <print>` command to output the current system state, which
+can include system properties, thermo data and variable values.
+
+YAML
+----
+
+.. code-block:: LAMMPS
+
+   print """---
+   timestep: $(step)
+   pe: $(pe)
+   ke: $(ke)""" file current_state.yaml screen no
+
+.. code-block:: yaml
+   :caption: current_state.yaml
+
+   ---
+   timestep: 250
+   pe: -4.7774327356321810711
+   ke: 2.4962152903997174569
+
+JSON
+----
+
+.. code-block:: LAMMPS
+
+   print """{
+     "timestep": $(step),
+     "pe": $(pe),
+     "ke": $(ke)
+   }""" file current_state.json screen no
+
+.. code-block:: JSON
+   :caption: current_state.json
+
+   {
+     "timestep": 250,
+     "pe": -4.7774327356321810711,
+     "ke": 2.4962152903997174569
+   }
+
+
+Writing continuous data during a simulation
+===========================================
+
+The :doc:`fix print <fix_print>` command allows you to output an arbitrary string at defined times during a simulation run.
+
+YAML
+----
+
+.. code-block:: LAMMPS
+
+   fix extra all print 50 """
+   - timestep: $(step)
+     pe: $(pe)
+     ke: $(ke)""" file output.yaml screen no
+
+.. code-block:: yaml
+   :caption: output.yaml
+
+   # Fix print output for fix extra
+   - timestep: 0
+     pe: -6.77336805325924729
+     ke: 4.4988750000000026219
+
+   - timestep: 50
+     pe: -4.8082494418323200591
+     ke: 2.5257981827119797558
+
+   - timestep: 100
+     pe: -4.7875608875581505686
+     ke: 2.5062598821985102582
+
+   - timestep: 150
+     pe: -4.7471033686005483787
+     ke: 2.466095925545450207
+
+   - timestep: 200
+     pe: -4.7509052858544134068
+     ke: 2.4701136792591693592
+
+   - timestep: 250
+     pe: -4.7774327356321810711
+     ke: 2.4962152903997174569
+
+Post-processing of YAML files can be easily be done with Python and other
+scripting languages. In case of Python the `yaml` package allows you to load the
+data files and obtain a list of dictionaries.
+
+.. code-block:: python
+
+   import yaml
+
+   with open("output.yaml") as f:
+      data = yaml.load(f, Loader=yaml.FullLoader)
+
+   print(data)
+
+.. code-block::
+
+   [{'timestep': 0, 'pe': -6.773368053259247, 'ke': 4.498875000000003}, {'timestep': 50, 'pe': -4.80824944183232, 'ke': 2.5257981827119798}, {'timestep': 100, 'pe': -4.787560887558151, 'ke': 2.5062598821985103}, {'timestep': 150, 'pe': -4.747103368600548, 'ke': 2.46609592554545}, {'timestep': 200, 'pe': -4.750905285854413, 'ke': 2.4701136792591694}, {'timestep': 250, 'pe': -4.777432735632181, 'ke': 2.4962152903997175}]
+
+Line Delimited JSON (LD-JSON)
+-----------------------------
+
+The JSON format itself is very strict when it comes to delimiters. For continuous
+output/streaming data it is beneficial use the *line delimited JSON* format.
+Each line represents one JSON object.
+
+.. code-block:: LAMMPS
+
+   fix extra all print 50 """{"timestep": $(step), "pe": $(pe), "ke": $(ke)}""" title "" file output.json screen no
+
+.. code-block:: json
+   :caption: output.json
+
+   {"timestep": 0, "pe": -6.77336805325924729, "ke": 4.4988750000000026219}
+   {"timestep": 50, "pe": -4.8082494418323200591, "ke": 2.5257981827119797558}
+   {"timestep": 100, "pe": -4.7875608875581505686, "ke": 2.5062598821985102582}
+   {"timestep": 150, "pe": -4.7471033686005483787, "ke": 2.466095925545450207}
+   {"timestep": 200, "pe": -4.7509052858544134068, "ke": 2.4701136792591693592}
+   {"timestep": 250, "pe": -4.7774327356321810711, "ke": 2.4962152903997174569}
+
+One simple way to load this data into a Python script is to use the `pandas`
+package. It can directly load these files into a data frame:
+
+.. code-block:: python
+
+   import pandas as pd
+
+   data = pd.read_json('output.json', lines=True)
+   print(data)
+
+.. code-block:: bash
+
+      timestep        pe        ke
+   0         0 -6.773368  4.498875
+   1        50 -4.808249  2.525798
+   2       100 -4.787561  2.506260
+   3       150 -4.747103  2.466096
+   4       200 -4.750905  2.470114
+   5       250 -4.777433  2.496215

doc/src/Howto_thermostat.rst

@@ -28,7 +28,7 @@ can be invoked via the *dpd/tstat* pair style:
 :doc:`Fix nvt <fix_nh>` only thermostats the translational velocity of
 particles.  :doc:`Fix nvt/sllod <fix_nvt_sllod>` also does this, except
 that it subtracts out a velocity bias due to a deforming box and
-integrates the SLLOD equations of motion.  See the :doc:`Howto nemd <Howto_nemd>` doc page for further details.  :doc:`Fix nvt/sphere <fix_nvt_sphere>` and :doc:`fix nvt/asphere <fix_nvt_asphere>` thermostat not only translation
+integrates the SLLOD equations of motion.  See the :doc:`Howto nemd <Howto_nemd>` page for further details.  :doc:`Fix nvt/sphere <fix_nvt_sphere>` and :doc:`fix nvt/asphere <fix_nvt_asphere>` thermostat not only translation
 velocities but also rotational velocities for spherical and aspherical
 particles.
 
@@ -88,7 +88,7 @@ Below is a list of some custom temperature computes that can be used like that:
 
 Thermodynamic output, which can be setup via the
 :doc:`thermo_style <thermo_style>` command, often includes temperature
-values.  As explained on the doc page for the
+values.  As explained on the page for the
 :doc:`thermo_style <thermo_style>` command, the default temperature is
 setup by the thermo command itself.  It is NOT the temperature
 associated with any thermostatting fix you have defined or with any

doc/src/Howto_triclinic.rst

@@ -23,21 +23,21 @@ origin given by **a** = (xhi-xlo,0,0); **b** = (xy,yhi-ylo,0); **c** =
 and are called "tilt factors" because they are the amount of
 displacement applied to faces of an originally orthogonal box to
 transform it into the parallelepiped.  In LAMMPS the triclinic
-simulation box edge vectors **a**\ , **b**\ , and **c** cannot be arbitrary
+simulation box edge vectors **a**, **b**, and **c** cannot be arbitrary
 vectors.  As indicated, **a** must lie on the positive x axis.  **b** must
 lie in the xy plane, with strictly positive y component. **c** may have
 any orientation with strictly positive z component.  The requirement
-that **a**\ , **b**\ , and **c** have strictly positive x, y, and z components,
-respectively, ensures that **a**\ , **b**\ , and **c** form a complete
+that **a**, **b**, and **c** have strictly positive x, y, and z components,
+respectively, ensures that **a**, **b**, and **c** form a complete
 right-handed basis.  These restrictions impose no loss of generality,
 since it is possible to rotate/invert any set of 3 crystal basis
 vectors so that they conform to the restrictions.
 
-For example, assume that the 3 vectors **A**\ ,\ **B**\ ,\ **C** are the edge
+For example, assume that the 3 vectors **A**,\ **B**,\ **C** are the edge
 vectors of a general parallelepiped, where there is no restriction on
-**A**\ ,\ **B**\ ,\ **C** other than they form a complete right-handed basis i.e.
-**A** x **B** . **C** > 0.  The equivalent LAMMPS **a**\ ,\ **b**\ ,\ **c** are a linear
-rotation of **A**\ , **B**\ , and **C** and can be computed as follows:
+**A**,\ **B**,\ **C** other than they form a complete right-handed basis i.e.
+**A** x **B** . **C** > 0.  The equivalent LAMMPS **a**,\ **b**,\ **c** are a linear
+rotation of **A**, **B**, and **C** and can be computed as follows:
 
 .. math::
 
@@ -57,9 +57,9 @@ rotation of **A**\ , **B**\ , and **C** and can be computed as follows:
 where A = \| **A** \| indicates the scalar length of **A**\ . The hat symbol (\^)
 indicates the corresponding unit vector. :math:`\beta` and :math:`\gamma` are angles
 between the vectors described below. Note that by construction,
-**a**\ , **b**\ , and **c** have strictly positive x, y, and z components, respectively.
+**a**, **b**, and **c** have strictly positive x, y, and z components, respectively.
 If it should happen that
-**A**\ , **B**\ , and **C** form a left-handed basis, then the above equations
+**A**, **B**, and **C** form a left-handed basis, then the above equations
 are not valid for **c**\ . In this case, it is necessary
 to first apply an inversion. This can be achieved
 by interchanging two basis vectors or by changing the sign of one of them.
@@ -95,7 +95,7 @@ for details.
 The 9 parameters (xlo,xhi,ylo,yhi,zlo,zhi,xy,xz,yz) are defined at the
 time the simulation box is created.  This happens in one of 3 ways.
 If the :doc:`create_box <create_box>` command is used with a region of
-style *prism*\ , then a triclinic box is setup.  See the
+style *prism*, then a triclinic box is setup.  See the
 :doc:`region <region>` command for details.  If the
 :doc:`read_data <read_data>` command is used to define the simulation
 box, and the header of the data file contains a line with the "xy xz
@@ -135,7 +135,7 @@ example), then configurations with tilt = ..., -15, -5, 5, 15, 25,
 ... are geometrically all equivalent.  If the box tilt exceeds this
 limit during a dynamics run (e.g. via the :doc:`fix deform <fix_deform>`
 command), then the box is "flipped" to an equivalent shape with a tilt
-factor within the bounds, so the run can continue.  See the :doc:`fix deform <fix_deform>` doc page for further details.
+factor within the bounds, so the run can continue.  See the :doc:`fix deform <fix_deform>` page for further details.
 
 One exception to this rule is if the first dimension in the tilt
 factor (x for xy) is non-periodic.  In that case, the limits on the
@@ -160,10 +160,10 @@ For extreme values of tilt, LAMMPS may also lose atoms and generate an
 error.
 
 Triclinic crystal structures are often defined using three lattice
-constants *a*\ , *b*\ , and *c*\ , and three angles :math:`\alpha`,
+constants *a*, *b*, and *c*, and three angles :math:`\alpha`,
 :math:`\beta`, and :math:`\gamma`. Note that in this nomenclature,
 the a, b, and c lattice constants are the scalar lengths of the edge
-vectors **a**\ , **b**\ , and **c** defined above.  The relationship
+vectors **a**, **b**, and **c** defined above.  The relationship
 between these 6 quantities (a, b, c, :math:`\alpha`, :math:`\beta`,
 :math:`\gamma`) and the LAMMPS box sizes (lx,ly,lz) =
 (xhi-xlo,yhi-ylo,zhi-zlo) and tilt factors (xy,xz,yz) is as follows:
@@ -188,10 +188,10 @@ The inverse relationship can be written as follows:
   {\rm yz}   = & \frac{b*c \cos{\alpha} - {\rm xy}*{\rm xz}}{\rm ly} \\
   {\rm lz}^2 = & c^2 - {\rm xz}^2 - {\rm yz}^2 \\
 
-The values of *a*\ , *b*\ , *c* , :math:`\alpha` , :math:`\beta`, and
+The values of *a*, *b*, *c*, :math:`\alpha` , :math:`\beta`, and
 :math:`\gamma` can be printed out or accessed by computes using the
 :doc:`thermo_style custom <thermo_style>` keywords
-*cella*\ , *cellb*\ , *cellc*\ , *cellalpha*\ , *cellbeta*\ , *cellgamma*\ ,
+*cella*, *cellb*, *cellc*, *cellalpha*, *cellbeta*, *cellgamma*,
 respectively.
 
 As discussed on the :doc:`dump <dump>` command doc page, when the BOX

doc/src/Howto_viscosity.rst

@@ -42,7 +42,7 @@ command, which determines grad(Vstream) in the equation above.
 E.g. the derivative in the y-direction of the Vx component of fluid
 motion or grad(Vstream) = dVx/dy.  The Pxy off-diagonal component of
 the pressure or stress tensor, as calculated by the :doc:`compute pressure <compute_pressure>` command, can also be monitored, which
-is the J term in the equation above.  See the :doc:`Howto nemd <Howto_nemd>` doc page for details on NEMD simulations.
+is the J term in the equation above.  See the :doc:`Howto nemd <Howto_nemd>` page for details on NEMD simulations.
 
 The third method is to perform a reverse non-equilibrium MD simulation
 using the :doc:`fix viscosity <fix_viscosity>` command which implements

doc/src/Howto_viz.rst

@@ -13,7 +13,7 @@ by several popular visualization tools. The :doc:`dump image <dump_image>` and :
 output internally rendered images and convert a sequence of them to a
 movie during the MD run.  Several programs included with LAMMPS as
 auxiliary tools can convert between LAMMPS format files and other
-formats.  See the :doc:`Tools <Tools>` doc page for details.
+formats.  See the :doc:`Tools <Tools>` page for details.
 
 A Python-based toolkit distributed by our group can read native LAMMPS
 dump files, including custom dump files with additional columns of
@@ -25,7 +25,7 @@ RasMol visualization programs.  Pizza.py has tools that do interactive
 3d OpenGL visualization and one that creates SVG images of dump file
 snapshots.
 
-.. _pizza: https://pizza.sandia.gov
+.. _pizza: https://lammps.github.io/pizza
 
 .. _ensight: https://www.ansys.com/products/fluids/ansys-ensight
 

doc/src/Howto_walls.rst

@@ -53,7 +53,7 @@ granular particles; all the other commands create smooth walls.
 * :doc:`fix wall/region <fix_wall_region>` - use region surface as wall
 * :doc:`fix wall/gran <fix_wall_gran>` - flat or curved walls with :doc:`pair_style granular <pair_gran>` potential
 
-The *lj93*\ , *lj126*\ , *colloid*\ , *harmonic*\ , and *morse* styles all
+The *lj93*, *lj126*, *colloid*, *harmonic*, and *morse* styles all
 allow the flat walls to move with a constant velocity, or oscillate in
 time.  The :doc:`fix wall/region <fix_wall_region>` command offers the
 most generality, since the region surface is treated as a wall, and

doc/src/Install_git.rst

@@ -137,9 +137,9 @@ changed.  How to do this depends on the build system you are using.
 .. admonition:: Git protocols
    :class: note
 
-   The servers at github.com support the "git://" and "https://" access
-   protocols for anonymous, read-only access.  If you have a suitably
-   configured GitHub account, you may also use SSH protocol with the
+   The servers at github.com support the "https://" access protocol for
+   anonymous, read-only access.  If you have a suitably configured GitHub
+   account, you may also use SSH protocol with the
    URL "git@github.com:lammps/lammps.git".
 
 The LAMMPS GitHub project is currently managed by Axel Kohlmeyer

doc/src/Install_windows.rst

@@ -12,7 +12,7 @@ Note that each installer package has a date in its name, which
 corresponds to the LAMMPS version of the same date.  Installers for
 current and older versions of LAMMPS are available.  32-bit and 64-bit
 installers are available, and each installer contains both a serial
-and parallel executable.  The installer web site also explains how to
+and parallel executable.  The installer website also explains how to
 install the Windows MPI package (MPICH2 from Argonne National Labs),
 needed to run in parallel with MPI.
 

doc/src/Intro_authors.rst

@@ -29,7 +29,7 @@ The following folks deserve special recognition.  Many of the packages
 they have written are unique for an MD code and LAMMPS would not be as
 general-purpose as it is without their expertise and efforts.
 
-* Metin Aktulga (MSU), REAXFF package for C version of ReaxFF
+* Metin Aktulga (MSU), REAXFF package for C/C++ version of ReaxFF
 * Mike Brown (Intel), GPU and INTEL packages
 * Colin Denniston (U Western Ontario), LATBOLTZ package
 * Georg Ganzenmuller (EMI), MACHDYN and SPH packages
@@ -37,9 +37,10 @@ general-purpose as it is without their expertise and efforts.
 * Reese Jones (Sandia) and colleagues, ATC package for atom/continuum coupling
 * Christoph Kloss (DCS Computing), LIGGGHTS code for granular materials, built on top of LAMMPS
 * Rudra Mukherjee (JPL), POEMS package for articulated rigid body motion
-* Trung Ngyuen (Northwestern U), GPU and RIGID and BODY packages
+* Trung Ngyuen (Northwestern U), GPU, RIGID, BODY, and DIELECTRIC packages
 * Mike Parks (Sandia), PERI package for Peridynamics
 * Roy Pollock (LLNL), Ewald and PPPM solvers
+* Julien Tranchida (Sandia), SPIN package
 * Christian Trott (Sandia), CUDA and KOKKOS packages
 * Ilya Valuev (JIHT), AWPMD package for wave packet MD
 * Greg Wagner (Northwestern U), MEAM package for MEAM potential

doc/src/Intro_citing.rst

@@ -4,28 +4,41 @@ Citing LAMMPS
 Core Algorithms
 ^^^^^^^^^^^^^^^
 
-Since LAMMPS is a community project, there is not a single one
-publication or reference that describes **all** of LAMMPS.
-The canonical publication that describes the foundation, that is
-the basic spatial decomposition approach, the neighbor finding,
-and basic communications algorithms used in LAMMPS is:
+The paper mentioned below is the best overview of LAMMPS, but there are
+also publications describing particular models or algorithms implemented
+in LAMMPS or complementary software that is has interfaces to.  Please
+see below for how to cite contributions to LAMMPS.
 
- `S. Plimpton, Fast Parallel Algorithms for Short-Range Molecular Dynamics, J Comp Phys, 117, 1-19 (1995). <http://www.sandia.gov/~sjplimp/papers/jcompphys95.pdf>`_
+.. _lammps_paper:
 
-So any project using LAMMPS (or a derivative application using LAMMPS as
-a simulation engine) should cite this paper. A new publication
-describing the developments and improvements of LAMMPS in the 25 years
-since then is currently in preparation.
+The latest canonical publication that describes the basic features, the
+source code design, the program structure, the spatial decomposition
+approach, the neighbor finding, basic communications algorithms, and how
+users and developers have contributed to LAMMPS is:
+
+  `LAMMPS - A flexible simulation tool for particle-based materials modeling at the atomic, meso, and continuum scales, Comp. Phys. Comm. 271, 108171 (2022) <https://doi.org/10.1016/j.cpc.2021.108171>`_
+
+So a project using LAMMPS or a derivative application that uses LAMMPS
+as a simulation engine should cite this paper.  The paper is expected to
+be published in its final form under the same DOI in the first half
+of 2022.  Please also give the URL of the LAMMPS website in your paper,
+namely https://www.lammps.org.
+
+The original publication describing the parallel algorithms used in the
+initial versions of LAMMPS is:
+
+  `S. Plimpton, Fast Parallel Algorithms for Short-Range Molecular Dynamics, J Comp Phys, 117, 1-19 (1995). <http://www.sandia.gov/~sjplimp/papers/jcompphys95.pdf>`_
 
 
 DOI for the LAMMPS code
 ^^^^^^^^^^^^^^^^^^^^^^^
 
-LAMMPS developers use the `Zenodo service at CERN
-<https://zenodo.org/>`_ to create digital object identifies (DOI) for
-stable releases of the LAMMPS code. There are two types of DOIs for the
-LAMMPS source code: the canonical DOI for **all** versions of LAMMPS,
-which will always point to the **latest** stable release version is:
+LAMMPS developers use the `Zenodo service at CERN <https://zenodo.org/>`_
+to create digital object identifies (DOI) for stable releases of the
+LAMMPS source code. There are two types of DOIs for the LAMMPS source code.
+
+The canonical DOI for **all** versions of LAMMPS, which will always
+point to the **latest** stable release version is:
 
 - DOI: `10.5281/zenodo.3726416 <https://dx.doi.org/10.5281/zenodo.3726416>`_
 
@@ -45,11 +58,13 @@ about LAMMPS and its features.
 Citing contributions
 ^^^^^^^^^^^^^^^^^^^^
 
-LAMMPS has many features and that use either previously published
-methods and algorithms or novel features.  It also includes potential
-parameter filed for specific models.  Where available, a reminder about
-references for optional features used in a specific run is printed to
-the screen and log file.  Style and output location can be selected with
-the :ref:`-cite command-line switch <cite>`.  Additional references are
+LAMMPS has many features that use either previously published methods
+and algorithms or novel features.  It also includes potential parameter
+files for specific models.  Where available, a reminder about references
+for optional features used in a specific run is printed to the screen
+and log file.  Style and output location can be selected with the
+:ref:`-cite command-line switch <cite>`.  Additional references are
 given in the documentation of the :doc:`corresponding commands
-<Commands_all>` or in the :doc:`Howto tutorials <Howto>`.
+<Commands_all>` or in the :doc:`Howto tutorials <Howto>`.  So please
+make certain, that you provide the proper acknowledgments and citations
+in any published works using LAMMPS.

doc/src/Intro_features.rst

@@ -24,18 +24,22 @@ General features
 ^^^^^^^^^^^^^^^^
 
 * runs on a single processor or in parallel
-* distributed-memory message-passing parallelism (MPI)
-* spatial-decomposition of simulation domain for parallelism
-* open-source distribution
-* highly portable C++
-* optional libraries used: MPI and single-processor FFT
-* GPU (CUDA and OpenCL), Intel Xeon Phi, and OpenMP support for many code features
+* distributed memory message-passing parallelism (MPI)
+* shared memory multi-threading parallelism (OpenMP)
+* spatial decomposition of simulation domain for MPI parallelism
+* particle decomposition inside of spatial decomposition for OpenMP and GPU parallelism
+* GPLv2 licensed open-source distribution
+* highly portable C++-11
+* modular code with most functionality in optional packages
+* only depends on MPI library for basic parallel functionality, MPI stub for serial compilation
+* other libraries are optional and only required for specific packages
+* GPU (CUDA, OpenCL, HIP, SYCL), Intel Xeon Phi, and OpenMP support for many code features
 * easy to extend with new features and functionality
 * runs from an input script
 * syntax for defining and using variables and formulas
 * syntax for looping over runs and breaking out of loops
 * run one or multiple simulations simultaneously (in parallel) from one script
-* build as library, invoke LAMMPS through library interface or provided Python wrapper
+* build as library, invoke LAMMPS through library interface or provided Python wrapper or SWIG based wrappers
 * couple with other codes: LAMMPS calls other code, other code calls LAMMPS, umbrella code calls both
 
 .. _particle:
@@ -53,9 +57,11 @@ Particle and model types
 * granular materials
 * coarse-grained mesoscale models
 * finite-size spherical and ellipsoidal particles
-* finite-size  line segment (2d) and triangle (3d) particles
+* finite-size line segment (2d) and triangle (3d) particles
+* finite-size rounded polygons (2d) and polyhedra (3d) particles
 * point dipole particles
-* rigid collections of particles
+* particles with magnetic spin
+* rigid collections of n particles
 * hybrid combinations of these
 
 .. _ff:
@@ -68,26 +74,30 @@ Interatomic potentials (force fields)
 :doc:`improper style <improper_style>`, :doc:`kspace style <kspace_style>`
 commands)
 
-* pairwise potentials: Lennard-Jones, Buckingham, Morse, Born-Mayer-Huggins,     Yukawa, soft, class 2 (COMPASS), hydrogen bond, tabulated
+* pairwise potentials: Lennard-Jones, Buckingham, Morse, Born-Mayer-Huggins, Yukawa, soft, class 2 (COMPASS), hydrogen bond, tabulated
 * charged pairwise potentials: Coulombic, point-dipole
-* many-body potentials: EAM, Finnis/Sinclair EAM, modified EAM (MEAM),     embedded ion method (EIM), EDIP, ADP, Stillinger-Weber, Tersoff,     REBO, AIREBO, ReaxFF, COMB, SNAP, Streitz-Mintmire, 3-body polymorphic
-* long-range interactions for charge, point-dipoles, and LJ dispersion:     Ewald, Wolf, PPPM (similar to particle-mesh Ewald)
+* many-body potentials: EAM, Finnis/Sinclair EAM, modified EAM (MEAM), embedded ion method (EIM), EDIP, ADP, Stillinger-Weber, Tersoff, REBO, AIREBO, ReaxFF, COMB, Streitz-Mintmire, 3-body polymorphic, BOP, Vashishta
+* machine learning potentials: SNAP, GAP, ACE, N2P2, RANN, AGNI
+* long-range interactions for charge, point-dipoles, and LJ dispersion:  Ewald, Wolf, PPPM (similar to particle-mesh Ewald), MSM
 * polarization models: :doc:`QEq <fix_qeq>`,     :doc:`core/shell model <Howto_coreshell>`,     :doc:`Drude dipole model <Howto_drude>`
 * charge equilibration (QEq via dynamic, point, shielded, Slater methods)
 * coarse-grained potentials: DPD, GayBerne, REsquared, colloidal, DLVO
-* mesoscopic potentials: granular, Peridynamics, SPH
+* mesoscopic potentials: granular, Peridynamics, SPH, mesoscopic tubular potential (MESONT)
+* semi-empirical potentials: multi-ion generalized pseudopotential theory (MGPT), second moment tight binding + QEq (SMTB-Q), density functional tight-binding (LATTE)
 * electron force field (eFF, AWPMD)
-* bond potentials: harmonic, FENE, Morse, nonlinear, class 2,     quartic (breakable)
-* angle potentials: harmonic, CHARMM, cosine, cosine/squared, cosine/periodic,     class 2 (COMPASS)
-* dihedral potentials: harmonic, CHARMM, multi-harmonic, helix,     class 2 (COMPASS), OPLS
-* improper potentials: harmonic, cvff, umbrella, class 2 (COMPASS)
+* bond potentials: harmonic, FENE, Morse, nonlinear, class 2, quartic (breakable), tabulated
+* angle potentials: harmonic, CHARMM, cosine, cosine/squared, cosine/periodic, class 2 (COMPASS), tabulated
+* dihedral potentials: harmonic, CHARMM, multi-harmonic, helix, class 2 (COMPASS), OPLS, tabulated
+* improper potentials: harmonic, cvff, umbrella, class 2 (COMPASS), tabulated
 * polymer potentials: all-atom, united-atom, bead-spring, breakable
-* water potentials: TIP3P, TIP4P, SPC
+* water potentials: TIP3P, TIP4P, SPC, SPC/E and variants
+* interlayer potentials for graphene and analogues
+* metal-organic framework potentials (QuickFF, MO-FF)
 * implicit solvent potentials: hydrodynamic lubrication, Debye
-* force-field compatibility with common CHARMM, AMBER, DREIDING,     OPLS, GROMACS, COMPASS options
+* force-field compatibility with common CHARMM, AMBER, DREIDING, OPLS, GROMACS, COMPASS options
 * access to the `OpenKIM Repository <http://openkim.org>`_ of potentials via     :doc:`kim command <kim_commands>`
-* hybrid potentials: multiple pair, bond, angle, dihedral, improper     potentials can be used in one simulation
-* overlaid potentials: superposition of multiple pair potentials
+* hybrid potentials: multiple pair, bond, angle, dihedral, improper potentials can be used in one simulation
+* overlaid potentials: superposition of multiple pair potentials (including many-body) with optional scale factor
 
 .. _create:
 
@@ -120,9 +130,10 @@ Ensembles, constraints, and boundary conditions
 * harmonic (umbrella) constraint forces
 * rigid body constraints
 * SHAKE bond and angle constraints
-* Monte Carlo bond breaking, formation, swapping
+* motion constraints to manifold surfaces
+* Monte Carlo bond breaking, formation, swapping, template based reaction modeling
 * atom/molecule insertion and deletion
-* walls of various kinds
+* walls of various kinds, static and moving
 * non-equilibrium molecular dynamics (NEMD)
 * variety of additional boundary conditions and constraints
 
@@ -146,6 +157,7 @@ Diagnostics
 ^^^^^^^^^^^
 
 * see various flavors of the :doc:`fix <fix>` and :doc:`compute <compute>` commands
+* introspection command for system, simulation, and compile time settings and configurations
 
 .. _output:
 
@@ -160,8 +172,9 @@ Output
 * parallel I/O of dump and restart files
 * per-atom quantities (energy, stress, centro-symmetry parameter, CNA, etc)
 * user-defined system-wide (log file) or per-atom (dump file) calculations
-* spatial and time averaging of per-atom quantities
-* time averaging of system-wide quantities
+* custom partitioning (chunks) for binning, and static or dynamic grouping of atoms for analysis
+* spatial, time, and per-chunk averaging of per-atom quantities
+* time averaging and histogramming of system-wide quantities
 * atom snapshots in native, XYZ, XTC, DCD, CFG formats
 
 .. _replica1:
@@ -170,9 +183,12 @@ Multi-replica models
 ^^^^^^^^^^^^^^^^^^^^
 
 * :doc:`nudged elastic band <neb>`
+* :doc:`hyperdynamics <hyper>`
 * :doc:`parallel replica dynamics <prd>`
 * :doc:`temperature accelerated dynamics <tad>`
 * :doc:`parallel tempering <temper>`
+* path-integral MD: `first variant <fix_pimd>`, `second variant <fix_ipi>`
+* multi-walker collective variables with :doc:`Colvars <fix_colvars>` and :doc:`Plumed <fix_plumed>`
 
 .. _prepost:
 
@@ -187,7 +203,7 @@ Pre- and post-processing
   plotting, and visualization for LAMMPS simulations.  Pizza.py is
   written in `Python <python_>`_ and is available for download from `the Pizza.py WWW site <pizza_>`_.
 
-.. _pizza: https://pizza.sandia.gov
+.. _pizza: https://lammps.github.io/pizza
 
 .. _python: http://www.python.org
 
@@ -203,11 +219,12 @@ page for details.
 These are LAMMPS capabilities which you may not think of as typical
 classical MD options:
 
-* :doc:`static <balance>` and :doc:`dynamic load-balancing <fix_balance>`
+* :doc:`static <balance>` and :doc:`dynamic load-balancing <fix_balance>`, optional with recursive bisectioning decomposition
 * :doc:`generalized aspherical particles <Howto_body>`
 * :doc:`stochastic rotation dynamics (SRD) <fix_srd>`
-* :doc:`real-time visualization and interactive MD <fix_imd>`
+* :doc:`real-time visualization and interactive MD <fix_imd>`, :doc:`built-in renderer for images and movies <dump_image>`
 * calculate :doc:`virtual diffraction patterns <compute_xrd>`
+* calculate :doc:`finite temperature phonon dispersion <fix_phonon>` and the :doc:`dynamical matrix of minimized structures <dynamical_matrix>`
 * :doc:`atom-to-continuum coupling <fix_atc>` with finite elements
 * coupled rigid body integration via the :doc:`POEMS <fix_poems>` library
 * :doc:`QM/MM coupling <fix_qmmm>`

doc/src/Intro_nonfeatures.rst

@@ -32,7 +32,7 @@ Here are suggestions on how to perform these tasks:
   are simple programs that will build simple molecular systems, such as
   linear bead-spring polymer chains.  The moltemplate program is a true
   molecular builder that will generate complex molecular models.  See
-  the :doc:`Tools <Tools>` doc page for details on tools packaged with
+  the :doc:`Tools <Tools>` page for details on tools packaged with
   LAMMPS.  The `Pre/post processing page <http:/www.lammps.org/prepost.html>`_ of the LAMMPS website
   describes a variety of third party tools for this task.  Furthermore,
   some LAMMPS internal commands allow to reconstruct, or selectively add
@@ -49,7 +49,7 @@ Here are suggestions on how to perform these tasks:
 * **Simulation analysis:** If you want to perform analysis on-the-fly as
   your simulation runs, see the :doc:`compute <compute>` and
   :doc:`fix <fix>` doc pages, which list commands that can be used in a
-  LAMMPS input script.  Also see the :doc:`Modify <Modify>` doc page for
+  LAMMPS input script.  Also see the :doc:`Modify <Modify>` page for
   info on how to add your own analysis code or algorithms to LAMMPS.
   For post-processing, LAMMPS output such as :doc:`dump file snapshots <dump>` can be converted into formats used by other MD or
   post-processing codes.  To some degree, that conversion can be done
@@ -61,7 +61,7 @@ Here are suggestions on how to perform these tasks:
   LAMMPS will do these conversions.  Scripts provided in the
   tools/python directory can extract and massage data in dump files to
   make it easier to import into other programs.  See the
-  :doc:`Tools <Tools>` doc page for details on these various options.
+  :doc:`Tools <Tools>` page for details on these various options.
 * **Visualization:** LAMMPS can produce NETPBM, JPG or PNG snapshot images
   on-the-fly via its :doc:`dump image <dump_image>` command and pass
   them to an external program, `FFmpeg <https://www.ffmpeg.org>`_ to generate
@@ -71,13 +71,13 @@ Here are suggestions on how to perform these tasks:
   LAMMPS website for
   visualization packages that can process LAMMPS output data.
 * **Plotting:** See the next bullet about Pizza.py as well as the
-  :doc:`Python <Python_head>` doc page for examples of plotting LAMMPS
+  :doc:`Python <Python_head>` page for examples of plotting LAMMPS
   output.  Scripts provided with the *python* tool in the tools
   directory will extract and massage data in log and dump files to make
   it easier to analyze and plot.  See the :doc:`Tools <Tools>` doc page
   for more discussion of the various tools.
 * **Pizza.py:** Our group has also written a separate toolkit called
-  `Pizza.py <https://pizza.sandia.gov>`_ which can do certain kinds of
+  `Pizza.py <https://lammps.github.io/pizza>`_ which can do certain kinds of
   setup, analysis, plotting, and visualization (via OpenGL) for LAMMPS
   simulations.  It thus provides some functionality for several of the
   above bullets.  Pizza.py is written in `Python <http://www.python.org>`_

doc/src/Intro_opensource.rst

@@ -1,40 +1,61 @@
 LAMMPS open-source license
 --------------------------
 
-LAMMPS is a freely-available open-source code, distributed under the
-terms of the `GNU Public License Version 2 <gpl_>`_, which means you can
-use or modify the code however you wish for your own purposes, but have
-to adhere to certain rules when redistributing it or software derived
+GPL version of LAMMPS
+^^^^^^^^^^^^^^^^^^^^^
+
+LAMMPS is an open-source code, available free-of-charge, and distributed
+under the terms of the `GNU Public License Version 2 <gpl_>`_ (GPLv2),
+which means you can use or modify the code however you wish for your own
+purposes, but have to adhere to certain rules when redistributing it -
+specifically in binary form - or are distributing software derived
 from it or that includes parts of it.
 
-LAMMPS comes with no warranty of any kind.  As each source file states
-in its header, it is a copyrighted code that is distributed free-of-
-charge, under the terms of the `GNU Public License Version 2 <gpl_>`_
-(GPLv2).  This is often referred to as open-source distribution - see
-`www.gnu.org <gnuorg_>`_ or `www.opensource.org <opensource_>`_.  The
-legal text of the GPL is in the LICENSE file included in the LAMMPS
-distribution.
+LAMMPS comes with no warranty of any kind.
+
+As each source file states in its header, it is a copyrighted code, and
+thus not in the public domain. For more information about open-source
+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
 
+.. _lgpl: https://www.gnu.org/licenses/old-licenses/lgpl-2.1.html
+
 .. _gnuorg: http://www.gnu.org
 
 .. _opensource: http://www.opensource.org
 
-Here is a summary of what the GPL means for LAMMPS users:
+Here is a more specific summary of what the GPL means for LAMMPS users:
 
-(1) Anyone is free to use, modify, or extend LAMMPS in any way they
+(1) Anyone is free to use, copy, modify, or extend LAMMPS in any way they
 choose, including for commercial purposes.
 
 (2) If you **distribute** a modified version of LAMMPS, it must remain
-open-source, meaning you distribute **all** of it under the terms of
-the GPL.  You should clearly annotate such a code as a derivative version
-of LAMMPS.
+open-source, meaning you are required to distribute **all** of it under
+the terms of the GPL.  You should clearly annotate such a modified code
+as a derivative version of LAMMPS.
 
 (3) If you release any code that includes or uses LAMMPS source code,
 then it must also be open-sourced, meaning you distribute it under
-the terms of the GPL.
+the terms of the GPL.  You may write code that interfaces LAMMPS to
+a differently licensed library.  In that case the code that provides
+the interface must be licensed GPL, but not necessarily that library
+unless you are distributing binaries that require the library to run.
 
 (4) If you give LAMMPS files to someone else, the GPL LICENSE file and
 source file headers (including the copyright and GPL notices) should
 remain part of the code.
+
+
+LGPL version of LAMMPS
+^^^^^^^^^^^^^^^^^^^^^^
+
+We occasionally make stable LAMMPS releases available under the `GNU
+Lesser Public License v2.1 <lgpl_>`_.  This is on request only and with
+non-LGPL compliant files removed.  This allows uses linking non-GPL
+compatible software with the (otherwise unmodified) LAMMPS library
+or loading it dynamically at runtime.  Any **modifications** to
+the LAMMPS code however, even with the LGPL licensed version, must still
+be made available under the same open source terms as LAMMPS itself.

doc/src/Intro_overview.rst

@@ -10,23 +10,26 @@ conditions.  It can model 2d or 3d systems with only a few particles
 up to millions or billions.
 
 LAMMPS can be built and run on a laptop or desktop machine, but is
-designed for parallel computers.  It will run on any parallel machine
-that supports the `MPI <mpi_>`_ message-passing library.  This includes
-shared-memory boxes and distributed-memory clusters and
-supercomputers.
+designed for parallel computers.  It will run in serial and on any
+parallel machine that supports the `MPI <mpi_>`_ message-passing
+library.  This includes shared-memory boxes and distributed-memory
+clusters and supercomputers. Parts of LAMMPS also support
+`OpenMP multi-threading <omp_>`_, vectorization and GPU acceleration.
 
 .. _mpi: https://en.wikipedia.org/wiki/Message_Passing_Interface
 .. _lws: https://www.lammps.org
+.. _omp: https://www.openmp.org
 
-LAMMPS is written in C++.  Earlier versions were written in F77 and
-F90.  See the `History page <https://www.lammps.org/history.html>`_ of
-the website for details.  All versions can be downloaded from the
-`LAMMPS website <lws_>`_.
+LAMMPS is written in C++ and requires a compiler that is at least
+compatible with the C++-11 standard.  Earlier versions were written in
+F77, F90, and C++-98.  See the `History page
+<https://www.lammps.org/history.html>`_ of the website for details.  All
+versions can be downloaded as source code from the `LAMMPS website
+<lws_>`_.
 
-LAMMPS is designed to be easy to modify or extend with new
-capabilities, such as new force fields, atom types, boundary
-conditions, or diagnostics.  See the :doc:`Modify <Modify>` doc page for
-more details.
+LAMMPS is designed to be easy to modify or extend with new capabilities,
+such as new force fields, atom types, boundary conditions, or
+diagnostics.  See the :doc:`Modify <Modify>` page for more details.
 
 In the most general sense, LAMMPS integrates Newton's equations of
 motion for a collection of interacting particles.  A single particle
@@ -41,8 +44,10 @@ short distances, so that the local density of particles never becomes
 too large.  This is in contrast to methods used for modeling plasma
 or gravitational bodies (e.g. galaxy formation).
 
-On parallel machines, LAMMPS uses spatial-decomposition techniques to
-partition the simulation domain into small sub-domains of equal
-computational cost, one of which is assigned to each processor.
-Processors communicate and store "ghost" atom information for atoms
-that border their sub-domain.
+On parallel machines, LAMMPS uses spatial-decomposition techniques with
+MPI parallelization to partition the simulation domain into small
+sub-domains of equal computational cost, one of which is assigned to
+each processor.  Processors communicate and store "ghost" atom
+information for atoms that border their sub-domain.  Multi-threading
+parallelization and GPU acceleration with with particle-decomposition
+can be used in addition.

doc/src/Intro_website.rst

@@ -20,12 +20,13 @@ available online are listed below.
 * `Glossary of terms relevant to LAMMPS <https://www.lammps.org/glossary.html>`_
 * `LAMMPS highlights with images <https://www.lammps.org/pictures.html>`_
 * `LAMMPS highlights with movies <https://www.lammps.org/movies.html>`_
-* `Mail list <https://www.lammps.org/mail.html>`_
+* `Mailing list <https://www.lammps.org/mail.html>`_
+* `LAMMPS forum <https://www.lammps.org/forum.html>`_
 * `Workshops <https://www.lammps.org/workshops.html>`_
 * `Tutorials <https://www.lammps.org/tutorials.html>`_
 
 * `Pre- and post-processing tools for LAMMPS <https://www.lammps.org/prepost.html>`_
-* `Other software usable with LAMMPS <https://www.lammps.org/offsite.html>`_
+* `Other software usable with LAMMPS <https://www.lammps.org/external.html>`_
 * `Viz tools usable with LAMMPS <https://www.lammps.org/viz.html>`_
 
 * `Benchmark performance <https://www.lammps.org/bench.html>`_

doc/src/Library_create.rst

@@ -10,6 +10,7 @@ This section documents the following functions:
 - :cpp:func:`lammps_mpi_init`
 - :cpp:func:`lammps_mpi_finalize`
 - :cpp:func:`lammps_kokkos_finalize`
+- :cpp:func:`lammps_python_finalize`
 
 --------------------
 
@@ -33,7 +34,7 @@ simple example demonstrating its use:
      int lmpargc = sizeof(lmpargv)/sizeof(const char *);
 
      /* create LAMMPS instance */
-     handle = lammps_open_no_mpi(lmpargc, lmpargv, NULL);
+     handle = lammps_open_no_mpi(lmpargc, (char **)lmpargv, NULL);
      if (handle == NULL) {
        printf("LAMMPS initialization failed");
        lammps_mpi_finalize();
@@ -104,3 +105,13 @@ calling program.
 
 .. doxygenfunction:: lammps_mpi_finalize
    :project: progguide
+
+-----------------------
+
+.. doxygenfunction:: lammps_kokkos_finalize
+   :project: progguide
+
+-----------------------
+
+.. doxygenfunction:: lammps_python_finalize
+   :project: progguide

doc/src/Library_scatter.rst

@@ -17,6 +17,7 @@ It documents the following functions:
 - :cpp:func:`lammps_gather_atoms_subset`
 - :cpp:func:`lammps_scatter_atoms`
 - :cpp:func:`lammps_scatter_atoms_subset`
+- :cpp:func:`lammps_gather_bonds`
 - :cpp:func:`lammps_gather`
 - :cpp:func:`lammps_gather_concat`
 - :cpp:func:`lammps_gather_subset`
@@ -51,6 +52,11 @@ It documents the following functions:
 
 -----------------------
 
+.. doxygenfunction:: lammps_gather_bonds
+   :project: progguide
+
+-----------------------
+
 .. doxygenfunction:: lammps_gather
    :project: progguide
 

doc/src/Library_utility.rst

@@ -8,7 +8,11 @@ functions.  They do not directly call the LAMMPS library.
 - :cpp:func:`lammps_decode_image_flags`
 - :cpp:func:`lammps_set_fix_external_callback`
 - :cpp:func:`lammps_fix_external_set_energy_global`
+- :cpp:func:`lammps_fix_external_set_energy_peratom`
 - :cpp:func:`lammps_fix_external_set_virial_global`
+- :cpp:func:`lammps_fix_external_set_virial_peratom`
+- :cpp:func:`lammps_fix_external_set_vector_length`
+- :cpp:func:`lammps_fix_external_set_vector`
 - :cpp:func:`lammps_free`
 - :cpp:func:`lammps_is_running`
 - :cpp:func:`lammps_force_timeout`
@@ -33,7 +37,7 @@ where such memory buffers were allocated that require the use of
 
 -----------------------
 
-.. doxygenfunction:: lammps_set_fix_external_callback(void *, char *, FixExternalFnPtr, void*)
+.. doxygenfunction:: lammps_set_fix_external_callback(void *, const char *, FixExternalFnPtr, void*)
    :project: progguide
 
 -----------------------
@@ -43,11 +47,31 @@ where such memory buffers were allocated that require the use of
 
 -----------------------
 
+.. doxygenfunction:: lammps_fix_external_set_energy_peratom
+   :project: progguide
+
+-----------------------
+
 .. doxygenfunction:: lammps_fix_external_set_virial_global
    :project: progguide
 
 -----------------------
 
+.. doxygenfunction:: lammps_fix_external_set_virial_peratom
+   :project: progguide
+
+-----------------------
+
+.. doxygenfunction:: lammps_fix_external_set_vector_length
+   :project: progguide
+
+-----------------------
+
+.. doxygenfunction:: lammps_fix_external_set_vector
+   :project: progguide
+
+-----------------------
+
 .. doxygenfunction:: lammps_free
    :project: progguide
 

doc/src/Manual_version.rst

@@ -2,12 +2,21 @@ What does a LAMMPS version mean
 -------------------------------
 
 The LAMMPS "version" is the date when it was released, such as 1 May
-2014. LAMMPS is updated continuously.  Whenever we fix a bug or add a
-feature, we release it in the next *patch* release, which are
-typically made every couple of weeks.  Info on patch releases are on
-`this website page <https://www.lammps.org/bug.html>`_. Every few
-months, the latest patch release is subjected to more thorough testing
-and labeled as a *stable* version.
+2014.  LAMMPS is updated continuously and we aim to keep it working
+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
+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
+<https://www.lammps.org/bug.html>`_.
+
+Once or twice a year, only bug fixes and small, non-intrusive changes are
+included for a period of time, and the code is subjected to more detailed
+and thorough testing than the default automated testing.  The latest
+patch release after such a period is then labeled as a *stable* version.
 
 Each version of LAMMPS contains all the features and bug-fixes up to
 and including its version date.