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

Merge branch 'master' into fmt_upgrade

Browse Source
This commit is contained in:
Axel Kohlmeyer
2021-10-09 23:42:17 -04:00
parent b3fed4d1a9 ab51c1bd3d
commit cf4e671474
5306 changed files with 133428 additions and 104984 deletions
Download Patch File Download Diff File Expand all files Collapse all files

67
.github/CODEOWNERS vendored
View File

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

58
.github/CONTRIBUTING.md vendored
View File

@ -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. 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: 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 guide for submitting new features in the LAMMPS 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 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 ## Table of Contents
@ -26,11 +27,11 @@ __
## I don't want to read this whole thing I just have a question! ## 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? ## 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. 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 ### 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 ### 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 USER-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 USER-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 USER-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/USER 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/USER-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 ## 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. 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 ### 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. 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 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. 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 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). 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. 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. 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. 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 workflow may be adjusted. 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.

3
.gitignore vendored
View File

@ -12,6 +12,7 @@
*.sif *.sif
*.dll *.dll
*.pyc *.pyc
a.out
__pycache__ __pycache__
Obj_* Obj_*
@ -43,6 +44,8 @@ Thumbs.db
/build* /build*
/CMakeCache.txt /CMakeCache.txt
/CMakeFiles/ /CMakeFiles/
/Testing
/Makefile /Makefile
/Testing
/cmake_install.cmake /cmake_install.cmake
/lmp /lmp

2
bench/POTENTIALS/in.meamc → bench/POTENTIALS/in.meam
View File

@ -8,7 +8,7 @@ region box block 0 20 0 20 0 20
create_box 1 box create_box 1 box
create_atoms 1 box create_atoms 1 box
pair_style meam/c pair_style meam
pair_coeff * * library.meam Ni4 Ni.meam Ni4 pair_coeff * * library.meam Ni4 Ni.meam Ni4
velocity all create 1600.0 376847 loop geom velocity all create 1600.0 376847 loop geom

6
bench/POTENTIALS/log.9Oct20.meamc.1 → bench/POTENTIALS/log.9Oct20.meam.1
View File

@ -15,7 +15,7 @@ create_atoms 1 box
Created 32000 atoms Created 32000 atoms
create_atoms CPU = 0.002 seconds create_atoms CPU = 0.002 seconds
pair_style meam/c pair_style meam
pair_coeff * * library.meam Ni4 Ni.meam Ni4 pair_coeff * * library.meam Ni4 Ni.meam Ni4
Reading potential file library.meam with DATE: 2012-06-29 Reading potential file library.meam with DATE: 2012-06-29
Reading potential file Ni.meam with DATE: 2007-06-11 Reading potential file Ni.meam with DATE: 2007-06-11
@ -38,12 +38,12 @@ Neighbor list info ...
ghost atom cutoff = 5 ghost atom cutoff = 5
binsize = 2.5, bins = 29 29 29 binsize = 2.5, bins = 29 29 29
2 neighbor lists, perpetual/occasional/extra = 2 0 0 2 neighbor lists, perpetual/occasional/extra = 2 0 0
(1) pair meam/c, perpetual (1) pair meam, perpetual
attributes: full, newton on attributes: full, newton on
pair build: full/bin/atomonly pair build: full/bin/atomonly
stencil: full/bin/3d stencil: full/bin/3d
bin: standard bin: standard
(2) pair meam/c, perpetual, half/full from (1) (2) pair meam, perpetual, half/full from (1)
attributes: half, newton on attributes: half, newton on
pair build: halffull/newton pair build: halffull/newton
stencil: none stencil: none

6
bench/POTENTIALS/log.9Oct20.meamc.4 → bench/POTENTIALS/log.9Oct20.meam.4
View File

@ -15,7 +15,7 @@ create_atoms 1 box
Created 32000 atoms Created 32000 atoms
create_atoms CPU = 0.001 seconds create_atoms CPU = 0.001 seconds
pair_style meam/c pair_style meam
pair_coeff * * library.meam Ni4 Ni.meam Ni4 pair_coeff * * library.meam Ni4 Ni.meam Ni4
Reading potential file library.meam with DATE: 2012-06-29 Reading potential file library.meam with DATE: 2012-06-29
Reading potential file Ni.meam with DATE: 2007-06-11 Reading potential file Ni.meam with DATE: 2007-06-11
@ -38,12 +38,12 @@ Neighbor list info ...
ghost atom cutoff = 5 ghost atom cutoff = 5
binsize = 2.5, bins = 29 29 29 binsize = 2.5, bins = 29 29 29
2 neighbor lists, perpetual/occasional/extra = 2 0 0 2 neighbor lists, perpetual/occasional/extra = 2 0 0
(1) pair meam/c, perpetual (1) pair meam, perpetual
attributes: full, newton on attributes: full, newton on
pair build: full/bin/atomonly pair build: full/bin/atomonly
stencil: full/bin/3d stencil: full/bin/3d
bin: standard bin: standard
(2) pair meam/c, perpetual, half/full from (1) (2) pair meam, perpetual, half/full from (1)
attributes: half, newton on attributes: half, newton on
pair build: halffull/newton pair build: halffull/newton
stencil: none stencil: none

2
bench/POTENTIALS/log.9Oct20.reaxc.1
View File

@ -24,7 +24,7 @@ velocity all create 300.0 9999
pair_style reax/c NULL pair_style reax/c NULL
pair_coeff * * ffield.reax C H O N pair_coeff * * ffield.reax C H O N
WARNING: Changed valency_val to valency_boc for X (src/USER-REAXC/reaxc_ffield.cpp:315) WARNING: Changed valency_val to valency_boc for X (src/REAXFF/reaxc_ffield.cpp:315)
timestep 0.1 timestep 0.1
fix 1 all nve fix 1 all nve

2
bench/POTENTIALS/log.9Oct20.reaxc.4
View File

@ -24,7 +24,7 @@ velocity all create 300.0 9999
pair_style reax/c NULL pair_style reax/c NULL
pair_coeff * * ffield.reax C H O N pair_coeff * * ffield.reax C H O N
WARNING: Changed valency_val to valency_boc for X (src/USER-REAXC/reaxc_ffield.cpp:315) WARNING: Changed valency_val to valency_boc for X (src/REAXFF/reaxc_ffield.cpp:315)
timestep 0.1 timestep 0.1
fix 1 all nve fix 1 all nve

10
cmake/.coveragerc.in Normal file
View File

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

166
cmake/CMakeLists.txt
View File

@ -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 # 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) 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() endif()
# If enabled, no need to use LD_LIBRARY_PATH / DYLD_LIBRARY_PATH when installed # 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) include(CheckIncludeFileCXX)
# set required compiler flags and compiler/CPU arch specific optimizations # 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") 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) if(CMAKE_CXX_COMPILER_VERSION VERSION_EQUAL 17.3 OR CMAKE_CXX_COMPILER_VERSION VERSION_EQUAL 17.4)
set(CMAKE_TUNE_DEFAULT "-xCOMMON-AVX512") set(CMAKE_TUNE_DEFAULT "-xCOMMON-AVX512")
@ -86,10 +90,17 @@ if(CMAKE_CXX_COMPILER_ID STREQUAL "Intel")
endif() endif()
endif() endif()
# we require C++11 without extensions # we require C++11 without extensions. Kokkos requires at least C++14 (currently)
set(CMAKE_CXX_STANDARD 11) set(CMAKE_CXX_STANDARD 11)
if(PKG_KOKKOS AND (CMAKE_CXX_STANDARD LESS 14))
set(CMAKE_CXX_STANDARD 14)
endif()
set(CMAKE_CXX_STANDARD_REQUIRED ON) set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_CXX_EXTENSIONS OFF CACHE BOOL "Use compiler extensions") 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 # export all symbols when building a .dll file on windows
if((CMAKE_SYSTEM_NAME STREQUAL "Windows") AND BUILD_SHARED_LIBS) if((CMAKE_SYSTEM_NAME STREQUAL "Windows") AND BUILD_SHARED_LIBS)
@ -138,17 +149,92 @@ install(TARGETS lmp EXPORT LAMMPS_Targets DESTINATION ${CMAKE_INSTALL_BINDIR})
option(CMAKE_VERBOSE_MAKEFILE "Generate verbose Makefiles" OFF) option(CMAKE_VERBOSE_MAKEFILE "Generate verbose Makefiles" OFF)
set(STANDARD_PACKAGES ASPHERE BODY CLASS2 COLLOID COMPRESS DIPOLE set(STANDARD_PACKAGES
GRANULAR KSPACE LATTE MANYBODY MC MESSAGE MISC MLIAP MOLECULE PERI POEMS ADIOS
PLUGIN QEQ REPLICA RIGID SHOCK SPIN SNAP SRD KIM PYTHON MSCG MPIIO VORONOI ASPHERE
USER-ADIOS USER-ATC USER-AWPMD USER-BOCS USER-CGDNA USER-MESODPD USER-CGSDK ATC
USER-COLVARS USER-DIELECTRIC USER-DIFFRACTION USER-DPD USER-DRUDE USER-EFF USER-FEP AWPMD
USER-H5MD USER-HDNNP USER-LB USER-MANIFOLD USER-MDI USER-MEAMC USER-MESONT USER-MGPT BOCS
USER-MISC USER-MOFFF USER-MOLFILE USER-NETCDF USER-PHONON USER-PLUMED USER-PTM USER-QTB BODY
USER-RANN USER-REACTION USER-REAXC USER-SCAFACOS USER-SDPD USER-SMD USER-SMTBQ USER-SPH BROWNIAN
USER-TALLY USER-UEF USER-VTK USER-QUIP USER-QMMM USER-YAFF USER-PACE USER-BROWNIAN) CG-DNA
CG-SDK
CLASS2
COLLOID
COLVARS
COMPRESS
DIELECTRIC
DIFFRACTION
DIPOLE
DPD-BASIC
DPD-MESO
DPD-REACT
DPD-SMOOTH
DRUDE
EFF
EXTRA-COMPUTE
EXTRA-DUMP
EXTRA-FIX
EXTRA-MOLECULE
EXTRA-PAIR
FEP
GRANULAR
H5MD
INTERLAYER
KIM
KSPACE
LATBOLTZ
LATTE
MACHDYN
MANIFOLD
MANYBODY
MC
MDI
MEAM
MESONT
MESSAGE
MGPT
MISC
ML-HDNNP
ML-IAP
ML-PACE
ML-QUIP
ML-RANN
ML-SNAP
MOFFF
MOLECULE
MOLFILE
MPIIO
MSCG
NETCDF
ORIENT
PERI
PHONON
PLUGIN
PLUMED
POEMS
PTM
PYTHON
QEQ
QMMM
QTB
REACTION
REAXFF
REPLICA
RIGID
SCAFACOS
SHOCK
SMTBQ
SPH
SPIN
SRD
TALLY
UEF
VORONOI
VTK
YAFF)
set(SUFFIX_PACKAGES CORESHELL GPU KOKKOS OPT USER-INTEL USER-OMP) set(SUFFIX_PACKAGES CORESHELL GPU KOKKOS OPT INTEL OPENMP)
foreach(PKG ${STANDARD_PACKAGES} ${SUFFIX_PACKAGES}) foreach(PKG ${STANDARD_PACKAGES} ${SUFFIX_PACKAGES})
option(PKG_${PKG} "Build ${PKG} Package" OFF) option(PKG_${PKG} "Build ${PKG} Package" OFF)
@ -159,7 +245,7 @@ endforeach()
###################################################### ######################################################
target_include_directories(lammps PUBLIC $<BUILD_INTERFACE:${LAMMPS_SOURCE_DIR}>) target_include_directories(lammps PUBLIC $<BUILD_INTERFACE:${LAMMPS_SOURCE_DIR}>)
if(PKG_USER-ADIOS) if(PKG_ADIOS)
# The search for ADIOS2 must come before MPI because # The search for ADIOS2 must come before MPI because
# it includes its own MPI search with the latest FindMPI.cmake # it includes its own MPI search with the latest FindMPI.cmake
# script that defines the MPI::MPI_C target # script that defines the MPI::MPI_C target
@ -169,15 +255,16 @@ if(PKG_USER-ADIOS)
endif() endif()
if(NOT CMAKE_CROSSCOMPILING) if(NOT CMAKE_CROSSCOMPILING)
set(MPI_CXX_SKIP_MPICXX TRUE)
find_package(MPI QUIET) find_package(MPI QUIET)
option(BUILD_MPI "Build MPI version" ${MPI_FOUND}) option(BUILD_MPI "Build MPI version" ${MPI_FOUND})
else() else()
set(MPI_CXX_SKIP_MPICXX TRUE)
option(BUILD_MPI "Build MPI version" OFF) option(BUILD_MPI "Build MPI version" OFF)
endif() endif()
if(BUILD_MPI) 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 # We use a non-standard procedure to cross-compile with MPI on Windows
if((CMAKE_SYSTEM_NAME STREQUAL "Windows") AND CMAKE_CROSSCOMPILING) if((CMAKE_SYSTEM_NAME STREQUAL "Windows") AND CMAKE_CROSSCOMPILING)
include(MPI4WIN) include(MPI4WIN)
@ -229,13 +316,16 @@ endif()
# "hard" dependencies between packages resulting # "hard" dependencies between packages resulting
# in an error instead of skipping over files # in an error instead of skipping over files
pkg_depends(MLIAP SNAP) pkg_depends(ML-IAP ML-SNAP)
pkg_depends(MPIIO MPI) pkg_depends(MPIIO MPI)
pkg_depends(USER-ATC MANYBODY) pkg_depends(ATC MANYBODY)
pkg_depends(USER-LB MPI) pkg_depends(LATBOLTZ MPI)
pkg_depends(USER-PHONON KSPACE) pkg_depends(PHONON KSPACE)
pkg_depends(USER-SCAFACOS MPI) pkg_depends(SCAFACOS MPI)
pkg_depends(USER-DIELECTRIC KSPACE) 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 # detect if we may enable OpenMP support by default
set(BUILD_OMP_DEFAULT OFF) set(BUILD_OMP_DEFAULT OFF)
@ -271,7 +361,7 @@ if(BUILD_OMP)
target_link_libraries(lammps PRIVATE OpenMP::OpenMP_CXX) target_link_libraries(lammps PRIVATE OpenMP::OpenMP_CXX)
endif() endif()
if(PKG_MSCG OR PKG_USER-ATC OR PKG_USER-AWPMD OR PKG_USER-QUIP OR PKG_LATTE) if(PKG_MSCG OR PKG_ATC OR PKG_AWPMD OR PKG_ML-QUIP OR PKG_LATTE)
enable_language(C) enable_language(C)
find_package(LAPACK) find_package(LAPACK)
find_package(BLAS) find_package(BLAS)
@ -291,6 +381,8 @@ if(PKG_MSCG OR PKG_USER-ATC OR PKG_USER-AWPMD OR PKG_USER-QUIP OR PKG_LATTE)
endif() endif()
endif() endif()
# tweak jpeg library names to avoid linker errors with MinGW cross-compilation
set(JPEG_NAMES libjpeg libjpeg-62)
find_package(JPEG QUIET) find_package(JPEG QUIET)
option(WITH_JPEG "Enable JPEG support" ${JPEG_FOUND}) option(WITH_JPEG "Enable JPEG support" ${JPEG_FOUND})
if(WITH_JPEG) if(WITH_JPEG)
@ -350,8 +442,8 @@ else()
set(CUDA_REQUEST_PIC) set(CUDA_REQUEST_PIC)
endif() endif()
foreach(PKG_WITH_INCL KSPACE PYTHON MLIAP VORONOI USER-COLVARS USER-HDNNP USER-MDI USER-MOLFILE USER-NETCDF foreach(PKG_WITH_INCL KSPACE PYTHON ML-IAP VORONOI COLVARS ML-HDNNP MDI MOLFILE NETCDF
USER-PLUMED USER-QMMM USER-QUIP USER-SCAFACOS USER-SMD USER-VTK KIM LATTE MESSAGE MSCG COMPRESS USER-PACE) PLUMED QMMM ML-QUIP SCAFACOS MACHDYN VTK KIM LATTE MESSAGE MSCG COMPRESS ML-PACE)
if(PKG_${PKG_WITH_INCL}) if(PKG_${PKG_WITH_INCL})
include(Packages/${PKG_WITH_INCL}) include(Packages/${PKG_WITH_INCL})
endif() endif()
@ -444,9 +536,8 @@ endforeach()
############################################## ##############################################
# add lib sources of (simple) enabled packages # add lib sources of (simple) enabled packages
############################################ ############################################
foreach(SIMPLE_LIB POEMS USER-ATC USER-AWPMD USER-H5MD USER-MESONT) foreach(PKG_LIB POEMS ATC AWPMD H5MD MESONT)
if(PKG_${SIMPLE_LIB}) if(PKG_${PKG_LIB})
string(REGEX REPLACE "^USER-" "" PKG_LIB "${SIMPLE_LIB}")
string(TOLOWER "${PKG_LIB}" PKG_LIB) string(TOLOWER "${PKG_LIB}" PKG_LIB)
if(PKG_LIB STREQUAL "mesont") if(PKG_LIB STREQUAL "mesont")
enable_language(Fortran) enable_language(Fortran)
@ -470,13 +561,13 @@ foreach(SIMPLE_LIB POEMS USER-ATC USER-AWPMD USER-H5MD USER-MESONT)
endif() endif()
endforeach() endforeach()
if(PKG_USER-AWPMD) if(PKG_AWPMD)
target_link_libraries(awpmd PRIVATE ${LAPACK_LIBRARIES}) target_link_libraries(awpmd PRIVATE ${LAPACK_LIBRARIES})
endif() endif()
if(PKG_USER-ATC) if(PKG_ATC)
if(LAMMPS_SIZES STREQUAL "BIGBIG") if(LAMMPS_SIZES STREQUAL "BIGBIG")
message(FATAL_ERROR "The USER-ATC Package is not compatible with -DLAMMPS_BIGBIG") message(FATAL_ERROR "The ATC Package is not compatible with -DLAMMPS_BIGBIG")
endif() endif()
target_link_libraries(atc PRIVATE ${LAPACK_LIBRARIES}) target_link_libraries(atc PRIVATE ${LAPACK_LIBRARIES})
if(BUILD_MPI) if(BUILD_MPI)
@ -488,15 +579,15 @@ if(PKG_USER-ATC)
target_compile_definitions(atc PRIVATE -DLAMMPS_${LAMMPS_SIZES}) target_compile_definitions(atc PRIVATE -DLAMMPS_${LAMMPS_SIZES})
endif() endif()
if(PKG_USER-H5MD) if(PKG_H5MD)
include(Packages/USER-H5MD) include(Packages/H5MD)
endif() endif()
###################################################################### ######################################################################
# packages which selectively include variants based on enabled styles # packages which selectively include variants based on enabled styles
# e.g. accelerator packages # e.g. accelerator packages
###################################################################### ######################################################################
foreach(PKG_WITH_INCL CORESHELL QEQ USER-OMP USER-SDPD KOKKOS OPT USER-INTEL GPU) foreach(PKG_WITH_INCL CORESHELL QEQ OPENMP DPD-SMOOTH KOKKOS OPT INTEL GPU)
if(PKG_${PKG_WITH_INCL}) if(PKG_${PKG_WITH_INCL})
include(Packages/${PKG_WITH_INCL}) include(Packages/${PKG_WITH_INCL})
endif() endif()
@ -689,6 +780,13 @@ endif()
include(Testing) include(Testing)
include(CodeCoverage) include(CodeCoverage)
include(CodingStandard) 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) get_target_property(DEFINES lammps COMPILE_DEFINITIONS)
include(FeatureSummary) include(FeatureSummary)

10
cmake/Modules/CodeCoverage.cmake
View File

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

2
cmake/Modules/FindFFTW3.cmake
View File

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

2
cmake/Modules/FindFFTW3F.cmake
View File

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

2
cmake/Modules/FindN2P2.cmake
View File

@ -22,7 +22,7 @@ find_library(N2P2_LIBNNPIF NAMES nnpif HINTS "${N2P2_DIR}/lib")
# #
# target_compile_definitions(lammps PRIVATE -DN2P2_NO_SF_GROUPS) # target_compile_definitions(lammps PRIVATE -DN2P2_NO_SF_GROUPS)
# #
# to "lib/lammps-extra.cmake" which is then included by USER-HDNNP.cmake. # to "lib/lammps-extra.cmake" which is then included by ML-HDNNP.cmake.
find_file(N2P2_CMAKE_EXTRA NAMES lammps-extra.cmake HINTS "${N2P2_DIR}/lib") find_file(N2P2_CMAKE_EXTRA NAMES lammps-extra.cmake HINTS "${N2P2_DIR}/lib")
find_package_handle_standard_args(N2P2 DEFAULT_MSG find_package_handle_standard_args(N2P2 DEFAULT_MSG

4
cmake/Modules/GTest.cmake
View File

@ -7,8 +7,8 @@ else()
endif() endif()
include(ExternalProject) include(ExternalProject)
set(GTEST_URL "https://github.com/google/googletest/archive/release-1.11.0.tar.gz" CACHE STRING "URL for GTest tarball") set(GTEST_URL "https://github.com/google/googletest/archive/release-1.10.0.tar.gz" CACHE STRING "URL for GTest tarball")
set(GTEST_MD5 "e8a8df240b6938bb6384155d4c37d937" CACHE STRING "MD5 checksum of GTest tarball") set(GTEST_MD5 "ecd1fa65e7de707cd5c00bdac56022cd" CACHE STRING "MD5 checksum of GTest tarball")
mark_as_advanced(GTEST_URL) mark_as_advanced(GTEST_URL)
mark_as_advanced(GTEST_MD5) mark_as_advanced(GTEST_MD5)
ExternalProject_Add(googletest ExternalProject_Add(googletest

2
cmake/Modules/LAMMPSUtils.cmake
View File

@ -67,7 +67,7 @@ endfunction()
macro(pkg_depends PKG1 PKG2) macro(pkg_depends PKG1 PKG2)
if(PKG_${PKG1} AND NOT (PKG_${PKG2} OR BUILD_${PKG2})) if(PKG_${PKG1} AND NOT (PKG_${PKG2} OR BUILD_${PKG2}))
message(FATAL_ERROR "${PKG1} package needs LAMMPS to be build with ${PKG2}") message(FATAL_ERROR "The ${PKG1} package needs LAMMPS to be build with the ${PKG2} package")
endif() endif()
endmacro() endmacro()

4
cmake/Modules/OpenCLLoader.cmake
View File

@ -1,6 +1,6 @@
message(STATUS "Downloading and building OpenCL loader library") 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_URL "${LAMMPS_THIRDPARTY_URL}/opencl-loader-2021.09.18.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_MD5 "3b3882627964bd02e5c3b02065daac3c" CACHE STRING "MD5 checksum of OpenCL loader tarball")
mark_as_advanced(OPENCL_LOADER_URL) mark_as_advanced(OPENCL_LOADER_URL)
mark_as_advanced(OPENCL_LOADER_MD5) mark_as_advanced(OPENCL_LOADER_MD5)

0
cmake/Modules/Packages/USER-COLVARS.cmake → cmake/Modules/Packages/COLVARS.cmake
View File

8
cmake/Modules/Packages/USER-SDPD.cmake → cmake/Modules/Packages/DPD-SMOOTH.cmake
View File

@ -1,13 +1,13 @@
# Fix rigid/meso requires RIGID to be installed # Fix rigid/meso requires RIGID to be installed
set(USER-SDPD_SOURCES_DIR ${LAMMPS_SOURCE_DIR}/USER-SDPD) set(DPD-SMOOTH_SOURCES_DIR ${LAMMPS_SOURCE_DIR}/DPD-SMOOTH)
get_property(hlist GLOBAL PROPERTY FIX) get_property(hlist GLOBAL PROPERTY FIX)
if(NOT PKG_RIGID) if(NOT PKG_RIGID)
list(REMOVE_ITEM hlist ${USER-SDPD_SOURCES_DIR}/fix_rigid_meso.h) list(REMOVE_ITEM hlist ${DPD-SMOOTH_SOURCES_DIR}/fix_rigid_meso.h)
get_target_property(LAMMPS_SOURCES lammps SOURCES) get_target_property(LAMMPS_SOURCES lammps SOURCES)
list(REMOVE_ITEM LAMMPS_SOURCES ${USER-SDPD_SOURCES_DIR}/fix_rigid_meso.cpp) list(REMOVE_ITEM LAMMPS_SOURCES ${DPD-SMOOTH_SOURCES_DIR}/fix_rigid_meso.cpp)
set_property(TARGET lammps PROPERTY SOURCES ${LAMMPS_SOURCES}) set_property(TARGET lammps PROPERTY SOURCES ${LAMMPS_SOURCES})
endif() endif()
set_property(GLOBAL PROPERTY FIX "${hlist}") set_property(GLOBAL PROPERTY FIX "${hlist}")
target_include_directories(lammps PRIVATE ${USER-SDPD_SOURCES_DIR}) target_include_directories(lammps PRIVATE ${DPD-SMOOTH_SOURCES_DIR})

98
cmake/Modules/Packages/GPU.cmake
View File

@ -71,44 +71,47 @@ if(GPU_API STREQUAL "CUDA")
# build arch/gencode commands for nvcc based on CUDA toolkit version and use choice # 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 # --arch translates directly instead of JIT, so this should be for the preferred or most common architecture
set(GPU_CUDA_GENCODE "-arch=${GPU_ARCH}") 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")) # apply the following to build "fat" CUDA binaries only for known CUDA toolkits
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()
if(CUDA_VERSION VERSION_GREATER_EQUAL "12.0") 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() endif()
cuda_compile_fatbin(GPU_GEN_OBJS ${GPU_LIB_CU} OPTIONS ${CUDA_REQUEST_PIC} 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") elseif(GPU_API STREQUAL "HIP")
if(NOT DEFINED HIP_PATH) if(NOT DEFINED HIP_PATH)
if(NOT DEFINED ENV{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() 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()
endif() endif()
set(CMAKE_MODULE_PATH "${HIP_PATH}/cmake" ${CMAKE_MODULE_PATH}) if(NOT DEFINED ROCM_PATH)
find_package(HIP REQUIRED) 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) option(HIP_USE_DEVICE_SORT "Use GPU sorting" ON)
if(NOT DEFINED HIP_PLATFORM) 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") 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_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 -D_${GPU_PREC_SETTING} -DMPI_GERYON -DUCL_NO_EXIT)
target_compile_definitions(gpu PRIVATE -DUSE_HIP) target_compile_definitions(gpu PRIVATE -DUSE_HIP)
target_link_libraries(gpu PRIVATE hip::host)
if(HIP_USE_DEVICE_SORT) if(HIP_USE_DEVICE_SORT)
# add hipCUB # add hipCUB
@ -374,8 +385,9 @@ elseif(GPU_API STREQUAL "HIP")
endif() endif()
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_compile_definitions(hip_get_devices PRIVATE -DUCL_HIP)
target_link_libraries(hip_get_devices hip::host)
if(HIP_PLATFORM STREQUAL "nvcc") if(HIP_PLATFORM STREQUAL "nvcc")
target_compile_definitions(gpu PRIVATE -D__HIP_PLATFORM_NVCC__) target_compile_definitions(gpu PRIVATE -D__HIP_PLATFORM_NVCC__)

0
cmake/Modules/Packages/USER-H5MD.cmake → cmake/Modules/Packages/H5MD.cmake
View File

48
cmake/Modules/Packages/USER-INTEL.cmake → cmake/Modules/Packages/INTEL.cmake
View File

@ -3,9 +3,9 @@ if(NOT FOUND_IMMINTRIN)
message(FATAL_ERROR "immintrin.h header not found, Intel package won't work without it") message(FATAL_ERROR "immintrin.h header not found, Intel package won't work without it")
endif() 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 USER-INTEL (cpu or knl)") set(INTEL_ARCH "cpu" CACHE STRING "Architectures used by INTEL (cpu or knl)")
set(INTEL_ARCH_VALUES cpu knl) set(INTEL_ARCH_VALUES cpu knl)
set_property(CACHE INTEL_ARCH PROPERTY STRINGS ${INTEL_ARCH_VALUES}) set_property(CACHE INTEL_ARCH PROPERTY STRINGS ${INTEL_ARCH_VALUES})
validate_option(INTEL_ARCH INTEL_ARCH_VALUES) validate_option(INTEL_ARCH INTEL_ARCH_VALUES)
@ -40,10 +40,10 @@ endif()
if(CMAKE_CXX_COMPILER_ID STREQUAL "Intel") if(CMAKE_CXX_COMPILER_ID STREQUAL "Intel")
if(CMAKE_CXX_COMPILER_VERSION VERSION_LESS 16) if(CMAKE_CXX_COMPILER_VERSION VERSION_LESS 16)
message(FATAL_ERROR "USER-INTEL needs at least a 2016 Intel compiler, found ${CMAKE_CXX_COMPILER_VERSION}") message(FATAL_ERROR "INTEL needs at least a 2016 Intel compiler, found ${CMAKE_CXX_COMPILER_VERSION}")
endif() endif()
else() else()
message(WARNING "USER-INTEL gives best performance with Intel compilers") message(WARNING "INTEL gives best performance with Intel compilers")
endif() endif()
find_package(TBB_MALLOC QUIET) find_package(TBB_MALLOC QUIET)
@ -52,7 +52,7 @@ if(TBB_MALLOC_FOUND)
else() else()
target_compile_definitions(lammps PRIVATE -DLMP_INTEL_NO_TBB) target_compile_definitions(lammps PRIVATE -DLMP_INTEL_NO_TBB)
if(CMAKE_CXX_COMPILER_ID STREQUAL "Intel") if(CMAKE_CXX_COMPILER_ID STREQUAL "Intel")
message(WARNING "USER-INTEL with Intel compilers should use TBB malloc libraries") message(WARNING "INTEL with Intel compilers should use TBB malloc libraries")
endif() endif()
endif() endif()
@ -65,12 +65,12 @@ else()
endif() endif()
if((NOT ${CMAKE_SYSTEM_NAME} STREQUAL "Windows") AND (NOT ${LAMMPS_MEMALIGN} STREQUAL "64") AND (NOT ${LAMMPS_MEMALIGN} STREQUAL "128") AND (NOT ${LAMMPS_MEMALIGN} STREQUAL "256")) if((NOT ${CMAKE_SYSTEM_NAME} STREQUAL "Windows") AND (NOT ${LAMMPS_MEMALIGN} STREQUAL "64") AND (NOT ${LAMMPS_MEMALIGN} STREQUAL "128") AND (NOT ${LAMMPS_MEMALIGN} STREQUAL "256"))
message(FATAL_ERROR "USER-INTEL only supports memory alignment of 64, 128 or 256 on this platform") message(FATAL_ERROR "INTEL only supports memory alignment of 64, 128 or 256 on this platform")
endif() endif()
if(INTEL_ARCH STREQUAL "KNL") if(INTEL_ARCH STREQUAL "KNL")
if(NOT CMAKE_CXX_COMPILER_ID STREQUAL "Intel") if(NOT CMAKE_CXX_COMPILER_ID STREQUAL "Intel")
message(FATAL_ERROR "Must use Intel compiler with USER-INTEL for KNL architecture") message(FATAL_ERROR "Must use Intel compiler with INTEL for KNL architecture")
endif() endif()
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -xHost -qopenmp -qoffload") set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -xHost -qopenmp -qoffload")
set(MIC_OPTIONS "-qoffload-option,mic,compiler,\"-fp-model fast=2 -mGLOB_default_function_attrs=\\\"gather_scatter_loop_unroll=4\\\"\"") set(MIC_OPTIONS "-qoffload-option,mic,compiler,\"-fp-model fast=2 -mGLOB_default_function_attrs=\\\"gather_scatter_loop_unroll=4\\\"\"")
@ -91,26 +91,26 @@ else()
endif() endif()
# collect sources # collect sources
set(USER-INTEL_SOURCES_DIR ${LAMMPS_SOURCE_DIR}/USER-INTEL) set(INTEL_SOURCES_DIR ${LAMMPS_SOURCE_DIR}/INTEL)
set(USER-INTEL_SOURCES ${USER-INTEL_SOURCES_DIR}/fix_intel.cpp set(INTEL_SOURCES ${INTEL_SOURCES_DIR}/fix_intel.cpp
${USER-INTEL_SOURCES_DIR}/fix_nh_intel.cpp ${INTEL_SOURCES_DIR}/fix_nh_intel.cpp
${USER-INTEL_SOURCES_DIR}/intel_buffers.cpp ${INTEL_SOURCES_DIR}/intel_buffers.cpp
${USER-INTEL_SOURCES_DIR}/nbin_intel.cpp ${INTEL_SOURCES_DIR}/nbin_intel.cpp
${USER-INTEL_SOURCES_DIR}/npair_intel.cpp) ${INTEL_SOURCES_DIR}/npair_intel.cpp)
set_property(GLOBAL PROPERTY "USER-INTEL_SOURCES" "${USER-INTEL_SOURCES}") set_property(GLOBAL PROPERTY "INTEL_SOURCES" "${INTEL_SOURCES}")
# detect styles which have a USER-INTEL version # detect styles which have a INTEL version
RegisterStylesExt(${USER-INTEL_SOURCES_DIR} intel USER-INTEL_SOURCES) RegisterStylesExt(${INTEL_SOURCES_DIR} intel INTEL_SOURCES)
RegisterNBinStyle(${USER-INTEL_SOURCES_DIR}/nbin_intel.h) RegisterNBinStyle(${INTEL_SOURCES_DIR}/nbin_intel.h)
RegisterNPairStyle(${USER-INTEL_SOURCES_DIR}/npair_intel.h) RegisterNPairStyle(${INTEL_SOURCES_DIR}/npair_intel.h)
RegisterFixStyle(${USER-INTEL_SOURCES_DIR}/fix_intel.h) RegisterFixStyle(${INTEL_SOURCES_DIR}/fix_intel.h)
get_property(USER-INTEL_SOURCES GLOBAL PROPERTY USER-INTEL_SOURCES) get_property(INTEL_SOURCES GLOBAL PROPERTY INTEL_SOURCES)
if(PKG_KSPACE) if(PKG_KSPACE)
list(APPEND USER-INTEL_SOURCES ${USER-INTEL_SOURCES_DIR}/verlet_lrt_intel.cpp) list(APPEND INTEL_SOURCES ${INTEL_SOURCES_DIR}/verlet_lrt_intel.cpp)
RegisterIntegrateStyle(${USER-INTEL_SOURCES_DIR}/verlet_lrt_intel.h) RegisterIntegrateStyle(${INTEL_SOURCES_DIR}/verlet_lrt_intel.h)
endif() endif()
target_sources(lammps PRIVATE ${USER-INTEL_SOURCES}) target_sources(lammps PRIVATE ${INTEL_SOURCES})
target_include_directories(lammps PRIVATE ${USER-INTEL_SOURCES_DIR}) target_include_directories(lammps PRIVATE ${INTEL_SOURCES_DIR})

11
cmake/Modules/Packages/KOKKOS.cmake
View File

@ -1,6 +1,8 @@
######################################################################## ########################################################################
# As of version 3.3.0 Kokkos requires C++14 # As of version 3.3.0 Kokkos requires C++14
set(CMAKE_CXX_STANDARD 14) if(CMAKE_CXX_STANDARD LESS 14)
message(FATAL_ERROR "The KOKKOS package requires the C++ standard to be set to at least C++14")
endif()
######################################################################## ########################################################################
# consistency checks and Kokkos options/settings required by LAMMPS # consistency checks and Kokkos options/settings required by LAMMPS
if(Kokkos_ENABLE_CUDA) if(Kokkos_ENABLE_CUDA)
@ -74,11 +76,12 @@ else()
target_link_libraries(lammps PRIVATE kokkos) target_link_libraries(lammps PRIVATE kokkos)
target_link_libraries(lmp PRIVATE kokkos) target_link_libraries(lmp PRIVATE kokkos)
endif() 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_DIR ${LAMMPS_SOURCE_DIR}/KOKKOS)
set(KOKKOS_PKG_SOURCES ${KOKKOS_PKG_SOURCES_DIR}/kokkos.cpp set(KOKKOS_PKG_SOURCES ${KOKKOS_PKG_SOURCES_DIR}/kokkos.cpp
${KOKKOS_PKG_SOURCES_DIR}/atom_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}/atom_vec_kokkos.cpp
${KOKKOS_PKG_SOURCES_DIR}/comm_kokkos.cpp ${KOKKOS_PKG_SOURCES_DIR}/comm_kokkos.cpp
${KOKKOS_PKG_SOURCES_DIR}/comm_tiled_kokkos.cpp ${KOKKOS_PKG_SOURCES_DIR}/comm_tiled_kokkos.cpp
@ -116,7 +119,7 @@ RegisterNBinStyle(${KOKKOS_PKG_SOURCES_DIR}/nbin_kokkos.h)
RegisterNPairStyle(${KOKKOS_PKG_SOURCES_DIR}/npair_kokkos.h) RegisterNPairStyle(${KOKKOS_PKG_SOURCES_DIR}/npair_kokkos.h)
RegisterNPairStyle(${KOKKOS_PKG_SOURCES_DIR}/npair_halffull_kokkos.h) RegisterNPairStyle(${KOKKOS_PKG_SOURCES_DIR}/npair_halffull_kokkos.h)
if(PKG_USER-DPD) if(PKG_DPD-REACT)
get_property(KOKKOS_PKG_SOURCES GLOBAL PROPERTY KOKKOS_PKG_SOURCES) get_property(KOKKOS_PKG_SOURCES GLOBAL PROPERTY KOKKOS_PKG_SOURCES)
list(APPEND KOKKOS_PKG_SOURCES ${KOKKOS_PKG_SOURCES_DIR}/npair_ssa_kokkos.cpp) list(APPEND KOKKOS_PKG_SOURCES ${KOKKOS_PKG_SOURCES_DIR}/npair_ssa_kokkos.cpp)
RegisterNPairStyle(${KOKKOS_PKG_SOURCES_DIR}/npair_ssa_kokkos.h) RegisterNPairStyle(${KOKKOS_PKG_SOURCES_DIR}/npair_ssa_kokkos.h)
@ -126,4 +129,4 @@ endif()
get_property(KOKKOS_PKG_SOURCES GLOBAL PROPERTY KOKKOS_PKG_SOURCES) get_property(KOKKOS_PKG_SOURCES GLOBAL PROPERTY KOKKOS_PKG_SOURCES)
target_sources(lammps PRIVATE ${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}>)

8
cmake/Modules/Packages/LATTE.cmake
View File

@ -19,6 +19,14 @@ if(DOWNLOAD_LATTE)
set(LATTE_MD5 "820e73a457ced178c08c71389a385de7" CACHE STRING "MD5 checksum of LATTE tarball") set(LATTE_MD5 "820e73a457ced178c08c71389a385de7" CACHE STRING "MD5 checksum of LATTE tarball")
mark_as_advanced(LATTE_URL) mark_as_advanced(LATTE_URL)
mark_as_advanced(LATTE_MD5) 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) include(ExternalProject)
ExternalProject_Add(latte_build ExternalProject_Add(latte_build
URL ${LATTE_URL} URL ${LATTE_URL}

10
cmake/Modules/Packages/USER-SMD.cmake → cmake/Modules/Packages/MACHDYN.cmake
View File

@ -7,8 +7,9 @@ endif()
option(DOWNLOAD_EIGEN3 "Download Eigen3 instead of using an already installed one)" ${DOWNLOAD_EIGEN3_DEFAULT}) option(DOWNLOAD_EIGEN3 "Download Eigen3 instead of using an already installed one)" ${DOWNLOAD_EIGEN3_DEFAULT})
if(DOWNLOAD_EIGEN3) if(DOWNLOAD_EIGEN3)
message(STATUS "Eigen3 download requested - we will build our own") 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_URL)
mark_as_advanced(EIGEN3_MD5) mark_as_advanced(EIGEN3_MD5)
include(ExternalProject) include(ExternalProject)
@ -30,3 +31,8 @@ else()
endif() endif()
target_link_libraries(lammps PRIVATE Eigen3::Eigen) target_link_libraries(lammps PRIVATE Eigen3::Eigen)
endif() 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()

4
cmake/Modules/Packages/USER-MDI.cmake → cmake/Modules/Packages/MDI.cmake
View File

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

10
cmake/Modules/Packages/USER-HDNNP.cmake → cmake/Modules/Packages/ML-HDNNP.cmake
View File

@ -45,12 +45,12 @@ if(DOWNLOAD_N2P2)
# get path to MPI include directory when cross-compiling to windows # get path to MPI include directory when cross-compiling to windows
if((CMAKE_SYSTEM_NAME STREQUAL Windows) AND CMAKE_CROSSCOMPILING) if((CMAKE_SYSTEM_NAME STREQUAL Windows) AND CMAKE_CROSSCOMPILING)
get_target_property(N2P2_MPI_INCLUDE MPI::MPI_CXX INTERFACE_INCLUDE_DIRECTORIES) 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}) set(MPI_CXX_COMPILER ${CMAKE_CXX_COMPILER})
endif() endif()
if(CMAKE_CXX_COMPILER_ID STREQUAL "Intel") if(CMAKE_CXX_COMPILER_ID STREQUAL "Intel")
get_target_property(N2P2_MPI_INCLUDE MPI::MPI_CXX INTERFACE_INCLUDE_DIRECTORIES) 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}) set(MPI_CXX_COMPILER ${CMAKE_CXX_COMPILER})
endif() endif()
endif() endif()
@ -69,6 +69,12 @@ if(DOWNLOAD_N2P2)
# echo final flag for debugging # echo final flag for debugging
message(STATUS "N2P2 BUILD OPTIONS: ${N2P2_BUILD_OPTIONS}") 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) # download compile n2p2 library. much patch MPI calls in LAMMPS interface to accommodate MPI-2 (e.g. for cross-compiling)
include(ExternalProject) include(ExternalProject)
ExternalProject_Add(n2p2_build ExternalProject_Add(n2p2_build

12
cmake/Modules/Packages/MLIAP.cmake → cmake/Modules/Packages/ML-IAP.cmake
View File

@ -1,4 +1,4 @@
# if PYTHON package is included we may also include Python support in MLIAP # if PYTHON package is included we may also include Python support in ML-IAP
set(MLIAP_ENABLE_PYTHON_DEFAULT OFF) set(MLIAP_ENABLE_PYTHON_DEFAULT OFF)
if(PKG_PYTHON) if(PKG_PYTHON)
find_package(Cythonize QUIET) find_package(Cythonize QUIET)
@ -7,25 +7,25 @@ if(PKG_PYTHON)
endif() endif()
endif() endif()
option(MLIAP_ENABLE_PYTHON "Build MLIAP package with Python support" ${MLIAP_ENABLE_PYTHON_DEFAULT}) option(MLIAP_ENABLE_PYTHON "Build ML-IAP package with Python support" ${MLIAP_ENABLE_PYTHON_DEFAULT})
if(MLIAP_ENABLE_PYTHON) if(MLIAP_ENABLE_PYTHON)
find_package(Cythonize REQUIRED) find_package(Cythonize REQUIRED)
if(NOT PKG_PYTHON) if(NOT PKG_PYTHON)
message(FATAL_ERROR "Must enable PYTHON package for including Python support in MLIAP") message(FATAL_ERROR "Must enable PYTHON package for including Python support in ML-IAP")
endif() endif()
if(CMAKE_VERSION VERSION_LESS 3.12) if(CMAKE_VERSION VERSION_LESS 3.12)
if(PYTHONLIBS_VERSION_STRING VERSION_LESS 3.6) if(PYTHONLIBS_VERSION_STRING VERSION_LESS 3.6)
message(FATAL_ERROR "Python support in MLIAP requires Python 3.6 or later") message(FATAL_ERROR "Python support in ML-IAP requires Python 3.6 or later")
endif() endif()
else() else()
if(Python_VERSION VERSION_LESS 3.6) if(Python_VERSION VERSION_LESS 3.6)
message(FATAL_ERROR "Python support in MLIAP requires Python 3.6 or later") message(FATAL_ERROR "Python support in ML-IAP requires Python 3.6 or later")
endif() endif()
endif() endif()
set(MLIAP_BINARY_DIR ${CMAKE_BINARY_DIR}/cython) set(MLIAP_BINARY_DIR ${CMAKE_BINARY_DIR}/cython)
set(MLIAP_CYTHON_SRC ${LAMMPS_SOURCE_DIR}/MLIAP/mliap_model_python_couple.pyx) set(MLIAP_CYTHON_SRC ${LAMMPS_SOURCE_DIR}/ML-IAP/mliap_model_python_couple.pyx)
get_filename_component(MLIAP_CYTHON_BASE ${MLIAP_CYTHON_SRC} NAME_WE) get_filename_component(MLIAP_CYTHON_BASE ${MLIAP_CYTHON_SRC} NAME_WE)
file(MAKE_DIRECTORY ${MLIAP_BINARY_DIR}) file(MAKE_DIRECTORY ${MLIAP_BINARY_DIR})
add_custom_command(OUTPUT ${MLIAP_BINARY_DIR}/${MLIAP_CYTHON_BASE}.cpp ${MLIAP_BINARY_DIR}/${MLIAP_CYTHON_BASE}.h add_custom_command(OUTPUT ${MLIAP_BINARY_DIR}/${MLIAP_CYTHON_BASE}.cpp ${MLIAP_BINARY_DIR}/${MLIAP_CYTHON_BASE}.h

0
cmake/Modules/Packages/USER-PACE.cmake → cmake/Modules/Packages/ML-PACE.cmake
View File

70
cmake/Modules/Packages/ML-QUIP.cmake Normal file
View File

@ -0,0 +1,70 @@
enable_language(Fortran)
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()

6
cmake/Modules/Packages/USER-MOLFILE.cmake → cmake/Modules/Packages/MOLFILE.cmake
View File

@ -1,5 +1,7 @@
set(MOLFILE_INCLUDE_DIR "${LAMMPS_LIB_SOURCE_DIR}/molfile" CACHE STRING "Path to VMD molfile plugin headers") set(MOLFILE_INCLUDE_DIR "${LAMMPS_LIB_SOURCE_DIR}/molfile" CACHE STRING "Path to VMD molfile plugin headers")
set(MOLFILE_INCLUDE_DIRS "${MOLFILE_INCLUDE_DIR}")
add_library(molfile INTERFACE) add_library(molfile INTERFACE)
target_include_directories(molfile INTERFACE ${MOLFILE_INCLUDE_DIRS}) target_include_directories(molfile INTERFACE ${MOLFILE_INCLUDE_DIR})
if(NOT (CMAKE_SYSTEM_NAME STREQUAL "Windows"))
target_link_libraries(molfile INTERFACE ${CMAKE_DL_LIBS})
endif()
target_link_libraries(lammps PRIVATE molfile) target_link_libraries(lammps PRIVATE molfile)

7
cmake/Modules/Packages/MSCG.cmake
View File

@ -12,6 +12,13 @@ if(DOWNLOAD_MSCG)
mark_as_advanced(MSCG_URL) mark_as_advanced(MSCG_URL)
mark_as_advanced(MSCG_MD5) 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) include(ExternalProject)
ExternalProject_Add(mscg_build ExternalProject_Add(mscg_build
URL ${MSCG_URL} URL ${MSCG_URL}

2
cmake/Modules/Packages/USER-NETCDF.cmake → cmake/Modules/Packages/NETCDF.cmake
View File

@ -1,4 +1,4 @@
# USER-NETCDF can use NetCDF, Parallel NetCDF (PNetCDF), or both. At least one necessary. # NETCDF can use NetCDF, Parallel NetCDF (PNetCDF), or both. At least one necessary.
# NetCDF library enables dump style "netcdf", while PNetCDF enables dump style "netcdf/mpiio" # NetCDF library enables dump style "netcdf", while PNetCDF enables dump style "netcdf/mpiio"
# may use NetCDF or PNetCDF with MPI, but must have NetCDF without # may use NetCDF or PNetCDF with MPI, but must have NetCDF without

40
cmake/Modules/Packages/OPENMP.cmake Normal file
View File

@ -0,0 +1,40 @@
set(OPENMP_SOURCES_DIR ${LAMMPS_SOURCE_DIR}/OPENMP)
set(OPENMP_SOURCES ${OPENMP_SOURCES_DIR}/thr_data.cpp
${OPENMP_SOURCES_DIR}/thr_omp.cpp
${OPENMP_SOURCES_DIR}/fix_omp.cpp
${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_OPENMP)
set_property(GLOBAL PROPERTY "OMP_SOURCES" "${OPENMP_SOURCES}")
# detects styles which have OPENMP version
RegisterStylesExt(${OPENMP_SOURCES_DIR} omp OMP_SOURCES)
RegisterFixStyle(${OPENMP_SOURCES_DIR}/fix_omp.h)
get_property(OPENMP_SOURCES GLOBAL PROPERTY OMP_SOURCES)
# manually add package dependent source files from OPENMP that do not provide styles
if(PKG_ASPHERE)
list(APPEND OPENMP_SOURCES ${OPENMP_SOURCES_DIR}/fix_nh_asphere_omp.cpp)
endif()
if(PKG_RIGID)
list(APPEND OPENMP_SOURCES ${OPENMP_SOURCES_DIR}/fix_rigid_nh_omp.cpp)
endif()
if(PKG_REAXFF)
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})
target_include_directories(lammps PRIVATE ${OPENMP_SOURCES_DIR})

5
cmake/Modules/Packages/USER-PLUMED.cmake → cmake/Modules/Packages/PLUMED.cmake
View File

@ -54,8 +54,8 @@ if(DOWNLOAD_PLUMED)
set(PLUMED_BUILD_BYPRODUCTS "<INSTALL_DIR>/lib/libplumedWrapper.a") set(PLUMED_BUILD_BYPRODUCTS "<INSTALL_DIR>/lib/libplumedWrapper.a")
endif() 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_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 "4eac6a462ec84dfe0cec96c82421b8e8" CACHE STRING "MD5 checksum of PLUMED tarball") set(PLUMED_MD5 "cfa0b4dd90a81c25d3302e8d97bfeaea" CACHE STRING "MD5 checksum of PLUMED tarball")
mark_as_advanced(PLUMED_URL) mark_as_advanced(PLUMED_URL)
mark_as_advanced(PLUMED_MD5) mark_as_advanced(PLUMED_MD5)
@ -72,7 +72,6 @@ if(DOWNLOAD_PLUMED)
${PLUMED_CONFIG_OMP} ${PLUMED_CONFIG_OMP}
CXX=${PLUMED_CONFIG_CXX} CXX=${PLUMED_CONFIG_CXX}
CC=${PLUMED_CONFIG_CC} CC=${PLUMED_CONFIG_CC}
PATCH_COMMAND sed -i "/^#include <algorithm>/a #include <limits>" <SOURCE_DIR>/src/lepton/Operation.h
BUILD_BYPRODUCTS ${PLUMED_BUILD_BYPRODUCTS} BUILD_BYPRODUCTS ${PLUMED_BUILD_BYPRODUCTS}
) )
ExternalProject_get_property(plumed_build INSTALL_DIR) ExternalProject_get_property(plumed_build INSTALL_DIR)

0
cmake/Modules/Packages/USER-QMMM.cmake → cmake/Modules/Packages/QMMM.cmake
View File

5
cmake/Modules/Packages/USER-SCAFACOS.cmake → cmake/Modules/Packages/SCAFACOS.cmake
View File

@ -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 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) 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) include(ExternalProject)
ExternalProject_Add(scafacos_build ExternalProject_Add(scafacos_build
URL ${SCAFACOS_URL} URL ${SCAFACOS_URL}

40
cmake/Modules/Packages/USER-OMP.cmake
View File

@ -1,40 +0,0 @@
set(USER-OMP_SOURCES_DIR ${LAMMPS_SOURCE_DIR}/USER-OMP)
set(USER-OMP_SOURCES ${USER-OMP_SOURCES_DIR}/thr_data.cpp
${USER-OMP_SOURCES_DIR}/thr_omp.cpp
${USER-OMP_SOURCES_DIR}/fix_omp.cpp
${USER-OMP_SOURCES_DIR}/fix_nh_omp.cpp
${USER-OMP_SOURCES_DIR}/fix_nh_sphere_omp.cpp
${USER-OMP_SOURCES_DIR}/domain_omp.cpp)
target_compile_definitions(lammps PRIVATE -DLMP_USER_OMP)
set_property(GLOBAL PROPERTY "OMP_SOURCES" "${USER-OMP_SOURCES}")
# detects styles which have USER-OMP version
RegisterStylesExt(${USER-OMP_SOURCES_DIR} omp OMP_SOURCES)
RegisterFixStyle(${USER-OMP_SOURCES_DIR}/fix_omp.h)
get_property(USER-OMP_SOURCES GLOBAL PROPERTY OMP_SOURCES)
# manually add package dependent source files from USER-OMP that do not provide styles
if(PKG_ASPHERE)
list(APPEND USER-OMP_SOURCES ${USER-OMP_SOURCES_DIR}/fix_nh_asphere_omp.cpp)
endif()
if(PKG_RIGID)
list(APPEND USER-OMP_SOURCES ${USER-OMP_SOURCES_DIR}/fix_rigid_nh_omp.cpp)
endif()
if(PKG_USER-REAXC)
list(APPEND USER-OMP_SOURCES ${USER-OMP_SOURCES_DIR}/reaxc_bond_orders_omp.cpp
${USER-OMP_SOURCES_DIR}/reaxc_hydrogen_bonds_omp.cpp
${USER-OMP_SOURCES_DIR}/reaxc_nonbonded_omp.cpp
${USER-OMP_SOURCES_DIR}/reaxc_bonds_omp.cpp
${USER-OMP_SOURCES_DIR}/reaxc_init_md_omp.cpp
${USER-OMP_SOURCES_DIR}/reaxc_torsion_angles_omp.cpp
${USER-OMP_SOURCES_DIR}/reaxc_forces_omp.cpp
${USER-OMP_SOURCES_DIR}/reaxc_multi_body_omp.cpp
${USER-OMP_SOURCES_DIR}/reaxc_valence_angles_omp.cpp)
endif()
target_sources(lammps PRIVATE ${USER-OMP_SOURCES})
target_include_directories(lammps PRIVATE ${USER-OMP_SOURCES_DIR})

3
cmake/Modules/Packages/USER-QUIP.cmake
View File

@ -1,3 +0,0 @@
enable_language(Fortran)
find_package(QUIP REQUIRED)
target_link_libraries(lammps PRIVATE QUIP::QUIP ${LAPACK_LIBRARIES})

5
cmake/Modules/Packages/VORONOI.cmake
View File

@ -26,6 +26,11 @@ if(DOWNLOAD_VORO)
set(VORO_BUILD_OPTIONS CXX=${CMAKE_CXX_COMPILER} CFLAGS=${VORO_BUILD_CFLAGS}) set(VORO_BUILD_OPTIONS CXX=${CMAKE_CXX_COMPILER} CFLAGS=${VORO_BUILD_CFLAGS})
endif() 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 ExternalProject_Add(voro_build
URL ${VORO_URL} URL ${VORO_URL}
URL_MD5 ${VORO_MD5} URL_MD5 ${VORO_MD5}

0
cmake/Modules/Packages/USER-VTK.cmake → cmake/Modules/Packages/VTK.cmake
View File

10
cmake/Modules/Tools.cmake
View File

@ -9,14 +9,16 @@ if(BUILD_TOOLS)
check_language(Fortran) check_language(Fortran)
if(CMAKE_Fortran_COMPILER) if(CMAKE_Fortran_COMPILER)
enable_language(Fortran) 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}) 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() 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() endif()
else() 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() endif()
enable_language(C) enable_language(C)

25
cmake/iwyu/iwyu-extra-map.imp
View File

@ -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: [ "@<Eigen/.*>", private, "<Eigen/Eigen>", public ] },
{ include: [ "@<gtest/.*>", private, "\"gtest/gtest.h\"", public ] }, { include: [ "@<gtest/.*>", private, "\"gtest/gtest.h\"", public ] },
{ include: [ "@<gmock/.*>", private, "\"gmock/gmock.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 ] },
] ]

103
cmake/presets/all_off.cmake
View File

@ -1,17 +1,96 @@
# preset that turns on all existing packages off. can be used to reset # Preset that turns on all existing packages off. Can be used to reset
# an existing package selection without losing any other settings # an existing package selection without losing any other settings
set(ALL_PACKAGES ASPHERE BODY CLASS2 COLLOID COMPRESS CORESHELL DIPOLE GPU set(ALL_PACKAGES
GRANULAR KIM KOKKOS KSPACE LATTE MANYBODY MC MESSAGE MISC MLIAP MOLECULE ADIOS
MPIIO MSCG OPT PERI PLUGIN POEMS PYTHON QEQ REPLICA RIGID SHOCK SNAP SPIN ASPHERE
SRD VORONOI ATC
USER-ADIOS USER-ATC USER-AWPMD USER-BROWNIAN USER-BOCS USER-CGDNA USER-CGSDK AWPMD
USER-COLVARS USER-DIFFRACTION USER-DPD USER-DRUDE USER-EFF USER-FEP USER-H5MD BOCS
USER-HDNNP USER-INTEL USER-LB USER-MANIFOLD USER-MDI USER-MEAMC USER-MESODPD BODY
USER-MESONT USER-MGPT USER-MISC USER-MOFFF USER-MOLFILE USER-NETCDF USER-OMP BROWNIAN
USER-PACE USER-PHONON USER-PLUMED USER-PTM USER-QMMM USER-QTB USER-QUIP USER-RANN CG-DNA
USER-REACTION USER-REAXC USER-SCAFACOS USER-SDPD USER-SMD USER-SMTBQ USER-SPH CG-SDK
USER-TALLY USER-UEF USER-VTK USER-YAFF USER-DIELECTRIC) CLASS2
COLLOID
COLVARS
COMPRESS
CORESHELL
DIELECTRIC
DIFFRACTION
DIPOLE
DPD-BASIC
DPD-MESO
DPD-REACT
DPD-SMOOTH
DRUDE
EFF
EXTRA-COMPUTE
EXTRA-DUMP
EXTRA-FIX
EXTRA-MOLECULE
EXTRA-PAIR
FEP
GPU
GRANULAR
H5MD
INTEL
INTERLAYER
KIM
KOKKOS
KSPACE
LATBOLTZ
LATTE
MACHDYN
MANIFOLD
MANYBODY
MC
MDI
MEAM
MESONT
MESSAGE
MGPT
MISC
ML-HDNNP
ML-IAP
ML-PACE
ML-QUIP
ML-RANN
ML-SNAP
MOFFF
MOLECULE
MOLFILE
MPIIO
MSCG
NETCDF
OPENMP
OPT
ORIENT
PERI
PHONON
PLUGIN
PLUMED
POEMS
PTM
PYTHON
QEQ
QMMM
QTB
REACTION
REAXFF
REPLICA
RIGID
SCAFACOS
SHOCK
SMTBQ
SPH
SPIN
SRD
TALLY
UEF
VORONOI
VTK
YAFF)
foreach(PKG ${ALL_PACKAGES}) foreach(PKG ${ALL_PACKAGES})
set(PKG_${PKG} OFF CACHE BOOL "" FORCE) set(PKG_${PKG} OFF CACHE BOOL "" FORCE)

107
cmake/presets/all_on.cmake
View File

@ -1,19 +1,98 @@
# preset that turns on all existing packages. using the combination # Preset that turns on all existing packages. Using the combination
# this preset followed by the nolib.cmake preset should configure a # of this preset followed by the nolib.cmake preset should configure
# LAMMPS binary, with as many packages included, that can be compiled # a LAMMPS binary, with as many packages included, that can be compiled
# with just a working C++ compiler and an MPI library. # with just a working C++ compiler and an MPI library.
set(ALL_PACKAGES ASPHERE BODY CLASS2 COLLOID COMPRESS CORESHELL DIPOLE GPU set(ALL_PACKAGES
GRANULAR KIM KOKKOS KSPACE LATTE MANYBODY MC MESSAGE MISC MLIAP MOLECULE ADIOS
MPIIO MSCG OPT PERI PLUGIN POEMS PYTHON QEQ REPLICA RIGID SHOCK SNAP SPIN ASPHERE
SRD VORONOI ATC
USER-ADIOS USER-ATC USER-AWPMD USER-BROWNIAN USER-BOCS USER-CGDNA USER-CGSDK AWPMD
USER-COLVARS USER-DIFFRACTION USER-DPD USER-DRUDE USER-EFF USER-FEP USER-H5MD BOCS
USER-HDNNP USER-INTEL USER-LB USER-MANIFOLD USER-MDI USER-MEAMC USER-MESODPD BODY
USER-MESONT USER-MGPT USER-MISC USER-MOFFF USER-MOLFILE USER-NETCDF USER-OMP BROWNIAN
USER-PACE USER-PHONON USER-PLUMED USER-PTM USER-QMMM USER-QTB USER-QUIP USER-RANN CG-DNA
USER-REACTION USER-REAXC USER-SCAFACOS USER-SDPD USER-SMD USER-SMTBQ USER-SPH CG-SDK
USER-TALLY USER-UEF USER-VTK USER-YAFF USER-DIELECTRIC) CLASS2
COLLOID
COLVARS
COMPRESS
CORESHELL
DIELECTRIC
DIFFRACTION
DIPOLE
DPD-BASIC
DPD-MESO
DPD-REACT
DPD-SMOOTH
DRUDE
EFF
EXTRA-COMPUTE
EXTRA-DUMP
EXTRA-FIX
EXTRA-MOLECULE
EXTRA-PAIR
FEP
GPU
GRANULAR
H5MD
INTEL
INTERLAYER
KIM
KOKKOS
KSPACE
LATBOLTZ
LATTE
MACHDYN
MANIFOLD
MANYBODY
MC
MDI
MEAM
MESONT
MESSAGE
MGPT
MISC
ML-HDNNP
ML-IAP
ML-PACE
ML-QUIP
ML-RANN
ML-SNAP
MOFFF
MOLECULE
MOLFILE
MPIIO
MSCG
NETCDF
OPENMP
OPT
ORIENT
PERI
PHONON
PLUGIN
PLUMED
POEMS
PTM
PYTHON
QEQ
QMMM
QTB
REACTION
REAXFF
REPLICA
RIGID
SCAFACOS
SHOCK
SMTBQ
SPH
SPIN
SRD
TALLY
UEF
VORONOI
VTK
YAFF)
foreach(PKG ${ALL_PACKAGES}) foreach(PKG ${ALL_PACKAGES})
set(PKG_${PKG} ON CACHE BOOL "" FORCE) set(PKG_${PKG} ON CACHE BOOL "" FORCE)

0
cmake/presets/minimal.cmake → cmake/presets/basic.cmake
View File

6
cmake/presets/clang.cmake
View File

@ -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_DEBUG "-Wall -Wextra -g" CACHE STRING "" FORCE)
set(CMAKE_CXX_FLAGS_RELWITHDEBINFO "-Wall -Wextra -g -O2 -DNDEBUG" 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_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_DEBUG "-Wall -Wextra -g -std=f2003" CACHE STRING "" FORCE)
set(CMAKE_Fortran_FLAGS_RELWITHDEBINFO "-Wall -Wextra -g -O2 -DNDEBUG -std=f95" 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=f95" 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_DEBUG "-Wall -Wextra -g" CACHE STRING "" FORCE)
set(CMAKE_C_FLAGS_RELWITHDEBINFO "-Wall -Wextra -g -O2 -DNDEBUG" 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(CMAKE_C_FLAGS_RELEASE "-O3 -DNDEBUG" CACHE STRING "" FORCE)

2
cmake/presets/download.cmake
View File

@ -1,7 +1,7 @@
# Preset that turns on packages with automatic downloads of sources or potentials. # Preset that turns on packages with automatic downloads of sources or potentials.
# Compilation of libraries like Plumed or ScaFaCoS can take a considerable amount of time. # Compilation of libraries like Plumed or ScaFaCoS can take a considerable amount of time.
set(ALL_PACKAGES KIM LATTE MSCG VORONOI USER-PLUMED USER-SCAFACOS USER-SMD USER-MESONT USER-MDI USER-PACE) set(ALL_PACKAGES KIM LATTE MSCG VORONOI PLUMED SCAFACOS MACHDYN MESONT MDI ML-PACE)
foreach(PKG ${ALL_PACKAGES}) foreach(PKG ${ALL_PACKAGES})
set(PKG_${PKG} ON CACHE BOOL "" FORCE) set(PKG_${PKG} ON CACHE BOOL "" FORCE)

18
cmake/presets/gcc.cmake
View File

@ -1,11 +1,23 @@
# 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_CXX_COMPILER "g++" CACHE STRING "" FORCE)
set(CMAKE_C_COMPILER "gcc" CACHE STRING "" FORCE) set(CMAKE_C_COMPILER "gcc" CACHE STRING "" FORCE)
set(CMAKE_CXX_FLAGS_DEBUG "-Wall -Wextra -g" CACHE STRING "" FORCE) set(CMAKE_Fortran_COMPILER "gfortran" CACHE STRING "" FORCE)
set(CMAKE_CXX_FLAGS_RELWITHDEBINFO "-Wall -Wextra -g -O2 -DNDEBUG" CACHE STRING "" FORCE) set(CMAKE_CXX_FLAGS_DEBUG "-Wall -g" CACHE STRING "" FORCE)
set(CMAKE_CXX_FLAGS_RELWITHDEBINFO "-g -O2 -DNDEBUG" CACHE STRING "" FORCE)
set(CMAKE_CXX_FLAGS_RELEASE "-O3 -DNDEBUG" CACHE STRING "" FORCE)
set(MPI_CXX "g++" CACHE STRING "" FORCE) set(MPI_CXX "g++" CACHE STRING "" FORCE)
set(MPI_CXX_COMPILER "mpicxx" CACHE STRING "" FORCE) set(MPI_CXX_COMPILER "mpicxx" CACHE STRING "" FORCE)
set(MPI_C "gcc" CACHE STRING "" FORCE)
set(MPI_C_COMPILER "mpicc" CACHE STRING "" FORCE)
set(CMAKE_C_FLAGS_DEBUG "-Wall -g" CACHE STRING "" FORCE)
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 -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) unset(HAVE_OMP_H_INCLUDE CACHE)
set(OpenMP_C "gcc" CACHE STRING "" FORCE) set(OpenMP_C "gcc" CACHE STRING "" FORCE)

20
cmake/presets/hip.cmake
View File

@ -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_CXX_COMPILER "hipcc" CACHE STRING "" FORCE)
set(CMAKE_C_COMPILER "gcc" 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_DEBUG "-Wall -Wextra -g" CACHE STRING "" FORCE)
set(CMAKE_CXX_FLAGS_RELWITHDEBINFO "-Wall -Wextra -g -O2 -DNDEBUG" 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_FLAGS "-fopenmp" CACHE STRING "" FORCE)
set(OpenMP_CXX "hipcc" CACHE STRING "" FORCE)
set(OpenMP_CXX_LIB_NAMES "omp" CACHE STRING "" FORCE) set(OpenMP_CXX_LIB_NAMES "omp" CACHE STRING "" FORCE)
set(OpenMP_omp_LIBRARY "libomp.so" CACHE PATH "" FORCE) set(OpenMP_omp_LIBRARY "libomp.so" CACHE PATH "" FORCE)

30
cmake/presets/hip_amd.cmake Normal file
View File

@ -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)

85
cmake/presets/mingw-cross.cmake
View File

@ -1,13 +1,76 @@
set(WIN_PACKAGES ASPHERE BODY CLASS2 COLLOID COMPRESS CORESHELL DIPOLE GPU set(WIN_PACKAGES
GRANULAR KSPACE LATTE MANYBODY MC MISC MLIAP MOLECULE OPT ASPHERE
PERI POEMS QEQ REPLICA RIGID SHOCK SNAP SPIN SRD VORONOI ATC
USER-ATC USER-AWPMD USER-BOCS USER-BROWNIAN USER-CGDNA USER-CGSDK AWPMD
USER-COLVARS USER-DIFFRACTION USER-DPD USER-DRUDE USER-EFF USER-FEP BOCS
USER-HDNNP USER-INTEL USER-MANIFOLD USER-MDI USER-MEAMC USER-MESODPD BODY
USER-MESONT USER-MISC USER-MGPT USER-MOFFF USER-MOLFILE USER-OMP BROWNIAN
USER-PHONON USER-PTM USER-QTB USER-REACTION USER-REAXC CG-DNA
USER-SDPD USER-SMD USER-SMTBQ USER-SPH USER-TALLY USER-UEF CG-SDK
USER-YAFF USER-DIELECTRIC) CLASS2
COLLOID
COLVARS
COMPRESS
CORESHELL
DIELECTRIC
DIFFRACTION
DIPOLE
DPD-BASIC
DPD-MESO
DPD-REACT
DPD-SMOOTH
DRUDE
EFF
EXTRA-COMPUTE
EXTRA-DUMP
EXTRA-FIX
EXTRA-MOLECULE
EXTRA-PAIR
FEP
GPU
GRANULAR
INTEL
INTERLAYER
KSPACE
LATTE
MACHDYN
MANIFOLD
MANYBODY
MC
MDI
MEAM
MESONT
MGPT
MISC
ML-HDNNP
ML-IAP
ML-SNAP
ML-RANN
MOFFF
MOLECULE
MOLFILE
OPENMP
OPT
ORIENT
PERI
PHONON
POEMS
PTM
QEQ
QTB
REACTION
REAXFF
REPLICA
RIGID
SHOCK
SMTBQ
SPH
SPIN
SRD
TALLY
UEF
VORONOI
YAFF)
foreach(PKG ${WIN_PACKAGES}) foreach(PKG ${WIN_PACKAGES})
set(PKG_${PKG} ON CACHE BOOL "" FORCE) set(PKG_${PKG} ON CACHE BOOL "" FORCE)
@ -16,7 +79,7 @@ endforeach()
# these two packages require a full MPI implementation # these two packages require a full MPI implementation
if(BUILD_MPI) if(BUILD_MPI)
set(PKG_MPIIO ON CACHE BOOL "" FORCE) set(PKG_MPIIO ON CACHE BOOL "" FORCE)
set(PKG_USER-LB ON CACHE BOOL "" FORCE) set(PKG_LATBOLTZ ON CACHE BOOL "" FORCE)
endif() endif()
set(DOWNLOAD_VORO ON CACHE BOOL "" FORCE) set(DOWNLOAD_VORO ON CACHE BOOL "" FORCE)

67
cmake/presets/most.cmake
View File

@ -2,13 +2,66 @@
# external libraries. Compared to all_on.cmake some more unusual packages # external libraries. Compared to all_on.cmake some more unusual packages
# are removed. The resulting binary should be able to run most inputs. # are removed. The resulting binary should be able to run most inputs.
set(ALL_PACKAGES ASPHERE BODY CLASS2 COLLOID COMPRESS CORESHELL DIPOLE set(ALL_PACKAGES
GRANULAR KSPACE MANYBODY MC MISC MLIAP MOLECULE OPT PERI ASPHERE
PLUGIN POEMS PYTHON QEQ REPLICA RIGID SHOCK SNAP SPIN SRD VORONOI BOCS
USER-BROWNIAN USER-BOCS USER-CGDNA USER-CGSDK USER-COLVARS BODY
USER-DIFFRACTION USER-DPD USER-DRUDE USER-EFF USER-FEP USER-MEAMC BROWNIAN
USER-MESODPD USER-MISC USER-MOFFF USER-OMP USER-PHONON USER-REACTION CG-DNA
USER-REAXC USER-SDPD USER-SPH USER-SMD USER-UEF USER-YAFF USER-DIELECTRIC) CG-SDK
CLASS2
COLLOID
COLVARS
COMPRESS
CORESHELL
DIELECTRIC
DIFFRACTION
DIPOLE
DPD-BASIC
DPD-MESO
DPD-REACT
DPD-SMOOTH
DRUDE
EFF
EXTRA-COMPUTE
EXTRA-DUMP
EXTRA-FIX
EXTRA-MOLECULE
EXTRA-PAIR
FEP
GRANULAR
INTERLAYER
KSPACE
MACHDYN
MANYBODY
MC
MEAM
MISC
ML-IAP
ML-SNAP
MOFFF
MOLECULE
OPENMP
OPT
ORIENT
PERI
PHONON
PLUGIN
POEMS
PYTHON
QEQ
REACTION
REAXFF
REPLICA
RIGID
SHOCK
SPH
SPIN
SRD
TALLY
UEF
VORONOI
YAFF)
foreach(PKG ${ALL_PACKAGES}) foreach(PKG ${ALL_PACKAGES})
set(PKG_${PKG} ON CACHE BOOL "" FORCE) set(PKG_${PKG} ON CACHE BOOL "" FORCE)

33
cmake/presets/nolib.cmake
View File

@ -1,11 +1,34 @@
# preset that turns off all packages that require some form of external # preset that turns off all packages that require some form of external
# library or special compiler (fortran or cuda) or equivalent. # library or special compiler (fortran or cuda) or equivalent.
set(PACKAGES_WITH_LIB COMPRESS GPU KIM KOKKOS LATTE MESSAGE MPIIO MSCG set(PACKAGES_WITH_LIB
PYTHON VORONOI ADIOS
USER-ADIOS USER-ATC USER-AWPMD USER-H5MD USER-HDNNP USER-LB USER-MOLFILE ATC
USER-MESONT USER-MDI USER-NETCDF USER-PACE USER-PLUMED USER-QMMM USER-QUIP AWPMD
USER-SCAFACOS USER-SMD USER-VTK) COMPRESS
GPU
H5MD
KIM
KOKKOS
LATBOLTZ
LATTE
MACHDYN
MDI
MESONT
MESSAGE
ML-HDNNP
ML-PACE
ML-QUIP
MOLFILE
MPIIO
MSCG
NETCDF
PLUMED
PYTHON
QMMM
SCAFACOS
VORONOI
VTK)
foreach(PKG ${PACKAGES_WITH_LIB}) foreach(PKG ${PACKAGES_WITH_LIB})
set(PKG_${PKG} OFF CACHE BOOL "" FORCE) set(PKG_${PKG} OFF CACHE BOOL "" FORCE)

26
cmake/presets/pedantic.cmake Normal file
View File

@ -0,0 +1,26 @@
# preset that will restore gcc/g++ with support for MPI and OpenMP (on Linux boxes)
set(CMAKE_CXX_COMPILER "g++" 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 -Werror=vla -Wno-maybe-uninitialized -g" CACHE STRING "" FORCE)
set(CMAKE_CXX_FLAGS_RELWITHDEBINFO "-Wall -Wextra -Werror=vla -Wno-maybe-uninitialized -g -O2 -DNDEBUG" CACHE STRING "" FORCE)
set(CMAKE_CXX_FLAGS_RELEASE "-Wall -O3 -DNDEBUG" CACHE STRING "" FORCE)
set(MPI_CXX "g++" CACHE STRING "" FORCE)
set(MPI_CXX_COMPILER "mpicxx" CACHE STRING "" FORCE)
set(MPI_C "gcc" CACHE STRING "" FORCE)
set(MPI_C_COMPILER "mpicc" CACHE STRING "" FORCE)
set(CMAKE_C_FLAGS_DEBUG "-Wall -Wextra -Wno-maybe-uninitialized -g" CACHE STRING "" FORCE)
set(CMAKE_C_FLAGS_RELWITHDEBINFO "-Wall -Wextra -Wno-maybe-uninitialized -g -O2 -DNDEBUG" CACHE STRING "" FORCE)
set(CMAKE_C_FLAGS_RELEASE "-Wall -O3 -DNDEBUG" CACHE STRING "" FORCE)
set(MPI_Fortran "gfortran" CACHE STRING "" FORCE)
set(MPI_Fortran_COMPILER "mpifort" 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 "g++" CACHE STRING "" FORCE)
set(OpenMP_CXX_FLAGS "-fopenmp" CACHE STRING "" FORCE)
set(OpenMP_CXX_LIB_NAMES "gomp" CACHE STRING "" FORCE)
set(OpenMP_omp_LIBRARY "libgomp.so" CACHE PATH "" FORCE)

2
doc/Makefile
View File

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

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

@ -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 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 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 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 ## 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 In the interest of consistency, ONLY ONE of the core LAMMPS developers
should doing the merging itself. This is currently should doing the merging itself. This is currently
[@akohlmey](https://github.com/akohlmey) (Axel Kohlmeyer). [@akohlmey](https://github.com/akohlmey) (Axel Kohlmeyer). If this
If this assignment needs to be changed, it shall be done right after a assignment needs to be changed, it shall be done right after a stable
stable release. If the currently assigned developer cannot merge outstanding pull release. If the currently assigned developer cannot merge outstanding
requests in a timely manner, or in other extenuating circumstances, pull requests in a timely manner, or in other extenuating circumstances,
other core LAMMPS developers with merge rights can merge pull requests, other core LAMMPS developers with merge rights can merge pull requests,
when necessary. 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 them. Even though, all LAMMPS developers may have write access to pull
requests (if enabled by the submitter, which is the default), only the 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 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 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 next, e.g. whether it should be assigned to a different developer for
additional checks and changes, or is recommended to be merged. Removing additional checks and changes, or is recommended to be merged. Removing
the `work_in_progress` label and assigning the pull request to the 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 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 ### 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 discussions, that are centered on tools or policies themselves
(git, GitHub, c++) rather than on the content of the pull request. (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 ## GitHub Issues
The GitHub issue tracker is the location where the LAMMPS developers The GitHub issue tracker is the location where the LAMMPS developers
and other contributors or LAMMPS users can report issues or bugs with and other contributors or LAMMPS users can report issues or bugs with
the LAMMPS code or request new features to be added. Feature requests the LAMMPS code or request new features to be added. Bug reports have
are usually indicated by a `[Feature Request]` marker in the subject. a `[Bug]` marker in the subject line; suggestions for changes or
Issues are assigned to a person, if this person is working on this adding new functionality are indicated by a `[Feature Request]`
feature or working to resolve an issue. Issues that have nobody working marker in the subject. This is automatically done when using the
on them at the moment, have the label `volunteer needed` attached. 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, When an issue, say `#125` is resolved by a specific pull request,
the comment for the pull request shall contain the text `closes #125` the comment for the pull request shall contain the text `closes #125`
or `fixes #125`, so that the issue is automatically deleted when 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 ## Milestones and Release Planning
LAMMPS uses a continuous release development model with incremental LAMMPS uses a continuous release development model with incremental
changes, i.e. significant effort is made - including automated pre-merge changes, i.e. significant effort is made - including automated pre-merge
testing - that the code in the branch "master" does not get broken. testing - that the code in the branch "master" does not get easily
More extensive testing (including regression testing) is performed after broken. These tests are run after every update to a pull request. More
code is merged to the "master" branch. There are patch releases of extensive and time consuming tests (including regression testing) are
LAMMPS every 1-3 weeks at a point, when the LAMMPS developers feel, that performed after code is merged to the "master" branch. There are patch
a sufficient amount of changes have happened, and the post-merge testing releases of LAMMPS every 3-5 weeks at a point, when the LAMMPS
has been successful. These patch releases are marked with a developers feel, that a sufficient amount of changes have happened, and
`patch_<version date>` tag and the "unstable" branch follows only these the post-merge testing has been successful. These patch releases are
versions (and thus is always supposed to be of production quality, marked with a `patch_<version date>` tag and the "unstable" branch
unlike "master", which may be temporary broken, in the case of larger follows only these versions (and thus is always supposed to be of
change sets or unexpected incompatibilities or side effects. 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 About 1-2 times each year, there are going to be "stable" releases of
of LAMMPS. These have seen additional, manual testing and review of LAMMPS. These have seen additional, manual testing and review of
results from testing with instrumented code and static code analysis. results from testing with instrumented code and static code analysis.
Also, in the last 2-3 patch releases before a stable release are Also, the last 1-3 patch releases before a stable release are "release
"release candidate" versions which only contain bugfixes and candidate" versions which only contain bugfixes and documentation
documentation updates. For release planning and the information of updates. For release planning and the information of code contributors,
code contributors, issues and pull requests being actively worked on issues and pull requests being actively worked on are assigned a
are assigned a "milestone", which corresponds to the next stable "milestone", which corresponds to the next stable release or the stable
release or the stable release after that, with a tentative release release after that, with a tentative release date.
date.

128
doc/include-file-conventions.md
View File

@ -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 USER-REAXC, or the USER-ATC package. The LAMMPS
developers are dedicated to make an effort to improve the compliance
and welcome volunteers wanting to help with the process.

55
doc/lammps.1
View File

@ -1,4 +1,4 @@
.TH LAMMPS "27 May 2021" "2021-05-27" .TH LAMMPS "29 September 2021" "2021-09-29"
.SH NAME .SH NAME
.B LAMMPS .B LAMMPS
\- Molecular Dynamics Simulator. \- Molecular Dynamics Simulator.
@ -54,7 +54,7 @@ using
this <machine name> parameter can be chosen arbitrarily at configuration this <machine name> parameter can be chosen arbitrarily at configuration
time, but more common is to just use time, but more common is to just use
.B lmp .B lmp
without a suffix. In this manpage we will use without a suffix. In this man page we will use
.B lmp .B lmp
to represent any of those names. 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 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 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 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 .TP
\fB\-l <log file>\fR or \fB\-log <log file>\fR \fB\-l <log file>\fR or \fB\-log <log file>\fR
Specify a log file for LAMMPS to write status information to. 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 .B LAMMPS
can act as either a client or server (or both). can act as either a client or server (or both).
.TP .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 \fB\-nc\fR or \fB\-nocite\fR
Disable writing the "log.cite" file which is normally written to Disable writing the "log.cite" file which is normally written to
list references for specific cite-able features used during a list references for specific cite-able features used during a
@ -135,7 +167,7 @@ For example "-pk gpu 2" is the same as "package gpu 2" in the input
script. The possible styles and options are discussed in the script. The possible styles and options are discussed in the
.B LAMMPS .B LAMMPS
manual for the "package" command. This switch can be used multiple manual for the "package" command. This switch can be used multiple
times, e.g. to set options for the USER-INTEL and USER-OMP packages times, e.g. to set options for the INTEL and OPENMP packages
when used together. Along with the "-sf" or "-suffix" switch, this when used together. Along with the "-sf" or "-suffix" switch, this
is a convenient mechanism for invoking accelerator packages and their is a convenient mechanism for invoking accelerator packages and their
options without having to edit an input script. options without having to edit an input script.
@ -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 "-package" command-line switch, this is a convenient mechanism for
invoking styles from accelerator packages and setting their options invoking styles from accelerator packages and setting their options
without having to edit an input script. 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. details and discussions on command-line options.
.SH LAMMPS BASICS .SH LAMMPS BASICS
@ -254,7 +297,7 @@ the chapter on errors in the
manual gives some additional information about error messages, if possible. manual gives some additional information about error messages, if possible.
.SH COPYRIGHT .SH COPYRIGHT
© 2003--2020 Sandia Corporation © 2003--2021 Sandia Corporation
This package is free software; you can redistribute it and/or modify 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 it under the terms of the GNU General Public License version 2 as

2
doc/msi2lmp.1
View File

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

4
doc/src/Bibliography.rst
View File

@ -191,7 +191,7 @@ Bibliography
A.\ Calhoun, M. Pavese, G. Voth, Chem Phys Letters, 262, 415 (1996). A.\ Calhoun, M. Pavese, G. Voth, Chem Phys Letters, 262, 415 (1996).
**(Campana)** **(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)** **(Cao1)**
J.\ Cao and B. Berne, J Chem Phys, 99, 2902 (1993). 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). Morris, Fox, Zhu, J Comp Physics, 136, 214-226 (1997).
**(Moustafa)** **(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-Plathe1)**
Muller-Plathe, J Chem Phys, 106, 6082 (1997). Muller-Plathe, J Chem Phys, 106, 6082 (1997).

1
doc/src/Build.rst
View File

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

22
doc/src/Build_basics.rst
View File

@ -90,7 +90,7 @@ standard. A more detailed discussion of that is below.
directory, or ``make`` from the ``src/STUBS`` dir. If the build directory, or ``make`` from the ``src/STUBS`` dir. If the build
fails, you may need to edit the ``STUBS/Makefile`` for your fails, you may need to edit the ``STUBS/Makefile`` for your
platform. The stubs library does not provide MPI/IO functions platform. The stubs library does not provide MPI/IO functions
required by some LAMMPS packages, e.g. ``MPIIO`` or ``USER-LB``, required by some LAMMPS packages, e.g. ``MPIIO`` or ``LATBOLTZ``,
and thus is not compatible with those packages. and thus is not compatible with those packages.
.. note:: .. note::
@ -120,19 +120,19 @@ self-installed MPICH or OpenMPI, so you should study the provided
documentation to find out how to build and link with it. documentation to find out how to build and link with it.
The majority of OpenMP (threading) support in LAMMPS is provided by the The majority of OpenMP (threading) support in LAMMPS is provided by the
``USER-OMP`` package; see the :doc:`Speed_omp` ``OPENMP`` package; see the :doc:`Speed_omp`
page for details. The ``USER-INTEL`` package also includes OpenMP page for details. The ``INTEL`` package also includes OpenMP
threading (it is compatible with ``USER-OMP`` and will usually fall threading (it is compatible with ``OPENMP`` and will usually fall
back on styles from that package, if a ``USER-INTEL`` does not exist) back on styles from that package, if a ``INTEL`` does not exist)
and adds vectorization support when compiled with compatible compilers, and adds vectorization support when compiled with compatible compilers,
in particular the Intel compilers on top of OpenMP. Also, the ``KOKKOS`` in particular the Intel compilers on top of OpenMP. Also, the ``KOKKOS``
package can be compiled to include OpenMP threading. package can be compiled to include OpenMP threading.
In addition, there are a few commands in LAMMPS that have native OpenMP In addition, there are a few commands in LAMMPS that have native OpenMP
support included as well. These are commands in the ``MPIIO``, support included as well. These are commands in the ``MPIIO``,
``SNAP``, ``USER-DIFFRACTION``, and ``USER-DPD`` packages. In addition ``ML-SNAP``, ``DIFFRACTION``, and ``DPD-REACT`` packages. In addition
some packages support OpenMP threading indirectly through the libraries some packages support OpenMP threading indirectly through the libraries
they interface to: e.g. ``LATTE``, ``KSPACE``, and ``USER-COLVARS``. they interface to: e.g. ``LATTE``, ``KSPACE``, and ``COLVARS``.
See the :doc:`Packages details <Packages_details>` page for more See the :doc:`Packages details <Packages_details>` page for more
info on these packages and the pages for their respective commands info on these packages and the pages for their respective commands
for OpenMP threading info. for OpenMP threading info.
@ -176,7 +176,7 @@ performance. Vendor provided compilers for a specific hardware can
produce faster code than open-source compilers like the GNU compilers. produce faster code than open-source compilers like the GNU compilers.
On the most common x86 hardware most popular C++ compilers are quite On the most common x86 hardware most popular C++ compilers are quite
similar in performance of C/C++ code at high optimization levels. When similar in performance of C/C++ code at high optimization levels. When
using the ``USER-INTEL`` package, there is a distinct advantage in using using the ``INTEL`` package, there is a distinct advantage in using
the `Intel C++ compiler <intel_>`_ due to much improved vectorization the `Intel C++ compiler <intel_>`_ due to much improved vectorization
through SSE and AVX instructions on compatible hardware as the source through SSE and AVX instructions on compatible hardware as the source
code includes changes and Intel compiler specific directives to enable code includes changes and Intel compiler specific directives to enable
@ -325,9 +325,9 @@ LAMMPS.
.. code-block:: bash .. code-block:: bash
Makefile.opt # OPT package Makefile.opt # OPT package
Makefile.omp # USER-OMP package Makefile.omp # OPENMP package
Makefile.intel_cpu # USER-INTEL package for CPUs Makefile.intel_cpu # INTEL package for CPUs
Makefile.intel_coprocessor # USER-INTEL package for KNLs Makefile.intel_coprocessor # INTEL package for KNLs
Makefile.gpu # GPU package Makefile.gpu # GPU package
Makefile.kokkos_cuda_mpi # KOKKOS package for GPUs Makefile.kokkos_cuda_mpi # KOKKOS package for GPUs
Makefile.kokkos_omp # KOKKOS package for CPUs (OpenMP) Makefile.kokkos_omp # KOKKOS package for CPUs (OpenMP)

2
doc/src/Build_cmake.rst
View File

@ -140,7 +140,7 @@ can be used several times in one command.
For your convenience we provide :ref:`CMake presets <cmake_presets>` For your convenience we provide :ref:`CMake presets <cmake_presets>`
that combine multiple settings to enable optional LAMMPS packages or use that combine multiple settings to enable optional LAMMPS packages or use
a different compiler tool chain. Those are loaded with the *-C* flag a different compiler tool chain. Those are loaded with the *-C* flag
(``-C ../cmake/presets/minimal.cmake``). This step would only be needed (``-C ../cmake/presets/basic.cmake``). This step would only be needed
once, as the settings from the preset files are stored in the once, as the settings from the preset files are stored in the
``CMakeCache.txt`` file. It is also possible to customize the build ``CMakeCache.txt`` file. It is also possible to customize the build
by adding one or more *-D* flags to the CMake command line. by adding one or more *-D* flags to the CMake command line.

97
doc/src/Build_development.rst
View File

@ -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. useful during development, testing or debugging.
---------- ----------
.. _compilation: .. _compilation:
Monitor compilation flags Monitor compilation flags (CMake only)
------------------------- --------------------------------------
Sometimes it is necessary to verify the complete sequence of compilation flags Sometimes it is necessary to verify the complete sequence of compilation flags
generated by the CMake build. To enable a more verbose output during generated by the CMake build. To enable a more verbose output during
@ -30,8 +30,8 @@ variable VERBOSE set to 1:
.. _clang-tidy: .. _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 The `clang-tidy tool <https://clang.llvm.org/extra/clang-tidy/>`_ is a
static code analysis tool to diagnose (and potentially fix) typical static code analysis tool to diagnose (and potentially fix) typical
@ -52,20 +52,22 @@ significantly more time consuming than the compilation itself.
.. _iwyu_processing: .. _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 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>`_ LAMMPS are documented in :doc:`Modify_style`. To assist with following
(also included in the source code distribution). To assist with following
these conventions one can use the `Include What You Use tool <https://include-what-you-use.org/>`_. 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. 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 It is recommended to use at least version 0.16, which has much fewer incorrect
reports than earlier versions. 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 The necessary steps to generate the report can be enabled via a CMake variable
CMake variable: during CMake configuration.
.. code-block:: bash .. code-block:: bash
@ -86,8 +88,8 @@ on recording all commands required to do the compilation.
.. _sanitizer: .. _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 Compilers such as GCC and Clang support generating instrumented binaries
which use different sanitizer libraries to detect problems in the code 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: .. _testing:
Code Coverage and Unit Testing Code Coverage and Unit Testing (CMake only)
------------------------------ -------------------------------------------
The LAMMPS code is subject to multiple levels of automated testing The LAMMPS code is subject to multiple levels of automated testing
during development: integration testing (i.e. whether the code compiles during development: integration testing (i.e. whether the code compiles
@ -310,7 +312,7 @@ and working.
parameter needs to be adjusted. Typically a value around 1.0e-13 parameter needs to be adjusted. Typically a value around 1.0e-13
can be used, but it may need to be as large as 1.0e-8 in some can be used, but it may need to be as large as 1.0e-8 in some
cases. cases.
- The tests for pair styles from OPT, USER-OMP and USER-INTEL are - The tests for pair styles from OPT, OPENMP and INTEL are
performed with automatically rescaled epsilon to account for performed with automatically rescaled epsilon to account for
additional loss of precision from code optimizations and different additional loss of precision from code optimizations and different
summation orders. summation orders.
@ -345,7 +347,7 @@ and compared. If the fix is a thermostat and thus the internal property
``t_target`` can be extracted, then this is compared to the reference ``t_target`` can be extracted, then this is compared to the reference
data. The tests are repeated with the respa run style. data. The tests are repeated with the respa run style.
If the fix has a multi-threaded version in the USER-OMP package, then If the fix has a multi-threaded version in the OPENMP package, then
the entire set of tests is repeated for that version as well. the entire set of tests is repeated for that version as well.
For this to work, some additional conditions have to be met by the For this to work, some additional conditions have to be met by the
@ -464,7 +466,8 @@ Coding style utilities
To aid with enforcing some of the coding style conventions in LAMMPS To aid with enforcing some of the coding style conventions in LAMMPS
some additional build targets have been added. These require Python 3.5 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. The following options are available.
.. code-block:: bash .. code-block:: bash
@ -476,17 +479,43 @@ The following options are available.
make check-permissions # search for files with permissions issues make check-permissions # search for files with permissions issues
make fix-permissions # correct permissions issues in files 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 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 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 code formatting style. The `clang-format` command bundled with Clang
or later is required. The configuration is in files ``.clang-format`` version 8.0 or later is required. The configuration is in files called
in the respective folders. Since the modifications from `clang-format` ``.clang-format`` in the respective folders. Since the modifications
can be significant and - especially for "legacy style code" - also is from `clang-format` can be significant and - especially for "legacy
not always improving readability, a large number of files currently have style code" - they are not always improving readability, a large number
a ``// clang-format off`` at the top, which will disable the processing. of files currently have a ``// clang-format off`` at the top, which will
Over time, files will be refactored and updated to that `clang-format` disable the processing. As of fall 2021 all files have been either
may be applied to them (at least in part). "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`` It is recommended for all newly contributed files to use the clang-format
tree can be updated to conform to the formatting settings using processing while writing the code or do the coding style processing
``make format-tests`` and the files in ``src`` with ``make format-src``. (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

45
doc/src/Build_diskspace.rst Normal file
View File

@ -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.

252
doc/src/Build_extras.rst
View File

@ -31,37 +31,37 @@ This is the list of packages that may require additional steps.
.. table_from_list:: .. table_from_list::
:columns: 6 :columns: 6
* :ref:`ADIOS <adios>`
* :ref:`ATC <atc>`
* :ref:`AWPMD <awpmd>`
* :ref:`COLVARS <colvars>`
* :ref:`COMPRESS <compress>` * :ref:`COMPRESS <compress>`
* :ref:`GPU <gpu>` * :ref:`GPU <gpu>`
* :ref:`H5MD <h5md>`
* :ref:`INTEL <intel>`
* :ref:`KIM <kim>` * :ref:`KIM <kim>`
* :ref:`KOKKOS <kokkos>` * :ref:`KOKKOS <kokkos>`
* :ref:`LATTE <latte>` * :ref:`LATTE <latte>`
* :ref:`MACHDYN <machdyn>`
* :ref:`MDI <mdi>`
* :ref:`MESONT <mesont>`
* :ref:`MESSAGE <message>` * :ref:`MESSAGE <message>`
* :ref:`MLIAP <mliap>` * :ref:`ML-HDNNP <ml-hdnnp>`
* :ref:`ML-IAP <mliap>`
* :ref:`ML-PACE <ml-pace>`
* :ref:`ML-QUIP <ml-quip>`
* :ref:`MOLFILE <molfile>`
* :ref:`MSCG <mscg>` * :ref:`MSCG <mscg>`
* :ref:`NETCDF <netcdf>`
* :ref:`OPENMP <openmp>`
* :ref:`OPT <opt>` * :ref:`OPT <opt>`
* :ref:`PLUMED <plumed>`
* :ref:`POEMS <poems>` * :ref:`POEMS <poems>`
* :ref:`PYTHON <python>` * :ref:`PYTHON <python>`
* :ref:`QMMM <qmmm>`
* :ref:`SCAFACOS <scafacos>`
* :ref:`VORONOI <voronoi>` * :ref:`VORONOI <voronoi>`
* :ref:`USER-ADIOS <user-adios>` * :ref:`VTK <vtk>`
* :ref:`USER-ATC <user-atc>`
* :ref:`USER-AWPMD <user-awpmd>`
* :ref:`USER-COLVARS <user-colvars>`
* :ref:`USER-H5MD <user-h5md>`
* :ref:`USER-HDNNP <user-hdnnp>`
* :ref:`USER-INTEL <user-intel>`
* :ref:`USER-MDI <user-mdi>`
* :ref:`USER-MESONT <user-mesont>`
* :ref:`USER-MOLFILE <user-molfile>`
* :ref:`USER-NETCDF <user-netcdf>`
* :ref:`USER-PACE <user-pace>`
* :ref:`USER-PLUMED <user-plumed>`
* :ref:`USER-OMP <user-omp>`
* :ref:`USER-QMMM <user-qmmm>`
* :ref:`USER-QUIP <user-quip>`
* :ref:`USER-SCAFACOS <user-scafacos>`
* :ref:`USER-SMD <user-smd>`
* :ref:`USER-VTK <user-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 <https://zlib.net>`_ available on your system to build dump styles with
a '/gz' suffix. There are also styles using the a '/gz' suffix. There are also styles using the
`Zstandard <https://facebook.github.io/zstd/>`_ library which have a `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:: .. tabs::
@ -622,7 +623,7 @@ This list was last updated for version 3.4.1 of the Kokkos library.
mkdir build-kokkos-cuda mkdir build-kokkos-cuda
cd build-kokkos-cuda cd build-kokkos-cuda
cmake -C ../cmake/presets/minimal.cmake -C ../cmake/presets/kokkos-cuda.cmake ../cmake cmake -C ../cmake/presets/basic.cmake -C ../cmake/presets/kokkos-cuda.cmake ../cmake
cmake --build . cmake --build .
.. tab:: Basic traditional make settings: .. tab:: Basic traditional make settings:
@ -811,16 +812,17 @@ be installed on your system.
.. _mliap: .. _mliap:
MLIAP package ML-IAP package
--------------------------- ---------------------------
Building the MLIAP package requires including the :ref:`SNAP <PKG-SNAP>` Building the ML-IAP package requires including the :ref:`ML-SNAP
package. There will be an error message if this requirement is not satisfied. <PKG-ML-SNAP>` package. There will be an error message if this requirement
Using the *mliappy* model also requires enabling Python support, which is not satisfied. Using the *mliappy* model also requires enabling
in turn requires the :ref:`PYTHON <PKG-PYTHON>` Python support, which in turn requires to include the :ref:`PYTHON
package **and** requires you have the `cython <https://cython.org>`_ software <PKG-PYTHON>` package **and** requires to have the `cython
installed and with it a working ``cythonize`` command. This feature requires <https://cython.org>`_ software installed and with it a working
compiling LAMMPS with Python version 3.6 or later. ``cythonize`` command. This feature requires compiling LAMMPS with
Python version 3.6 or later.
.. tabs:: .. tabs::
@ -834,9 +836,9 @@ compiling LAMMPS with Python version 3.6 or later.
suitable Python version and the ``cythonize`` command and choose suitable Python version and the ``cythonize`` command and choose
the default accordingly. During the build procedure the provided the default accordingly. During the build procedure the provided
.pyx file(s) will be automatically translated to C++ code and compiled. .pyx file(s) will be automatically translated to C++ code and compiled.
Please do **not** run ``cythonize`` manually in the ``src/MLIAP`` folder, Please do **not** run ``cythonize`` manually in the ``src/ML-IAP`` folder,
as that can lead to compilation errors if Python support is not enabled. as that can lead to compilation errors if Python support is not enabled.
If you did by accident, please remove the generated .cpp and .h files. If you did it by accident, please remove the generated .cpp and .h files.
.. tab:: Traditional make .. tab:: Traditional make
@ -845,15 +847,16 @@ compiling LAMMPS with Python version 3.6 or later.
the ``cythonize`` command in case the corresponding .pyx file(s) were the ``cythonize`` command in case the corresponding .pyx file(s) were
modified. You may need to modify ``lib/python/Makefile.lammps`` modified. You may need to modify ``lib/python/Makefile.lammps``
if the LAMMPS build fails. if the LAMMPS build fails.
To manually enforce building MLIAP with Python support enabled,
you can add To enable building the ML-IAP package with Python support enabled,
``-DMLIAP_PYTHON`` to the ``LMP_INC`` variable in your machine makefile. you need to add ``-DMLIAP_PYTHON`` to the ``LMP_INC`` variable in
You may have to manually run the ``cythonize`` command on .pyx file(s) your machine makefile. You may have to manually run the
in the ``src`` folder, if this is not automatically done during ``cythonize`` command on .pyx file(s) in the ``src`` folder, if
installing the MLIAP package. Please do **not** run ``cythonize`` this is not automatically done during installing the ML-IAP
in the ``src/MLIAP`` folder, as that can lead to compilation errors package. Please do **not** run ``cythonize`` in the ``src/ML-IAP``
if Python support is not enabled. folder, as that can lead to compilation errors if Python support
If you did by accident, please remove the generated .cpp and .h files. is not enabled. If you did this by accident, please remove the
generated .cpp and .h files.
---------- ----------
@ -1054,12 +1057,12 @@ binary package provided by your operating system.
---------- ----------
.. _user-adios: .. _adios:
USER-ADIOS package ADIOS package
----------------------------------- -----------------------------------
The USER-ADIOS package requires the `ADIOS I/O library The ADIOS package requires the `ADIOS I/O library
<https://github.com/ornladios/ADIOS2>`_, version 2.3.1 or newer. Make <https://github.com/ornladios/ADIOS2>`_, version 2.3.1 or newer. Make
sure that you have ADIOS built either with or without MPI to match if sure that you have ADIOS built either with or without MPI to match if
you build LAMMPS with or without MPI. ADIOS compilation settings for you build LAMMPS with or without MPI. ADIOS compilation settings for
@ -1075,38 +1078,38 @@ systems.
.. code-block:: bash .. code-block:: bash
-D ADIOS2_DIR=path # path is where ADIOS 2.x is installed -D ADIOS2_DIR=path # path is where ADIOS 2.x is installed
-D PKG_USER-ADIOS=yes -D PKG_ADIOS=yes
.. tab:: Traditional make .. tab:: Traditional make
Turn on the USER-ADIOS package before building LAMMPS. If the Turn on the ADIOS package before building LAMMPS. If the
ADIOS 2.x software is installed in PATH, there is nothing else to ADIOS 2.x software is installed in PATH, there is nothing else to
do: do:
.. code-block:: bash .. code-block:: bash
$ make yes-user-adios $ make yes-adios
otherwise, set ADIOS2_DIR environment variable when turning on the package: otherwise, set ADIOS2_DIR environment variable when turning on the package:
.. code-block:: bash .. code-block:: bash
$ ADIOS2_DIR=path make yes-user-adios # path is where ADIOS 2.x is installed $ ADIOS2_DIR=path make yes-adios # path is where ADIOS 2.x is installed
---------- ----------
.. _user-atc: .. _atc:
USER-ATC package ATC package
------------------------------- -------------------------------
The USER-ATC package requires the MANYBODY package also be installed. The ATC package requires the MANYBODY package also be installed.
.. tabs:: .. tabs::
.. tab:: CMake build .. tab:: CMake build
No additional settings are needed besides ``-D PKG_USER-ATC=yes`` No additional settings are needed besides ``-D PKG_ATC=yes``
and ``-D PKG_MANYBODY=yes``. and ``-D PKG_MANYBODY=yes``.
.. tab:: Traditional make .. tab:: Traditional make
@ -1149,16 +1152,16 @@ The USER-ATC package requires the MANYBODY package also be installed.
---------- ----------
.. _user-awpmd: .. _awpmd:
USER-AWPMD package AWPMD package
------------------ ------------------
.. tabs:: .. tabs::
.. tab:: CMake build .. tab:: CMake build
No additional settings are needed besides ``-D PKG_USER-AQPMD=yes``. No additional settings are needed besides ``-D PKG_AQPMD=yes``.
.. tab:: Traditional make .. tab:: Traditional make
@ -1200,9 +1203,9 @@ USER-AWPMD package
---------- ----------
.. _user-colvars: .. _colvars:
USER-COLVARS package COLVARS package
--------------------------------------- ---------------------------------------
This package includes the `Colvars library This package includes the `Colvars library
@ -1216,7 +1219,7 @@ be built for the most part with all major versions of the C++ language.
This is the recommended build procedure for using Colvars in This is the recommended build procedure for using Colvars in
LAMMPS. No additional settings are normally needed besides LAMMPS. No additional settings are normally needed besides
``-D PKG_USER-COLVARS=yes``. ``-D PKG_COLVARS=yes``.
.. tab:: Traditional make .. tab:: Traditional make
@ -1259,9 +1262,9 @@ be built for the most part with all major versions of the C++ language.
---------- ----------
.. _user-pace: .. _ml-pace:
USER-PACE package ML-PACE package
----------------------------- -----------------------------
This package requires a library that can be downloaded and built This package requires a library that can be downloaded and built
@ -1274,8 +1277,8 @@ at: `https://github.com/ICAMS/lammps-user-pace/ <https://github.com/ICAMS/lammps
.. tab:: CMake build .. tab:: CMake build
By default the library will be downloaded from the git repository By default the library will be downloaded from the git repository
and built automatically when the USER-PACE package is enabled with and built automatically when the ML-PACE package is enabled with
``-D PKG_USER-PACE=yes``. The location for the sources may be ``-D PKG_ML-PACE=yes``. The location for the sources may be
customized by setting the variable ``PACELIB_URL`` when customized by setting the variable ``PACELIB_URL`` when
configuring with CMake (e.g. to use a local archive on machines configuring with CMake (e.g. to use a local archive on machines
without internet access). Since CMake checks the validity of the without internet access). Since CMake checks the validity of the
@ -1286,7 +1289,7 @@ at: `https://github.com/ICAMS/lammps-user-pace/ <https://github.com/ICAMS/lammps
.. tab:: Traditional make .. tab:: Traditional make
You can download and build the USER-PACE library You can download and build the ML-PACE library
in one step from the ``lammps/src`` dir, using these commands, in one step from the ``lammps/src`` dir, using these commands,
which invoke the ``lib/pace/Install.py`` script. which invoke the ``lib/pace/Install.py`` script.
@ -1299,9 +1302,9 @@ at: `https://github.com/ICAMS/lammps-user-pace/ <https://github.com/ICAMS/lammps
---------- ----------
.. _user-plumed: .. _plumed:
USER-PLUMED package PLUMED package
------------------------------------- -------------------------------------
.. _plumedinstall: https://plumed.github.io/doc-master/user-doc/html/_installation.html .. _plumedinstall: https://plumed.github.io/doc-master/user-doc/html/_installation.html
@ -1309,7 +1312,7 @@ USER-PLUMED package
Before building LAMMPS with this package, you must first build PLUMED. Before building LAMMPS with this package, you must first build PLUMED.
PLUMED can be built as part of the LAMMPS build or installed separately PLUMED can be built as part of the LAMMPS build or installed separately
from LAMMPS using the generic `PLUMED installation instructions <plumedinstall_>`_. from LAMMPS using the generic `PLUMED installation instructions <plumedinstall_>`_.
The USER-PLUMED package has been tested to work with Plumed versions The PLUMED package has been tested to work with Plumed versions
2.4.x, 2.5.x, and 2.6.x and will error out, when trying to run calculations 2.4.x, 2.5.x, and 2.6.x and will error out, when trying to run calculations
with a different version of the Plumed kernel. with a different version of the Plumed kernel.
@ -1345,7 +1348,7 @@ LAMMPS build.
.. tab:: CMake build .. tab:: CMake build
When the ``-D PKG_USER-PLUMED=yes`` flag is included in the cmake When the ``-D PKG_PLUMED=yes`` flag is included in the cmake
command you must ensure that GSL is installed in locations that command you must ensure that GSL is installed in locations that
are specified in your environment. There are then two additional are specified in your environment. There are then two additional
variables that control the manner in which PLUMED is obtained and variables that control the manner in which PLUMED is obtained and
@ -1378,7 +1381,7 @@ LAMMPS build.
.. tab:: Traditional make .. tab:: Traditional make
PLUMED needs to be installed before the USER-PLUMED package is PLUMED needs to be installed before the PLUMED package is
installed so that LAMMPS can find the right settings when installed so that LAMMPS can find the right settings when
compiling and linking the LAMMPS executable. You can either compiling and linking the LAMMPS executable. You can either
download and build PLUMED inside the LAMMPS plumed library folder download and build PLUMED inside the LAMMPS plumed library folder
@ -1403,12 +1406,12 @@ LAMMPS build.
build to use. A new file ``lib/plumed/Makefile.lammps`` is also build to use. A new file ``lib/plumed/Makefile.lammps`` is also
created with settings suitable for LAMMPS to compile and link created with settings suitable for LAMMPS to compile and link
PLUMED using the desired linkage mode. After this step is PLUMED using the desired linkage mode. After this step is
completed, you can install the USER-PLUMED package and compile completed, you can install the PLUMED package and compile
LAMMPS in the usual manner: LAMMPS in the usual manner:
.. code-block:: bash .. code-block:: bash
$ make yes-user-plumed $ make yes-plumed
$ make machine $ make machine
Once this compilation completes you should be able to run LAMMPS Once this compilation completes you should be able to run LAMMPS
@ -1423,15 +1426,15 @@ LAMMPS build.
If you want to change the linkage mode, you have to re-run "make If you want to change the linkage mode, you have to re-run "make
lib-plumed" with the desired settings **and** do a re-install if lib-plumed" with the desired settings **and** do a re-install if
the USER-PLUMED package with "make yes-user-plumed" to update the the PLUMED package with "make yes-plumed" to update the
required makefile settings with the changes in the lib/plumed required makefile settings with the changes in the lib/plumed
folder. folder.
---------- ----------
.. _user-h5md: .. _h5md:
USER-H5MD package H5MD package
--------------------------------- ---------------------------------
To build with this package you must have the HDF5 software package To build with this package you must have the HDF5 software package
@ -1442,7 +1445,7 @@ the HDF5 library.
.. tab:: CMake build .. tab:: CMake build
No additional settings are needed besides ``-D PKG_USER-H5MD=yes``. No additional settings are needed besides ``-D PKG_H5MD=yes``.
This should auto-detect the H5MD library on your system. Several This should auto-detect the H5MD library on your system. Several
advanced CMake H5MD options exist if you need to specify where it advanced CMake H5MD options exist if you need to specify where it
@ -1474,13 +1477,13 @@ the HDF5 library.
---------- ----------
.. _user-hdnnp: .. _ml-hdnnp:
USER-HDNNP package ML-HDNNP package
--------------------------------- ----------------
To build with the USER-HDNNP package it is required to download and build the To build with the ML-HDNNP package it is required to download and build the
external `n2p2 <https://github.com/CompPhysVienna/n2p2>`__ library ``v2.1.4`` external `n2p2 <https://github.com/CompPhysVienna/n2p2>`_ library ``v2.1.4``
(or higher). The LAMMPS build process offers an automatic download and (or higher). The LAMMPS build process offers an automatic download and
compilation of *n2p2* or allows you to choose the installation directory of compilation of *n2p2* or allows you to choose the installation directory of
*n2p2* manually. Please see the boxes below for the CMake and traditional build *n2p2* manually. Please see the boxes below for the CMake and traditional build
@ -1490,7 +1493,7 @@ In case of a manual installation of *n2p2* you only need to build the *n2p2* cor
library ``libnnp`` and interface library ``libnnpif``. When using GCC it should library ``libnnp`` and interface library ``libnnpif``. When using GCC it should
suffice to execute ``make libnnpif`` in the *n2p2* ``src`` directory. For more suffice to execute ``make libnnpif`` in the *n2p2* ``src`` directory. For more
details please see ``lib/hdnnp/README`` and the `n2p2 build documentation details please see ``lib/hdnnp/README`` and the `n2p2 build documentation
<https://compphysvienna.github.io/n2p2/topics/build.html>`__. <https://compphysvienna.github.io/n2p2/topics/build.html>`_.
.. tabs:: .. tabs::
@ -1528,24 +1531,24 @@ details please see ``lib/hdnnp/README`` and the `n2p2 build documentation
---------- ----------
.. _user-intel: .. _intel:
USER-INTEL package INTEL package
----------------------------------- -----------------------------------
To build with this package, you must choose which hardware you want to To build with this package, you must choose which hardware you want to
build for, either x86 CPUs or Intel KNLs in offload mode. You should build for, either x86 CPUs or Intel KNLs in offload mode. You should
also typically :ref:`install the USER-OMP package <user-omp>`, as it can be also typically :ref:`install the OPENMP package <openmp>`, as it can be
used in tandem with the USER-INTEL package to good effect, as explained used in tandem with the INTEL package to good effect, as explained
on the :doc:`Speed_intel` page. on the :doc:`Speed_intel` page.
When using Intel compilers version 16.0 or later is required. You can When using Intel compilers version 16.0 or later is required. You can
also use the GNU or Clang compilers and they will provide performance also use the GNU or Clang compilers and they will provide performance
improvements over regular styles and USER-OMP styles, but less so than improvements over regular styles and OPENMP styles, but less so than
with the Intel compilers. Please also note, that some compilers have with the Intel compilers. Please also note, that some compilers have
been found to apply memory alignment constraints incompletely or been found to apply memory alignment constraints incompletely or
incorrectly and thus can cause segmentation faults in otherwise correct incorrectly and thus can cause segmentation faults in otherwise correct
code when using features from the USER-INTEL package. code when using features from the INTEL package.
.. tabs:: .. tabs::
@ -1562,7 +1565,7 @@ code when using features from the USER-INTEL package.
Choose which hardware to compile for in Makefile.machine via the Choose which hardware to compile for in Makefile.machine via the
following settings. See ``src/MAKE/OPTIONS/Makefile.intel_cpu*`` following settings. See ``src/MAKE/OPTIONS/Makefile.intel_cpu*``
and ``Makefile.knl`` files for examples. and and ``Makefile.knl`` files for examples. and
``src/USER-INTEL/README`` for additional information. ``src/INTEL/README`` for additional information.
For CPUs: For CPUs:
@ -1598,9 +1601,9 @@ TBB and MKL.
---------- ----------
.. _user-mdi: .. _mdi:
USER-MDI package MDI package
----------------------------- -----------------------------
.. tabs:: .. tabs::
@ -1627,9 +1630,9 @@ USER-MDI package
---------- ----------
.. _user-mesont: .. _mesont:
USER-MESONT package MESONT package
------------------------- -------------------------
This package includes a library written in Fortran 90 in the This package includes a library written in Fortran 90 in the
@ -1642,7 +1645,7 @@ they will be downloaded the first time this package is installed.
.. tab:: CMake build .. tab:: CMake build
No additional settings are needed besides ``-D PKG_USER-MESONT=yes`` No additional settings are needed besides ``-D PKG_MESONT=yes``
.. tab:: Traditional make .. tab:: Traditional make
@ -1669,9 +1672,9 @@ they will be downloaded the first time this package is installed.
---------- ----------
.. _user-molfile: .. _molfile:
USER-MOLFILE package MOLFILE package
--------------------------------------- ---------------------------------------
.. tabs:: .. tabs::
@ -1681,9 +1684,9 @@ USER-MOLFILE package
.. code-block:: bash .. code-block:: bash
-D MOLFILE_INCLUDE_DIR=path # (optional) path where VMD molfile plugin headers are installed -D MOLFILE_INCLUDE_DIR=path # (optional) path where VMD molfile plugin headers are installed
-D PKG_USER-MOLFILE=yes -D PKG_MOLFILE=yes
Using ``-D PKG_USER-MOLFILE=yes`` enables the package, and setting Using ``-D PKG_MOLFILE=yes`` enables the package, and setting
``-D MOLFILE_INCLUDE_DIR`` allows to provide a custom location for ``-D MOLFILE_INCLUDE_DIR`` allows to provide a custom location for
the molfile plugin header files. These should match the ABI of the the molfile plugin header files. These should match the ABI of the
plugin files used, and thus one typically sets them to include plugin files used, and thus one typically sets them to include
@ -1707,9 +1710,9 @@ USER-MOLFILE package
---------- ----------
.. _user-netcdf: .. _netcdf:
USER-NETCDF package NETCDF package
------------------------------------- -------------------------------------
To build with this package you must have the NetCDF library installed To build with this package you must have the NetCDF library installed
@ -1719,7 +1722,7 @@ on your system.
.. tab:: CMake build .. tab:: CMake build
No additional settings are needed besides ``-D PKG_USER-NETCDF=yes``. No additional settings are needed besides ``-D PKG_NETCDF=yes``.
This should auto-detect the NETCDF library if it is installed on This should auto-detect the NETCDF library if it is installed on
your system at standard locations. Several advanced CMake NETCDF your system at standard locations. Several advanced CMake NETCDF
@ -1738,9 +1741,9 @@ on your system.
---------- ----------
.. _user-omp: .. _openmp:
USER-OMP package OPENMP package
------------------------------- -------------------------------
.. tabs:: .. tabs::
@ -1748,13 +1751,13 @@ USER-OMP package
.. tab:: CMake build .. tab:: CMake build
No additional settings are required besides ``-D No additional settings are required besides ``-D
PKG_USER-OMP=yes``. If CMake detects OpenMP compiler support, the PKG_OPENMP=yes``. If CMake detects OpenMP compiler support, the
USER-OMP code will be compiled with multi-threading support OPENMP code will be compiled with multi-threading support
enabled, otherwise as optimized serial code. enabled, otherwise as optimized serial code.
.. tab:: Traditional make .. tab:: Traditional make
To enable multi-threading support in the USER-OMP package (and To enable multi-threading support in the OPENMP package (and
other styles supporting OpenMP) the following compile and link other styles supporting OpenMP) the following compile and link
flags must be added to your Makefile.machine file. See flags must be added to your Makefile.machine file. See
``src/MAKE/OPTIONS/Makefile.omp`` for an example. ``src/MAKE/OPTIONS/Makefile.omp`` for an example.
@ -1771,12 +1774,12 @@ USER-OMP package
---------- ----------
.. _user-qmmm: .. _qmmm:
USER-QMMM package QMMM package
--------------------------------- ---------------------------------
For using LAMMPS to do QM/MM simulations via the USER-QMMM package you For using LAMMPS to do QM/MM simulations via the QMMM package you
need to build LAMMPS as a library. A LAMMPS executable with :doc:`fix need to build LAMMPS as a library. A LAMMPS executable with :doc:`fix
qmmm <fix_qmmm>` included can be built, but will not be able to do a qmmm <fix_qmmm>` included can be built, but will not be able to do a
QM/MM simulation on as such. You must also build a QM code - currently QM/MM simulation on as such. You must also build a QM code - currently
@ -1799,11 +1802,11 @@ verified to work in February 2020 with Quantum Espresso versions 6.3 to
libqmmm.a) are not included in the static LAMMPS library and libqmmm.a) are not included in the static LAMMPS library and
(currently) not installed, while their code is included in the (currently) not installed, while their code is included in the
shared LAMMPS library. Thus a typical command line to configure shared LAMMPS library. Thus a typical command line to configure
building LAMMPS for USER-QMMM would be: building LAMMPS for QMMM would be:
.. code-block:: bash .. code-block:: bash
cmake -C ../cmake/presets/minimal.cmake -D PKG_USER-QMMM=yes \ cmake -C ../cmake/presets/basic.cmake -D PKG_QMMM=yes \
-D BUILD_LIB=yes -DBUILD_SHARED_LIBS=yes ../cmake -D BUILD_LIB=yes -DBUILD_SHARED_LIBS=yes ../cmake
After completing the LAMMPS build and also configuring and After completing the LAMMPS build and also configuring and
@ -1846,16 +1849,16 @@ verified to work in February 2020 with Quantum Espresso versions 6.3 to
---------- ----------
.. _user-quip: .. _ml-quip:
USER-QUIP package ML-QUIP package
--------------------------------- ---------------------------------
To build with this package, you must download and build the QUIP To build with this package, you must download and build the QUIP
library. It can be obtained from GitHub. For support of GAP library. It can be obtained from GitHub. For support of GAP
potentials, additional files with specific licensing conditions need potentials, additional files with specific licensing conditions need
to be downloaded and configured. See step 1 and step 1.1 in the to be downloaded and configured. The automatic download will from
``lib/quip/README`` file for details on how to do this. within CMake will download the non-commercial use version.
.. tabs:: .. tabs::
@ -1863,11 +1866,14 @@ to be downloaded and configured. See step 1 and step 1.1 in the
.. code-block:: bash .. 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) -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 CMake will try to download and build the QUIP library from GitHub, if it is not
done that, a CMake build of LAMMPS with ``-D PKG_USER-QUIP=yes`` should found on the local machine. This requires to have git installed. It will use the same compilers
work. Set the ``QUIP_LIBRARY`` variable if CMake cannot find the QUIP library. 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 .. tab:: Traditional make
@ -1881,9 +1887,9 @@ to be downloaded and configured. See step 1 and step 1.1 in the
---------- ----------
.. _user-scafacos: .. _scafacos:
USER-SCAFACOS package SCAFACOS package
----------------------------------------- -----------------------------------------
To build with this package, you must download and build the To build with this package, you must download and build the
@ -1928,9 +1934,9 @@ To build with this package, you must download and build the
---------- ----------
.. _user-smd: .. _machdyn:
USER-SMD package MACHDYN package
------------------------------- -------------------------------
To build with this package, you must download the Eigen3 library. To build with this package, you must download the Eigen3 library.
@ -1972,9 +1978,9 @@ Eigen3 is a template library, so you do not need to build it.
---------- ----------
.. _user-vtk: .. _vtk:
USER-VTK package VTK package
------------------------------- -------------------------------
To build with this package you must have the VTK library installed on To build with this package you must have the VTK library installed on
@ -1984,7 +1990,7 @@ your system.
.. tab:: CMake build .. tab:: CMake build
No additional settings are needed besides ``-D PKG_USER-VTK=yes``. No additional settings are needed besides ``-D PKG_VTK=yes``.
This should auto-detect the VTK library if it is installed on your This should auto-detect the VTK library if it is installed on your
system at standard locations. Several advanced VTK options exist system at standard locations. Several advanced VTK options exist

6
doc/src/Build_make.rst
View File

@ -117,10 +117,10 @@ settings may become outdated:
make mac # build serial LAMMPS on a Mac make mac # build serial LAMMPS on a Mac
make mac_mpi # build parallel LAMMPS on a Mac make mac_mpi # build parallel LAMMPS on a Mac
make intel_cpu # build with the USER-INTEL package optimized for CPUs make intel_cpu # build with the INTEL package optimized for CPUs
make knl # build with the USER-INTEL package optimized for KNLs make knl # build with the INTEL package optimized for KNLs
make opt # build with the OPT package optimized for CPUs make opt # build with the OPT package optimized for CPUs
make omp # build with the USER-OMP package optimized for OpenMP make omp # build with the OPENMP package optimized for OpenMP
make kokkos_omp # build with the KOKKOS package for OpenMP make kokkos_omp # build with the KOKKOS package for OpenMP
make kokkos_cuda_mpi # build with the KOKKOS package for GPUs make kokkos_cuda_mpi # build with the KOKKOS package for GPUs
make kokkos_phi # build with the KOKKOS package for KNLs make kokkos_phi # build with the KOKKOS package for KNLs

11
doc/src/Build_manual.rst
View File

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

85
doc/src/Build_package.rst
View File

@ -30,17 +30,37 @@ steps, as explained on the :doc:`Build extras <Build_extras>` page.
These links take you to the extra instructions for those select These links take you to the extra instructions for those select
packages: packages:
+--------------------------------------+--------------------------------------+------------------------------------+----------------------------------+--------------------------------+--------------------------------+ .. table_from_list::
| :ref:`COMPRESS <compress>` | :ref:`GPU <gpu>` | :ref:`KIM <kim>` | :ref:`KOKKOS <kokkos>` | :ref:`LATTE <latte>` | :ref:`MESSAGE <message>` | :columns: 6
+--------------------------------------+--------------------------------------+------------------------------------+----------------------------------+--------------------------------+--------------------------------+
| :ref:`MSCG <mscg>` | :ref:`OPT <opt>` | :ref:`POEMS <poems>` | :ref:`PYTHON <python>` | :ref:`VORONOI <voronoi>` | :ref:`USER-ADIOS <user-adios>` | * :ref:`ADIOS <adios>`
+--------------------------------------+--------------------------------------+------------------------------------+----------------------------------+--------------------------------+--------------------------------+ * :ref:`ATC <atc>`
| :ref:`USER-ATC <user-atc>` | :ref:`USER-AWPMD <user-awpmd>` | :ref:`USER-COLVARS <user-colvars>` | :ref:`USER-H5MD <user-h5md>` | :ref:`USER-HDNNP <user-hdnnp>` | :ref:`USER-INTEL <user-intel>` | * :ref:`AWPMD <awpmd>`
+--------------------------------------+--------------------------------------+------------------------------------+----------------------------------+--------------------------------+--------------------------------+ * :ref:`COLVARS <colvars>`
| :ref:`USER-MOLFILE <user-molfile>` | :ref:`USER-NETCDF <user-netcdf>` | :ref:`USER-PACE <user-pace>` | :ref:`USER-PLUMED <user-plumed>` | :ref:`USER-OMP <user-omp>` | :ref:`USER-QMMM <user-qmmm>` | * :ref:`COMPRESS <compress>`
+--------------------------------------+--------------------------------------+------------------------------------+----------------------------------+--------------------------------+--------------------------------+ * :ref:`GPU <gpu>`
| :ref:`USER-QUIP <user-quip>` | :ref:`USER-SCAFACOS <user-scafacos>` | :ref:`USER-SMD <user-smd>` | :ref:`USER-VTK <user-vtk>` | | | * :ref:`H5MD <h5md>`
+--------------------------------------+--------------------------------------+------------------------------------+----------------------------------+--------------------------------+--------------------------------+ * :ref:`INTEL <intel>`
* :ref:`KIM <kim>`
* :ref:`KOKKOS <kokkos>`
* :ref:`LATTE <latte>`
* :ref:`MACHDYN <machdyn>`
* :ref:`MESSAGE <message>`
* :ref:`ML-HDNNP <ml-hdnnp>`
* :ref:`ML-PACE <ml-pace>`
* :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:`VORONOI <voronoi>`
* :ref:`VTK <vtk>`
The mechanism for including packages is simple but different for CMake The mechanism for including packages is simple but different for CMake
versus make. versus make.
@ -58,14 +78,10 @@ versus make.
.. code-block:: csh .. code-block:: csh
-D PKG_MANYBODY=yes -D PKG_MANYBODY=yes
-D PKG_USER-INTEL=yes -D PKG_INTEL=yes
All standard and user packages are included the same way. Note All packages are included the same way. See the shortcut section
that USER packages have a hyphen between USER and the rest of the below for how to install many packages at once with CMake.
package name, not an underscore.
See the shortcut section below for how to install many packages at
once with CMake.
.. note:: .. note::
@ -89,12 +105,10 @@ versus make.
.. code-block:: bash .. code-block:: bash
make no-rigid make no-rigid
make yes-user-intel make yes-intel
All standard and user packages are included the same way. All packages are included the same way. See the shortcut section
below for how to install many packages at once with make.
See the shortcut section below for how to install many packages at
once with make.
.. note:: .. note::
@ -126,7 +140,7 @@ other files dependent on that package are also excluded.
.. note:: .. note::
By default no package is installed. Prior to August 2018, however, By default no packages are installed. Prior to August 2018, however,
if you downloaded a tarball, 3 packages (KSPACE, MANYBODY, MOLECULE) if you downloaded a tarball, 3 packages (KSPACE, MANYBODY, MOLECULE)
were pre-installed via the traditional make procedure in the ``src`` were pre-installed via the traditional make procedure in the ``src``
directory. That is no longer the case, so that CMake will build directory. That is no longer the case, so that CMake will build
@ -153,7 +167,7 @@ one of them as a starting point and customize it to your needs.
.. code-block:: bash .. code-block:: bash
cmake -C ../cmake/presets/minimal.cmake [OPTIONS] ../cmake # enable just a few core packages cmake -C ../cmake/presets/basic.cmake [OPTIONS] ../cmake # enable just a few core packages
cmake -C ../cmake/presets/most.cmake [OPTIONS] ../cmake # enable most packages cmake -C ../cmake/presets/most.cmake [OPTIONS] ../cmake # enable most packages
cmake -C ../cmake/presets/download.cmake [OPTIONS] ../cmake # enable packages which download sources or potential files cmake -C ../cmake/presets/download.cmake [OPTIONS] ../cmake # enable packages which download sources or potential files
cmake -C ../cmake/presets/nolib.cmake [OPTIONS] ../cmake # disable packages that do require extra libraries or tools cmake -C ../cmake/presets/nolib.cmake [OPTIONS] ../cmake # disable packages that do require extra libraries or tools
@ -208,10 +222,10 @@ These commands install/un-install sets of packages:
make yes-all # install all packages make yes-all # install all packages
make no-all # uninstall all packages make no-all # uninstall all packages
make yes-standard or make yes-std # install standard packages make yes-basic # install a few commonly used packages'
make no-standard or make no-std # uninstall standard packages make no-basic # remove a few commonly used packages'
make yes-user # install user packages make yes-most # install most packages w/o libs'
make no-user # uninstall user packages make no-most # remove most packages w/o libs'
make yes-lib # install packages that require extra libraries make yes-lib # install packages that require extra libraries
make no-lib # uninstall packages that require extra libraries make no-lib # uninstall packages that require extra libraries
make yes-ext # install packages that require external libraries make yes-ext # install packages that require external libraries
@ -225,15 +239,14 @@ package`` will list all the these commands.
Installing or un-installing a package for the make based build process Installing or un-installing a package for the make based build process
works by simply copying files back and forth between the main source works by simply copying files back and forth between the main source
directory src and the sub-directories with the package name (e.g. directory src and the sub-directories with the package name (e.g.
src/KSPACE, src/USER-ATC), so that the files are included or excluded src/KSPACE, src/ATC), so that the files are included or excluded
when LAMMPS is built. Only source files in the src folder will be when LAMMPS is built. Only source files in the src folder will be
compiled. compiled.
The following make commands help manage files that exist in both the The following make commands help manage files that exist in both the
src directory and in package sub-directories. You do not normally src directory and in package sub-directories. You do not normally
need to use these commands unless you are editing LAMMPS files or are need to use these commands unless you are editing LAMMPS files or are
:doc:`installing a patch <Install_patch>` downloaded from the LAMMPS web updating LAMMPS via git.
site.
Type ``make package-status`` or ``make ps`` to show which packages are Type ``make package-status`` or ``make ps`` to show which packages are
currently installed. For those that are installed, it will list any currently installed. For those that are installed, it will list any
@ -245,10 +258,10 @@ currently installed, without listing the status of packages that are
not installed. not installed.
Type ``make package-update`` or ``make pu`` to overwrite src files with Type ``make package-update`` or ``make pu`` to overwrite src files with
files from the package sub-directories if the package is installed. files from the package sub-directories if the package is installed. It
It should be used after a :doc:`patch has been applied <Install_patch>`, should be used after the checkout has been :doc:`updated or changed
since patches only update the files in the package sub-directory, but withy git <Install_git>`, this will only update the files in the package
not the src files. sub-directories, but not the copies in the src folder.
Type ``make package-overwrite`` to overwrite files in the package Type ``make package-overwrite`` to overwrite files in the package
sub-directories with src files. sub-directories with src files.

9
doc/src/Build_settings.rst
View File

@ -64,14 +64,15 @@ LAMMPS can use them if they are available on your system.
selected, then CMake will try to detect, if threaded FFTW selected, then CMake will try to detect, if threaded FFTW
libraries are available and enable them by default. This setting libraries are available and enable them by default. This setting
is independent of whether OpenMP threads are enabled and a is independent of whether OpenMP threads are enabled and a
packages like KOKKOS or USER-OMP is used. If CMake cannot detect packages like KOKKOS or OPENMP is used. If CMake cannot detect
the FFT library, you can set these variables to assist: the FFT library, you can set these variables to assist:
.. code-block:: bash .. code-block:: bash
-D FFTW3_INCLUDE_DIR=path # path to FFTW3 include files -D FFTW3_INCLUDE_DIR=path # path to FFTW3 include files
-D FFTW3_LIBRARY=path # path to FFTW3 libraries -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 MKL_INCLUDE_DIR=path # ditto for Intel MKL library
-D FFT_MKL_THREADS=on # enable using threaded FFTs with MKL libraries -D FFT_MKL_THREADS=on # enable using threaded FFTs with MKL libraries
-D MKL_LIBRARY=path # path to MKL libraries -D MKL_LIBRARY=path # path to MKL libraries
@ -242,8 +243,8 @@ does not support 64-bit integers or incurs performance penalties when
using them. using them.
These are limits for the core of the LAMMPS code, specific features or These are limits for the core of the LAMMPS code, specific features or
some styles may impose additional limits. The :ref:`USER-ATC some styles may impose additional limits. The :ref:`ATC
<PKG-USER-ATC>` package cannot be compiled with the "bigbig" setting. <PKG-ATC>` package cannot be compiled with the "bigbig" setting.
Also, there are limitations when using the library interface where some Also, there are limitations when using the library interface where some
functions with known issues have been replaced by dummy calls printing a functions with known issues have been replaced by dummy calls printing a
corresponding error message rather than crashing randomly or corrupting corresponding error message rather than crashing randomly or corrupting

8
doc/src/Commands_bond.rst
View File

@ -18,7 +18,7 @@ Bond_style potentials
All LAMMPS :doc:`bond_style <bond_style>` commands. Some styles have All LAMMPS :doc:`bond_style <bond_style>` commands. Some styles have
accelerated versions. This is indicated by additional letters in accelerated versions. This is indicated by additional letters in
parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o = USER-OMP, t = parenthesis: g = GPU, i = INTEL, k = KOKKOS, o = OPENMP, t =
OPT. OPT.
.. table_from_list:: .. table_from_list::
@ -57,7 +57,7 @@ Angle_style potentials
All LAMMPS :doc:`angle_style <angle_style>` commands. Some styles have All LAMMPS :doc:`angle_style <angle_style>` commands. Some styles have
accelerated versions. This is indicated by additional letters in accelerated versions. This is indicated by additional letters in
parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o = USER-OMP, t = parenthesis: g = GPU, i = INTEL, k = KOKKOS, o = OPENMP, t =
OPT. OPT.
.. table_from_list:: .. table_from_list::
@ -99,7 +99,7 @@ Dihedral_style potentials
All LAMMPS :doc:`dihedral_style <dihedral_style>` commands. Some styles All LAMMPS :doc:`dihedral_style <dihedral_style>` commands. Some styles
have accelerated versions. This is indicated by additional letters in have accelerated versions. This is indicated by additional letters in
parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o = USER-OMP, t = parenthesis: g = GPU, i = INTEL, k = KOKKOS, o = OPENMP, t =
OPT. OPT.
.. table_from_list:: .. table_from_list::
@ -135,7 +135,7 @@ Improper_style potentials
All LAMMPS :doc:`improper_style <improper_style>` commands. Some styles All LAMMPS :doc:`improper_style <improper_style>` commands. Some styles
have accelerated versions. This is indicated by additional letters in have accelerated versions. This is indicated by additional letters in
parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o = USER-OMP, t = parenthesis: g = GPU, i = INTEL, k = KOKKOS, o = OPENMP, t =
OPT. OPT.
.. table_from_list:: .. table_from_list::

2
doc/src/Commands_category.rst
View File

@ -2,7 +2,7 @@ Commands by category
==================== ====================
This page lists most of the LAMMPS commands, grouped by category. The 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. alphabetically. Style options for entries like fix, compute, pair etc.
have their own pages where they are listed alphabetically. have their own pages where they are listed alphabetically.

9
doc/src/Commands_compute.rst
View File

@ -16,8 +16,8 @@ Compute commands
An alphabetic list of all LAMMPS :doc:`compute <compute>` commands. An alphabetic list of all LAMMPS :doc:`compute <compute>` commands.
Some styles have accelerated versions. This is indicated by Some styles have accelerated versions. This is indicated by
additional letters in parenthesis: g = GPU, i = USER-INTEL, k = additional letters in parenthesis: g = GPU, i = INTEL, k =
KOKKOS, o = USER-OMP, t = OPT. KOKKOS, o = OPENMP, t = OPT.
.. table_from_list:: .. table_from_list::
:columns: 5 :columns: 5
@ -47,6 +47,7 @@ KOKKOS, o = USER-OMP, t = OPT.
* :doc:`dihedral <compute_dihedral>` * :doc:`dihedral <compute_dihedral>`
* :doc:`dihedral/local <compute_dihedral_local>` * :doc:`dihedral/local <compute_dihedral_local>`
* :doc:`dilatation/atom <compute_dilatation_atom>` * :doc:`dilatation/atom <compute_dilatation_atom>`
* :doc:`dipole <compute_dipole>`
* :doc:`dipole/chunk <compute_dipole_chunk>` * :doc:`dipole/chunk <compute_dipole_chunk>`
* :doc:`displace/atom <compute_displace_atom>` * :doc:`displace/atom <compute_displace_atom>`
* :doc:`dpd <compute_dpd>` * :doc:`dpd <compute_dpd>`
@ -59,6 +60,7 @@ KOKKOS, o = USER-OMP, t = OPT.
* :doc:`erotate/sphere <compute_erotate_sphere>` * :doc:`erotate/sphere <compute_erotate_sphere>`
* :doc:`erotate/sphere/atom <compute_erotate_sphere_atom>` * :doc:`erotate/sphere/atom <compute_erotate_sphere_atom>`
* :doc:`event/displace <compute_event_displace>` * :doc:`event/displace <compute_event_displace>`
* :doc:`fabric <compute_fabric>`
* :doc:`fep <compute_fep>` * :doc:`fep <compute_fep>`
* :doc:`force/tally <compute_tally>` * :doc:`force/tally <compute_tally>`
* :doc:`fragment/atom <compute_cluster_atom>` * :doc:`fragment/atom <compute_cluster_atom>`
@ -70,6 +72,7 @@ KOKKOS, o = USER-OMP, t = OPT.
* :doc:`gyration/shape/chunk <compute_gyration_shape_chunk>` * :doc:`gyration/shape/chunk <compute_gyration_shape_chunk>`
* :doc:`heat/flux <compute_heat_flux>` * :doc:`heat/flux <compute_heat_flux>`
* :doc:`heat/flux/tally <compute_tally>` * :doc:`heat/flux/tally <compute_tally>`
* :doc:`heat/flux/virial/tally <compute_tally>`
* :doc:`hexorder/atom <compute_hexorder_atom>` * :doc:`hexorder/atom <compute_hexorder_atom>`
* :doc:`hma <compute_hma>` * :doc:`hma <compute_hma>`
* :doc:`improper <compute_improper>` * :doc:`improper <compute_improper>`
@ -149,7 +152,7 @@ KOKKOS, o = USER-OMP, t = OPT.
* :doc:`temp/chunk <compute_temp_chunk>` * :doc:`temp/chunk <compute_temp_chunk>`
* :doc:`temp/com <compute_temp_com>` * :doc:`temp/com <compute_temp_com>`
* :doc:`temp/cs <compute_temp_cs>` * :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/deform/eff <compute_temp_deform_eff>`
* :doc:`temp/drude <compute_temp_drude>` * :doc:`temp/drude <compute_temp_drude>`
* :doc:`temp/eff <compute_temp_eff>` * :doc:`temp/eff <compute_temp_eff>`

12
doc/src/Commands_fix.rst
View File

@ -16,7 +16,7 @@ Fix commands
An alphabetic list of all LAMMPS :doc:`fix <fix>` commands. Some styles An alphabetic list of all LAMMPS :doc:`fix <fix>` commands. Some styles
have accelerated versions. This is indicated by additional letters in have accelerated versions. This is indicated by additional letters in
parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o = USER-OMP, t = parenthesis: g = GPU, i = INTEL, k = KOKKOS, o = OPENMP, t =
OPT. OPT.
.. table_from_list:: .. table_from_list::
@ -148,7 +148,7 @@ OPT.
* :doc:`nvt/body <fix_nvt_body>` * :doc:`nvt/body <fix_nvt_body>`
* :doc:`nvt/eff <fix_nh_eff>` * :doc:`nvt/eff <fix_nh_eff>`
* :doc:`nvt/manifold/rattle <fix_nvt_manifold_rattle>` * :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/sllod/eff <fix_nvt_sllod_eff>`
* :doc:`nvt/sphere (o) <fix_nvt_sphere>` * :doc:`nvt/sphere (o) <fix_nvt_sphere>`
* :doc:`nvt/uef <fix_nh_uef>` * :doc:`nvt/uef <fix_nh_uef>`
@ -157,6 +157,7 @@ OPT.
* :doc:`orient/fcc <fix_orient>` * :doc:`orient/fcc <fix_orient>`
* :doc:`orient/eco <fix_orient_eco>` * :doc:`orient/eco <fix_orient_eco>`
* :doc:`pafi <fix_pafi>` * :doc:`pafi <fix_pafi>`
* :doc:`pair/tracker <fix_pair_tracker>`
* :doc:`phonon <fix_phonon>` * :doc:`phonon <fix_phonon>`
* :doc:`pimd <fix_pimd>` * :doc:`pimd <fix_pimd>`
* :doc:`planeforce <fix_planeforce>` * :doc:`planeforce <fix_planeforce>`
@ -178,14 +179,14 @@ OPT.
* :doc:`qeq/dynamic <fix_qeq>` * :doc:`qeq/dynamic <fix_qeq>`
* :doc:`qeq/fire <fix_qeq>` * :doc:`qeq/fire <fix_qeq>`
* :doc:`qeq/point <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/shielded <fix_qeq>`
* :doc:`qeq/slater <fix_qeq>` * :doc:`qeq/slater <fix_qeq>`
* :doc:`qmmm <fix_qmmm>` * :doc:`qmmm <fix_qmmm>`
* :doc:`qtb <fix_qtb>` * :doc:`qtb <fix_qtb>`
* :doc:`rattle <fix_shake>` * :doc:`rattle <fix_shake>`
* :doc:`reax/c/bonds (k) <fix_reaxc_bonds>` * :doc:`reaxff/bonds (k) <fix_reaxff_bonds>`
* :doc:`reax/c/species (k) <fix_reaxc_species>` * :doc:`reaxff/species (k) <fix_reaxff_species>`
* :doc:`recenter <fix_recenter>` * :doc:`recenter <fix_recenter>`
* :doc:`restrain <fix_restrain>` * :doc:`restrain <fix_restrain>`
* :doc:`rhok <fix_rhok>` * :doc:`rhok <fix_rhok>`
@ -235,6 +236,7 @@ OPT.
* :doc:`ti/spring <fix_ti_spring>` * :doc:`ti/spring <fix_ti_spring>`
* :doc:`tmd <fix_tmd>` * :doc:`tmd <fix_tmd>`
* :doc:`ttm <fix_ttm>` * :doc:`ttm <fix_ttm>`
* :doc:`ttm/grid <fix_ttm>`
* :doc:`ttm/mod <fix_ttm>` * :doc:`ttm/mod <fix_ttm>`
* :doc:`tune/kspace <fix_tune_kspace>` * :doc:`tune/kspace <fix_tune_kspace>`
* :doc:`vector <fix_vector>` * :doc:`vector <fix_vector>`

88
doc/src/Commands_input.rst
View File

@ -1,55 +1,75 @@
LAMMPS input scripts LAMMPS input scripts
==================== ====================
LAMMPS executes by reading commands from a input script (text file), LAMMPS executes calculations by reading commands from a input script (text file), one
one line at a time. When the input script ends, LAMMPS exits. Each line at a time. When the input script ends, LAMMPS exits. This is different
command causes LAMMPS to take some action. It may set an internal from programs that read and process the entire input before starting a calculation.
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 Each command causes LAMMPS to take some immediate action without regard
wish to change the default. 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 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 (1) LAMMPS does not read your entire input script and then perform a
simulation with all the settings. Rather, the input script is read 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. one line at a time and each command takes effect when it is read.
Thus this sequence of commands: Thus this sequence of commands:
.. code-block:: LAMMPS .. code-block:: LAMMPS
timestep 0.5 timestep 0.5
run 100 run 100
run 100 run 100
does something different than this sequence: does something different than this sequence:
.. code-block:: LAMMPS .. code-block:: LAMMPS
run 100 run 100
timestep 0.5 timestep 0.5
run 100 run 100
In the first case, the specified timestep (0.5 fs) is used for two 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 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 (1.0 fs) is used for the first 100 step simulation and a
timestep is used for the second one. 0.5 fs timestep is used for the second one.
(2) Some commands are only valid when they follow other commands. For (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 example you cannot set the temperature of a group of atoms until
have been defined and a group command is used to define which atoms atoms have been defined and a group command is used to define which
belong to the group. atoms belong to the group.
(3) Sometimes command B will use values that can be set by command A. (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 This means command A must precede command B in the input script if
is to have the desired effect. For example, the it is to have the desired effect. For example, the :doc:`read_data
:doc:`read_data <read_data>` command initializes the system by setting <read_data>` command initializes the system by setting up the
up the simulation box and assigning atoms to processors. If default simulation box and assigning atoms to processors. If default values
values are not desired, the :doc:`processors <processors>` and are not desired, the :doc:`processors <processors>` and
:doc:`boundary <boundary>` commands need to be used before read_data to :doc:`boundary <boundary>` commands need to be used before read_data
tell LAMMPS how to map processors to the simulation box. to tell LAMMPS how to map processors to the simulation box.
Many input script errors are detected by LAMMPS and an ERROR or 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 more information on what errors mean. The documentation for each
command lists restrictions on how the command can be used. 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.

5
doc/src/Commands_kspace.rst
View File

@ -16,7 +16,7 @@ KSpace solvers
All LAMMPS :doc:`kspace_style <kspace_style>` solvers. Some styles have All LAMMPS :doc:`kspace_style <kspace_style>` solvers. Some styles have
accelerated versions. This is indicated by additional letters in accelerated versions. This is indicated by additional letters in
parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o = USER-OMP, t = parenthesis: g = GPU, i = INTEL, k = KOKKOS, o = OPENMP, t =
OPT. OPT.
.. table_from_list:: .. table_from_list::
@ -24,6 +24,7 @@ OPT.
* :doc:`ewald (o) <kspace_style>` * :doc:`ewald (o) <kspace_style>`
* :doc:`ewald/disp <kspace_style>` * :doc:`ewald/disp <kspace_style>`
* :doc:`ewald/disp/dipole <kspace_style>`
* :doc:`ewald/dipole <kspace_style>` * :doc:`ewald/dipole <kspace_style>`
* :doc:`ewald/dipole/spin <kspace_style>` * :doc:`ewald/dipole/spin <kspace_style>`
* :doc:`msm (o) <kspace_style>` * :doc:`msm (o) <kspace_style>`
@ -33,8 +34,10 @@ OPT.
* :doc:`pppm/cg (o) <kspace_style>` * :doc:`pppm/cg (o) <kspace_style>`
* :doc:`pppm/dipole <kspace_style>` * :doc:`pppm/dipole <kspace_style>`
* :doc:`pppm/dipole/spin <kspace_style>` * :doc:`pppm/dipole/spin <kspace_style>`
* :doc:`pppm/dielectric <kspace_style>`
* :doc:`pppm/disp (io) <kspace_style>` * :doc:`pppm/disp (io) <kspace_style>`
* :doc:`pppm/disp/tip4p (o) <kspace_style>` * :doc:`pppm/disp/tip4p (o) <kspace_style>`
* :doc:`pppm/disp/dielectric <kspace_style>`
* :doc:`pppm/stagger <kspace_style>` * :doc:`pppm/stagger <kspace_style>`
* :doc:`pppm/tip4p (o) <kspace_style>` * :doc:`pppm/tip4p (o) <kspace_style>`
* :doc:`pppm/dielectric <kspace_style>` * :doc:`pppm/dielectric <kspace_style>`

9
doc/src/Commands_pair.rst
View File

@ -16,7 +16,7 @@ Pair_style potentials
All LAMMPS :doc:`pair_style <pair_style>` commands. Some styles have All LAMMPS :doc:`pair_style <pair_style>` commands. Some styles have
accelerated versions. This is indicated by additional letters in accelerated versions. This is indicated by additional letters in
parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o = USER-OMP, t = parenthesis: g = GPU, i = INTEL, k = KOKKOS, o = OPENMP, t =
OPT. OPT.
.. table_from_list:: .. table_from_list::
@ -29,7 +29,7 @@ OPT.
* :doc:`hybrid/scaled <pair_hybrid>` * :doc:`hybrid/scaled <pair_hybrid>`
* :doc:`kim <pair_kim>` * :doc:`kim <pair_kim>`
* :doc:`list <pair_list>` * :doc:`list <pair_list>`
* * :doc:`tracker <pair_tracker>`
* *
* *
* *
@ -75,6 +75,7 @@ OPT.
* :doc:`coul/debye (gko) <pair_coul>` * :doc:`coul/debye (gko) <pair_coul>`
* :doc:`coul/diel (o) <pair_coul_diel>` * :doc:`coul/diel (o) <pair_coul_diel>`
* :doc:`coul/dsf (gko) <pair_coul>` * :doc:`coul/dsf (gko) <pair_coul>`
* :doc:`coul/exclude <pair_coul>`
* :doc:`coul/long (gko) <pair_coul>` * :doc:`coul/long (gko) <pair_coul>`
* :doc:`coul/long/cs (g) <pair_cs>` * :doc:`coul/long/cs (g) <pair_cs>`
* :doc:`coul/long/dielectric <pair_dielectric>` * :doc:`coul/long/dielectric <pair_dielectric>`
@ -190,7 +191,7 @@ OPT.
* :doc:`lubricateU/poly <pair_lubricateU>` * :doc:`lubricateU/poly <pair_lubricateU>`
* :doc:`mdpd <pair_mesodpd>` * :doc:`mdpd <pair_mesodpd>`
* :doc:`mdpd/rhosum <pair_mesodpd>` * :doc:`mdpd/rhosum <pair_mesodpd>`
* :doc:`meam/c <pair_meamc>` * :doc:`meam <pair_meam>`
* :doc:`meam/spline (o) <pair_meam_spline>` * :doc:`meam/spline (o) <pair_meam_spline>`
* :doc:`meam/sw/spline <pair_meam_sw_spline>` * :doc:`meam/sw/spline <pair_meam_sw_spline>`
* :doc:`mesocnt <pair_mesocnt>` * :doc:`mesocnt <pair_mesocnt>`
@ -235,7 +236,7 @@ OPT.
* :doc:`python <pair_python>` * :doc:`python <pair_python>`
* :doc:`quip <pair_quip>` * :doc:`quip <pair_quip>`
* :doc:`rann <pair_rann>` * :doc:`rann <pair_rann>`
* :doc:`reax/c (ko) <pair_reaxc>` * :doc:`reaxff (ko) <pair_reaxff>`
* :doc:`rebo (io) <pair_airebo>` * :doc:`rebo (io) <pair_airebo>`
* :doc:`resquared (go) <pair_resquared>` * :doc:`resquared (go) <pair_resquared>`
* :doc:`sdpd/taitwater/isothermal <pair_sdpd_taitwater_isothermal>` * :doc:`sdpd/taitwater/isothermal <pair_sdpd_taitwater_isothermal>`

4
doc/src/Commands_parse.rst
View File

@ -47,7 +47,7 @@ LAMMPS:
named "x" followed by an "x" character. named "x" followed by an "x" character.
How the variable is converted to a text string depends on what style 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 details. It can be a variable that stores multiple text strings, and
return one of them. The returned text string can be multiple "words" return one of them. The returned text string can be multiple "words"
(space separated) which will then be interpreted as multiple (space separated) which will then be interpreted as multiple
@ -164,7 +164,7 @@ LAMMPS:
allowed, but that should be sufficient for most use cases. allowed, but that should be sufficient for most use cases.
.. admonition:: ASCII versus UTF-8 .. admonition:: ASCII versus UTF-8
:class: note :class: note
LAMMPS expects and processes 7-bit ASCII format text internally. LAMMPS expects and processes 7-bit ASCII format text internally.
Many modern environments use UTF-8 encoding, which is a superset Many modern environments use UTF-8 encoding, which is a superset

19
doc/src/Commands_removed.rst
View File

@ -25,23 +25,20 @@ The reset_ids command has been renamed to :doc:`reset_atom_ids <reset_atom_ids>`
MEAM package MEAM package
------------ ------------
The MEAM package has been removed since it was superseded by the The MEAM package in Fortran has been replaced by a C++ implementation.
:ref:`USER-MEAMC package <PKG-USER-MEAMC>`. The code in The code in the :ref:`MEAM package <PKG-MEAM>` is a translation of the
the USER-MEAMC package is a translation of the Fortran code of MEAM into C++, Fortran code of MEAM into C++, which removes several restrictions
which removes several restrictions (e.g. there can be multiple instances (e.g. there can be multiple instances in hybrid pair styles) and allows
in hybrid pair styles) and allows for some optimizations leading for some optimizations leading to better performance. The pair style
to better performance. The new pair style :doc:`meam/c <pair_meamc>` has :doc:`meam <pair_meam>` has the exact same syntax.
the exact same syntax as the old "meam" pair style and thus pair style
meam is an alias to the new style and backward
compatibility of old inputs is preserved.
REAX package REAX package
------------ ------------
The REAX package has been removed since it was superseded by the The REAX package has been removed since it was superseded by the
:ref:`USER-REAXC package <PKG-USER-REAXC>`. The USER-REAXC :ref:`REAXFF package <PKG-REAXFF>`. The REAXFF
package has been tested to yield equivalent results to the REAX package, package has been tested to yield equivalent results to the REAX package,
offers better performance, supports OpenMP multi-threading via USER-OMP, offers better performance, supports OpenMP multi-threading via OPENMP,
and GPU and threading parallelization through KOKKOS. The new pair styles and GPU and threading parallelization through KOKKOS. The new pair styles
are not syntax compatible with the removed reax pair style, so input are not syntax compatible with the removed reax pair style, so input
files will have to be adapted. files will have to be adapted.

1
doc/src/Developer.rst
View File

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

2
doc/src/Developer_org.rst
View File

@ -17,7 +17,7 @@ currently supports building with :doc:`conventional makefiles
differ in how packages are enabled or disabled for inclusion into a differ in how packages are enabled or disabled for inclusion into a
LAMMPS binary so they cannot be mixed. The source files for each LAMMPS binary so they cannot be mixed. The source files for each
package are in all-uppercase sub-directories of the ``src`` folder, for 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 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`` used when building a serial version of the code. The ``src/MAKE``
directory and its sub-directories contain makefiles with settings and directory and its sub-directories contain makefiles with settings and

120
doc/src/Developer_par_comm.rst Normal file
View File

@ -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.

188
doc/src/Developer_par_long.rst Normal file
View File

@ -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.

159
doc/src/Developer_par_neigh.rst Normal file
View File

@ -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.

114
doc/src/Developer_par_openmp.rst Normal file
View File

@ -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.

89
doc/src/Developer_par_part.rst Normal file
View File

@ -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).

28
doc/src/Developer_parallel.rst Normal file
View File

@ -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

4
doc/src/Developer_unittest.rst
View File

@ -404,8 +404,8 @@ noise). Then it will restart from the previously generated restart and
compare with the reference and also start from the data file. A final compare with the reference and also start from the data file. A final
check will use multi-cutoff r-RESPA (if supported by the pair style) at check will use multi-cutoff r-RESPA (if supported by the pair style) at
a 1:1 split and compare to the Verlet results. These sets of tests are a 1:1 split and compare to the Verlet results. These sets of tests are
run with multiple test fixtures for accelerated styles (OPT, USER-OMP, run with multiple test fixtures for accelerated styles (OPT, OPENMP,
USER-INTEL) and for the latter two with 4 OpenMP threads enabled. For INTEL) and for the latter two with 4 OpenMP threads enabled. For
these tests the relative error (epsilon) is lowered by a common factor these tests the relative error (epsilon) is lowered by a common factor
due to the additional numerical noise, but the tests are still comparing due to the additional numerical noise, but the tests are still comparing
to the same reference data. to the same reference data.

21
doc/src/Developer_utils.rst
View File

@ -60,6 +60,9 @@ silently returning the result of a partial conversion or zero in cases
where the string is not a valid number. This behavior allows to more where the string is not a valid number. This behavior allows to more
easily detect typos or issues when processing input files. easily detect typos or issues when processing input files.
Similarly the :cpp:func:`logical() <LAMMPS_NS::utils::logical>` function
will convert a string into a boolean and will only accept certain words.
The *do_abort* flag should be set to ``true`` in case this function The *do_abort* flag should be set to ``true`` in case this function
is called only on a single MPI rank, as that will then trigger the is called only on a single MPI rank, as that will then trigger the
a call to ``Error::one()`` for errors instead of ``Error::all()`` a call to ``Error::one()`` for errors instead of ``Error::all()``
@ -83,6 +86,9 @@ strings for compliance without conversion.
.. doxygenfunction:: tnumeric .. doxygenfunction:: tnumeric
:project: progguide :project: progguide
.. doxygenfunction:: logical
:project: progguide
String processing String processing
^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^
@ -203,9 +209,15 @@ Convenience functions
.. doxygenfunction:: date2num .. doxygenfunction:: date2num
:project: progguide :project: progguide
.. doxygenfunction:: current_date
:project: progguide
Customized standard functions Customized standard functions
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. doxygenfunction:: binary_search
:project: progguide
.. doxygenfunction:: merge_sort .. doxygenfunction:: merge_sort
:project: progguide :project: progguide
@ -334,10 +346,11 @@ arguments of commands in LAMMPS are parsed and to make abstractions of
repetitive tasks. repetitive tasks.
The :cpp:class:`LAMMPS_NS::ArgInfo` class provides an abstraction The :cpp:class:`LAMMPS_NS::ArgInfo` class provides an abstraction
for parsing references to compute or fix styles or variables. These for parsing references to compute or fix styles, variables or custom
would start with a "c\_", "f\_", "v\_" followed by the ID or name of integer or double properties handled by :doc:`fix property/atom <fix_property_atom>`.
than instance and may be postfixed with one or two array indices These would start with a "c\_", "f\_", "v\_", "d\_", "d2\_", "i\_", or "i2\_"
"[<number>]" with numbers > 0. 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: A typical code segment would look like this:

2
doc/src/Developer_write.rst
View File

@ -59,7 +59,7 @@ of each timestep. First of all, implement a constructor:
} }
In the constructor you should parse your fix arguments which are In the constructor you should parse your fix arguments which are
specified in the script. All fixes have pretty the same syntax: specified in the script. All fixes have pretty much the same syntax:
``fix <fix-ID> <fix group> <fix name> <fix arguments ...>``. The ``fix <fix-ID> <fix group> <fix name> <fix arguments ...>``. The
first 3 parameters are parsed by Fix base class constructor, while first 3 parameters are parsed by Fix base class constructor, while
``<fix arguments>`` should be parsed by you. In our case, we need to ``<fix arguments>`` should be parsed by you. In our case, we need to

10
doc/src/Errors.rst
View File

@ -1,11 +1,11 @@
Errors Errors
****** ******
These doc pages describe the errors you can encounter when using These doc pages describe many of the error and warning message you can
LAMMPS. The common problems include conceptual issues. The messages encounter when using LAMMPS. The common problems include conceptual
and warnings doc pages give complete lists of all the messages the issues. The messages and warnings doc pages give complete lists of all
code may generate (except those generated by USER packages), with the messages the code may generate, with additional details for many of
additional details for many of them. them.
.. toctree:: .. toctree::
:maxdepth: 1 :maxdepth: 1

5
doc/src/Errors_bugs.rst
View File

@ -17,8 +17,9 @@ the steps outlined below:
if your issue has already been reported and if it is still open. 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>`_ * Check the `GitHub Pull Requests page <https://github.com/lammps/lammps/pulls>`_
to see if there is already a fix for your bug pending. to see if there is already a fix for your bug pending.
* Check the `mailing list archives <https://www.lammps.org/mail.html>`_ * Check the `mailing list archives <https://www.lammps.org/mail.html>`_ or
to see if the issue has been discussed before. 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 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>`_. bug report on the `GitHub Issue page <https://github.com/lammps/lammps/issues>`_.

3
doc/src/Errors_debug.rst
View File

@ -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: After recompiling LAMMPS and running the input you should get something like this:
.. code-block: .. code-block::
$ ./lmp -in in.melt $ ./lmp -in in.melt
LAMMPS (19 Mar 2020) 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 using 1 OpenMP thread(s) per MPI task
Lattice spacing in x,y,z = 1.6796 1.6796 1.6796 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) Created orthogonal box = (0 0 0) to (16.796 16.796 16.796)

62
doc/src/Errors_messages.rst
View File

@ -14,10 +14,6 @@ For example, a message like this:
means that line #78 in the file src/velocity.cpp generated the error. means that line #78 in the file src/velocity.cpp generated the error.
Looking in the source code may help you figure out what went wrong. Looking in the source code may help you figure out what went wrong.
Note that error messages from :doc:`user-contributed packages <Packages_user>` are not listed here. If such an error
occurs and is not self-explanatory, you will need to look in the source
code or contact the author of the package.
Doc page with :doc:`WARNING messages <Errors_warnings>` Doc page with :doc:`WARNING messages <Errors_warnings>`
---------- ----------
@ -574,10 +570,10 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
See the region prism command for details. See the region prism command for details.
*Can only use -plog with multiple partitions* *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* *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* *Can only use Kokkos supported regions with Kokkos package*
Self-explanatory. Self-explanatory.
@ -718,7 +714,7 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
*Cannot create/grow a vector/array of pointers for %s* *Cannot create/grow a vector/array of pointers for %s*
LAMMPS code is making an illegal call to the templated memory 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* *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 The per-atom info was stored to be used when by a fix that you may
@ -1158,7 +1154,7 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
Self-explanatory. Self-explanatory.
*Cannot use -reorder after -partition* *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* *Cannot use Ewald with 2d simulation*
The kspace style ewald cannot be used in 2d simulations. You can use The kspace style ewald cannot be used in 2d simulations. You can use
@ -2351,14 +2347,14 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
*Compute used in variable between runs is not current* *Compute used in variable between runs is not current*
Computes cannot be invoked by a variable in between runs. Thus they 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 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. variable command for more info.
*Compute used in variable thermo keyword between runs is not current* *Compute used in variable thermo keyword between runs is not current*
Some thermo keywords rely on a compute to calculate their value(s). Some thermo keywords rely on a compute to calculate their value(s).
Computes cannot be invoked by a variable in between runs. Thus they 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 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. variable command for more info.
*Compute vcm/chunk does not use chunk/atom compute* *Compute vcm/chunk does not use chunk/atom compute*
@ -3130,7 +3126,7 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
*Energy was not tallied on needed timestep* *Energy was not tallied on needed timestep*
You are using a thermo keyword that requires potentials to You are using a thermo keyword that requires potentials to
have tallied energy, but they did not on this timestep. See the 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* *Epsilon or sigma reference not set by pair style in PPPMDisp*
Self-explanatory. Self-explanatory.
@ -4539,10 +4535,10 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
particles. particles.
*Incorrect # of floating-point values in Bodies section of data file* *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* *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* *Incorrect %s format in data file*
A section of the data file being read by fix property/atom does A section of the data file being read by fix property/atom does
@ -4577,7 +4573,7 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
The number of fields per line is not what expected. The number of fields per line is not what expected.
*Incorrect bonus data format in data file* *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. bonus data must be formatted for certain atom styles.
*Incorrect boundaries with slab Ewald* *Incorrect boundaries with slab Ewald*
@ -4645,7 +4641,7 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
Incorrect number of words per line in the potential file. Incorrect number of words per line in the potential file.
*Incorrect integer value in Bodies section of data 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* *Incorrect multiplicity arg for dihedral coefficients*
Self-explanatory. Check the input script or data file. Self-explanatory. Check the input script or data file.
@ -5899,7 +5895,7 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
other. other.
*Must set number of threads via package omp command* *Must set number of threads via package omp command*
Because you are using the USER-OMP package, set the number of threads Because you are using the OPENMP package, set the number of threads
via its settings, not by the pair_style snap nthreads setting. via its settings, not by the pair_style snap nthreads setting.
*Must shrink-wrap piston boundary* *Must shrink-wrap piston boundary*
@ -6000,7 +5996,7 @@ Doc page with :doc:`WARNING messages <Errors_warnings>`
Self-explanatory. Self-explanatory.
*Needed bonus data not in data file* *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. details.
*Needed molecular topology not in data file* *Needed molecular topology not in data file*
@ -6202,7 +6198,7 @@ keyword to allow for additional bonds to be formed
*One or more atom IDs is too big* *One or more atom IDs is too big*
The limit on atom IDs is set by the SMALLBIG, BIGBIG, SMALLSMALL 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* *One or more atom IDs is zero*
Either all atoms IDs must be zero or none of them. Either all atoms IDs must be zero or none of them.
@ -6344,16 +6340,16 @@ keyword to allow for additional bonds to be formed
The GPU package must be installed via "make yes-gpu" before LAMMPS is The GPU package must be installed via "make yes-gpu" before LAMMPS is
built. built.
*Package intel command without USER-INTEL package installed* *Package intel command without INTEL package installed*
The USER-INTEL package must be installed via "make yes-user-intel" The INTEL package must be installed via "make yes-intel"
before LAMMPS is built. before LAMMPS is built.
*Package kokkos command without KOKKOS package enabled* *Package kokkos command without KOKKOS package enabled*
The KOKKOS package must be installed via "make yes-kokkos" before The KOKKOS package must be installed via "make yes-kokkos" before
LAMMPS is built, and the "-k on" must be used to enable the package. LAMMPS is built, and the "-k on" must be used to enable the package.
*Package omp command without USER-OMP package installed* *Package omp command without OPENMP package installed*
The USER-OMP package must be installed via "make yes-user-omp" before The OPENMP package must be installed via "make yes-openmp" before
LAMMPS is built. LAMMPS is built.
*Pair body requires atom style body* *Pair body requires atom style body*
@ -6597,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* *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 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* *Pair style born/coul/long requires atom attribute q*
An atom style that defines this attribute must be used. An atom style that defines this attribute must be used.
@ -6917,7 +6913,7 @@ keyword to allow for additional bonds to be formed
*Per-atom energy was not tallied on needed timestep* *Per-atom energy was not tallied on needed timestep*
You are using a thermo keyword that requires potentials to You are using a thermo keyword that requires potentials to
have tallied energy, but they did not on this timestep. See the 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* *Per-atom fix in equal-style variable formula*
Equal-style variables cannot use per-atom quantities. Equal-style variables cannot use per-atom quantities.
@ -6925,7 +6921,7 @@ keyword to allow for additional bonds to be formed
*Per-atom virial was not tallied on needed timestep* *Per-atom virial was not tallied on needed timestep*
You are using a thermo keyword that requires potentials to have You are using a thermo keyword that requires potentials to have
tallied the virial, but they did not on this timestep. See the 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* *Per-processor system is too big*
The number of owned atoms plus ghost atoms on a single The number of owned atoms plus ghost atoms on a single
@ -7883,19 +7879,19 @@ keyword to allow for additional bonds to be formed
*Unexpected end of -reorder file* *Unexpected end of -reorder file*
Self-explanatory. 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. 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. 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. 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. 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. Read a blank line where there should be coefficient data.
*Unexpected end of custom file* *Unexpected end of custom file*
@ -8064,13 +8060,13 @@ keyword to allow for additional bonds to be formed
*Using suffix gpu without GPU package installed* *Using suffix gpu without GPU package installed*
Self-explanatory. Self-explanatory.
*Using suffix intel without USER-INTEL package installed* *Using suffix intel without INTEL package installed*
Self-explanatory. Self-explanatory.
*Using suffix kk without KOKKOS package enabled* *Using suffix kk without KOKKOS package enabled*
Self-explanatory. Self-explanatory.
*Using suffix omp without USER-OMP package installed* *Using suffix omp without OPENMP package installed*
Self-explanatory. Self-explanatory.
*Using update dipole flag requires atom attribute mu* *Using update dipole flag requires atom attribute mu*
@ -8412,7 +8408,7 @@ keyword to allow for additional bonds to be formed
*Virial was not tallied on needed timestep* *Virial was not tallied on needed timestep*
You are using a thermo keyword that requires potentials to You are using a thermo keyword that requires potentials to
have tallied the virial, but they did not on this timestep. See the 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* *Voro++ error: narea and neigh have a different size*
This error is returned by the Voro++ library. This error is returned by the Voro++ library.

12
doc/src/Errors_warnings.rst
View File

@ -14,10 +14,6 @@ generated. For example, a message like this:
means that line #187 in the file src/domain.cpp generated the error. means that line #187 in the file src/domain.cpp generated the error.
Looking in the source code may help you figure out what went wrong. Looking in the source code may help you figure out what went wrong.
Note that warning messages from :doc:`user-contributed packages <Packages_user>` are not listed here. If such a warning
occurs and is not self-explanatory, you will need to look in the source
code or contact the author of the package.
Doc page with :doc:`ERROR messages <Errors_messages>` Doc page with :doc:`ERROR messages <Errors_messages>`
---------- ----------
@ -217,7 +213,7 @@ Doc page with :doc:`ERROR messages <Errors_messages>`
in unexpected behavior. in unexpected behavior.
*Fix bond/swap will ignore defined angles* *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. restriction.
*Fix deposit near setting < possible overlap separation %g* *Fix deposit near setting < possible overlap separation %g*
@ -518,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 will integrate the body motion, but it would be more efficient to use
fix rigid. 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 This is most likely an error, unless you have created your own ReaxFF
parameter file in a different set of units. parameter file in a different set of units.
@ -529,7 +525,7 @@ This will most likely cause errors in kinetic fluctuations.
*OMP_NUM_THREADS environment is not set.* *OMP_NUM_THREADS environment is not set.*
This environment variable must be set appropriately to use the This environment variable must be set appropriately to use the
USER-OMP package. OPENMP package.
*One or more atoms are time integrated more than once* *One or more atoms are time integrated more than once*
This is probably an error since you typically do not want to This is probably an error since you typically do not want to
@ -809,5 +805,3 @@ This will most likely cause errors in kinetic fluctuations.
*Using pair tail corrections with pair_modify compute no* *Using pair tail corrections with pair_modify compute no*
The tail corrections will thus not be computed. 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.

22
doc/src/Examples.rst
View File

@ -27,7 +27,7 @@ be quickly post-processed into a movie using commands described on the
:doc:`dump image <dump_image>` doc page. :doc:`dump image <dump_image>` doc page.
Animations of many of the examples can be viewed on the Movies section 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 There are two kinds of sub-directories in the examples folder. Lower
case named directories contain one or a few simple, quick-to-run 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 | | threebody | regression test input for a variety of manybody potentials |
+-------------+------------------------------------------------------------------+ +-------------+------------------------------------------------------------------+
| tracker | track interactions in LJ melt |
+-------------+------------------------------------------------------------------+
| vashishta | use of the Vashishta potential | | vashishta | use of the Vashishta potential |
+-------------+------------------------------------------------------------------+ +-------------+------------------------------------------------------------------+
| voronoi | Voronoi tesselation via compute voronoi/atom command | | 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 *log.lammps*\ . You can visualize the dump file of snapshots with a
variety of third-party tools highlighted on the variety of third-party tools highlighted on the
`Visualization <https://www.lammps.org/viz.html>`_ page of the LAMMPS `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 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 script a series of JPG images will be produced by the run (assuming
you built LAMMPS with JPG support; see the 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 be viewed individually or turned into a movie or animated by tools
like ImageMagick or QuickTime or various Windows-based tools. See the 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 Imagemagick command would create a GIF file suitable for viewing in a
browser. browser.
@ -205,23 +207,23 @@ Uppercase directories
+------------+--------------------------------------------------------------------------------------------------+ +------------+--------------------------------------------------------------------------------------------------+
| MC | using LAMMPS in a Monte Carlo mode to relax the energy of a system | | MC | using LAMMPS in a Monte Carlo mode to relax the energy of a system |
+------------+--------------------------------------------------------------------------------------------------+ +------------+--------------------------------------------------------------------------------------------------+
| PACKAGES | examples for specific packages and contributed commands |
+------------+--------------------------------------------------------------------------------------------------+
| SPIN | examples for features of the SPIN package | | SPIN | examples for features of the SPIN package |
+------------+--------------------------------------------------------------------------------------------------+ +------------+--------------------------------------------------------------------------------------------------+
| UNITS | examples that run the same simulation in lj, real, metal units | | UNITS | examples that run the same simulation in lj, real, metal units |
+------------+--------------------------------------------------------------------------------------------------+ +------------+--------------------------------------------------------------------------------------------------+
| USER | examples for USER packages and USER-contributed commands |
+------------+--------------------------------------------------------------------------------------------------+
| VISCOSITY | compute viscosity via several methods | | VISCOSITY | compute viscosity via several methods |
+------------+--------------------------------------------------------------------------------------------------+ +------------+--------------------------------------------------------------------------------------------------+
Nearly all of these directories have README files which give more Nearly all of these directories have README files which give more
details on how to understand and use their contents. details on how to understand and use their contents.
The USER directory has a large number of sub-directories which The PACKAGES directory has a large number of sub-directories which
correspond by name to a USER package. They contain scripts that correspond by name to specific packages. They contain scripts that
illustrate how to use the command(s) provided in that package. Many illustrate how to use the command(s) provided in those packages. Many
of the sub-directories have their own README files which give further of the sub-directories have their own README files which give further
instructions. See the :doc:`Packages_details <Packages_details>` doc instructions. See the :doc:`Packages_details <Packages_details>` doc
page for more info on specific USER packages. page for more info on specific packages.
.. _openkim: https://openkim.org .. _openkim: https://openkim.org

1
doc/src/Howto.rst
View File

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

2
doc/src/Howto_barostat.rst
View File

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

2
doc/src/Howto_bioFF.rst
View File

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

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