Merge pull request #1323 from akohlmey/next-patch-release

Patch release 8 February 2019

.github/CODEOWNERS

@@ -17,6 +17,7 @@ src/GPU/*             @ndtrung81
 src/KOKKOS/*          @stanmoore1
 src/KIM/*             @ellio167
 src/LATTE/*           @cnegre
+src/MESSAGE/*         @sjplimp
 src/SPIN/*            @julient31
 src/USER-CGDNA/*      @ohenrich
 src/USER-CGSDK/*      @akohlmey
@@ -28,20 +29,88 @@ src/USER-MEAMC/*      @martok
 src/USER-MOFFF/*      @hheenen
 src/USER-MOLFILE/*    @akohlmey
 src/USER-NETCDF/*     @pastewka
+src/USER-PLUMED/*     @gtribello
 src/USER-PHONON/*     @lingtikong
+src/USER-PTM/*        @pmla
 src/USER-OMP/*        @akohlmey
 src/USER-QMMM/*       @akohlmey
 src/USER-REAXC/*      @hasanmetin
+src/USER-SCAFACOS/*   @rhalver
 src/USER-TALLY/*      @akohlmey
 src/USER-UEF/*        @danicholson
 src/USER-VTK/*        @rbberger
 
+
 # individual files in packages
 src/GPU/pair_vashishta_gpu.*        @andeplane
 src/KOKKOS/pair_vashishta_kokkos.*  @andeplane
 src/MANYBODY/pair_vashishta_table.* @andeplane
+src/MANYBODY/pair_atm.*             @sergeylishchuk
 src/USER-MISC/fix_bond_react.*      @jrgissing
 src/USER-MISC/*_grem.*              @dstelter92
+src/USER-MISC/compute_stress_mop*.* @RomainVermorel
+
+# core LAMMPS classes
+src/lammps.*              @sjplimp
+src/pointers.h            @sjplimp
+src/atom.*                @sjplimp
+src/atom_vec.*            @sjplimp
+src/angle.*               @sjplimp
+src/bond.*                @sjplimp
+src/comm*.*               @sjplimp
+src/compute.*             @sjplimp
+src/dihedral.*            @sjplimp
+src/domain.*              @sjplimp
+src/dump*.*               @sjplimp
+src/error.*               @sjplimp
+src/finish.*              @sjplimp
+src/fix.*                 @sjplimp
+src/force.*               @sjplimp
+src/group.*               @sjplimp
+src/improper.*            @sjplimp
+src/kspace.*              @sjplimp
+src/lmptyp.h              @sjplimp
+src/library.*             @sjplimp
+src/main.cpp              @sjplimp
+src/memory.*              @sjplimp
+src/modify.*              @sjplimp
+src/molecule.*            @sjplimp
+src/my_page.h             @sjplimp
+src/my_pool_chunk.h       @sjplimp
+src/npair*.*              @sjplimp
+src/ntopo*.*              @sjplimp
+src/nstencil*.*           @sjplimp
+src/neighbor.*            @sjplimp
+src/nbin*.*               @sjplimp
+src/neigh_*.*             @sjplimp
+src/output.*              @sjplimp
+src/pair.*                @sjplimp
+src/rcb.*                 @sjplimp
+src/random_*.*            @sjplimp
+src/region*.*             @sjplimp
+src/rcb.*                 @sjplimp
+src/read*.*               @sjplimp
+src/rerun.*               @sjplimp
+src/run.*                 @sjplimp
+src/respa.*               @sjplimp
+src/set.*                 @sjplimp
+src/special.*             @sjplimp
+src/suffix.h              @sjplimp
+src/thermo.*              @sjplimp
+src/universe.*            @sjplimp
+src/update.*              @sjplimp
+src/variable.*            @sjplimp
+src/verlet.*              @sjplimp
+src/velocity.*            @sjplimp
+src/write_data.*          @sjplimp
+src/write_restart.*       @sjplimp
+
+# overrides for specific files
+src/dump_movie.*          @akohlmey
+src/exceptions.h          @rbberger
+src/fix_nh.*              @athomps
+src/info.*                @akohlmey @rbberger
+src/timer.*               @akohlmey
 
 # tools
 tools/msi2lmp/*       @akohlmey
@@ -57,3 +126,6 @@ python/*              @rbberger
 doc/utils/*/*         @rbberger
 doc/Makefile          @rbberger
 doc/README            @rbberger
+
+# for releases
+src/version.h         @sjplimp

.github/CODE_OF_CONDUCT.md

@@ -0,0 +1,67 @@
+# Code of Conduct for the LAMMPS Project on GitHub
+
+## Our Pledge
+
+In the interest of fostering an open and welcoming environment, we as LAMMPS
+developers, contributors, and maintainers pledge to making participation in
+our project a harassment-free experience for everyone.
+
+## Our Standards
+
+Examples of behavior that contributes to creating a positive environment
+include:
+
+* Using welcoming and inclusive language
+* Being respectful of differing viewpoints and experiences
+* Gracefully accepting constructive criticism
+* Focusing on what is best for the community
+* Showing empathy towards other community members
+
+Examples of unacceptable behavior by participants include:
+
+* The use of explicit language or imagery
+* Trolling, insulting/derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or electronic
+  address, without explicit permission
+
+## Our Responsibilities
+
+Project maintainers are responsible for clarifying the standards of acceptable
+behavior and are expected to take appropriate and fair corrective action in
+response to any instances of unacceptable behavior.
+
+Project maintainers have the right and responsibility to remove, edit, or
+reject comments, commits, code, issues, and other contributions that are not
+aligned to this Code of Conduct, or to ban temporarily or permanently any
+developer, maintainer, or contributor for this or other behaviors that they
+deem inappropriate, threatening, offensive, or harmful.
+
+## Scope
+
+This Code of Conduct applies to all public exchanges in the LAMMPS project
+on GitHub and in submitted code.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported by contacting the project team at developer@lammps.org. All
+complaints will be reviewed and investigated and will result in a response
+that is deemed necessary and appropriate to the circumstances. The project
+team is obligated to maintain confidentiality with regard to the reporter
+of an incident.
+
+Project maintainers who do not follow or enforce the Code of Conduct in good
+faith may face temporary or permanent repercussions as determined by other
+members of the project's leadership.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
+available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
+
+[homepage]: https://www.contributor-covenant.org
+
+For answers to common questions about this code of conduct, see
+https://www.contributor-covenant.org/faq
+

.github/CONTRIBUTING.md

@@ -2,11 +2,11 @@
 
 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 workflows 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:
-* [The Section on submitting new features for inclusion in LAMMPS of the Manual](http://lammps.sandia.gov/doc/Section_modify.html#mod-15)
-* [The LAMMPS GitHub Tutorial in the Manual](http://lammps.sandia.gov/doc/tutorial_github.html)
+* [The Section on submitting new features for inclusion in LAMMPS of the Manual](https://lammps.sandia.gov/doc/Modify_contribute.html)
+* [The LAMMPS GitHub Tutorial in the Manual](http://lammps.sandia.gov/doc/Howto_github.html)
 
 ## Table of Contents
 
@@ -18,7 +18,7 @@ Thus please also have a look at:
 * [Suggesting Enhancements](#suggesting-enhancements)
 * [Contributing Code](#contributing-code)
 
-[GitHub Workflows](#github-workflows)
+[GitHub Work flows](#github-workflows)
 * [Issues](#issues)
 * [Pull Requests](#pull-requests)
 
@@ -26,17 +26,17 @@ __
 
 ## 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 the ['lammps-users' mailing list](http://lammps.sandia.gov/mail.html). 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](http://lammps.sandia.gov/guidelines.html). Following those guidelines will help greatly to get a helpful response. Always mention which LAMMPS version you are using.
+> **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 the ['lammps-users' mailing list](https://lammps.sandia.gov/mail.html). 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.
 
 ## 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), and you can contribute by submitting pull requests on GitHub or e-mail your code
-to one of the [LAMMPS core developers](http://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
 
 The LAMMPS mailing list is hosted at SourceForge. The mailing list began in 2005, and now includes tens of thousands of messages in thousands of threads. LAMMPS developers try to respond to posted questions in a timely manner, but there are no guarantees. Please consider that people live in different timezone and may not have time to answer e-mails outside of their work hours.
-You can post to list by sending your email to lammps-users at lists.sourceforge.net (no subscription required), but before posting, please read the [mailing list guidelines](http://lammps.sandia.gov/guidelines.html) to maximize your chances to receive a helpful response.
+You can post to list by sending your email to lammps-users at lists.sourceforge.net (no subscription required), but before posting, please read the [mailing list guidelines](https://lammps.sandia.gov/guidelines.html) to maximize your chances to receive a helpful response.
 
 Anyone can browse/search previous questions/answers in the archives. You do not have to subscribe to the list to post questions, receive answers (to your questions), or browse/search the archives. You **do** need to subscribe to the list if you want emails for **all** the posts (as individual messages or in digest form), or to answer questions yourself. Feel free to sign up and help us out! Answering questions from fellow LAMMPS users is a great way to pay back the community for providing you a useful tool for free, and to pass on the advice you have received yourself to others. It improves your karma and helps you understand your own research better.
 
@@ -44,7 +44,7 @@ If you post a message and you are a subscriber, your message will appear immedia
 
 ### Reporting Bugs
 
-While developers writing code for LAMMPS are careful to test their code, LAMMPS is such a large and complex software, that it is impossible to test for all combinations of features under all normal and not so normal circumstances. Thus bugs do happen, and if you suspect, that you have encountered one, please try to document it and report it as an [Issue](https://github.com/lammps/lammps/issues) on the LAMMPS GitHub project web page. However, before reporting a bug, you need to check whether this is something that may have already been corrected. The [Latest Features and Bug Fixes in LAMMPS](http://lammps.sandia.gov/bug.html) web page lists all significant changes to LAMMPS over the years. It also tells you what the current latest development version of LAMMPS is, and you should test whether your issue still applies to that version.
+While developers writing code for LAMMPS are careful to test their code, LAMMPS is such a large and complex software, that it is impossible to test for all combinations of features under all normal and not so normal circumstances. Thus bugs do happen, and if you suspect, that you have encountered one, please try to document it and report it as an [Issue](https://github.com/lammps/lammps/issues) on the LAMMPS GitHub project web page. However, before reporting a bug, you need to check whether this is something that may have already been corrected. The [Latest Features and Bug Fixes in LAMMPS](https://lammps.sandia.gov/bug.html) web page lists all significant changes to LAMMPS over the years. It also tells you what the current latest development version of LAMMPS is, and you should test whether your issue still applies to that version.
 
 When you click on the green "New Issue" button, you will be provided with a text field, where you can enter your message. That text field with contain a template with several headlines and some descriptions. Keep the headlines that are relevant to your reported potential bug and replace the descriptions with the information as suggested by the descriptions.
 You can also attach small text files (please add the file name extension `.txt` or it will be rejected), images, or small compressed text files (using gzip, do not use RAR or 7-ZIP or similar tools that are uncommon outside of Windows machines). In many cases, bugs are best illustrated by providing a small input deck (do **not** attach your entire production input, but remove everything that is not required to reproduce the issue, and scale down your system size, that the resulting calculation runs fast and can be run on small desktop quickly).
@@ -62,13 +62,13 @@ To be able to submit an issue on GitHub, you have to register for an account (fo
 
 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.
 
-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](http://lammps.sandia.gov/doc/tutorial_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.
 
 * 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 lines over 80 characters. I/O is done via the C-style stdio library, class header files should not import any system headers outside <stdio.h>, 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. Header files must not import namespaces with using. 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.
+* 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 lines over 80 characters. I/O is done via the C-style stdio library, style class header files should not import any system headers outside of <cstdio>, 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.
 * 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.
@@ -102,11 +102,11 @@ For bug reports, the next step is that one of the core LAMMPS developers will se
 
 ### Pull Requests
 
-For submitting pull requests, there is a [detailed tutorial](http://lammps.sandia.gov/doc/tutorial_github.html) in the LAMMPS manual. Thus only a brief breakdown of the steps is presented here.
+For submitting pull requests, there is a [detailed tutorial](https://lammps.sandia.gov/doc/Howto_github.html) in the LAMMPS manual. Thus only a brief breakdown of the steps is presented here. Please note, that the LAMMPS developers are still reviewing and trying to improve the process. If you are unsure about something, do not hesitate to post a question on the lammps-users mailing list or contact one fo the core LAMMPS developers.
 Immediately after the submission, the LAMMPS continuing integration server at ci.lammps.org will download your submitted branch and perform a simple compilation test, i.e. will test whether your submitted code can be compiled under various conditions. It will also do a check on whether your included documentation translates cleanly. Whether these tests are successful or fail will be recorded. If a test fails, please inspect the corresponding output on the CI server and take the necessary steps, if needed, so that the code can compile cleanly again. The test will be re-run each the pull request is updated with a push to the remote branch on GitHub.
-Next a LAMMPS core developer will self-assign and do an overall technical assessment of the submission. If you are not yet registered as a LAMMPS collaborator, you will receive an invitation for that.
-You may also receive comments and suggestions on the overall submission or specific details. If permitted, 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.
+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 assesment, the pull request will be categorized with labels. There are two special labels: `needs_work` (indicates that work from the submitter of the pull request is needed) and `work_in_progress` (indicates, that the assigned LAMMPS developer will make changes, if not done by the contributor who made the submit). 
+You may also receive comments and suggestions on the overall submission or specific details and on occasion specific requests for changes as part of the review. If permitted, also additional changes may be pushed into your pull request branch or a pull request may be filed in your LAMMPS fork on GitHub to include those changes.
 The LAMMPS developer may then decide to assign the pull request to another developer (e.g. when that developer is more knowledgeable about the submitted feature or enhancement or has written the modified code). It may also happen, that additional developers are requested to provide a review and approve the changes. For submissions, that may change the general behavior of LAMMPS, or where a possibility of unwanted side effects exists, additional tests may be requested by the assigned developer.
-If the assigned developer is satisfied and considers the submission ready for inclusion into LAMMPS, the pull request will be assigned to the LAMMPS lead developer, Steve Plimpton (@sjplimp), who will then have the final decision on whether the submission will be included, additional changes are required or it will be ultimately rejected. After the pull request is merged, you may delete the pull request branch in your personal LAMMPS fork.
-Since the learning curve for git is quite steep for efficiently managing remote repositories, local and remote branches, pull requests and more, do not hesitate to ask questions, if you are not sure about how to do certain steps that are asked of you. Even if the changes asked of you do not make sense to you, they may be important for the LAMMPS developers. Please also note, that these all are guidelines and not set in stone.
+If the assigned developer is satisfied and considers the submission ready for inclusion into LAMMPS, the pull request will receive approvals and be merged into the master branch by one of the core LAMMPS developers. After the pull request is merged, you may delete the feature branch used for the pull request in your personal LAMMPS fork.
+Since the learning curve for git is quite steep for efficiently managing remote repositories, local and remote branches, pull requests and more, do not hesitate to ask questions, if you are not sure about how to do certain steps that are asked of you. Even if the changes asked of you do not make sense to you, they may be important for the LAMMPS developers. Please also note, that these all are guidelines and nothing set in stone. So depending on the nature of the contribution, the workflow may be adjusted.
 

.github/ISSUE_TEMPLATE.md

@@ -1,31 +0,0 @@
-## Summary
-
-_Please provide a brief description of the issue_
-
-## Type of Issue
-
-_Is this a 'Bug Report' or a 'Suggestion for an Enhancement'?_
-
-## Detailed Description (Enhancement Suggestion)
-
-_Explain how you would like to see LAMMPS enhanced, what feature(s) you are looking for, provide references to relevant background information, and whether you are willing to implement the enhancement yourself or would like to participate in the implementation_
-
-## LAMMPS Version (Bug Report)
-
-_Please specify which LAMMPS version this issue was detected with. If this is not the latest development version, please stop and test that version, too, and report it here if the bug persists_
-
-## Expected Behavior (Bug Report)
-
-_Describe the expected behavior. Quote from the LAMMPS manual where needed or explain why the expected behavior is meaningful, especially when it differs from the manual_
-
-## Actual Behavior (Bug Report)
-
-_Describe the actual behavior, how it differs from the expected behavior, and how this can be observed. Try to be specific and do **not* use vague terms like "doesn't work" or "wrong result". Do not assume that the person reading this has any experience with or knowledge of your specific research._
-
-## Steps to Reproduce (Bug Report)
-
-_Describe the steps required to quickly reproduce the issue. You can attach (small) files to the section below or add URLs where to download an archive with all necessary files. Please try to create input that are as small as possible and run as fast as possible. NOTE: the less effort and time it takes to reproduce your issue, the more likely, that somebody will look into it._
-
-## Further Information, Files, and Links
-
-_Put any additional information here, attach relevant text or image files and URLs to external sites, e.g. relevant publications_

.github/ISSUE_TEMPLATE/bug_report.md

@@ -0,0 +1,32 @@
+---
+name: Bug report
+about: Create a bug report to help us eliminate issues and improve LAMMPS
+title: "[BUG] _Replace With Suitable Title_"
+labels: bug
+assignees: ''
+
+---
+
+**Summary**
+
+_Please provide a clear and concise description of what the bug is._
+
+**LAMMPS Version and Platform**
+
+_Please specify precisely which LAMMPS version this issue was detected with (the first line of the output) and what platform (operating system and its version, hardware) you are running on. If possible, test with the most recent LAMMPS patch version_
+
+**Expected Behavior**
+
+_Describe the expected behavior.  Quote from the LAMMPS manual where needed, or explain why the expected behavior is meaningful, especially when it differs from the manual_
+
+**Actual Behavior**
+
+_Describe the actual behavior, how it differs from the expected behavior, and how this can be observed.  Try to be specific and do **not** use vague terms like "doesn't work" or "wrong result".  Do not assume that the person reading this has any experience with or knowledge of your specific area of research._
+
+**Steps to Reproduce**
+
+_Describe the steps required to (quickly) reproduce the issue. You can attach (small) files to the section below or add URLs where to download an archive with all necessary files. Please try to create an input set that is as minimal and small as possible and reproduces the bug as quickly as possible. **NOTE:** the less effort and time it takes to reproduce your reported bug, the more likely it becomes, that somebody will look into it and fix the problem._
+
+**Further Information, Files, and Links**
+
+_Put any additional information here, attach relevant text or image files and URLs to external sites, e.g. relevant publications_

.github/ISSUE_TEMPLATE/feature_request.md

@@ -0,0 +1,20 @@
+---
+name: Feature request
+about: Make a suggestion for a new feature or a change to LAMMPS
+title: "[Feature Request] _Replace with Title_"
+labels: enhancement
+assignees: ''
+
+---
+
+**Summary**
+
+_Please provide a brief and concise description of the suggested feature or change_
+
+**Detailed Description**
+
+_Please explain how you would like to see LAMMPS enhanced, what feature(s) you are looking for, what specific problems this will solve. If possible, provide references to relevant background information like publications or web pages, and whether you are planning to implement the enhancement yourself or would like to participate in the implementation. If applicable add a reference to an existing bug report or issue that this will address._
+
+**Further Information, Files, and Links**
+
+_Put any additional information here, attach relevant text or image files and URLs to external sites, e.g. relevant publications_

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,28 +1,46 @@
-## Purpose
+**Summary**
 
-_Briefly describe the new feature(s), enhancement(s), or bugfix(es) included in this pull request. If this addresses an open GitHub Issue, mention the issue number, e.g. with `fixes #221` or `closes #135`, so that issue will be automatically closed when the pull request is merged_
+_Briefly describe the new feature(s), enhancement(s), or bugfix(es) included in this pull request._
 
-## Author(s)
+**Related Issues**
 
-_Please state name and affiliation of the author or authors that should be credited with the changes in this pull request_
+__If this addresses an open GitHub Issue, mention the issue number here. Use the phrases `fixes #221` or `closes #135`, when you want those issues to be automatically closed when the pull request is merged_
 
-## Backward Compatibility
+**Author(s)**
+
+_Please state name and affiliation of the author or authors that should be credited with the changes in this pull request. If this pull request adds new files to the distribution, please also provide a suitable "long-lived" e-mail address (e.g. from gmail, yahoo, outlook, etc.) for the *corresponding* author, i.e. the person the LAMMPS developers can contact directly with questions and requests related to maintenance and support of this code. now and in the future_
+
+**Licensing**
+
+By submitting this pull request, I agree, that my contribution will be included in LAMMPS and redistributed under the GNU General Public License version 2.
+
+_Please complete the following statement by adding "yes" or "no":_
+My contribution may be re-licensed as LGPL (for use of LAMMPS as a library linked to proprietary software):
+
+**Backward Compatibility**
 
 _Please state whether any changes in the pull request break backward compatibility for inputs, and - if yes - explain what has been changed and why_
 
-## Implementation Notes
+**Implementation Notes**
 
 _Provide any relevant details about how the changes are implemented, how correctness was verified, how other features - if any - in LAMMPS are affected_
 
-## Post Submission Checklist
+**Post Submission Checklist**
+
+_Please check the fields below as they are completed **after** the pull request has been submitted_
 
-_Please check the fields below as they are completed_
 - [ ] The feature or features in this pull request is complete
-- [ ] Suitable new documentation files and/or updates to the existing docs are included
-- [ ] One or more example input decks are included
+- [ ] Licensing information is complete
+- [ ] Corresponding author information is complete
 - [ ] The source code follows the LAMMPS formatting guidelines
+- [ ] Suitable new documentation files and/or updates to the existing docs are included
+- [ ] The added/updated documentation is integrated and tested with the documentation build system
+- [ ] The feature has been verified to work with the conventional build system
+- [ ] The feature has been verified to work with the CMake based build system
+- [ ] A package specific README file has been included or updated
+- [ ] One or more example input decks are included
 
-## Further Information, Files, and Links
+**Further Information, Files, and Links**
 
 _Put any additional information here, attach relevant text or image files, and URLs to external sites (e.g. DOIs or webpages)_
 

.github/PULL_REQUEST_TEMPLATE/bug_fix.md

@@ -0,0 +1,42 @@
+---
+name: Bug fix
+about: Submit a pull request that fixes one or more bugs
+title: "[BUGFIX] _Replace With Suitable Title_"
+labels: bugfix
+assignees: ''
+
+---
+
+**Summary**
+
+_Briefly describe the bug or bugs, that are eliminated by this pull request._
+
+**Related Issue(s)**
+
+_If this request addresses or is related to an existing (open) GitHub issue, e.g. a bug report, mention the issue number number here following a pound sign (aka hashmark), e.g.`#222`._
+
+**Author(s)**
+
+_Please state name and affiliation of the author or authors that should be credited with the changes in this pull request_
+
+**Licensing**
+
+By submitting this pull request I implicitly accept, that my submission is subject to the same licensing terms as the files that are modified.
+
+**Backward Compatibility**
+
+_Please state whether any changes in the pull request break backward compatibility for inputs, and - if yes - explain what has been changed and why_
+
+**Detailed Description**
+
+_Provide any relevant details about how the fixed bug can be reproduced, how the changes are implemented, how correctness was verified, how other features - if any - in LAMMPS are affected_
+
+## Post Submission Checklist
+
+_Please check the fields below as they are completed *after* the pull request is submitted_
+- [ ] The code in this pull request is complete
+- [ ] The source code follows the LAMMPS formatting guidelines
+
+## Further Information, Files, and Links
+
+_Put any additional information here, attach relevant text or image files, and URLs to external sites (e.g. to download input decks for testing)_

.github/PULL_REQUEST_TEMPLATE/maintenance_refactoring.md

@@ -0,0 +1,35 @@
+---
+name: Maintenance or Refactoring
+about: Submit a pull request that does code refactoring or other maintenance changes
+title: "[MAINTENANCE] _Replace With Suitable Title_"
+labels: maintenance
+assignees: ''
+
+---
+
+**Summary**
+
+_Briefly describe the included changes._
+
+**Related Issue(s)**
+
+_If this request addresses or is related to an existing (open) GitHub issue, e.g. a bug report, mention the issue number number here following a pound sign (aka hashmark), e.g.`#222`.
+
+**Author(s)**
+
+_Please state name and affiliation of the author or authors that should be credited with the changes in this pull request_
+
+**Licensing**
+
+By submitting this pull request I implicitly accept, that my submission is subject to the same licensing terms as the files that are modified.
+
+**Detailed Description**
+
+_Provide any relevant details about the included changes._
+
+## Post Submission Checklist
+
+_Please check the fields below as they are completed *after* the pull request is submitted_
+- [ ] The pull request is complete
+- [ ] The source code follows the LAMMPS formatting guidelines
+

.github/PULL_REQUEST_TEMPLATE/new_feature.md

@@ -0,0 +1,56 @@
+---
+name: New Feature
+about: Submit a pull request that adds new Features (complete files) to LAMMPS
+title: "[New Feature] _Replace With Suitable Title_"
+labels: enhancement
+assignees: ''
+
+---
+
+**Summary**
+
+_Briefly describe the new feature(s) included in this pull request._
+
+**Related Issues**
+
+_If this addresses an existing (open) GitHub issue, e.g. a feature request, mention the issue number here following a pound sign (aka hashmark), e.g. `#331`._
+
+**Author(s)**
+
+_Please state name and affiliation of the author or authors that should be credited with the features added in this pull request. Please provide a suitable "long-lived" e-mail address (e.g. from gmail, yahoo, outlook, etc.) for the *corresponding* author, i.e. the person the LAMMPS developers can contact directly with questions and requests related to maintenance and support of this code. now and in the future_
+
+**Licensing**
+
+_Please add *yes* or *no* to the following two statements (please contact @lammps/core if you have questions about this)_
+
+My contribution may be licensed as GPL v2 (default LAMMPS license):
+My contribution may be licensed as LGPL (for use as a library with proprietary software):
+
+**Backward Compatibility**
+
+_Please state if any of the changes in this pull request will affect backward compatibility for inputs, and - if yes - explain what has been changed and why_
+
+**Implementation Notes**
+
+_Provide any relevant details about how the new features are implemented, how correctness was verified, what platforms (OS, compiler, MPI, hardware, number of processors, accelerator(s)) it was tested on_
+
+## Post Submission Checklist
+
+_Please check the fields below as they are completed *after* the pull request has been submitted_
+
+- [ ] The feature or features in this pull request is complete
+- [ ] Licensing information is complete
+- [ ] Corresponding author information is complete
+- [ ] The source code follows the LAMMPS formatting guidelines
+- [ ] Suitable new documentation files and/or updates to the existing docs are included
+- [ ] The added/updated documentation is integrated and tested with the documentation build system
+- [ ] The feature has been verified to work with the conventional build system
+- [ ] The feature has been verified to work with the CMake based build system
+- [ ] A package specific README file has been included or updated
+- [ ] One or more example input decks are included
+
+## Further Information, Files, and Links
+
+_Put any additional information here, attach relevant text or image files, and URLs to external sites (e.g. DOIs or webpages)_
+
+

.github/PULL_REQUEST_TEMPLATE/update_enhancement.md

@@ -0,0 +1,42 @@
+---
+name: Update or Enhancement
+about: Submit a pull request that provides update or enhancements for a package or feature in LAMMPS
+title: "[UPDATE] _Replace With Suitable Title_"
+labels: enhancement
+assignees: ''
+
+---
+
+**Summary**
+
+_Briefly describe what kind of updates or enhancements for a package or feature are included. If you are not the original author of the package or feature, please mention, whether your contribution was created independently or in collaboration/cooperation with the original author._
+
+**Author(s)**
+
+_Please state name and affiliation of the author or authors that should be credited with the changes in this pull request_
+
+**Licensing**
+
+By submitting this pull request I implicitly accept, that my submission is subject to the same licensing terms as the original package or feature(s) that are updated or amended by this pull request.
+
+**Backward Compatibility**
+
+_Please state whether any changes in the pull request break backward compatibility for inputs, and - if yes - explain what has been changed and why_
+
+**Implementation Notes**
+
+_Provide any relevant details about how the changes are implemented, how correctness was verified, how other features - if any - in LAMMPS are affected_
+
+**Post Submission Checklist**
+
+_Please check the fields below as they are completed_
+- [ ] The feature or features in this pull request is complete
+- [ ] Suitable updates to the existing docs are included
+- [ ] One or more example input decks are included
+- [ ] The source code follows the LAMMPS formatting guidelines
+
+**Further Information, Files, and Links**
+
+_Put any additional information here, attach relevant text or image files, and URLs to external sites (e.g. DOIs or webpages)_
+
+

.gitignore

@@ -1,6 +1,7 @@
 *~
 *.o
 *.so
+*.lo
 *.cu_o
 *.ptx
 *_ptx.h
@@ -21,6 +22,7 @@ log.cite
 .*.swp
 *.orig
 *.rej
+vgcore.*
 .vagrant
 \#*#
 .#*
@@ -32,6 +34,7 @@ log.cite
 .Trashes
 ehthumbs.db
 Thumbs.db
+.clang-format
 
 #cmake
 /build*

README

@@ -36,7 +36,14 @@ tools			   pre- and post-processing tools
 
 Point your browser at any of these files to get started:
 
-doc/Manual.html	           the LAMMPS manual
-doc/Section_intro.html	   hi-level introduction to LAMMPS
-doc/Section_start.html	   how to build and use LAMMPS
-doc/Developer.pdf          LAMMPS developer guide
+http://lammps.sandia.gov/doc/Manual.html         the LAMMPS manual
+http://lammps.sandia.gov/doc/Intro.html          hi-level introduction
+http://lammps.sandia.gov/doc/Build.html          how to build LAMMPS
+http://lammps.sandia.gov/doc/Run_head.html       how to run LAMMPS
+http://lammps.sandia.gov/doc/Developer.pdf       LAMMPS developer guide
+
+You can also create these doc pages locally:
+
+% cd doc
+% make html                # creates HTML pages in doc/html
+% make pdf                 # creates Manual.pdf and Developer.pdf

cmake/FindLAMMPS.cmake.in

@@ -0,0 +1,48 @@
+# - Find liblammps
+# Find the native liblammps headers and libraries.
+#
+# The following variables will set:
+#  LAMMPS_INCLUDE_DIRS - where to find lammps/library.h, etc.
+#  LAMMPS_LIBRARIES    - List of libraries when using lammps.
+#  LAMMPS_API_DEFINES  - lammps library api defines
+#  LAMMPS_VERSION      - lammps library version 
+#  LAMMPS_FOUND        - True if liblammps found.
+#
+# In addition a LAMMPS::LAMMPS imported target is getting created.
+#
+#  LAMMPS - Large-scale Atomic/Molecular Massively Parallel Simulator
+#  http://lammps.sandia.gov, Sandia National Laboratories
+#  Steve Plimpton, sjplimp@sandia.gov
+#
+#  Copyright (2003) Sandia Corporation.  Under the terms of Contract
+#  DE-AC04-94AL85000 with Sandia Corporation, the U.S. Government retains
+#  certain rights in this software.  This software is distributed under
+#  the GNU General Public License.
+#
+#  See the README file in the top-level LAMMPS directory.
+#
+
+find_package(PkgConfig)
+
+pkg_check_modules(PC_LAMMPS liblammps@LAMMPS_LIB_SUFFIX@)
+find_path(LAMMPS_INCLUDE_DIR lammps/library.h HINTS ${PC_LAMMPS_INCLUDE_DIRS} @CMAKE_INSTALL_FULL_INCLUDEDIR@)
+
+set(LAMMPS_VERSION @LAMMPS_VERSION@)
+set(LAMMPS_API_DEFINES @LAMMPS_API_DEFINES@)
+
+find_library(LAMMPS_LIBRARY NAMES lammps@LAMMPS_LIB_SUFFIX@ HINTS ${PC_LAMMPS_LIBRARY_DIRS} @CMAKE_INSTALL_FULL_LIBDIR@)
+
+set(LAMMPS_INCLUDE_DIRS "${LAMMPS_INCLUDE_DIR}")
+set(LAMMPS_LIBRARIES "${LAMMPS_LIBRARY}")
+
+include(FindPackageHandleStandardArgs)
+# handle the QUIETLY and REQUIRED arguments and set LAMMPS_FOUND to TRUE
+# if all listed variables are TRUE
+find_package_handle_standard_args(LAMMPS REQUIRED_VARS LAMMPS_LIBRARY LAMMPS_INCLUDE_DIR VERSION_VAR LAMMPS_VERSION)
+
+mark_as_advanced(LAMMPS_INCLUDE_DIR LAMMPS_LIBRARY)
+
+if(LAMMPS_FOUND AND NOT TARGET LAMMPS::LAMMPS)
+  add_library(LAMMPS::LAMMPS UNKNOWN IMPORTED)
+  set_target_properties(LAMMPS::LAMMPS PROPERTIES IMPORTED_LOCATION "${LAMMPS_LIBRARY}" INTERFACE_INCLUDE_DIRECTORIES "${LAMMPS_INCLUDE_DIR}" INTERFACE_COMPILE_DEFINITIONS "${LAMMPS_API_DEFINES}")
+endif()

cmake/Modules/FindQUIP.cmake

@@ -1,8 +1,8 @@
 # - Find quip
 # Find the native QUIP libraries.
 #
-#  QUIP_LIBRARIES    - List of libraries when using fftw3.
-#  QUIP_FOUND        - True if fftw3 found.
+#  QUIP_LIBRARIES    - List of libraries of the QUIP package
+#  QUIP_FOUND        - True if QUIP library was found.
 #
 
 find_library(QUIP_LIBRARY NAMES quip)

cmake/Modules/FindTBB.cmake

@@ -0,0 +1,46 @@
+# - Find parts of TBB
+# Find the native TBB headers and libraries.
+#
+#  TBB_INCLUDE_DIRS - where to find tbb.h, etc.
+#  TBB_LIBRARIES    - List of libraries when using tbb.
+#  TBB_FOUND        - True if tbb found.
+#
+
+########################################################
+# TBB
+
+# TODO use more generic FindTBB
+
+find_path(TBB_INCLUDE_DIR NAMES tbb/tbb.h PATHS $ENV{TBBROOT}/include)
+find_library(TBB_LIBRARY NAMES tbb PATHS $ENV{TBBROOT}/lib/intel64/gcc4.7
+                                         $ENV{TBBROOT}/lib/intel64/gcc4.4
+                                         $ENV{TBBROOT}/lib/intel64/gcc4.1)
+set(TBB_LIBRARIES ${TBB_LIBRARY})
+set(TBB_INCLUDE_DIRS ${TBB_INCLUDE_DIR})
+
+include(FindPackageHandleStandardArgs)
+# handle the QUIETLY and REQUIRED arguments and set TBB_FOUND to TRUE
+# if all listed variables are TRUE
+
+find_package_handle_standard_args(TBB DEFAULT_MSG TBB_LIBRARY TBB_INCLUDE_DIR)
+
+mark_as_advanced(TBB_INCLUDE_DIR TBB_LIBRARY )
+
+########################################################
+# TBB Malloc
+
+find_path(TBB_MALLOC_INCLUDE_DIR NAMES tbb/tbb.h PATHS $ENV{TBBROOT}/include)
+find_library(TBB_MALLOC_LIBRARY NAMES tbbmalloc PATHS $ENV{TBBROOT}/lib/intel64/gcc4.7
+                                                      $ENV{TBBROOT}/lib/intel64/gcc4.4
+                                                      $ENV{TBBROOT}/lib/intel64/gcc4.1)
+
+set(TBB_MALLOC_LIBRARIES ${TBB_MALLOC_LIBRARY})
+set(TBB_MALLOC_INCLUDE_DIRS ${TBB_MALLOC_INCLUDE_DIR})
+
+include(FindPackageHandleStandardArgs)
+# handle the QUIETLY and REQUIRED arguments and set TBB_MALLOC_FOUND to TRUE
+# if all listed variables are TRUE
+
+find_package_handle_standard_args(TBB_MALLOC DEFAULT_MSG TBB_MALLOC_LIBRARY TBB_MALLOC_INCLUDE_DIR)
+
+mark_as_advanced(TBB_MALLOC_INCLUDE_DIR TBB_MALLOC_LIBRARY )

cmake/Modules/FindZMQ.cmake

@@ -0,0 +1,8 @@
+find_path(ZMQ_INCLUDE_DIR zmq.h)
+find_library(ZMQ_LIBRARY NAMES zmq)
+
+set(ZMQ_LIBRARIES ${ZMQ_LIBRARY})
+set(ZMQ_INCLUDE_DIRS ${ZMQ_INCLUDE_DIR})
+
+include(FindPackageHandleStandardArgs)
+find_package_handle_standard_args(ZMQ DEFAULT_MSG ZMQ_LIBRARY ZMQ_INCLUDE_DIR)

cmake/Modules/PreventInSourceBuilds.cmake

@@ -0,0 +1,23 @@
+# - Prevent in-source builds.
+# https://stackoverflow.com/questions/1208681/with-cmake-how-would-you-disable-in-source-builds/
+
+function(prevent_in_source_builds)
+  # make sure the user doesn't play dirty with symlinks
+  get_filename_component(srcdir "${CMAKE_SOURCE_DIR}" REALPATH)
+  get_filename_component(srcdir2 "${CMAKE_SOURCE_DIR}/.." REALPATH)
+  get_filename_component(srcdir3 "${CMAKE_SOURCE_DIR}/../src" REALPATH)
+  get_filename_component(bindir "${CMAKE_BINARY_DIR}" REALPATH)
+
+  # disallow in-source builds
+  if("${srcdir}" STREQUAL "${bindir}" OR "${srcdir2}" STREQUAL "${bindir}" OR "${srcdir3}" STREQUAL "${bindir}")
+    message(FATAL_ERROR "\
+
+CMake must not to be run in the source directory. \
+Rather create a dedicated build directory and run CMake there. \
+To clean up after this aborted in-place compilation:
+  rm -r CMakeCache.txt CMakeFiles
+")
+  endif()
+endfunction()
+
+prevent_in_source_builds()

cmake/Modules/StyleHeaderUtils.cmake

@@ -48,8 +48,13 @@ function(CreateStyleHeader path filename)
     set(temp "")
     if(ARGC GREATER 2)
         list(REMOVE_AT ARGV 0 1)
+        set(header_list)
         foreach(FNAME ${ARGV})
             get_filename_component(FNAME ${FNAME} NAME)
+            list(APPEND header_list ${FNAME})
+        endforeach()
+        list(SORT header_list)
+        foreach(FNAME ${header_list})
             set(temp "${temp}#include \"${FNAME}\"\n")
         endforeach()
     endif()
@@ -80,19 +85,23 @@ function(RegisterNPairStyle path)
     AddStyleHeader(${path} NPAIR)
 endfunction(RegisterNPairStyle)
 
+function(RegisterFixStyle path)
+    AddStyleHeader(${path} FIX)
+endfunction(RegisterFixStyle)
+
 function(RegisterStyles search_path)
     FindStyleHeaders(${search_path} ANGLE_CLASS     angle_     ANGLE     ) # angle     ) # force
     FindStyleHeaders(${search_path} ATOM_CLASS      atom_vec_  ATOM_VEC  ) # atom      ) # atom      atom_vec_hybrid
     FindStyleHeaders(${search_path} BODY_CLASS      body_      BODY      ) # body      ) # atom_vec_body
     FindStyleHeaders(${search_path} BOND_CLASS      bond_      BOND      ) # bond      ) # force
-    FindStyleHeaders(${search_path} COMMAND_CLASS   ""         COMMAND   ) # command   ) # input
+    FindStyleHeaders(${search_path} COMMAND_CLASS   "[^.]"     COMMAND   ) # command   ) # input
     FindStyleHeaders(${search_path} COMPUTE_CLASS   compute_   COMPUTE   ) # compute   ) # modify
     FindStyleHeaders(${search_path} DIHEDRAL_CLASS  dihedral_  DIHEDRAL  ) # dihedral  ) # force
     FindStyleHeaders(${search_path} DUMP_CLASS      dump_      DUMP      ) # dump      ) # output    write_dump
     FindStyleHeaders(${search_path} FIX_CLASS       fix_       FIX       ) # fix       ) # modify
     FindStyleHeaders(${search_path} IMPROPER_CLASS  improper_  IMPROPER  ) # improper  ) # force
-    FindStyleHeaders(${search_path} INTEGRATE_CLASS ""         INTEGRATE ) # integrate ) # update
-    FindStyleHeaders(${search_path} KSPACE_CLASS    ""         KSPACE    ) # kspace    ) # force
+    FindStyleHeaders(${search_path} INTEGRATE_CLASS "[^.]"     INTEGRATE ) # integrate ) # update
+    FindStyleHeaders(${search_path} KSPACE_CLASS    "[^.]"     KSPACE    ) # kspace    ) # force
     FindStyleHeaders(${search_path} MINIMIZE_CLASS  min_       MINIMIZE  ) # minimize  ) # update
     FindStyleHeaders(${search_path} NBIN_CLASS      nbin_      NBIN      ) # nbin      ) # neighbor
     FindStyleHeaders(${search_path} NPAIR_CLASS     npair_     NPAIR     ) # npair     ) # neighbor

cmake/README.md

@@ -24,7 +24,7 @@ tasks, act as a reference and provide examples of typical use cases.
       * [Build directory vs. Source Directory](#build-directory-vs-source-directory)
    * [Defining and using presets](#defining-and-using-presets)
    * [Reference](#reference)
-      * [Common CMAKE Configuration Options](#common-cmake-configuration-options)
+      * [Common CMake Configuration Options](#common-cmake-configuration-options)
       * [LAMMPS Configuration Options](#lammps-configuration-options)
       * [Parallelization and Accelerator Packages](#parallelization-and-accelerator-packages)
       * [Default Packages](#default-packages)
@@ -62,7 +62,7 @@ should get you started.
 git clone https://github.com/lammps/lammps.git
 mkdir lammps/build
 cd lammps/build
-cmake ../cmake [-DOPTION_A=VALUE_A -DOPTION_B=VALUE_B ...]
+cmake [-D OPTION_A=VALUE_A -D OPTION_B=VALUE_B ...] ../cmake
 make
 ```
 
@@ -174,12 +174,12 @@ presets can be found in the `cmake/presets` folder.
 # build LAMMPS with all "standard" packages which don't use libraries and enable GPU package
 mkdir build
 cd build
-cmake -C ../cmake/presets/std_nolib.cmake ../cmake -DPKG_GPU=on
+cmake -C ../cmake/presets/std_nolib.cmake -D PKG_GPU=on ../cmake
 ```
 
 # Reference
 
-## Common CMAKE Configuration Options
+## Common CMake Configuration Options
 
 
 <table>
@@ -195,6 +195,7 @@ cmake -C ../cmake/presets/std_nolib.cmake ../cmake -DPKG_GPU=on
   <td><code>CMAKE_INSTALL_PREFIX</code></td>
   <td>Install location where LAMMPS files will be copied to. In the Unix/Linux case with Makefiles this controls what `make install` will do.</td>
   <td>
+   Default setting is <code>$HOME/.local</code>.
   </td>
 </tr>
 <tr>
@@ -207,6 +208,16 @@ cmake -C ../cmake/presets/std_nolib.cmake ../cmake -DPKG_GPU=on
   </dl>
   </td>
 </tr>
+<tr>
+  <td><code><CMAKE_VERBOSE_MAKEFILE/code></td>
+  <td>Enable verbose output from Makefile builds (useful for debugging), the same can be achived by adding `VERBOSE=1` to the `make` call.</td>
+  <td>
+  <dl>
+    <dt><code>off</code> (default)</dt>
+    <dt><code>on</code></dt>
+  </dl>
+  </td>
+</tr>
 </tbody>
 </table>
 
@@ -265,6 +276,26 @@ cmake -C ../cmake/presets/std_nolib.cmake ../cmake -DPKG_GPU=on
   </dl>
   </td>
 </tr>
+<tr>
+  <td><code>BUILD_LIB</code></td>
+  <td>control whether to build LAMMPS as a library</td>
+  <td>
+  <dl>
+    <dt><code>off</code> (default)</dt>
+    <dt><code>on</code></dt>
+  </dl>
+  </td>
+</tr>
+<tr>
+  <td><code>BUILD_EXE</code></td>
+  <td>control whether to build LAMMPS executable</td>
+  <td>
+  <dl>
+    <dt><code>on</code> (default)</dt>
+    <dt><code>off</code></dt>
+  </dl>
+  </td>
+</tr>
 <tr>
   <td><code>BUILD_SHARED_LIBS</code></td>
   <td>control whether to build LAMMPS as a shared-library</td>
@@ -315,8 +346,8 @@ cmake -C ../cmake/presets/std_nolib.cmake ../cmake -DPKG_GPU=on
   `mpicxx` in your path and use this MPI implementation.</td>
   <td>
   <dl>
-    <dt><code>off</code> (default)</dt>
-    <dt><code>on</code></dt>
+    <dt><code>on</code> (default, if found)</dt>
+    <dt><code>off</code></dt>
   </dl>
   </td>
 </tr>
@@ -325,8 +356,8 @@ cmake -C ../cmake/presets/std_nolib.cmake ../cmake -DPKG_GPU=on
   <td>control whether to build LAMMPS with OpenMP support.</td>
   <td>
   <dl>
-    <dt><code>off</code> (default)</dt>
-    <dt><code>on</code></dt>
+    <dt><code>on</code> (default, if found)</dt>
+    <dt><code>off</code></dt>
   </dl>
   </td>
 </tr>
@@ -1271,7 +1302,7 @@ providing the identical features and USER interface.</strong></p>
   </td>
   <td>
   <dl>
-    <dt><code>KISSFFT</code></dt>
+    <dt><code>KISS</code></dt>
     <dt><code>FFTW3</code></dt>
     <dt><code>FFTW2</code></dt>
     <dt><code>MKL</code></dt>
@@ -1279,13 +1310,13 @@ providing the identical features and USER interface.</strong></p>
   </td>
 </tr>
 <tr>
-  <td><code>PACK_ARRAY</code></td>
+  <td><code>FFT_PACK</code></td>
   <td>Optimization for FFT</td>
   <td>
   <dl>
-    <dt><code>PACK_ARRAY</code></dt>
-    <dt><code>PACK_POINTER</code></dt>
-    <dt><code>PACK_MEMCPY</code></dt>
+    <dt><code>array (default)</code></dt>
+    <dt><code>pointer</code></dt>
+    <dt><code>memcpy</code></dt>
   </dl>
   </td>
 </tr>
@@ -1377,6 +1408,29 @@ TODO
 
 ### PYTHON Package
 
+### USER-INTEL Package
+
+<table>
+<thead>
+<tr>
+  <th>Option</th>
+  <th>Description</th>
+  <th>Values</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+  <td><code>INTEL_ARCH</code></td>
+  <td>Target architecture for USER-INTEL package</td>
+  <td>
+  <dl>
+    <dt><code>cpu</code> (default)</dt>
+    <dt><code>knl</code></dt>
+  </dl>
+  </td>
+</tr>
+</tbody>
+</table>
 
 ### GPU Package
 The GPU package builds a support library which can either use OpenCL or CUDA as
@@ -1396,8 +1450,8 @@ target API.
   <td>API used by GPU package</td>
   <td>
   <dl>
-    <dt><code>OpenCL</code> (default)</dt>
-    <dt><code>CUDA</code></dt>
+    <dt><code>opencl</code> (default)</dt>
+    <dt><code>cuda</code></dt>
   </dl>
   </td>
 </tr>
@@ -1406,9 +1460,9 @@ target API.
   <td>Precision size used by GPU package kernels</td>
   <td>
   <dl>
-    <dt><code>SINGLE_DOUBLE</code></dt>
-    <dt><code>SINGLE_SINGLE</code></dt>
-    <dt><code>DOUBLE_DOUBLE</code></dt>
+    <dt><code>mixed</code> (default)</dt>
+    <dt><code>single</code></dt>
+    <dt><code>double</code></dt>
   </dl>
   </td>
 </tr>
@@ -1417,12 +1471,12 @@ target API.
   <td>Tuning target for OpenCL driver code</td>
   <td>
   <dl>
-    <dt><code>GENERIC</code> (default)</dt>
-    <dt><code>INTEL</code> (Intel CPU)</dt>
-    <dt><code>PHI</code> (Intel Xeon Phi)</dt>
-    <dt><code>FERMI</code> (NVIDIA)</dt>
-    <dt><code>KEPLER</code> (NVIDIA)</dt>
-    <dt><code>CYPRESS</code> (AMD)</dt>
+    <dt><code>generic</code> (default)</dt>
+    <dt><code>intel</code> (Intel CPU)</dt>
+    <dt><code>phi</code> (Intel Xeon Phi)</dt>
+    <dt><code>fermi</code> (NVIDIA)</dt>
+    <dt><code>kepler</code> (NVIDIA)</dt>
+    <dt><code>cypress</code> (AMD)</dt>
   </dl>
   </td>
 </tr>
@@ -1449,6 +1503,11 @@ target API.
   </dl>
   </td>
 </tr>
+<tr>
+  <td><code>BIN2C</code> (CUDA only)</td>
+  <td>Path to bin2c executable, will automatically pick up the first one in your $PATH.</td>
+  <td>(automatic)</td>
+</tr>
 </tbody>
 </table>
 
@@ -1517,6 +1576,16 @@ Requires a Eigen3 installation
 </tr>
 </thead>
 <tbody>
+<tr>
+  <td><code>WITH_JPEG</code></td>
+  <td>Enables/Disable JPEG support in LAMMPS</td>
+  <td>
+  <dl>
+    <dt><code>yes</code> (default, if found)</dt>
+    <dt><code>no</code></dt>
+  </dl>
+  </td>
+</tr>
 <tr>
   <td><code>JPEG_INCLUDE_DIR</code></td>
   <td></td>
@@ -1544,6 +1613,16 @@ Requires a Eigen3 installation
 </tr>
 </thead>
 <tbody>
+<tr>
+  <td><code>WITH_PNG</code></td>
+  <td>Enables/Disable PNG support in LAMMPS</td>
+  <td>
+  <dl>
+    <dt><code>yes</code> (default, if found)</dt>
+    <dt><code>no</code></dt>
+  </dl>
+  </td>
+</tr>
 <tr>
   <td><code>PNG_INCLUDE_DIR</code></td>
   <td></td>
@@ -1573,11 +1652,20 @@ requires `gzip` to be in your `PATH`
 </thead>
 <tbody>
 <tr>
-  <td><code>GZIP_EXECUTABLE</code></td>
-  <td></td>
+  <td><code>WITH_GZIP</code></td>
+  <td>Enables/Disable GZIP support in LAMMPS</td>
   <td>
+  <dl>
+    <dt><code>yes</code> (default, if found)</dt>
+    <dt><code>no</code></dt>
+  </dl>
   </td>
 </tr>
+<tr>
+  <td><code>GZIP_EXECUTABLE</code></td>
+  <td>Path to gzip executable, will automatically pick up the first one in your $PATH.</td>
+  <td>(automatic)</td>
+</tr>
 </tbody>
 </table>
 
@@ -1595,19 +1683,33 @@ requires `ffmpeg` to be in your `PATH`
 </thead>
 <tbody>
 <tr>
-  <td><code>FFMPEG_EXECUTABLE</code></td>
-  <td></td>
+  <td><code>WITH_FFMPEG</code></td>
+  <td>Enables/Disable FFMPEG support in LAMMPS</td>
   <td>
+  <dl>
+    <dt><code>yes</code> (default, if found)</dt>
+    <dt><code>no</code></dt>
+  </dl>
   </td>
 </tr>
+<tr>
+  <td><code>FFMPEG_EXECUTABLE</code></td>
+  <td>Path to ffmpeg executable, will automatically pick up the first one in your $PATH.</td>
+  <td>(automatic)</td>
+</tr>
 </tbody>
 </table>
 
 
 ## Compilers
 
-By default, `cmake` will use your environment C/C++/Fortran compilers for a build. It uses the `CC`, `CXX` and `FC` environment variables to detect which compilers should be used. However, these values
-will be cached after the first run of `cmake`. Subsequent runs of `cmake` will ignore changes in these environment variables. To ensure the correct values are used you avoid the cache by setting the `CMAKE_C_COMPILER`, `CMAKE_CXX_COMPILER`, `CMAKE_Fortran_COMPILER` options directly.
+By default, `cmake` will use your environment C/C++/Fortran compilers for a
+build. It uses the `CC`, `CXX` and `FC` environment variables to detect which
+compilers should be used. However, these values will be cached after the first
+run of `cmake`. Subsequent runs of `cmake` will ignore changes in these
+environment variables. To ensure the correct values are used you avoid the
+cache by setting the `CMAKE_C_COMPILER`, `CMAKE_CXX_COMPILER`,
+`CMAKE_Fortran_COMPILER` options directly.
 
 <table>
 <thead>
@@ -1637,26 +1739,33 @@ will be cached after the first run of `cmake`. Subsequent runs of `cmake` will i
   value of `FC` environment variable at first `cmake` run
   </td>
 </tr>
+<tr>
+  <td><code>CXX_COMPILER_LAUNCHER</code></td>
+  <td>CMake will run this tool and pass the compiler and its arguments to the tool. Some example tools are distcc and ccache.</td>
+  <td>
+  (empty)
+  </td>
+</tr>
 </tbody>
 </table>
 
 ### Building with GNU Compilers
 
 ```bash
-cmake ../cmake -DCMAKE_C_COMPILER=gcc -DCMAKE_CXX_COMPILER=g++ -DCMAKE_Fortran_COMPILER=gfortran
+cmake -D CMAKE_C_COMPILER=gcc -D CMAKE_CXX_COMPILER=g++ -D CMAKE_Fortran_COMPILER=gfortran ../cmake
 ```
 
 ### Building with Intel Compilers
 
 ```bash
-cmake ../cmake -DCMAKE_C_COMPILER=icc -DCMAKE_CXX_COMPILER=icpc -DCMAKE_Fortran_COMPILER=ifort
+cmake -D CMAKE_C_COMPILER=icc -D CMAKE_CXX_COMPILER=icpc -D CMAKE_Fortran_COMPILER=ifort ../cmake
 ```
 
 
 ### Building with LLVM/Clang Compilers
 
 ```bash
-cmake ../cmake -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_Fortran_COMPILER=flang
+cmake -D CMAKE_C_COMPILER=clang -D CMAKE_CXX_COMPILER=clang++ -D CMAKE_Fortran_COMPILER=flang ../cmake
 ```
 
 

cmake/pkgconfig/liblammps.pc.in

@@ -1,18 +1,38 @@
 # pkg-config file for lammps
 # https://people.freedesktop.org/~dbn/pkg-config-guide.html
-# Usage: cc `pkg-config --cflags --libs liblammps` -o myapp myapp.c
-# after you added @CMAKE_INSTALL_FULL_LIBDIR@/pkg-config to PKG_CONFIG_PATH,
+
+# Add the directory where lammps.pc got installed to your PKG_CONFIG_PATH
 # e.g. export PKG_CONFIG_PATH=@CMAKE_INSTALL_FULL_LIBDIR@/pkgconfig
 
-prefix=@CMAKE_INSTALL_FULL_PREFIX@
+# Use this on commandline with:
+# c++ `pkg-config --cflags --libs lammps` -o myapp myapp.cpp
+
+# Use this in a Makefile:
+# myapp: myapp.cpp
+# 	$(CC) `pkg-config --cflags --libs lammps` -o $@ $<
+
+# Use this in autotools:
+# configure.ac:
+# PKG_CHECK_MODULES([LAMMPS], [lammps])
+# Makefile.am:
+# myapp_CFLAGS = $(LAMMPS_CFLAGS)
+# myapp_LDADD = $(LAMMPS_LIBS)
+
+# Use this in CMake:
+# CMakeLists.txt:
+# find_package(PkgConfig)
+# pkg_check_modules(LAMMPS IMPORTED_TARGET lammps)
+# target_link_libraries(<lib> PkgConfig::LAMMPS)
+
+prefix=@CMAKE_INSTALL_PREFIX@
 libdir=@CMAKE_INSTALL_FULL_LIBDIR@
 includedir=@CMAKE_INSTALL_FULL_INCLUDEDIR@
 
 Name: liblammps@LAMMPS_MACHINE@
 Description: Large-scale Atomic/Molecular Massively Parallel Simulator Library
 URL: http://lammps.sandia.gov
-Version:
+Version: @LAMMPS_VERSION@
 Requires:
-Libs: -L${libdir} -llammps@LIB_SUFFIX@@
+Libs: -L${libdir} -llammps@LAMMPS_LIB_SUFFIX@
 Libs.private: -lm
 Cflags: -I${includedir} @LAMMPS_API_DEFINES@

cmake/presets/all_off.cmake

@@ -8,12 +8,12 @@ set(USER_PACKAGES USER-ATC USER-AWPMD USER-BOCS USER-CGDNA USER-CGSDK USER-COLVA
                   USER-INTEL USER-LB USER-MANIFOLD USER-MEAMC USER-MESO
                   USER-MGPT USER-MISC USER-MOFFF USER-MOLFILE
                   USER-NETCDF USER-OMP USER-PHONON USER-QMMM USER-QTB
-                  USER-QUIP USER-REAXC USER-SMD USER-SMTBQ USER-SPH USER-TALLY
+                  USER-QUIP USER-REAXC USER-SDPD USER-SMD USER-SMTBQ USER-SPH USER-TALLY
                   USER-UEF USER-VTK)
 
 set(PACKAGES_WITH_LIB COMPRESS GPU KIM KOKKOS LATTE MEAM MPIIO MSCG POEMS PYTHON REAX VORONOI
                       USER-ATC USER-AWPMD USER-COLVARS USER-H5MD USER-LB USER-MOLFILE
-                      USER-NETCDF USER-QMMM USER-QUIP USER-SMD USER-VTK)
+                      USER-NETCDF USER-PLUMED USER-QMMM USER-QUIP USER-SMD USER-VTK)
 
 set(ALL_PACKAGES ${STANDARD_PACKAGES} ${USER_PACKAGES})
 

cmake/presets/all_on.cmake

@@ -8,12 +8,12 @@ set(USER_PACKAGES USER-ATC USER-AWPMD USER-BOCS USER-CGDNA USER-CGSDK USER-COLVA
                   USER-INTEL USER-LB USER-MANIFOLD USER-MEAMC USER-MESO
                   USER-MGPT USER-MISC USER-MOFFF USER-MOLFILE
                   USER-NETCDF USER-OMP USER-PHONON USER-QMMM USER-QTB
-                  USER-QUIP USER-REAXC USER-SMD USER-SMTBQ USER-SPH USER-TALLY
+                  USER-QUIP USER-REAXC USER-SDPD USER-SMD USER-SMTBQ USER-SPH USER-TALLY
                   USER-UEF USER-VTK)
 
 set(PACKAGES_WITH_LIB COMPRESS GPU KIM KOKKOS LATTE MEAM MPIIO MSCG POEMS PYTHON REAX VORONOI
                       USER-ATC USER-AWPMD USER-COLVARS USER-H5MD USER-LB USER-MOLFILE
-                      USER-NETCDF USER-QMMM USER-QUIP USER-SMD USER-VTK)
+                      USER-NETCDF USER-PLUMED USER-QMMM USER-QUIP USER-SMD USER-VTK)
 
 set(ALL_PACKAGES ${STANDARD_PACKAGES} ${USER_PACKAGES})
 

cmake/presets/manual_selection.cmake

@@ -56,11 +56,13 @@ set(PKG_USER-MOFFF OFF CACHE BOOL "" FORCE)
 set(PKG_USER-MOLFILE OFF CACHE BOOL "" FORCE)
 set(PKG_USER-NETCDF OFF CACHE BOOL "" FORCE)
 set(PKG_USER-OMP OFF CACHE BOOL "" FORCE)
-set(PKG_USER-PHOFFOFF OFF CACHE BOOL "" FORCE)
+set(PKG_USER-PHONON OFF CACHE BOOL "" FORCE)
+set(PKG_USER-PLUMED OFF CACHE BOOL "" FORCE)
 set(PKG_USER-QMMM OFF CACHE BOOL "" FORCE)
 set(PKG_USER-QTB OFF CACHE BOOL "" FORCE)
 set(PKG_USER-QUIP OFF CACHE BOOL "" FORCE)
 set(PKG_USER-REAXC OFF CACHE BOOL "" FORCE)
+set(PKG_USER-SDPD OFF CACHE BOOL "" FORCE)
 set(PKG_USER-SMD OFF CACHE BOOL "" FORCE)
 set(PKG_USER-SMTBQ OFF CACHE BOOL "" FORCE)
 set(PKG_USER-SPH OFF CACHE BOOL "" FORCE)

cmake/presets/nolib.cmake

@@ -8,12 +8,12 @@ set(USER_PACKAGES USER-ATC USER-AWPMD USER-BOCS USER-CGDNA USER-CGSDK USER-COLVA
                   USER-INTEL USER-LB USER-MANIFOLD USER-MEAMC USER-MESO
                   USER-MGPT USER-MISC USER-MOFFF USER-MOLFILE
                   USER-NETCDF USER-OMP USER-PHONON USER-QMMM USER-QTB
-                  USER-QUIP USER-REAXC USER-SMD USER-SMTBQ USER-SPH USER-TALLY
+                  USER-QUIP USER-REAXC USER-SDPD USER-SMD USER-SMTBQ USER-SPH USER-TALLY
                   USER-UEF USER-VTK)
 
 set(PACKAGES_WITH_LIB COMPRESS GPU KIM KOKKOS LATTE MEAM MPIIO MSCG POEMS PYTHON REAX VORONOI
                       USER-ATC USER-AWPMD USER-COLVARS USER-H5MD USER-LB USER-MOLFILE
-                      USER-NETCDF USER-QMMM USER-QUIP USER-SMD USER-VTK)
+                      USER-NETCDF USER-PLUMED USER-QMMM USER-QUIP USER-SMD USER-VTK)
 
 set(ALL_PACKAGES ${STANDARD_PACKAGES} ${USER_PACKAGES})
 

cmake/presets/std.cmake

@@ -8,7 +8,7 @@ set(USER_PACKAGES USER-ATC USER-AWPMD USER-BOCS USER-CGDNA USER-CGSDK USER-COLVA
                   USER-INTEL USER-LB USER-MANIFOLD USER-MEAMC USER-MESO
                   USER-MGPT USER-MISC USER-MOFFF USER-MOLFILE
                   USER-NETCDF USER-OMP USER-PHONON USER-QMMM USER-QTB
-                  USER-QUIP USER-REAXC USER-SMD USER-SMTBQ USER-SPH USER-TALLY
+                  USER-QUIP USER-REAXC USER-SDPD USER-SMD USER-SMTBQ USER-SPH USER-TALLY
                   USER-UEF USER-VTK)
 
 set(PACKAGES_WITH_LIB COMPRESS GPU KIM KOKKOS LATTE MEAM MPIIO MSCG POEMS PYTHON REAX VORONOI

cmake/presets/std_nolib.cmake

@@ -8,7 +8,7 @@ set(USER_PACKAGES USER-ATC USER-AWPMD USER-BOCS USER-CGDNA USER-CGSDK USER-COLVA
                   USER-INTEL USER-LB USER-MANIFOLD USER-MEAMC USER-MESO
                   USER-MGPT USER-MISC USER-MOFFF USER-MOLFILE
                   USER-NETCDF USER-OMP USER-PHONON USER-QMMM USER-QTB
-                  USER-QUIP USER-REAXC USER-SMD USER-SMTBQ USER-SPH USER-TALLY
+                  USER-QUIP USER-REAXC USER-SDPD USER-SMD USER-SMTBQ USER-SPH USER-TALLY
                   USER-UEF USER-VTK)
 
 set(PACKAGES_WITH_LIB COMPRESS GPU KIM KOKKOS LATTE MEAM MPIIO MSCG POEMS PYTHON REAX VORONOI

cmake/presets/user.cmake

@@ -8,12 +8,12 @@ set(USER_PACKAGES USER-ATC USER-AWPMD USER-BOCS USER-CGDNA USER-CGSDK USER-COLVA
                   USER-INTEL USER-LB USER-MANIFOLD USER-MEAMC USER-MESO
                   USER-MGPT USER-MISC USER-MOFFF USER-MOLFILE
                   USER-NETCDF USER-OMP USER-PHONON USER-QMMM USER-QTB
-                  USER-QUIP USER-REAXC USER-SMD USER-SMTBQ USER-SPH USER-TALLY
+                  USER-QUIP USER-REAXC USER-SDPD USER-SMD USER-SMTBQ USER-SPH USER-TALLY
                   USER-UEF USER-VTK)
 
 set(PACKAGES_WITH_LIB COMPRESS GPU KIM KOKKOS LATTE MEAM MPIIO MSCG POEMS PYTHON REAX VORONOI
                       USER-ATC USER-AWPMD USER-COLVARS USER-H5MD USER-LB USER-MOLFILE
-                      USER-NETCDF USER-QMMM USER-QUIP USER-SMD USER-VTK)
+                      USER-NETCDF USER-PLUMED USER-QMMM USER-QUIP USER-SMD USER-VTK)
 
 set(ALL_PACKAGES ${STANDARD_PACKAGES} ${USER_PACKAGES})
 

doc/.gitignore

@@ -1,4 +1,5 @@
 /html
+/latex
 /spelling
 /LAMMPS.epub
 /LAMMPS.mobi

doc/Makefile

@@ -1,7 +1,7 @@
 # Makefile for LAMMPS documentation
 
-SHELL 	      = /bin/bash
-SHA1          = $(shell echo $USER-$PWD | python utils/sha1sum.py)
+SHELL         = /bin/bash
+SHA1          = $(shell echo ${USER}-${PWD} | python utils/sha1sum.py)
 BUILDDIR      = /tmp/lammps-docs-$(SHA1)
 RSTDIR        = $(BUILDDIR)/rst
 VENV          = $(BUILDDIR)/docenv
@@ -31,21 +31,24 @@ SPHINXEXTRA = -j $(shell $(PYTHON) -c 'import multiprocessing;print(multiprocess
 SOURCES=$(filter-out $(wildcard src/lammps_commands*.txt) src/lammps_support.txt src/lammps_tutorials.txt,$(wildcard src/*.txt))
 OBJECTS=$(SOURCES:src/%.txt=$(RSTDIR)/%.rst)
 
-.PHONY: help clean-all clean epub html pdf old venv spelling anchor_check
+.PHONY: help clean-all clean epub mobi html pdf old venv spelling anchor_check
 
 # ------------------------------------------
 
 help:
 	@echo "Please use \`make <target>' where <target> is one of"
 	@echo "  html       create HTML doc pages in html dir"
-	@echo "  pdf        create Manual.pdf and Developer.pdf in this dir"
+	@echo "  pdf        create Developer.pdf and Manual.pdf in this dir"
 	@echo "  old        create old-style HTML doc pages in old dir"
 	@echo "  fetch      fetch HTML and PDF files from LAMMPS web site"
 	@echo "  epub       create ePUB format manual for e-book readers"
+	@echo "  mobi       convert ePUB to MOBI format manual for e-book readers (e.g. Kindle)"
+	@echo "                      (requires ebook-convert tool from calibre)"
 	@echo "  clean      remove all intermediate RST files"
 	@echo "  clean-all  reset the entire build environment"
 	@echo "  txt2html   build txt2html tool"
 	@echo "  anchor_check  scan for duplicate anchor labels"
+	@echo "  spelling   spell-check the manual"
 
 # ------------------------------------------
 
@@ -93,9 +96,10 @@ spelling: $(OBJECTS) utils/sphinx-config/false_positives.txt
 	@echo "Spell check finished."
 
 epub: $(OBJECTS)
-	@mkdir -p epub
+	@mkdir -p epub/JPG
 	@rm -f LAMMPS.epub
 	@cp src/JPG/lammps-logo.png epub/
+	@cp src/JPG/*.* epub/JPG
 	@(\
 		. $(VENV)/bin/activate ;\
 		cp -r src/* $(RSTDIR)/ ;\
@@ -106,20 +110,25 @@ epub: $(OBJECTS)
 	@rm -rf epub
 	@echo "Build finished. The ePUB manual file is created."
 
+mobi: epub
+	@rm -f LAMMPS.mobi
+	@ebook-convert LAMMPS.epub LAMMPS.mobi
+	@echo "Conversion finished. The MOBI manual file is created."
+
 pdf: utils/txt2html/txt2html.exe
 	@(\
 		set -e; \
-		cd src; \
-		../utils/txt2html/txt2html.exe -b *.txt; \
-		htmldoc --batch lammps.book;          \
-		for s in `echo *.txt | sed -e 's,\.txt,\.html,g'` ; \
-			do grep -q $$s lammps.book || \
-			echo doc file $$s missing in src/lammps.book; done; \
-		rm *.html; \
-		cd Developer; \
+		cd src/Developer; \
 		pdflatex developer; \
 		pdflatex developer; \
 		mv developer.pdf ../../Developer.pdf; \
+		cd ..; \
+		../utils/txt2html/txt2html.exe -b *.txt; \
+		htmldoc --batch lammps.book;          \
+		for s in `echo *.txt | sed -e 's/ \(pairs\|bonds\|angles\|dihedrals\|impropers\|commands_list\|fixes\|computes\).txt/ /g' | sed -e 's,\.txt,\.html,g'` ; \
+			do grep -q ^$$s lammps.book || \
+			echo WARNING: doc file $$s missing in src/lammps.book; done; \
+		rm *.html; \
 	)
 
 old: utils/txt2html/txt2html.exe
@@ -168,7 +177,6 @@ $(VENV):
 		$(VIRTUALENV) -p $(PYTHON) $(VENV); \
 		. $(VENV)/bin/activate; \
 		pip install Sphinx; \
-		pip install sphinxcontrib-images; \
 		deactivate;\
 	)
 

doc/github-development-workflow.md

@@ -0,0 +1,196 @@
+# Outline of the GitHub Development Workflow
+
+This purpose of this document is to provide a point of reference for the
+core LAMMPS developers and other LAMMPS contributors to understand the
+choices the LAMMPS developers have agreed on. Git and GitHub provide the
+tools, but do not set policies, so it is up to the developers to come to
+an agreement as to how to define and interpret policies. This document
+is likely to change as our experiences and needs change and we try to
+adapt accordingly. Last change 2018-12-19.
+
+## Table of Contents
+
+  * [GitHub Merge Management](#github-merge-management)
+  * [Pull Requests](#pull-requests)
+    * [Pull Request Assignments](#pull-request-assignments)
+    * [Pull Request Reviews](#pull-request-reviews)
+    * [Pull Request Discussions](#pull-request-discussions)
+    * [Checklist for Pull Requests](#checklist-for-pull-requests)
+  * [GitHub Issues](#github-issues)
+  * [Milestones and Release Planning](#milestones-and-release-planning)
+
+## GitHub Merge Management
+
+In the interest of consistency, ONLY ONE of the core LAMMPS developers
+should doing the merging itself.  This is currently
+[@akohlmey](https://github.com/akohlmey) (Axel Kohlmeyer).
+If this assignment needs to be changed, it shall be done right after a
+stable release.  If the currently assigned developer cannot merge outstanding pull 
+requests in a timely manner, or in other extenuating circumstances, 
+other core LAMMPS developers with merge rights can merge pull requests,
+when necessary. 
+
+## Pull Requests
+
+ALL changes to the LAMMPS code and documentation, however trivial, MUST
+be submitted as a pull request to GitHub. All changes to the "master"
+branch must be made exclusively through merging pull requests. The
+"unstable" and "stable" branches, respectively are only to be updated
+upon patch or stable releases with fast-forward merges based on the
+associated tags. Pull requests may also be submitted to (long-running)
+feature branches created by LAMMPS developers inside the LAMMPS project,
+if needed. Those are not subject to the merge and review restrictions
+discussed in this document, though, but get managed as needed on a
+case-by-case basis.
+
+### Pull Request Assignments
+
+Pull requests can be "chaperoned" by one of the LAMMPS core developers.
+This is indicated by who the pull request is assigned to. LAMMPS core
+developers can self-assign or they can decide to assign a pull request
+to a different LAMMPS developer. Being assigned to a pull request means,
+that this pull request may need some work and the assignee is tasked to
+determine whether this might be needed or not, and may either implement
+the required changes or ask the submitter of the pull request to implement
+them.  Even though, all LAMMPS developers may have write access to pull
+requests (if enabled by the submitter, which is the default), only the
+submitter or the assignee of a pull request may do so.  During this
+period the `work_in_progress` label shall be applied to the pull
+request.  The assignee gets to decide what happens to the pull request
+next, e.g. whether it should be assigned to a different developer for
+additional checks and changes, or is recommended to be merged.  Removing
+the `work_in_progress` label and assigning the pull request to the
+developer tasked with merging signals that a pull request is ready to be
+merged.
+
+### Pull Request Reviews
+
+People can be assigned to review a pull request in two ways:
+
+  * They can be assigned manually to review a pull request
+    by the submitter or a LAMMPS developer
+  * They can be automatically assigned, because a developers matches
+    a file pattern in the `.github/CODEOWNERS` file, which associates
+    developers with the code they contributed and maintain.
+
+Reviewers are requested to state their appraisal of the proposed changes
+and either approve or request changes. People may unassign themselves
+from review, if they feel not competent about the changes proposed. At
+least two approvals from LAMMPS developers with write access are required
+before merging in addition to the automated compilation tests.
+Merging counts as implicit approval, so does submission of a pull request
+(by a LAMMPS developer). So the person doing the merge may not also submit
+an approving review. The feature, that reviews from code owners are "hard"
+reviews (i.e. they must all be approved before merging is allowed), is
+currently disabled and it is in the discretion of the merge maintainer to
+assess when a sufficient degree of approval, especially from external
+contributors, has been reached in these cases.  Reviews may be
+(automatically) dismissed, when the reviewed code has been changed,
+and then approval is required a second time.
+
+### Pull Request Discussions
+
+All discussions about a pull request should be kept as much as possible
+on the pull request discussion page on GitHub, so that other developers
+can later review the entire discussion after the fact and understand the
+rationale behind choices made.  Exceptions to this policy are technical
+discussions, that are centered on tools or policies themselves
+(git, github, c++) rather than on the content of the pull request.
+
+### Checklist for Pull Requests
+
+Here are some items to check:
+  * source and text files should not have CR/LF line endings (use dos2unix to remove)
+  * every new command or style should have documentation. The names of
+  source files (c++ and manual) should follow the name of the style.
+  (example: `src/fix_nve.cpp`, `src/fix_nve.h` for `fix nve` command,
+  implementing the class `FixNVE`, documented in `doc/src/fix_nve.txt`)
+  * 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_*.txt`, `doc/src/{fixes,computes,pairs,bonds,...}.txt`
+  and `doc/src/lammps.book`
+  * check whether manual cleanly translates with `make html` and `make pdf`
+  * check spelling of manual with `make spelling` in doc folder
+  * 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 should follow the C++-98 standard. C++-11 is only accepted
+  in individual special purpose packages
+  * indentation is 2 spaces per level
+  * there should be NO tabs and no trailing whitespace
+  * 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.
+  * 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.
+  * when pair styles are added, check if settings for flags like
+  `single_enable`, `writedata`, `reinitflag`, `manybody_flag`
+  and others are correctly set and supported.
+
+## GitHub Issues
+
+The GitHub issue tracker is the location where the LAMMPS developers
+and other contributors or LAMMPS users can report issues or bugs with
+the LAMMPS code or request new features to be added. Feature requests
+are usually indicated by a `[Feature Request]` marker in the subject.
+Issues are assigned to a person, if this person is working on this
+feature or working to resolve an issue. Issues that have nobody working
+on them at the moment, have the label `volunteer needed` attached.
+
+When an issue, say `#125` is resolved by a specific pull request,
+the comment for the pull request shall contain the text `closes #125`
+or `fixes #125`, so that the issue is automatically deleted when
+the pull request is merged.
+
+## Milestones and Release Planning
+
+LAMMPS uses a continuous release development model with incremental
+changes, i.e. significant effort is made - including automated pre-merge
+testing - that the code in the branch "master" does not get broken.
+More extensive testing (including regression testing) is performed after
+code is merged to the "master" branch. There are patch releases of
+LAMMPS every 1-3 weeks at a point, when the LAMMPS developers feel, that
+a sufficient amount of changes have happened, and the post-merge testing
+has been successful. These patch releases are marked with a
+`patch_<version date>` tag and the "unstable" branch follows only these
+versions (and thus is always supposed to be of production quality,
+unlike "master", which may be temporary broken, in the case of larger
+change sets or unexpected incompatibilities or side effects.
+
+About 3-4 times each year, there are going to be "stable" releases
+of LAMMPS.  These have seen additional, manual testing and review of
+results from testing with instrumented code and static code analysis.
+Also, in the last 2-3 patch releases before a stable release are
+"release candidate" versions which only contain bugfixes and
+documentation updates.  For release planning and the information of
+code contributors, issues and pull requests being actively worked on
+are assigned a "milestone", which corresponds to the next stable
+release or the stable release after that, with a tentative release
+date.
+

doc/lammps.1

@@ -0,0 +1,45 @@
+.TH LAMMPS "2018-08-22"
+.SH NAME
+.B LAMMPS
+\- Molecular Dynamics Simulator.
+
+.SH SYNOPSIS
+.B lmp 
+-in in.file
+
+or
+
+mpirun \-np 2 
+.B lmp 
+-in in.file
+
+.SH DESCRIPTION
+.B LAMMPS 
+LAMMPS is a classical molecular dynamics code, and an acronym for Large-scale 
+Atomic/Molecular Massively Parallel Simulator. LAMMPS has potentials for soft 
+materials (biomolecules, polymers) and solid-state materials (metals, 
+semiconductors) and coarse-grained or mesoscopic systems. It can be used to 
+model atoms or, more generically, as a parallel particle simulator at the 
+atomic, meso, or continuum scale.
+
+See http://lammps.sandia.gov/ for documentation.
+
+.SH OPTIONS
+See https://lammps.sandia.gov/doc/Run_options.html for details on
+command-line options.
+
+.SH COPYRIGHT 
+© 2003--2018 Sandia Corporation
+
+This package is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 2 of the License, or
+(at your option) any later version.
+
+This package is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+On Debian systems, the complete text of the GNU General
+Public License can be found in `/usr/share/common-licenses/GPL-2'.

doc/src/Build.txt

@@ -0,0 +1,49 @@
+"Previous Section"_Install.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc - "Next Section"_Run_head.html :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+Build LAMMPS :h2
+
+LAMMPS can be built as an executable or library from source code via
+either traditional makefiles (which may require manual editing)
+for use with GNU make or gmake, or a build environment generated by CMake
+(Unix Makefiles, Xcode, Visual Studio, KDevelop or more).  As an
+alternative you can download a package with pre-built executables
+as described on the "Install"_Install.html doc page.
+
+<!-- RST
+
+.. toctree::
+   :maxdepth: 1
+
+   Build_cmake
+   Build_make
+   Build_link
+   Build_basics
+   Build_settings
+   Build_package
+   Build_extras
+   Build_windows
+
+END_RST -->
+
+<!-- HTML_ONLY -->
+
+"Build LAMMPS with CMake"_Build_cmake.html
+"Build LAMMPS with make"_Build_make.html
+"Link LAMMPS as a library to another code"_Build_link.html
+"Basic build options"_Build_basics.html
+"Optional build settings"_Build_settings.html
+"Include packages in build"_Build_package.html
+"Packages with extra build options"_Build_extras.html
+"Notes for building LAMMPS on Windows"_Build_windows.html  :all(b)
+
+If you have problems building LAMMPS, it is often due to software
+issues on your local machine.  If you can, find a local expert to
+help.  If you're still stuck, send an email to the "LAMMPS mail
+list"_http://lammps.sandia.gov/mail.html.

doc/src/Build_basics.txt

@@ -0,0 +1,319 @@
+"Higher level section"_Build.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+Basic build options :h3
+
+The following topics are covered on this page, for building both with
+CMake and make:
+
+"Serial vs parallel build"_#serial
+"Choice of compiler and compile/link options"_#compile
+"Build LAMMPS as an executable or a library"_#exe
+"Build the LAMMPS documentation"_#doc
+"Install LAMMPS after a build"_#install :ul
+
+:line
+
+Serial vs parallel build :h4,link(serial)
+
+LAMMPS can be built to run in parallel using the ubiquitous "MPI
+(message-passing
+interface)"_https://en.wikipedia.org/wiki/Message_Passing_Interface
+library.  Or it can built to run on a single processor (serial)
+without MPI.  It can also be built with support for OpenMP threading
+(see more discussion below).
+
+[CMake variables]:
+
+-D BUILD_MPI=value        # yes or no, default is yes if CMake finds MPI, else no
+-D BUILD_OMP=value        # yes or no (default)
+-D LAMMPS_MACHINE=name    # name = mpi, serial, mybox, titan, laptop, etc
+                          # no default value :pre
+
+The executable created by CMake (after running make) is lmp_name.  If
+the LAMMPS_MACHINE variable is not specified, the executable is just
+lmp.  Using BUILD_MPI=no will produce a serial executable.
+
+[Traditional make]:
+
+cd lammps/src
+make mpi                # parallel build, produces lmp_mpi using Makefile.mpi
+make serial             # serial build, produces lmp_serial using Makefile/serial
+make mybox :pre         # uses Makefile.mybox to produce lmp_mybox :pre
+
+Serial build (see src/MAKE/Makefile.serial):
+
+MPI_INC =       -I../STUBS
+MPI_PATH =      -L../STUBS
+MPI_LIB =	-lmpi_stubs :pre
+
+For a parallel build, if MPI is installed on your system in the usual
+place (e.g. under /usr/local), you do not need to specify the 3
+variables MPI_INC, MPI_PATH, MPI_LIB.  The MPI wrapper on the compiler
+(e.g. mpicxx, mpiCC) knows where to find the needed include and
+library files.  Failing this, these 3 variables can be used to specify
+where the mpi.h file (MPI_INC), and the MPI library files (MPI_PATH)
+are found, and the name of the library files (MPI_LIB).
+
+For a serial build, you need to specify the 3 variables, as shown
+above.
+
+For a serial LAMMPS build, use the dummy MPI library provided in
+src/STUBS.  You also need to build the STUBS library for your platform
+before making LAMMPS itself.  A "make serial" build does this for.
+Otherwise, type "make mpi-stubs" from the src directory, or "make"
+from the src/STUBS dir.  If the build fails, you will need to edit the
+STUBS/Makefile for your platform.
+
+The file STUBS/mpi.c provides a CPU timer function called MPI_Wtime()
+that calls gettimeofday() .  If your system doesn't support
+gettimeofday() , you'll need to insert code to call another timer.
+Note that the ANSI-standard function clock() rolls over after an hour
+or so, and is therefore insufficient for timing long LAMMPS
+simulations.
+
+[CMake and make info]:
+
+If you are installing MPI yourself, we recommend MPICH2 from Argonne
+National Laboratory or OpenMPI.  MPICH can be downloaded from the
+"Argonne MPI site"_http://www.mcs.anl.gov/research/projects/mpich2/.
+OpenMPI can be downloaded from the "OpenMPI
+site"_http://www.open-mpi.org.  Other MPI packages should also work.
+If you are running on a large parallel machine, your system admins or
+the vendor should have already installed a version of MPI, which is
+likely to be faster than a self-installed MPICH or OpenMPI, so find
+out how to build and link with it.
+
+The majority of OpenMP (threading) support in LAMMPS is provided by
+the USER-OMP package; see the "Speed omp"_Speed_omp.html doc page for
+details. The USER-INTEL package also provides OpenMP support (it is
+compatible with USER-OMP) and adds vectorization support when compiled
+with the Intel compilers on top of that. Also, the KOKKOS package can
+be compiled for using OpenMP threading.
+
+However, there are a few commands in LAMMPS that have native OpenMP
+support.  These are commands in the MPIIO, SNAP, USER-DIFFRACTION, and
+USER-DPD packages.  In addition some packages support OpenMP threading
+indirectly through the libraries they interface to: e.g. LATTE and
+USER-COLVARS.  See the "Packages details"_Packages_details.html doc
+page for more info on these packages and the doc pages for their
+respective commands for OpenMP threading info.
+
+For CMake, if you use BUILD_OMP=yes, you can use these packages and
+turn on their native OpenMP support and turn on their native OpenMP
+support at run time, by setting the OMP_NUM_THREADS environment
+variable before you launch LAMMPS.
+
+For building via conventional make, the CCFLAGS and LINKFLAGS
+variables in Makefile.machine need to include the compiler flag that
+enables OpenMP. For GNU compilers it is -fopenmp.  For (recent) Intel
+compilers it is -qopenmp.  If you are using a different compiler,
+please refer to its documentation.
+
+:line
+
+Choice of compiler and compile/link options :h4,link(compile)
+
+The choice of compiler and compiler flags can be important for
+performance.  Vendor compilers can produce faster code than
+open-source compilers like GNU.  On boxes with Intel CPUs, we suggest
+trying the "Intel C++ compiler"_intel.
+
+:link(intel,https://software.intel.com/en-us/intel-compilers)
+
+On parallel clusters or supercomputers which use "modules" for their
+compile/link environments, you can often access different compilers by
+simply loading the appropriate module before building LAMMPS.
+
+[CMake variables]:
+
+-D CMAKE_CXX_COMPILER=name            # name of C++ compiler
+-D CMAKE_C_COMPILER=name              # name of C compiler
+-D CMAKE_Fortran_COMPILER=name        # name of Fortran compiler :pre
+
+-D CMAKE_CXX_FLAGS=string             # flags to use with C++ compiler
+-D CMAKE_C_FLAGS=string               # flags to use with C compiler
+-D CMAKE_Fortran_FLAGS=string         # flags to use with Fortran compiler :pre
+
+By default CMake will use a compiler it finds and it will add
+optimization flags appropriate to that compiler and any "accelerator
+packages"_Speed_packages.html you have included in the build.
+
+You can tell CMake to look for a specific compiler with these variable
+settings.  Likewise you can specify the FLAGS variables if you want to
+experiment with alternate optimization flags.  You should specify all
+3 compilers, so that the small number of LAMMPS source files written
+in C or Fortran are built with a compiler consistent with the one used
+for all the C++ files:
+
+Building with GNU Compilers:
+cmake ../cmake -DCMAKE_C_COMPILER=gcc -DCMAKE_CXX_COMPILER=g++ -DCMAKE_Fortran_COMPILER=gfortran
+Building with Intel Compilers:
+cmake ../cmake -DCMAKE_C_COMPILER=icc -DCMAKE_CXX_COMPILER=icpc -DCMAKE_Fortran_COMPILER=ifort
+Building with LLVM/Clang Compilers:
+cmake ../cmake -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_Fortran_COMPILER=flang :pre
+
+NOTE: When the cmake command completes, it prints info to the screen
+as to which compilers it is using, and what flags will be used in the
+compilation.  Note that if the top-level compiler is mpicxx, it is
+simply a wrapper on a real compiler.  The underlying compiler info is
+what will be listed in the CMake output.  You should check to insure
+you are using the compiler and optimization flags are the ones you
+want.
+
+[Makefile.machine settings]:
+
+Parallel build (see src/MAKE/Makefile.mpi):
+
+CC =		mpicxx
+CCFLAGS =	-g -O3
+LINK =		mpicxx
+LINKFLAGS =	-g -O :pre
+
+Serial build (see src/MAKE/Makefile.serial):
+
+CC =		g++
+CCFLAGS =	-g -O3
+LINK =		g++
+LINKFLAGS =	-g -O :pre
+
+The "compiler/linker settings" section of a Makefile.machine lists
+compiler and linker settings for your C++ compiler, including
+optimization flags.  You should always use mpicxx or mpiCC for
+a parallel build, since these compiler wrappers will include
+a variety of settings appropriate for your MPI installation.
+
+NOTE: If you build LAMMPS with any "accelerator
+packages"_Speed_packages.html included, they have specific
+optimization flags that are either required or recommended for optimal
+performance.  You need to include these in the CCFLAGS and LINKFLAGS
+settings above.  For details, see the individual package doc pages
+listed on the "Speed packages"_Speed_packages.html doc page.  Or
+examine these files in the src/MAKE/OPTIONS directory.  They
+correspond to each of the 5 accelerator packages and their hardware
+variants:
+
+Makefile.opt                   # OPT package
+Makefile.omp                   # USER-OMP package
+Makefile.intel_cpu             # USER-INTEL package for CPUs
+Makefile.intel_coprocessor     # USER-INTEL package for KNLs
+Makefile.gpu                   # GPU package
+Makefile.kokkos_cuda_mpi       # KOKKOS package for GPUs
+Makefile.kokkos_omp            # KOKKOS package for CPUs (OpenMP)
+Makefile.kokkos_phi            # KOKKOS package for KNLs (OpenMP) :pre
+
+:line
+
+Build LAMMPS as an executable or a library :h4,link(exe)
+
+LAMMPS can be built as either an executable or as a static or shared
+library.  The LAMMPS library can be called from another application or
+a scripting language.  See the "Howto couple"_Howto_couple.html doc
+page for more info on coupling LAMMPS to other codes.  See the
+"Python"_Python_head.html doc page for more info on wrapping and
+running LAMMPS from Python via its library interface.
+
+[CMake variables]:
+
+-D BUILD_EXE=value           # yes (default) or no
+-D BUILD_LIB=value           # yes or no (default)
+-D BUILD_SHARED_LIBS=value   # yes or no (default) :pre
+
+Setting BUILD_EXE=no will not produce an executable.  Setting
+BUILD_LIB=yes will produce a static library named liblammps.a.
+Setting both BUILD_LIB=yes and BUILD_SHARED_LIBS=yes will produce a
+shared library named liblammps.so.
+
+[Traditional make]:
+
+cd lammps/src
+make machine               # build LAMMPS executable lmp_machine
+make mode=lib machine      # build LAMMPS static lib liblammps_machine.a
+make mode=shlib machine    # build LAMMPS shared lib liblammps_machine.so :pre
+
+The two library builds also create generic soft links, named
+liblammps.a and liblammps.so, which point to the liblammps_machine
+files.
+
+[CMake and make info]:
+
+Note that for a shared library to be usable by a calling program, all
+the auxiliary libraries it depends on must also exist as shared
+libraries.  This will be the case for libraries included with LAMMPS,
+such as the dummy MPI library in src/STUBS or any package libraries in
+the lib/packages directory, since they are always built as shared
+libraries using the -fPIC switch.  However, if a library like MPI or
+FFTW does not exist as a shared library, the shared library build will
+generate an error.  This means you will need to install a shared
+library version of the auxiliary library.  The build instructions for
+the library should tell you how to do this.
+
+As an example, here is how to build and install the "MPICH
+library"_mpich, a popular open-source version of MPI, distributed by
+Argonne National Lab, as a shared library in the default
+/usr/local/lib location:
+
+:link(mpich,http://www-unix.mcs.anl.gov/mpi)
+
+./configure --enable-shared
+make
+make install :pre
+
+You may need to use "sudo make install" in place of the last line if
+you do not have write privileges for /usr/local/lib.  The end result
+should be the file /usr/local/lib/libmpich.so.
+
+:line
+
+Build the LAMMPS documentation :h4,link(doc)
+
+[CMake variable]:
+
+-D BUILD_DOC=value       # yes or no (default) :pre
+
+This will create the HTML doc pages within the CMake build directory.
+The reason to do this is if you want to "install" LAMMPS on a system
+after the CMake build via "make install", and include the doc pages in
+the install.
+
+[Traditional make]:
+
+cd lammps/doc
+make html       # html doc pages
+make pdf        # single Manual.pdf file :pre
+
+This will create a lammps/doc/html dir with the HTML doc pages so that
+you can browse them locally on your system.  Type "make" from the
+lammps/doc dir to see other options.
+
+NOTE: You can also download a tarball of the documentation for the
+current LAMMPS version (HTML and PDF files), from the website
+"download page"_http://lammps.sandia.gov/download.html.
+
+:line
+
+Install LAMMPS after a build :h4,link(install)
+
+After building LAMMPS, you may wish to copy the LAMMPS executable of
+library, along with other LAMMPS files (library header, doc files) to
+a globally visible place on your system, for others to access.  Note
+that you may need super-user privileges (e.g. sudo) if the directory
+you want to copy files to is protected.
+
+[CMake variable]:
+
+cmake -D CMAKE_INSTALL_PREFIX=path \[options ...\] ../cmake
+make                        # perform make after CMake command
+make install                # perform the installation into prefix :pre
+
+[Traditional make]:
+
+There is no "install" option in the src/Makefile for LAMMPS.  If you
+wish to do this you will need to first build LAMMPS, then manually
+copy the desired LAMMPS files to the appropriate system directories.

doc/src/Build_cmake.txt

@@ -0,0 +1,196 @@
+"Higher level section"_Build.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+Build LAMMPS with CMake :h3
+
+This page is a short summary of how to use CMake to build LAMMPS.
+Details on CMake variables that enable specific LAMMPS build options
+are given on the pages linked to from the "Build"_Build.html doc page.
+
+Richard Berger (Temple U) has also written a "more comprehensive
+guide"_https://github.com/lammps/lammps/blob/master/cmake/README.md
+for how to use CMake to build LAMMPS.  If you are new to CMake it is a
+good place to start.
+
+:line
+
+Building LAMMPS with CMake is a two-step process.  First you use CMake
+to create a build environment in a new directory.  On Linux systems,
+this will be based on makefiles for use with make.  Then you use the
+make command to build LAMMPS, which uses the created
+Makefile(s). Example:
+
+cd lammps                        # change to the LAMMPS distribution directory
+mkdir build; cd build            # create a new directory (folder) for build
+cmake ../cmake \[options ...\]   # configuration with (command-line) cmake
+make                             # compilation :pre
+
+The cmake command will detect available features, enable selected
+packages and options, and will generate the build environment.  The make
+command will then compile and link LAMMPS, producing (by default) an
+executable called "lmp" and a library called "liblammps.a" in the
+"build" folder.
+
+If your machine has multiple CPU cores (most do these days), using a
+command like "make -jN" (with N being the number of available local
+CPU cores) can be much faster.  If you plan to do development on
+LAMMPS or need to re-compile LAMMPS repeatedly, installation of the
+ccache (= Compiler Cache) software may speed up compilation even more.
+
+After compilation, you can optionally copy the LAMMPS executable and
+library into your system folders (by default under $HOME/.local) with:
+
+make install    # optional, copy LAMMPS executable & library elsewhere :pre
+
+:line
+
+There are 3 variants of CMake: a command-line version (cmake), a text mode
+UI version (ccmake), and a graphical GUI version (cmake-GUI).  You can use
+any of them interchangeably to configure and create the LAMMPS build
+environment.  On Linux all the versions produce a Makefile as their
+output.  See more details on each below.
+
+You can specify a variety of options with any of the 3 versions, which
+affect how the build is performed and what is included in the LAMMPS
+executable.  Links to pages explaining all the options are listed on
+the "Build"_Build.html doc page.
+
+You must perform the CMake build system generation and compilation in
+a new directory you create.  It can be anywhere on your local machine.
+In these Build pages we assume that you are building in a directory
+called "lammps/build".  You can perform separate builds independently
+with different options, so long as you perform each of them in a
+separate directory you create.  All the auxiliary files created by one
+build process (executable, object files, log files, etc) are stored in
+this directory or sub-directories within it that CMake creates.
+
+NOTE: To perform a CMake build, no packages can be installed or a
+build been previously attempted in the LAMMPS src directory by using
+"make" commands to "perform a conventional LAMMPS
+build"_Build_make.html.  CMake detects if this is the case and
+generates an error, telling you to type "make no-all purge" in the src
+directory to un-install all packages.  The purge removes all the *.h
+files auto-generated by make.
+
+You must have CMake version 2.8 or later on your system to build
+LAMMPS.  A handful of LAMMPS packages (KOKKOS, LATTE, MSCG) require a
+later version.  CMake will print a message telling you if a later
+version is required.  Installation instructions for CMake are below.
+
+After the initial build, if you edit LAMMPS source files, or add your
+own new files to the source directory, you can just re-type make from
+your build directory and it will re-compile only the files that have
+changed.  If you want to change CMake options you can run cmake (or
+ccmake or cmake-gui) again from the same build directory and alter
+various options; see details below.  Or you can remove the entire build
+folder, recreate the directory and start over.
+
+:line
+
+[Command-line version of CMake]:
+
+cmake \[options ...\] /path/to/lammps/cmake  # build from any dir
+cmake \[options ...\] ../cmake               # build from lammps/build :pre
+
+The cmake command takes one required argument, which is the LAMMPS
+cmake directory which contains the CMakeLists.txt file.
+
+The argument can be preceeded or followed by various CMake
+command-line options.  Several useful ones are:
+
+-D CMAKE_INSTALL_PREFIX=path  # where to install LAMMPS executable/lib if desired
+-D CMAKE_BUILD_TYPE=type      # type = Release or Debug
+-G output                     # style of output CMake generates
+-DVARIABLE=value              # setting for a LAMMPS feature to enable
+-D VARIABLE=value             # ditto, but cannot come after CMakeLists.txt dir :pre
+
+All the LAMMPS-specific -D variables that a LAMMPS build supports are
+described on the pages linked to from the "Build"_Build.html doc page.
+All of these variable names are upper-case and their values are
+lower-case, e.g. -D LAMMPS_SIZES=smallbig.  For boolean values, any of
+these forms can be used: yes/no, on/off, 1/0.
+
+On Unix/Linux machines, CMake generates a Makefile by default to
+perform the LAMMPS build.  Alternate forms of build info can be
+generated via the -G switch, e.g. Visual Studio on a Windows machine,
+Xcode on MacOS, or KDevelop on Linux.  Type "cmake --help" to see the
+"Generator" styles of output your system supports.
+
+NOTE: When CMake runs, it prints configuration info to the screen.
+You should review this to verify all the features you requested were
+enabled, including packages.  You can also see what compilers and
+compile options will be used for the build.  Any errors in CMake
+variable syntax will also be flagged, e.g. mis-typed variable names or
+variable values.
+
+CMake creates a CMakeCache.txt file when it runs.  This stores all the
+settings, so that when running CMake again you can use the current
+folder '.' instead of the path to the LAMMPS cmake folder as the
+required argument to the CMake command. Either way the existing
+settings will be inherited unless the CMakeCache.txt file is removed.
+
+If you later want to change a setting you can rerun cmake in the build
+directory with different setting. Please note that some automatically
+detected variables will not change their value when you rerun cmake.
+In these cases it is usually better to first remove all the
+files/directories in the build directory, or start with a fresh build
+directory.
+
+:line
+
+[Curses version (terminal-style menu) of CMake]:
+
+ccmake ../cmake :pre
+
+You initiate the configuration and build environment generation steps
+separately. For the first you have to type [c], for the second you
+have to type [g]. You may need to type [c] multiple times, and may be
+required to edit some of the entries of CMake configuration variables
+in between.  Please see the "ccmake
+manual"_https://cmake.org/cmake/help/latest/manual/ccmake.1.html for
+more information.
+
+:line
+
+[GUI version of CMake]:
+
+cmake-gui ../cmake :pre
+
+You initiate the configuration and build environment generation steps
+separately. For the first you have to click on the [Configure] button,
+for the second you have to click on the [Generate] button.  You may
+need to click on [Configure] multiple times, and may be required to
+edit some of the entries of CMake configuration variables in between.
+Please see the "cmake-gui
+manual"_https://cmake.org/cmake/help/latest/manual/cmake-gui.1.html
+for more information.
+
+:line
+
+[Installing CMake]
+
+Check if your machine already has CMake installed:
+
+which cmake             # do you have it?
+which cmake3            # version 3 may have this name
+cmake --version         # what specific version you have :pre
+
+On clusters or supercomputers which use environment modules to manage
+software packages, do this:
+
+module list            # is a cmake module already loaded?
+module avail           # is a cmake module available?
+module load cmake3     # load cmake module with appropriate name :pre
+
+Most Linux distributions offer pre-compiled cmake packages through
+their package management system. If you do not have CMake or a new
+enough version, you can download the latest version at
+"https://cmake.org/download/"_https://cmake.org/download/.
+Instructions on how to install it on various platforms can be found
+"on this page"_https://cmake.org/install/.

doc/src/Build_link.txt

@@ -0,0 +1,85 @@
+"Higher level section"_Build.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+Link LAMMPS as a library to another code :h3
+
+LAMMPS can be used as a library by another application, including
+Python scripts.  The files src/library.cpp and library.h define the
+C-style API for using LAMMPS as a library.  See the "Howto
+library"_Howto_library.html doc page for a description of the
+interface and how to extend it for your needs.
+
+The "Build basics"_Build_basics.html doc page explains how to build
+LAMMPS as either a shared or static library.  This results in one of
+these 2 files:
+
+liblammps.so      # shared library
+liblammps.a       # static library
+
+:line
+
+[Link with LAMMPS as a static library]:
+
+The calling application can link to LAMMPS as a static library with a
+link command like this:
+
+g++ caller.o -L/home/sjplimp/lammps/src -llammps -o caller
+
+The -L argument is the path to where the liblammps.a file is.  The
+-llammps argument is shorthand for the file liblammps.a.
+
+:line
+
+[Link with LAMMPS as a shared library]:
+
+If you wish to link to liblammps.so, the operating system finds shared
+libraries to load at run-time using the environment variable
+LD_LIBRARY_PATH.  To enable this you can do one of two things:
+
+(1) Copy the liblammps.so file to a location the system can find it,
+such as /usr/local/lib.  I.e. a directory already listed in your
+LD_LIBRARY_PATH variable.  You can type
+
+printenv LD_LIBRARY_PATH :pre
+
+to see what directories are in that list.
+
+(2) Add the LAMMPS src directory (or the directory you perform CMake
+build in) to your LD_LIBRARY_PATH, so that the current version of the
+shared library is always available to programs that use it.
+
+For the csh or tcsh shells, you would add something like this to your
+~/.cshrc file:
+
+setenv LD_LIBRARY_PATH $\{LD_LIBRARY_PATH\}:/home/sjplimp/lammps/src :pre
+
+:line
+
+[Calling the LAMMPS library]:
+
+Either flavor of library (static or shared) allows one or more LAMMPS
+objects to be instantiated from the calling program.
+
+When used from a C++ program, all of LAMMPS is wrapped in a LAMMPS_NS
+namespace; you can safely use any of its classes and methods from
+within the calling code, as needed.
+
+When used from a C or Fortran program, the library has a simple
+C-style interface, provided in src/library.cpp and src/library.h.
+
+See the "Python library"_Python_library.html doc page for a
+description of the Python interface to LAMMPS, which wraps the C-style
+interface.
+
+See the sample codes in examples/COUPLE/simple for examples of C++ and
+C and Fortran codes that invoke LAMMPS through its library interface.
+Other examples in the COUPLE directory use coupling ideas discussed on
+the "Howto couple"_Howto_couple.html doc page.
+
+

doc/src/Build_make.txt

@@ -0,0 +1,85 @@
+"Higher level section"_Build.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+Build LAMMPS with make :h3
+
+Building LAMMPS with traditional makefiles requires that you have a
+Makefile."machine" file appropriate for your system in the src/MAKE,
+src/MAKE/MACHINES, src/MAKE/OPTIONS, or src/MAKE/MINE directory (see
+below).  It can include various options for customizing your LAMMPS
+build with a number of global compilation options and features.
+
+To include LAMMPS packages (i.e. optional commands and styles) you
+must install them first, as discussed on the "Build
+package"_Build_package.html doc page.  If the packages require
+provided or external libraries, you must build those libraries before
+building LAMMPS.  Building "LAMMPS with CMake"_Build_cmake.html can
+automate all of this for many types of machines, especially
+workstations, desktops and laptops, so we suggest you try it first.
+
+These commands perform a default LAMMPS build, producing the LAMMPS
+executable lmp_serial or lmp_mpi in lammps/src:
+
+cd lammps/src
+make serial     # build a serial LAMMPS executable
+make mpi        # build a parallel LAMMPS executable with MPI
+make            # see a variety of make options :pre
+
+This initial compilation can take a long time, since LAMMPS is a large
+project with many features. If your machine has multiple CPU cores
+(most do these days), using a command like "make -jN mpi" (with N =
+the number of available CPU cores) can be much faster.  If you plan to
+do development on LAMMPS or need to re-compile LAMMPS repeatedly, the
+installation of the ccache (= Compiler Cache) software may speed up
+compilation even more.
+
+After the initial build, whenever you edit LAMMPS source files, or add
+or remove new files to the source directory (e.g. by installing or
+uninstalling packages), you must re-compile and relink the LAMMPS
+executable with the same "make" command.  This makefiles dependencies
+should insure that only the subset of files that need to be are
+re-compiled.
+
+NOTE: When you build LAMMPS for the first time, a long list of *.d
+files will be printed out rapidly.  This is not an error; it is the
+Makefile doing its normal creation of dependencies.
+
+:line
+
+The lammps/src/MAKE tree contains all the Makefile.machine files
+included in the LAMMPS distribution.  Typing "make machine" uses
+Makefile.machine.  Thus the "make serial" or "make mpi" lines above
+use Makefile.serial and Makefile.mpi.  Others are in these dirs:
+
+OPTIONS      # Makefiles which enable specific options
+MACHINES     # Makefiles for specific machines
+MINE         # customized Makefiles you create (you may need to create this folder) :pre
+
+Typing "make" lists all the available Makefile.machine files.  A file
+with the same name can appear in multiple folders (not a good idea).
+The order the dirs are searched is as follows: src/MAKE/MINE,
+src/MAKE, src/MAKE/OPTIONS, src/MAKE/MACHINES.  This gives preference
+to a customized file you put in src/MAKE/MINE.
+
+Makefiles you may wish to try include these (some require a package
+first be installed).  Many of these include specific compiler flags
+for optimized performance.  Please note, however, that some of these
+customized machine Makefile are contributed by users.  Since both
+compilers, OS configurations, and LAMMPS itself keep changing, their
+settings may become outdated:
+
+make mac             # build serial 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 knl             # build with the USER-INTEL package optimized for KNLs
+make opt             # build with the OPT package optimized for CPUs
+make omp             # build with the USER-OMP package optimized 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_phi      # build with the KOKKOS package for KNLs :pre

doc/src/Build_package.txt

@@ -0,0 +1,225 @@
+"Higher level section"_Build.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+Include packages in build :h3
+
+In LAMMPS, a package is a group of files that enable a specific set of
+features.  For example, force fields for molecular systems or
+rigid-body constraints are in packages.  In the src directory, each
+package is a sub-directory with the package name in capital letters.
+
+An overview of packages is given on the "Packages"_Packages.html doc
+page.  Brief overviews of each package are on the "Packages
+details"_Packages_details.html doc page.
+
+When building LAMMPS, you can choose to include or exclude each
+package.  In general there is no need to include a package if you
+never plan to use its features.
+
+If you get a run-time error that a LAMMPS command or style is
+"Unknown", it is often because the command is contained in a package,
+and your build did not include that package.  Running LAMMPS with the
+"-h command-line switch"_Run_options.html will print all the included
+packages and commands for that executable.
+
+For the majority of packages, if you follow the single step below to
+include it, you can then build LAMMPS exactly the same as you would
+without any packages installed.  A few packages may require additional
+steps, as explained on the "Build extras"_Build_extras.html doc page.
+
+These links take you to the extra instructions for those select
+packages:
+
+"COMPRESS"_Build_extras.html#compress,
+"GPU"_Build_extras.html#gpu,
+"KIM"_Build_extras.html#kim,
+"KOKKOS"_Build_extras.html#kokkos,
+"LATTE"_Build_extras.html#latte,
+"MEAM"_Build_extras.html#meam,
+"MESSAGE"_Build_extras.html#message,
+"MSCG"_Build_extras.html#mscg,
+"OPT"_Build_extras.html#opt,
+"POEMS"_Build_extras.html#poems,
+"PYTHON"_Build_extras.html#python,
+"VORONOI"_Build_extras.html#voronoi,
+"USER-ATC"_Build_extras.html#user-atc,
+"USER-AWPMD"_Build_extras.html#user-awpmd,
+"USER-COLVARS"_Build_extras.html#user-colvars,
+"USER-H5MD"_Build_extras.html#user-h5md,
+"USER-INTEL"_Build_extras.html#user-intel,
+"USER-MOLFILE"_Build_extras.html#user-molfile,
+"USER-NETCDF"_Build_extras.html#user-netcdf,
+"USER-PLUMED"_Build_extras.html#user-plumed,
+"USER-OMP"_Build_extras.html#user-omp,
+"USER-QMMM"_Build_extras.html#user-qmmm,
+"USER-QUIP"_Build_extras.html#user-quip,
+"USER-SCAFACOS"_Build_extras.html#user-scafacos,
+"USER-SMD"_Build_extras.html#user-smd,
+"USER-VTK"_Build_extras.html#user-vtk :tb(c=6,ea=c,a=l)
+
+The mechanism for including packages is simple but different for CMake
+versus make.
+
+[CMake variables]:
+
+-D PKG_NAME=value          # yes or no (default) :pre
+
+Examples:
+
+-D PKG_MANYBODY=yes
+-D PKG_USER-INTEL=yes :pre
+
+All standard and user packages are included the same way.  Note that
+USER packages have a hyphen between USER and the rest of the package
+name, not an underscore.
+
+See the shortcut section below for how to install many packages at
+once with CMake.
+
+NOTE: If you toggle back and forth between building with CMake vs
+make, no packages in the src directory can be installed when you
+invoke cmake.  CMake will give an error if that is not the case,
+indicating how you can un-install all packages in the src dir.
+
+[Traditional make]:
+
+cd lammps/src
+make ps                    # check which packages are currently installed
+make yes-name              # install a package with name
+make no-name               # un-install a package with name
+make mpi                   # build LAMMPS with whatever packages are now installed :pre
+
+Examples:
+
+make no-rigid
+make yes-user-intel :pre
+
+All standard and user packages are included the same way.
+
+See the shortcut section below for how to install many packages at
+once with make.
+
+NOTE: You must always re-build LAMMPS (via make) after installing or
+un-installing a package, for the action to take effect.
+
+NOTE: You cannot install or un-install packages and build LAMMPS in a
+single make command with multiple targets, e.g. make yes-colloid mpi.
+This is because the make procedure creates a list of source files that
+will be out-of-date for the build if the package configuration changes
+within the same command.  You can include or exclude multiple packages
+in a single make command, e.g. make yes-colloid no-manybody.
+
+[CMake and make info]:
+
+Any package can be included or excluded in a LAMMPS build, independent
+of all other packages.  However, some packages include files derived
+from files in other packages.  LAMMPS checks for this and does the
+right thing.  Individual files are only included if their dependencies
+are already included.  Likewise, if a package is excluded, other files
+dependent on that package are also excluded.
+
+When you download a LAMMPS tarball or download LAMMPS source files
+from the Git or SVN repositories, no packages are pre-installed in the
+src directory.
+
+NOTE: Prior to Aug 2018, if you downloaded a tarball, 3 packages
+(KSPACE, MANYBODY, MOLECULE) were pre-installed in the src directory.
+That is no longer the case, so that CMake will build as-is without the
+need to un-install those packages.
+
+:line
+
+[CMake shortcuts for installing many packages]:
+
+Instead of specifying all the CMake options via the command-line,
+CMake allows initializing the variable cache using script files. These
+are regular CMake files which can manipulate and set variables, and
+can also contain control flow constructs.
+
+LAMMPS includes several of these files to define configuration
+"presets", similar to the options that exist for the Make based
+system. Using these files you can enable/disable portions of the
+available packages in LAMMPS. If you need a custom preset you can take
+one of them as a starting point and customize it to your needs.
+
+cmake -C ../cmake/presets/all_on.cmake \[OPTIONS\] ../cmake | enable all packages
+cmake -C ../cmake/presets/all_off.cmake \[OPTIONS\] ../cmake | disable all packages
+cmake -C ../cmake/presets/std.cmake \[OPTIONS\] ../cmake | enable standard packages
+cmake -C ../cmake/presets/user.cmake \[OPTIONS\] ../cmake | enable user packages
+cmake -C ../cmake/presets/std_nolib.cmake \[OPTIONS\] ../cmake | enable standard packages that do not require extra libraries
+cmake -C ../cmake/presets/nolib.cmake \[OPTIONS\] ../cmake | disable all packages that do not require extra libraries
+cmake -C ../cmake/presets/manual_selection.cmake \[OPTIONS\] ../cmake | example of how to create a manual selection of packages :tb(s=|,a=l)
+
+NOTE: Running cmake this way manipulates the variable cache in your
+current build directory. You can combine presets and options with
+multiple cmake runs.
+
+[Example:]
+
+# build LAMMPS with all "standard" packages which don't
+# use libraries and enable GPU package
+mkdir build
+cd build
+cmake -C ../cmake/presets/std_nolib.cmake -D PKG_GPU=on ../cmake :pre
+
+:line
+
+[Make shortcuts for installing many packages]:
+
+The following commands are useful for managing package source files
+and their installation when building LAMMPS via traditional make.
+Just type "make" in lammps/src to see a one-line summary.
+
+These commands install/un-install sets of packages:
+
+make yes-all | install all packages
+make no-all | un-install all packages
+make yes-standard or make yes-std | install standard packages
+make no-standard or make no-std| un-install standard packages
+make yes-user | install user packages
+make no-user | un-install user packages
+make yes-lib | install packages that require extra libraries
+make no-lib | un-install packages that require extra libraries
+make yes-ext | install packages that require external libraries
+make no-ext | un-install packages that require external libraries :tb(s=|,a=l)
+
+which install/un-install various sets of packages.  Typing "make
+package" will list all the these commands.
+
+NOTE: Installing or un-installing a package works by simply copying
+files back and forth between the main src directory and
+sub-directories with the package name (e.g. src/KSPACE, src/USER-ATC),
+so that the files are included or excluded when LAMMPS is built.
+
+The following make commands help manage files that exist in both the
+src directory and in package sub-directories.  You do not normally
+need to use these commands unless you are editing LAMMPS files or are
+"installing a patch"_Install_patch.html downloaded from the LAMMPS web
+site.
+
+Type "make package-status" or "make ps" to show which packages are
+currently installed.  For those that are installed, it will list any
+files that are different in the src directory and package
+sub-directory.
+
+Type "make package-installed" or "make pi" to show which packages are
+currently installed, without listing the status of packages that are
+not installed.
+
+Type "make package-update" or "make pu" to overwrite src files with
+files from the package sub-directories if the package is installed.
+It should be used after a "patch has been applied"_Install_patch.html,
+since patches only update the files in the package sub-directory, but
+not the src files.
+
+Type "make package-overwrite" to overwrite files in the package
+sub-directories with src files.
+
+Type "make package-diff" to list all differences between pairs of
+files in both the src dir and a package dir.

doc/src/Build_settings.txt

@@ -0,0 +1,341 @@
+"Higher level section"_Build.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+Optional build settings :h3
+
+LAMMPS can be built with several optional settings.  Each sub-section
+explain how to do this for building both with CMake and make.
+
+"FFT library"_#fft for use with the "kspace_style pppm"_kspace_style.html command
+"Size of LAMMPS data types"_#size
+"Read or write compressed files"_#gzip
+"Output of JPG and PNG files"_#graphics via the "dump image"_dump_image.html command
+"Output of movie files"_#graphics via the "dump_movie"_dump_image.html command
+"Memory allocation alignment"_#align
+"Workaround for long long integers"_#longlong
+"Error handling exceptions"_#exceptions when using LAMMPS as a library :all(b)
+
+:line
+
+FFT library :h4,link(fft)
+
+When the KSPACE package is included in a LAMMPS build, the
+"kspace_style pppm"_kspace_style.html command performs 3d FFTs which
+require use of an FFT library to compute 1d FFTs.  The KISS FFT
+library is included with LAMMPS but other libraries can be faster.
+LAMMPS can use them if they are available on your system.
+
+[CMake variables]:
+
+-D FFT=value              # FFTW3 or MKL or KISS, default is FFTW3 if found, else KISS
+-D FFT_SINGLE=value       # yes or no (default), no = double precision
+-D FFT_PACK=value         # array (default) or pointer or memcpy :pre
+
+NOTE: The values for the FFT variable must be in upper-case.  This is
+an exception to the rule that all CMake variables can be specified
+with lower-case values.
+
+Usually these settings are all that is needed.  If CMake cannot find
+the FFT library, you can set these variables:
+
+-D FFTW3_INCLUDE_DIRS=path  # path to FFTW3 include files
+-D FFTW3_LIBRARIES=path     # path to FFTW3 libraries
+-D MKL_INCLUDE_DIRS=path    # ditto for Intel MKL library
+-D MKL_LIBRARIES=path :pre
+
+[Makefile.machine settings]:
+
+FFT_INC = -DFFT_FFTW3         # -DFFT_FFTW3, -DFFT_FFTW (same as -DFFT_FFTW3), -DFFT_MKL, or -DFFT_KISS
+                              # default is KISS if not specified
+FFT_INC = -DFFT_SINGLE        # do not specify for double precision
+FFT_INC = -DFFT_PACK_ARRAY    # or -DFFT_PACK_POINTER or -DFFT_PACK_MEMCPY :pre
+                              # default is FFT_PACK_ARRAY if not specified
+
+FFT_INC =    	-I/usr/local/include
+FFT_PATH =      -L/usr/local/lib
+FFT_LIB =	-lfftw3             # FFTW3 double precision
+FFT_LIB =	-lfftw3 -lfftw3f    # FFTW3 single precision
+FFT_LIB =       -lmkl_intel_lp64 -lmkl_sequential -lmkl_core  # MKL with Intel compiler
+FFT_LIB =       -lmkl_gf_lp64 -lmkl_sequential -lmkl_core     # MKL with GNU compier :pre
+
+As with CMake, you do not need to set paths in FFT_INC or FFT_PATH, if
+make can find the FFT header and library files.  You must specify
+FFT_LIB with the appropriate FFT libraries to include in the link.
+
+[CMake and make info]:
+
+The "KISS FFT library"_http://kissfft.sf.net is included in the LAMMPS
+distribution.  It is portable across all platforms.  Depending on the
+size of the FFTs and the number of processors used, the other
+libraries listed here can be faster.
+
+However, note that long-range Coulombics are only a portion of the
+per-timestep CPU cost, FFTs are only a portion of long-range
+Coulombics, and 1d FFTs are only a portion of the FFT cost (parallel
+communication can be costly).  A breakdown of these timings is printed
+to the screen at the end of a run using the "kspace_style
+pppm"_kspace_style.html command.  The "Run output"_Run_output.html
+doc page gives more details.
+
+FFTW is a fast, portable FFT library that should also work on any
+platform and can be faster than the KISS FFT library.  You can
+download it from "www.fftw.org"_http://www.fftw.org.  LAMMPS requires
+version 3.X; the legacy version 2.1.X is no longer supported.
+
+Building FFTW for your box should be as simple as ./configure; make;
+make install.  The install command typically requires root privileges
+(e.g. invoke it via sudo), unless you specify a local directory with
+the "--prefix" option of configure.  Type "./configure --help" to see
+various options.
+
+The Intel MKL math library is part of the Intel compiler suite.  It
+can be used with the Intel or GNU compiler (see FFT_LIB setting above).
+
+Performing 3d FFTs in parallel can be time consuming due to data
+access and required communication.  This cost can be reduced by
+performing single-precision FFTs instead of double precision.  Single
+precision means the real and imaginary parts of a complex datum are
+4-byte floats.  Double precision means they are 8-byte doubles.  Note
+that Fourier transform and related PPPM operations are somewhat less
+sensitive to floating point truncation errors and thus the resulting
+error is less than the difference in precision. Using the -DFFT_SINGLE
+setting trades off a little accuracy for reduced memory use and
+parallel communication costs for transposing 3d FFT data.
+
+When using -DFFT_SINGLE with FFTW3 you may need to build the FFTW
+library a second time with support for single-precision.
+
+For FFTW3, do the following, which should produce the additional
+library libfftw3f.a
+
+make clean
+./configure --enable-single; make; make install :pre
+
+Performing 3d FFTs requires communication to transpose the 3d FFT
+grid.  The data packing/unpacking for this can be done in one of 3
+modes (ARRAY, POINTER, MEMCPY) as set by the FFT_PACK syntax above.
+Depending on the machine, the size of the FFT grid, the number of
+processors used, one option may be slightly faster.  The default is
+ARRAY mode.
+
+:line
+
+Size of LAMMPS data types :h4,link(size)
+
+LAMMPS has a few integer data types which can be defined as 4-byte or
+8-byte integers.  The default setting of "smallbig" is almost always
+adequate.
+
+[CMake variable]:
+
+-D LAMMPS_SIZES=value   # smallbig (default) or bigbig or smallsmall :pre
+
+[Makefile.machine setting]:
+
+LMP_INC = -DLAMMPS_SMALLBIG    # or -DLAMMPS_BIGBIG or -DLAMMPS_SMALLSMALL :pre
+                               # default is LAMMPS_SMALLBIG if not specified
+[CMake and make info]:
+
+The default "smallbig" setting allows for simulations with:
+
+total atom count = 2^63 atoms (about 9e18)
+total timesteps = 2^63 (about 9e18)
+atom IDs = 2^31 (about 2 billion)
+image flags = roll over at 512 :ul
+
+The "bigbig" setting increases the latter two limits.  It allows for:
+
+total atom count = 2^63 atoms (about 9e18)
+total timesteps = 2^63 (about 9e18)
+atom IDs = 2^63 (about 9e18)
+image flags = roll over at about 1 million (2^20) :ul
+
+The "smallsmall" setting is only needed if your machine does not
+support 8-byte integers.  It allows for:
+
+total atom count = 2^31 atoms (about 2 billion)
+total timesteps = 2^31 (about 2 billion)
+atom IDs = 2^31 (about 2 billion)
+image flags = roll over at 512 (2^9) :ul
+
+Atom IDs are not required for atomic systems which do not store bond
+topology information, though IDs are enabled by default.  The
+"atom_modify id no"_atom_modify.html command will turn them off.  Atom
+IDs are required for molecular systems with bond topology (bonds,
+angles, dihedrals, etc).  Thus if you model a molecular system with
+more than 2 billion atoms, you need the "bigbig" setting.
+
+Image flags store 3 values per atom which count the number of times an
+atom has moved through the periodic box in each dimension.  See the
+"dump"_dump.html doc page for a discussion.  If an atom moves through
+the periodic box more than this limit, the value will "roll over",
+e.g. from 511 to -512, which can cause diagnostics like the
+mean-squared displacement, as calculated by the "compute
+msd"_compute_msd.html command, to be faulty.
+
+Note that the USER-ATC package is not currently compatible with the
+"bigbig" setting.
+
+Also note that the GPU package requires its lib/gpu library to be
+compiled with the same size setting, or the link will fail.  A CMake
+build does this automatically.  When building with make, the setting
+in whichever lib/gpu/Makefile is used must be the same as above.
+
+:line
+
+Output of JPG, PNG, and movie files :h4,link(graphics)
+
+The "dump image"_dump_image.html command has options to output JPEG or
+PNG image files.  Likewise the "dump movie"_dump_image.html command
+outputs movie files in MPEG format.  Using these options requires the
+following settings:
+
+[CMake variables]:
+
+-D WITH_JPEG=value      # yes or no
+                          # default = yes if CMake finds JPEG files, else no
+-D WITH_PNG=value       # yes or no
+                          # default = yes if CMake finds PNG and ZLIB files, else no
+-D WITH_FFMPEG=value    # yes or no
+                          # default = yes if CMake can find ffmpeg, else no :pre
+
+Usually these settings are all that is needed.  If CMake cannot find
+the graphics header, library, executable files, you can set these
+variables:
+
+-D JPEG_INCLUDE_DIR=path    # path to jpeglib.h header file
+-D JPEG_LIBRARIES=path      # path to libjpeg.a (.so) file
+-D PNG_INCLUDE_DIR=path     # path to png.h header file
+-D PNG_LIBRARIES=path       # path to libpng.a (.so) file
+-D ZLIB_INCLUDE_DIR=path    # path to zlib.h header file
+-D ZLIB_LIBRARIES=path      # path to libz.a (.so) file
+-D FFMPEG_EXECUTABLE=path   # path to ffmpeg executable :pre
+
+[Makefile.machine settings]:
+
+LMP_INC = -DLAMMPS_JPEG
+LMP_INC = -DLAMMPS_PNG
+LMP_INC = -DLAMMPS_FFMPEG :pre
+
+JPG_INC = -I/usr/local/include   # path to jpeglib.h, png.h, zlib.h header files if make cannot find them
+JPG_PATH = -L/usr/lib            # paths to libjpeg.a, libpng.a, libz.a (.so) files if make cannot find them
+JPG_LIB = -ljpeg -lpng -lz       # library names :pre
+
+As with CMake, you do not need to set JPG_INC or JPG_PATH, if make can
+find the graphics header and library files.  You must specify JPG_LIB
+with a list of graphics libraries to include in the link.  You must
+insure ffmpeg is in a directory where LAMMPS can find it at runtime,
+i.e. a dir in your PATH environment variable.
+
+[CMake and make info]:
+
+Using ffmpeg to output movie files requires that your machine
+supports the "popen" function in the standard runtime library.
+
+NOTE: On some clusters with high-speed networks, using the fork()
+library calls (required by popen()) can interfere with the fast
+communication library and lead to simulations using ffmpeg to hang or
+crash.
+
+:line
+
+Read or write compressed files :h4,link(gzip)
+
+If this option is enabled, large files can be read or written with
+gzip compression by several LAMMPS commands, including
+"read_data"_read_data.html, "rerun"_rerun.html, and "dump"_dump.html.
+
+[CMake variables]:
+
+-D WITH_GZIP=value       # yes or no
+                         # default is yes if CMake can find gzip, else no
+-D GZIP_EXECUTABLE=path  # path to gzip executable if CMake cannot find it :pre
+
+[Makefile.machine setting]:
+
+LMP_INC = -DLAMMPS_GZIP :pre
+
+[CMake and make info]:
+
+This option requires that your machine supports the "popen()" function
+in the standard runtime library and that a gzip executable can be
+found by LAMMPS during a run.
+
+NOTE: On some clusters with high-speed networks, using the fork()
+library calls (required by popen()) can interfere with the fast
+communication library and lead to simulations using compressed output
+or input to hang or crash. For selected operations, compressed file
+I/O is also available using a compression library instead, which is
+what the "COMPRESS package"_Packages_details.html#PKG-COMPRESS enables.
+
+:line
+
+Memory allocation alignment :h4,link(align)
+
+This setting enables the use of the posix_memalign() call instead of
+malloc() when LAMMPS allocates large chunks or memory.  This can make
+vector instructions on CPUs more efficient, if dynamically allocated
+memory is aligned on larger-than-default byte boundaries.
+On most current systems, the malloc() implementation returns
+pointers that are aligned to 16-byte boundaries. Using SSE vector
+instructions efficiently, however, requires memory blocks being
+aligned on 64-byte boundaries.
+
+[CMake variable]:
+
+-D LAMMPS_MEMALIGN=value            # 0, 8, 16, 32, 64 (default) :pre
+
+Use a LAMMPS_MEMALIGN value of 0 to disable using posix_memalign()
+and revert to using the malloc() C-library function instead.  When
+compiling LAMMPS for Windows systems, malloc() will always be used
+and this setting ignored.
+
+[Makefile.machine setting]:
+
+LMP_INC = -DLAMMPS_MEMALIGN=value   # 8, 16, 32, 64 :pre
+
+Do not set -DLAMMPS_MEMALIGN, if you want to have memory allocated
+with the malloc() function call instead. -DLAMMPS_MEMALIGN [cannot]
+be used on Windows, as it does use different function calls for
+allocating aligned memory, that are not compatible with how LAMMPS
+manages its dynamical memory.
+
+:line
+
+Workaround for long long integers :h4,link(longlong)
+
+If your system or MPI version does not recognize "long long" data
+types, the following setting will be needed.  It converts "long long"
+to a "long" data type, which should be the desired 8-byte integer on
+those systems:
+
+[CMake variable]:
+
+-D LAMMPS_LONGLONG_TO_LONG=value     # yes or no (default) :pre
+
+[Makefile.machine setting]:
+
+LMP_INC = -DLAMMPS_LONGLONG_TO_LONG :pre
+
+:line
+
+Exception handling when using LAMMPS as a library :h4,link(exceptions)
+
+This setting is useful when external codes drive LAMMPS as a library.
+With this option enabled LAMMPS errors do not kill the caller.
+Instead, the call stack is unwound and control returns to the caller,
+e.g. to Python.
+
+[CMake variable]:
+
+-D LAMMPS_EXCEPTIONS=value        # yes or no (default) :pre
+
+[Makefile.machine setting]:
+
+LMP_INC = -DLAMMPS_EXCEPTIONS :pre

doc/src/Build_windows.txt

@@ -0,0 +1,97 @@
+"Higher level section"_Build.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+Notes for building LAMMPS on Windows :h3
+
+"General remarks"_#generic
+"Running Linux on Windows"_#linux
+"Using GNU GCC ported to Windows"_#gnu
+"Using a cross-compiler"_#cross :ul
+
+:line
+
+General remarks :h4,link(generic)
+
+LAMMPS is developed and tested primarily on Linux machines.  The vast
+majority of HPC clusters and supercomputers today runs on Linux as well.
+Thus portability to other platforms is desired, but not always achieved.
+The LAMMPS developers strongly rely on LAMMPS users giving feedback and
+providing assistance in resolving portability issues. This particularly
+true for compiling LAMMPS on Windows, since this platform has significant
+differences with some low-level functionality.
+
+
+Running Linux on Windows :h4,link(linux)
+
+So before trying to build LAMMPS on Windows, please consider if using
+the pre-compiled Windows binary packages are sufficient for your needs
+(as an aside, those packages themselves are build on a Linux machine
+using cross-compilers).  If it is necessary for your to compile LAMMPS
+on a Windows machine (e.g. because it is your main desktop), please also
+consider using a virtual machine software and run a Linux virtual machine,
+or - if have a recently updated Windows 10 installation - consider using
+the Windows subsystem for Linux, which allows to run a bash shell from
+Ubuntu and from there on, you can pretty much use that shell like you
+are running on an Ubuntu Linux machine (e.g. installing software via
+apt-get). For more details on that, please see "this tutorial"_Howto_bash.html
+
+
+Using GNU GCC ported to Windows :h4,link(gnu)
+
+One option for compiling LAMMPS on Windows natively, that has been known
+to work in the past is to install a bash shell, unix shell utilities,
+perl, GNU make, and a GNU compiler ported to Windows. The Cygwin package
+provides a unix/linux interface to low-level Windows functions, so LAMMPS
+can be compiled on Windows. The necessary (minor) modifications to LAMMPS
+are included, but may not always up-to-date for recently added functionality
+and the corresponding new code. A machine makefile for using cygwin for
+the old build system is provided. The CMake build system is untested
+for this; you will have to request that makefiles are generated and
+manually set the compiler.
+
+When compiling for Windows [not] set the -DLAMMPS_MEMALIGN define
+in the LMP_INC makefile variable and add -lwsock32 -lpsapi to the linker
+flags in LIB makefile variable. Try adding -static-libgcc or -static or
+both to the linker flags when your resulting LAMMPS Windows executable
+complains about missing .dll files. The CMake configuration should set
+this up automatically, but is untested.
+
+In case of problems, you are recommended to contact somebody with
+experience in using cygwin.  If you do come across portability problems
+requiring changes to the LAMMPS source code, or figure out corrections
+yourself, please report them on the lammps-users mailing list, or file
+them as an issue or pull request on the LAMMPS GitHub project.
+
+
+Using a cross-compiler :h4,link(cross)
+
+If you need to provide custom LAMMPS binaries for Windows, but do not
+need to do the compilation on Windows, please consider using a Linux
+to Windows cross-compiler. This is how currently the Windows binary
+packages are created by the LAMMPS developers. Because of that, this is
+probably the currently best tested and supported way to build LAMMPS
+executables for Windows.  There are makefiles provided for the
+traditional build system, but CMake has also been successfully tested
+using the mingw32-cmake and mingw64-cmake wrappers that are bundled
+with the cross-compiler environment on Fedora machines.
+
+Please keep in mind, though, that this only applies to compiling LAMMPS.
+Whether the resulting binaries do work correctly is no tested by the
+LAMMPS developers.  We instead rely on the feedback of the users
+of these pre-compiled LAMMPS packages for Windows.  We will try to resolve
+issues to the best of our abilities if we become aware of them. However
+this is subject to time constraints and focus on HPC platforms.
+
+
+Native Visual C++ support :h4,link(native)
+
+Support for the Visual C++ compilers is currently not available. The
+CMake build system is capable of creating suitable a Visual Studio
+style build environment, but the LAMMPS code itself is not fully ported
+to support Visual C++. Volunteers to take on this task are welcome.

doc/src/Commands.txt

@@ -0,0 +1,53 @@
+"Previous Section"_Run_head.html - "LAMMPS WWW Site"_lws -
+"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
+Section"_Packages.html :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html#comm)
+
+:line
+
+Commands :h2
+
+These pages describe how a LAMMPS input script is formatted and the
+commands in it are used to define a LAMMPS simulation.
+
+<!-- RST
+
+.. toctree::
+   :maxdepth: 1
+
+   Commands_input
+   Commands_parse
+   Commands_structure
+   Commands_category
+
+.. toctree::
+   :maxdepth: 1
+
+   Commands_all
+   Commands_fix
+   Commands_compute
+   Commands_pair
+   Commands_bond
+   Commands_kspace
+
+END_RST -->
+
+<!-- HTML_ONLY -->
+
+"LAMMPS input scripts"_Commands_input.html
+"Parsing rules for input scripts"_Commands_parse.html
+"Input script structure"_Commands_structure.html
+"Commands by category"_Commands_category.html :all(b)
+
+"General commands"_Commands_all.html
+"Fix commands"_Commands_fix.html
+"Compute commands"_Commands_compute.html
+"Pair commands"_Commands_pair.html
+"Bond, angle, dihedral, improper commands"_Commands_bond.html
+"KSpace solvers"_Commands_kspace.html  :all(b)
+
+<!-- END_HTML_ONLY -->
+

doc/src/Commands_all.txt

@@ -0,0 +1,131 @@
+"Higher level section"_Commands.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+"General commands"_Commands_all.html,
+"Fix styles"_Commands_fix.html,
+"Compute styles"_Commands_compute.html,
+"Pair styles"_Commands_pair.html,
+"Bond styles"_Commands_bond.html,
+"Angle styles"_Commands_bond.html#angle,
+"Dihedral styles"_Commands_bond.html#dihedral,
+"Improper styles"_Commands_bond.html#improper,
+"KSpace styles"_Commands_kspace.html :tb(c=3,ea=c)
+
+General commands :h3
+
+An alphabetic list of all general LAMMPS commands.
+
+"angle_coeff"_angle_coeff.html,
+"angle_style"_angle_style.html,
+"atom_modify"_atom_modify.html,
+"atom_style"_atom_style.html,
+"balance"_balance.html,
+"bond_coeff"_bond_coeff.html,
+"bond_style"_bond_style.html,
+"bond_write"_bond_write.html,
+"boundary"_boundary.html,
+"box"_box.html,
+"change_box"_change_box.html,
+"clear"_clear.html,
+"comm_modify"_comm_modify.html,
+"comm_style"_comm_style.html,
+"compute"_compute.html,
+"compute_modify"_compute_modify.html,
+"create_atoms"_create_atoms.html,
+"create_bonds"_create_bonds.html,
+"create_box"_create_box.html,
+"delete_atoms"_delete_atoms.html,
+"delete_bonds"_delete_bonds.html,
+"dielectric"_dielectric.html,
+"dihedral_coeff"_dihedral_coeff.html,
+"dihedral_style"_dihedral_style.html,
+"dimension"_dimension.html,
+"displace_atoms"_displace_atoms.html,
+"dump"_dump.html,
+"dump image"_dump_image.html,
+"dump_modify"_dump_modify.html,
+"dump movie"_dump_image.html,
+"dump netcdf"_dump_netcdf.html,
+"dump netcdf/mpiio"_dump_netcdf.html,
+"dump vtk"_dump_vtk.html,
+"echo"_echo.html,
+"fix"_fix.html,
+"fix_modify"_fix_modify.html,
+"group"_group.html,
+"group2ndx"_group2ndx.html,
+"hyper"_hyper.html,
+"if"_if.html,
+"info"_info.html,
+"improper_coeff"_improper_coeff.html,
+"improper_style"_improper_style.html,
+"include"_include.html,
+"jump"_jump.html,
+"kspace_modify"_kspace_modify.html,
+"kspace_style"_kspace_style.html,
+"label"_label.html,
+"lattice"_lattice.html,
+"log"_log.html,
+"mass"_mass.html,
+"message"_message.html,
+"minimize"_minimize.html,
+"min_modify"_min_modify.html,
+"min_style"_min_style.html,
+"molecule"_molecule.html,
+"ndx2group"_group2ndx.html,
+"neb"_neb.html,
+"neigh_modify"_neigh_modify.html,
+"neighbor"_neighbor.html,
+"newton"_newton.html,
+"next"_next.html,
+"package"_package.html,
+"pair_coeff"_pair_coeff.html,
+"pair_modify"_pair_modify.html,
+"pair_style"_pair_style.html,
+"pair_write"_pair_write.html,
+"partition"_partition.html,
+"prd"_prd.html,
+"print"_print.html,
+"processors"_processors.html,
+"python"_python.html,
+"quit"_quit.html,
+"read_data"_read_data.html,
+"read_dump"_read_dump.html,
+"read_restart"_read_restart.html,
+"region"_region.html,
+"replicate"_replicate.html,
+"rerun"_rerun.html,
+"reset_ids"_reset_ids.html,
+"reset_timestep"_reset_timestep.html,
+"restart"_restart.html,
+"run"_run.html,
+"run_style"_run_style.html,
+"server"_server.html,
+"set"_set.html,
+"shell"_shell.html,
+"special_bonds"_special_bonds.html,
+"suffix"_suffix.html,
+"tad"_tad.html,
+"temper"_temper.html,
+"temper/grem"_temper_grem.html,
+"temper/npt"_temper_npt.html,
+"thermo"_thermo.html,
+"thermo_modify"_thermo_modify.html,
+"thermo_style"_thermo_style.html,
+"timer"_timer.html,
+"timestep"_timestep.html,
+"uncompute"_uncompute.html,
+"undump"_undump.html,
+"unfix"_unfix.html,
+"units"_units.html,
+"variable"_variable.html,
+"velocity"_velocity.html,
+"write_coeff"_write_coeff.html,
+"write_data"_write_data.html,
+"write_dump"_write_dump.html,
+"write_restart"_write_restart.html :tb(c=6,ea=c)

doc/src/Commands_bond.txt

@@ -0,0 +1,132 @@
+"Higher level section"_Commands.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+"General commands"_Commands_all.html,
+"Fix styles"_Commands_fix.html,
+"Compute styles"_Commands_compute.html,
+"Pair styles"_Commands_pair.html,
+"Bond styles"_Commands_bond.html#bond,
+"Angle styles"_Commands_bond.html#angle,
+"Dihedral styles"_Commands_bond.html#dihedral,
+"Improper styles"_Commands_bond.html#improper,
+"KSpace styles"_Commands_kspace.html :tb(c=3,ea=c)
+
+Bond, angle, dihedral, and improper commands :h3
+
+:line
+
+Bond_style potentials :h3,link(bond)
+
+All LAMMPS "bond_style"_bond_style.html commands.  Some styles have
+accelerated versions.  This is indicated by additional letters in
+parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o = USER-OMP, t =
+OPT.
+
+"none"_bond_none.html,
+"zero"_bond_zero.html,
+"hybrid"_bond_hybrid.html :tb(c=3,ea=c)
+
+"class2 (ko)"_bond_class2.html,
+"fene (iko)"_bond_fene.html,
+"fene/expand (o)"_bond_fene_expand.html,
+"gromos (o)"_bond_gromos.html,
+"harmonic (iko)"_bond_harmonic.html,
+"harmonic/shift (o)"_bond_harmonic_shift.html,
+"harmonic/shift/cut (o)"_bond_harmonic_shift_cut.html,
+"mm3"_bond_mm3.html,
+"morse (o)"_bond_morse.html,
+"nonlinear (o)"_bond_nonlinear.html,
+"oxdna/fene"_bond_oxdna.html,
+"oxdna2/fene"_bond_oxdna.html,
+"quartic (o)"_bond_quartic.html,
+"table (o)"_bond_table.html :tb(c=4,ea=c)
+
+:line
+
+Angle_style potentials :h3,link(angle)
+
+All LAMMPS "angle_style"_angle_style.html commands.  Some styles have
+accelerated versions.  This is indicated by additional letters in
+parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o = USER-OMP, t =
+OPT.
+
+"none"_angle_none.html,
+"zero"_angle_zero.html,
+"hybrid"_angle_hybrid.html :tb(c=3,ea=c)
+
+"charmm (iko)"_angle_charmm.html,
+"class2 (ko)"_angle_class2.html,
+"class2/p6"_angle_class2.html,
+"cosine (ko)"_angle_cosine.html,
+"cosine/buck6d"_angle_cosine_buck6d.html,
+"cosine/delta (o)"_angle_cosine_delta.html,
+"cosine/periodic (o)"_angle_cosine_periodic.html,
+"cosine/shift (o)"_angle_cosine_shift.html,
+"cosine/shift/exp (o)"_angle_cosine_shift_exp.html,
+"cosine/squared (o)"_angle_cosine_squared.html,
+"cross"_angle_cross.html,
+"dipole (o)"_angle_dipole.html,
+"fourier (o)"_angle_fourier.html,
+"fourier/simple (o)"_angle_fourier_simple.html,
+"harmonic (iko)"_angle_harmonic.html,
+"mm3"_angle_mm3.html,
+"quartic (o)"_angle_quartic.html,
+"sdk (o)"_angle_sdk.html,
+"table (o)"_angle_table.html :tb(c=4,ea=c)
+
+:line
+
+Dihedral_style potentials :h3,link(dihedral)
+
+All LAMMPS "dihedral_style"_dihedral_style.html commands.  Some styles
+have accelerated versions.  This is indicated by additional letters in
+parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o = USER-OMP, t =
+OPT.
+
+"none"_dihedral_none.html,
+"zero"_dihedral_zero.html,
+"hybrid"_dihedral_hybrid.html :tb(c=3,ea=c)
+
+"charmm (iko)"_dihedral_charmm.html,
+"charmmfsw"_dihedral_charmm.html,
+"class2 (ko)"_dihedral_class2.html,
+"cosine/shift/exp (o)"_dihedral_cosine_shift_exp.html,
+"fourier (io)"_dihedral_fourier.html,
+"harmonic (io)"_dihedral_harmonic.html,
+"helix (o)"_dihedral_helix.html,
+"multi/harmonic (o)"_dihedral_multi_harmonic.html,
+"nharmonic (o)"_dihedral_nharmonic.html,
+"opls (iko)"_dihedral_opls.html,
+"quadratic (o)"_dihedral_quadratic.html,
+"spherical"_dihedral_spherical.html,
+"table (o)"_dihedral_table.html,
+"table/cut"_dihedral_table_cut.html :tb(c=4,ea=c)
+
+:line
+
+Improper_style potentials :h3,link(improper)
+
+All LAMMPS "improper_style"_improper_style.html commands.  Some styles
+have accelerated versions.  This is indicated by additional letters in
+parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o = USER-OMP, t =
+OPT.
+
+"none"_improper_none.html,
+"zero"_improper_zero.html,
+"hybrid"_improper_hybrid.html :tb(c=3,ea=c)
+
+"class2 (ko)"_improper_class2.html,
+"cossq (o)"_improper_cossq.html,
+"cvff (io)"_improper_cvff.html,
+"distance"_improper_distance.html,
+"distharm"_improper_distharm.html,
+"fourier (o)"_improper_fourier.html,
+"harmonic (iko)"_improper_harmonic.html,
+"inversion/harmonic"_improper_inversion_harmonic.html,
+"ring (o)"_improper_ring.html,
+"sqdistharm"_improper_sqdistharm.html,
+"umbrella (o)"_improper_umbrella.html :tb(c=4,ea=c)

doc/src/Commands_category.txt

@@ -0,0 +1,140 @@
+"Higher level section"_Commands.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+Commands by category :h3
+
+This page lists most of the LAMMPS commands, grouped by category.  The
+"General commands"_Commands_all.html doc page lists all general commands
+alphabetically.  Style options for entries like fix, compute, pair etc.
+have their own pages where they are listed alphabetically.
+
+Initialization:
+
+"newton"_newton.html,
+"package"_package.html,
+"processors"_processors.html,
+"suffix"_suffix.html,
+"units"_units.html :ul
+
+Setup simulation box:
+
+"boundary"_boundary.html,
+"box"_box.html,
+"change_box"_change_box.html,
+"create_box"_create_box.html,
+"dimension"_dimension.html,
+"lattice"_lattice.html,
+"region"_region.html :ul
+
+Setup atoms:
+
+"atom_modify"_atom_modify.html,
+"atom_style"_atom_style.html,
+"balance"_balance.html,
+"create_atoms"_create_atoms.html,
+"create_bonds"_create_bonds.html,
+"delete_atoms"_delete_atoms.html,
+"delete_bonds"_delete_bonds.html,
+"displace_atoms"_displace_atoms.html,
+"group"_group.html,
+"mass"_mass.html,
+"molecule"_molecule.html,
+"read_data"_read_data.html,
+"read_dump"_read_dump.html,
+"read_restart"_read_restart.html,
+"replicate"_replicate.html,
+"set"_set.html,
+"velocity"_velocity.html :ul
+
+Force fields:
+
+"angle_coeff"_angle_coeff.html,
+"angle_style"_angle_style.html,
+"bond_coeff"_bond_coeff.html,
+"bond_style"_bond_style.html,
+"bond_write"_bond_write.html,
+"dielectric"_dielectric.html,
+"dihedral_coeff"_dihedral_coeff.html,
+"dihedral_style"_dihedral_style.html,
+"improper_coeff"_improper_coeff.html,
+"improper_style"_improper_style.html,
+"kspace_modify"_kspace_modify.html,
+"kspace_style"_kspace_style.html,
+"pair_coeff"_pair_coeff.html,
+"pair_modify"_pair_modify.html,
+"pair_style"_pair_style.html,
+"pair_write"_pair_write.html,
+"special_bonds"_special_bonds.html :ul
+
+Settings:
+
+"comm_modify"_comm_modify.html,
+"comm_style"_comm_style.html,
+"info"_info.html,
+"min_modify"_min_modify.html,
+"min_style"_min_style.html,
+"neigh_modify"_neigh_modify.html,
+"neighbor"_neighbor.html,
+"partition"_partition.html,
+"reset_timestep"_reset_timestep.html,
+"run_style"_run_style.html,
+"timer"_timer.html,
+"timestep"_timestep.html :ul
+
+Operations within timestepping (fixes) and diagnostics (computes):
+
+"compute"_compute.html,
+"compute_modify"_compute_modify.html,
+"fix"_fix.html,
+"fix_modify"_fix_modify.html,
+"uncompute"_uncompute.html,
+"unfix"_unfix.html :ul
+
+Output:
+
+"dump image"_dump_image.html,
+"dump movie"_dump_image.html,
+"dump"_dump.html,
+"dump_modify"_dump_modify.html,
+"restart"_restart.html,
+"thermo"_thermo.html,
+"thermo_modify"_thermo_modify.html,
+"thermo_style"_thermo_style.html,
+"undump"_undump.html,
+"write_coeff"_write_coeff.html,
+"write_data"_write_data.html,
+"write_dump"_write_dump.html,
+"write_restart"_write_restart.html :ul
+
+Actions:
+
+"minimize"_minimize.html,
+"neb"_neb.html,
+"prd"_prd.html,
+"rerun"_rerun.html,
+"run"_run.html,
+"tad"_tad.html,
+"temper"_temper.html :ul
+
+Input script control:
+
+"clear"_clear.html,
+"echo"_echo.html,
+"if"_if.html,
+"include"_include.html,
+"jump"_jump.html,
+"label"_label.html,
+"log"_log.html,
+"next"_next.html,
+"print"_print.html,
+"python"_python.html,
+"quit"_quit.html,
+"shell"_shell.html,
+"variable"_variable.html :ul
+

doc/src/Commands_compute.txt

@@ -0,0 +1,161 @@
+"Higher level section"_Commands.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+"General commands"_Commands_all.html,
+"Fix styles"_Commands_fix.html,
+"Compute styles"_Commands_compute.html,
+"Pair styles"_Commands_pair.html,
+"Bond styles"_Commands_bond.html,
+"Angle styles"_Commands_bond.html#angle,
+"Dihedral styles"_Commands_bond.html#dihedral,
+"Improper styles"_Commands_bond.html#improper,
+"KSpace styles"_Commands_kspace.html :tb(c=3,ea=c)
+
+Compute commands :h3
+
+An alphabetic list of all LAMMPS "compute"_compute.html commands.
+Some styles have accelerated versions.  This is indicated by
+additional letters in parenthesis: g = GPU, i = USER-INTEL, k =
+KOKKOS, o = USER-OMP, t = OPT.
+
+"ackland/atom"_compute_ackland_atom.html,
+"adf"_compute_adf.html,
+"aggregate/atom"_compute_cluster_atom.html,
+"angle"_compute_angle.html,
+"angle/local"_compute_angle_local.html,
+"angmom/chunk"_compute_angmom_chunk.html,
+"basal/atom"_compute_basal_atom.html,
+"body/local"_compute_body_local.html,
+"bond"_compute_bond.html,
+"bond/local"_compute_bond_local.html,
+"centro/atom"_compute_centro_atom.html,
+"chunk/atom"_compute_chunk_atom.html,
+"chunk/spread/atom"_compute_chunk_spread_atom.html,
+"cluster/atom"_compute_cluster_atom.html,
+"cna/atom"_compute_cna_atom.html,
+"cnp/atom"_compute_cnp_atom.html,
+"com"_compute_com.html,
+"com/chunk"_compute_com_chunk.html,
+"contact/atom"_compute_contact_atom.html,
+"coord/atom"_compute_coord_atom.html,
+"damage/atom"_compute_damage_atom.html,
+"dihedral"_compute_dihedral.html,
+"dihedral/local"_compute_dihedral_local.html,
+"dilatation/atom"_compute_dilatation_atom.html,
+"dipole/chunk"_compute_dipole_chunk.html,
+"displace/atom"_compute_displace_atom.html,
+"dpd"_compute_dpd.html,
+"dpd/atom"_compute_dpd_atom.html,
+"edpd/temp/atom"_compute_edpd_temp_atom.html,
+"entropy/atom"_compute_entropy_atom.html,
+"erotate/asphere"_compute_erotate_asphere.html,
+"erotate/rigid"_compute_erotate_rigid.html,
+"erotate/sphere"_compute_erotate_sphere.html,
+"erotate/sphere/atom"_compute_erotate_sphere_atom.html,
+"event/displace"_compute_event_displace.html,
+"fep"_compute_fep.html,
+"force/tally"_compute_tally.html,
+"fragment/atom"_compute_cluster_atom.html,
+"global/atom"_compute_global_atom.html,
+"group/group"_compute_group_group.html,
+"gyration"_compute_gyration.html,
+"gyration/chunk"_compute_gyration_chunk.html,
+"heat/flux"_compute_heat_flux.html,
+"heat/flux/tally"_compute_tally.html,
+"hexorder/atom"_compute_hexorder_atom.html,
+"improper"_compute_improper.html,
+"improper/local"_compute_improper_local.html,
+"inertia/chunk"_compute_inertia_chunk.html,
+"ke"_compute_ke.html,
+"ke/atom"_compute_ke_atom.html,
+"ke/atom/eff"_compute_ke_atom_eff.html,
+"ke/eff"_compute_ke_eff.html,
+"ke/rigid"_compute_ke_rigid.html,
+"meso/e/atom"_compute_meso_e_atom.html,
+"meso/rho/atom"_compute_meso_rho_atom.html,
+"meso/t/atom"_compute_meso_t_atom.html,
+"msd"_compute_msd.html,
+"msd/chunk"_compute_msd_chunk.html,
+"msd/nongauss"_compute_msd_nongauss.html,
+"omega/chunk"_compute_omega_chunk.html,
+"orientorder/atom"_compute_orientorder_atom.html,
+"pair"_compute_pair.html,
+"pair/local"_compute_pair_local.html,
+"pe"_compute_pe.html,
+"pe/atom"_compute_pe_atom.html,
+"pe/mol/tally"_compute_tally.html,
+"pe/tally"_compute_tally.html,
+"plasticity/atom"_compute_plasticity_atom.html,
+"pressure"_compute_pressure.html,
+"pressure/cylinder"_compute_pressure_cylinder.html,
+"pressure/uef"_compute_pressure_uef.html,
+"property/atom"_compute_property_atom.html,
+"property/chunk"_compute_property_chunk.html,
+"property/local"_compute_property_local.html,
+"ptm/atom"_compute_ptm_atom.html,
+"rdf"_compute_rdf.html,
+"reduce"_compute_reduce.html,
+"reduce/chunk"_compute_reduce_chunk.html,
+"reduce/region"_compute_reduce.html,
+"rigid/local"_compute_rigid_local.html,
+"saed"_compute_saed.html,
+"slice"_compute_slice.html,
+"smd/contact/radius"_compute_smd_contact_radius.html,
+"smd/damage"_compute_smd_damage.html,
+"smd/hourglass/error"_compute_smd_hourglass_error.html,
+"smd/internal/energy"_compute_smd_internal_energy.html,
+"smd/plastic/strain"_compute_smd_plastic_strain.html,
+"smd/plastic/strain/rate"_compute_smd_plastic_strain_rate.html,
+"smd/rho"_compute_smd_rho.html,
+"smd/tlsph/defgrad"_compute_smd_tlsph_defgrad.html,
+"smd/tlsph/dt"_compute_smd_tlsph_dt.html,
+"smd/tlsph/num/neighs"_compute_smd_tlsph_num_neighs.html,
+"smd/tlsph/shape"_compute_smd_tlsph_shape.html,
+"smd/tlsph/strain"_compute_smd_tlsph_strain.html,
+"smd/tlsph/strain/rate"_compute_smd_tlsph_strain_rate.html,
+"smd/tlsph/stress"_compute_smd_tlsph_stress.html,
+"smd/triangle/vertices"_compute_smd_triangle_vertices.html,
+"smd/ulsph/num/neighs"_compute_smd_ulsph_num_neighs.html,
+"smd/ulsph/strain"_compute_smd_ulsph_strain.html,
+"smd/ulsph/strain/rate"_compute_smd_ulsph_strain_rate.html,
+"smd/ulsph/stress"_compute_smd_ulsph_stress.html,
+"smd/vol"_compute_smd_vol.html,
+"sna/atom"_compute_sna_atom.html,
+"snad/atom"_compute_sna_atom.html,
+"snav/atom"_compute_sna_atom.html,
+"spin"_compute_spin.html,
+"stress/atom"_compute_stress_atom.html,
+"stress/mop"_compute_stress_mop.html,
+"stress/mop/profile"_compute_stress_mop.html,
+"stress/tally"_compute_tally.html,
+"tdpd/cc/atom"_compute_tdpd_cc_atom.html,
+"temp (k)"_compute_temp.html,
+"temp/asphere"_compute_temp_asphere.html,
+"temp/body"_compute_temp_body.html,
+"temp/chunk"_compute_temp_chunk.html,
+"temp/com"_compute_temp_com.html,
+"temp/cs"_compute_temp_cs.html,
+"temp/deform"_compute_temp_deform.html,
+"temp/deform/eff"_compute_temp_deform_eff.html,
+"temp/drude"_compute_temp_drude.html,
+"temp/eff"_compute_temp_eff.html,
+"temp/partial"_compute_temp_partial.html,
+"temp/profile"_compute_temp_profile.html,
+"temp/ramp"_compute_temp_ramp.html,
+"temp/region"_compute_temp_region.html,
+"temp/region/eff"_compute_temp_region_eff.html,
+"temp/rotate"_compute_temp_rotate.html,
+"temp/sphere"_compute_temp_sphere.html,
+"temp/uef"_compute_temp_uef.html,
+"ti"_compute_ti.html,
+"torque/chunk"_compute_torque_chunk.html,
+"vacf"_compute_vacf.html,
+"vcm/chunk"_compute_vcm_chunk.html,
+"voronoi/atom"_compute_voronoi_atom.html,
+"xrd"_compute_xrd.html :tb(c=6,ea=c)

doc/src/Commands_fix.txt

@@ -0,0 +1,237 @@
+"Higher level section"_Commands.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+"General commands"_Commands_all.html,
+"Fix styles"_Commands_fix.html,
+"Compute styles"_Commands_compute.html,
+"Pair styles"_Commands_pair.html,
+"Bond styles"_Commands_bond.html,
+"Angle styles"_Commands_bond.html#angle,
+"Dihedral styles"_Commands_bond.html#dihedral,
+"Improper styles"_Commands_bond.html#improper,
+"KSpace styles"_Commands_kspace.html :tb(c=3,ea=c)
+
+Fix commands :h3
+
+An alphabetic list of all LAMMPS "fix"_fix.html commands.  Some styles
+have accelerated versions.  This is indicated by additional letters in
+parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o = USER-OMP, t =
+OPT.
+
+"adapt"_fix_adapt.html,
+"adapt/fep"_fix_adapt_fep.html,
+"addforce"_fix_addforce.html,
+"addtorque"_fix_addtorque.html,
+"append/atoms"_fix_append_atoms.html,
+"atc"_fix_atc.html,
+"atom/swap"_fix_atom_swap.html,
+"ave/atom"_fix_ave_atom.html,
+"ave/chunk"_fix_ave_chunk.html,
+"ave/correlate"_fix_ave_correlate.html,
+"ave/correlate/long"_fix_ave_correlate_long.html,
+"ave/histo"_fix_ave_histo.html,
+"ave/histo/weight"_fix_ave_histo.html,
+"ave/time"_fix_ave_time.html,
+"aveforce"_fix_aveforce.html,
+"balance"_fix_balance.html,
+"bocs"_fix_bocs.html,
+"bond/break"_fix_bond_break.html,
+"bond/create"_fix_bond_create.html,
+"bond/react"_fix_bond_react.html,
+"bond/swap"_fix_bond_swap.html,
+"box/relax"_fix_box_relax.html,
+"client/md"_fix_client_md.html,
+"cmap"_fix_cmap.html,
+"colvars"_fix_colvars.html,
+"controller"_fix_controller.html,
+"deform (k)"_fix_deform.html,
+"deposit"_fix_deposit.html,
+"dpd/energy (k)"_fix_dpd_energy.html,
+"drag"_fix_drag.html,
+"drude"_fix_drude.html,
+"drude/transform/direct"_fix_drude_transform.html,
+"drude/transform/inverse"_fix_drude_transform.html,
+"dt/reset"_fix_dt_reset.html,
+"edpd/source"_fix_dpd_source.html,
+"efield"_fix_efield.html,
+"ehex"_fix_ehex.html,
+"enforce2d (k)"_fix_enforce2d.html,
+"eos/cv"_fix_eos_cv.html,
+"eos/table"_fix_eos_table.html,
+"eos/table/rx (k)"_fix_eos_table_rx.html,
+"evaporate"_fix_evaporate.html,
+"external"_fix_external.html,
+"ffl"_fix_ffl.html,
+"filter/corotate"_fix_filter_corotate.html,
+"flow/gauss"_fix_flow_gauss.html,
+"freeze (k)"_fix_freeze.html,
+"gcmc"_fix_gcmc.html,
+"gld"_fix_gld.html,
+"gle"_fix_gle.html,
+"gravity (ko)"_fix_gravity.html,
+"grem"_fix_grem.html,
+"halt"_fix_halt.html,
+"heat"_fix_heat.html,
+"hyper/global"_fix_hyper_global.html,
+"hyper/local"_fix_hyper_local.html,
+"imd"_fix_imd.html,
+"indent"_fix_indent.html,
+"ipi"_fix_ipi.html,
+"langevin (k)"_fix_langevin.html,
+"langevin/drude"_fix_langevin_drude.html,
+"langevin/eff"_fix_langevin_eff.html,
+"langevin/spin"_fix_langevin_spin.html,
+"latte"_fix_latte.html,
+"lb/fluid"_fix_lb_fluid.html,
+"lb/momentum"_fix_lb_momentum.html,
+"lb/pc"_fix_lb_pc.html,
+"lb/rigid/pc/sphere"_fix_lb_rigid_pc_sphere.html,
+"lb/viscous"_fix_lb_viscous.html,
+"lineforce"_fix_lineforce.html,
+"manifoldforce"_fix_manifoldforce.html,
+"meso"_fix_meso.html,
+"meso/move"_fix_meso_move.html,
+"meso/stationary"_fix_meso_stationary.html,
+"momentum (k)"_fix_momentum.html,
+"move"_fix_move.html,
+"mscg"_fix_mscg.html,
+"msst"_fix_msst.html,
+"mvv/dpd"_fix_mvv_dpd.html,
+"mvv/edpd"_fix_mvv_dpd.html,
+"mvv/tdpd"_fix_mvv_dpd.html,
+"neb"_fix_neb.html,
+"nph (ko)"_fix_nh.html,
+"nph/asphere (o)"_fix_nph_asphere.html,
+"nph/body"_fix_nph_body.html,
+"nph/eff"_fix_nh_eff.html,
+"nph/sphere (o)"_fix_nph_sphere.html,
+"nphug (o)"_fix_nphug.html,
+"npt (iko)"_fix_nh.html,
+"npt/asphere (o)"_fix_npt_asphere.html,
+"npt/body"_fix_npt_body.html,
+"npt/eff"_fix_nh_eff.html,
+"npt/sphere (o)"_fix_npt_sphere.html,
+"npt/uef"_fix_nh_uef.html,
+"nve (iko)"_fix_nve.html,
+"nve/asphere (i)"_fix_nve_asphere.html,
+"nve/asphere/noforce"_fix_nve_asphere_noforce.html,
+"nve/awpmd"_fix_nve_awpmd.html,
+"nve/body"_fix_nve_body.html,
+"nve/dot"_fix_nve_dot.html,
+"nve/dotc/langevin"_fix_nve_dotc_langevin.html,
+"nve/eff"_fix_nve_eff.html,
+"nve/limit"_fix_nve_limit.html,
+"nve/line"_fix_nve_line.html,
+"nve/manifold/rattle"_fix_nve_manifold_rattle.html,
+"nve/noforce"_fix_nve_noforce.html,
+"nve/sphere (ko)"_fix_nve_sphere.html,
+"nve/spin"_fix_nve_spin.html,
+"nve/tri"_fix_nve_tri.html,
+"nvk"_fix_nvk.html,
+"nvt (iko)"_fix_nh.html,
+"nvt/asphere (o)"_fix_nvt_asphere.html,
+"nvt/body"_fix_nvt_body.html,
+"nvt/eff"_fix_nh_eff.html,
+"nvt/manifold/rattle"_fix_nvt_manifold_rattle.html,
+"nvt/sllod (io)"_fix_nvt_sllod.html,
+"nvt/sllod/eff"_fix_nvt_sllod_eff.html,
+"nvt/sphere (o)"_fix_nvt_sphere.html,
+"nvt/uef"_fix_nh_uef.html,
+"oneway"_fix_oneway.html,
+"orient/bcc"_fix_orient.html,
+"orient/fcc"_fix_orient.html,
+"phonon"_fix_phonon.html,
+"pimd"_fix_pimd.html,
+"planeforce"_fix_planeforce.html,
+"plumed"_fix_plumed.html,
+"poems"_fix_poems.html,
+"pour"_fix_pour.html,
+"precession/spin"_fix_precession_spin.html,
+"press/berendsen"_fix_press_berendsen.html,
+"print"_fix_print.html,
+"property/atom (k)"_fix_property_atom.html,
+"python/invoke"_fix_python_invoke.html,
+"python/move"_fix_python_move.html,
+"qbmsst"_fix_qbmsst.html,
+"qeq/comb (o)"_fix_qeq_comb.html,
+"qeq/dynamic"_fix_qeq.html,
+"qeq/fire"_fix_qeq.html,
+"qeq/point"_fix_qeq.html,
+"qeq/reax (ko)"_fix_qeq_reax.html,
+"qeq/shielded"_fix_qeq.html,
+"qeq/slater"_fix_qeq.html,
+"qmmm"_fix_qmmm.html,
+"qtb"_fix_qtb.html,
+"rattle"_fix_shake.html,
+"reax/c/bonds (k)"_fix_reaxc_bonds.html,
+"reax/c/species (k)"_fix_reaxc_species.html,
+"recenter"_fix_recenter.html,
+"restrain"_fix_restrain.html,
+"rhok"_fix_rhok.html,
+"rigid (o)"_fix_rigid.html,
+"rigid/meso"_fix_rigid_meso.html,
+"rigid/nph (o)"_fix_rigid.html,
+"rigid/nph/small"_fix_rigid.html,
+"rigid/npt (o)"_fix_rigid.html,
+"rigid/npt/small"_fix_rigid.html,
+"rigid/nve (o)"_fix_rigid.html,
+"rigid/nve/small"_fix_rigid.html,
+"rigid/nvt (o)"_fix_rigid.html,
+"rigid/nvt/small"_fix_rigid.html,
+"rigid/small (o)"_fix_rigid.html,
+"rx (k)"_fix_rx.html,
+"saed/vtk"_fix_saed_vtk.html,
+"setforce (k)"_fix_setforce.html,
+"shake"_fix_shake.html,
+"shardlow (k)"_fix_shardlow.html,
+"smd"_fix_smd.html,
+"smd/adjust_dt"_fix_smd_adjust_dt.html,
+"smd/integrate_tlsph"_fix_smd_integrate_tlsph.html,
+"smd/integrate_ulsph"_fix_smd_integrate_ulsph.html,
+"smd/move_tri_surf"_fix_smd_move_triangulated_surface.html,
+"smd/setvel"_fix_smd_setvel.html,
+"smd/wall_surface"_fix_smd_wall_surface.html,
+"spring"_fix_spring.html,
+"spring/chunk"_fix_spring_chunk.html,
+"spring/rg"_fix_spring_rg.html,
+"spring/self"_fix_spring_self.html,
+"srd"_fix_srd.html,
+"store/force"_fix_store_force.html,
+"store/state"_fix_store_state.html,
+"tdpd/source"_fix_dpd_source.html,
+"temp/berendsen"_fix_temp_berendsen.html,
+"temp/csld"_fix_temp_csvr.html,
+"temp/csvr"_fix_temp_csvr.html,
+"temp/rescale"_fix_temp_rescale.html,
+"temp/rescale/eff"_fix_temp_rescale_eff.html,
+"tfmc"_fix_tfmc.html,
+"thermal/conductivity"_fix_thermal_conductivity.html,
+"ti/spring"_fix_ti_spring.html,
+"tmd"_fix_tmd.html,
+"ttm"_fix_ttm.html,
+"ttm/mod"_fix_ttm.html,
+"tune/kspace"_fix_tune_kspace.html,
+"vector"_fix_vector.html,
+"viscosity"_fix_viscosity.html,
+"viscous"_fix_viscous.html,
+"wall/body/polygon"_fix_wall_body_polygon.html,
+"wall/body/polyhedron"_fix_wall_body_polyhedron.html,
+"wall/colloid"_fix_wall.html,
+"wall/ees"_fix_wall_ees.html,
+"wall/gran (o)"_fix_wall_gran.html,
+"wall/gran/region"_fix_wall_gran_region.html,
+"wall/harmonic"_fix_wall.html,
+"wall/lj1043"_fix_wall.html,
+"wall/lj126"_fix_wall.html,
+"wall/lj93 (k)"_fix_wall.html,
+"wall/piston"_fix_wall_piston.html,
+"wall/reflect (k)"_fix_wall_reflect.html,
+"wall/region"_fix_wall_region.html,
+"wall/region/ees"_fix_wall_ees.html,
+"wall/srd"_fix_wall_srd.html :tb(c=6,ea=c)

doc/src/Commands_input.txt

@@ -0,0 +1,60 @@
+"Higher level section"_Commands.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+LAMMPS input scripts :h3
+
+LAMMPS executes by reading commands from a input script (text file),
+one line at a time.  When the input script ends, LAMMPS exits.  Each
+command causes LAMMPS to take some action.  It may set an internal
+variable, read in a file, or run a simulation.  Most commands have
+default settings, which means you only need to use the command if you
+wish to change the default.
+
+In many cases, the ordering of commands in an input script is not
+important.  However the following rules apply:
+
+(1) LAMMPS does not read your entire input script and then perform a
+simulation with all the settings.  Rather, the input script is read
+one line at a time and each command takes effect when it is read.
+Thus this sequence of commands:
+
+timestep 0.5
+run      100
+run      100 :pre
+
+does something different than this sequence:
+
+run      100
+timestep 0.5
+run      100 :pre
+
+In the first case, the specified timestep (0.5 fs) is used for two
+simulations of 100 timesteps each.  In the 2nd case, the default
+timestep (1.0 fs) is used for the 1st 100 step simulation and a 0.5 fs
+timestep is used for the 2nd one.
+
+(2) Some commands are only valid when they follow other commands.  For
+example you cannot set the temperature of a group of atoms until atoms
+have been defined and a group command is used to define which atoms
+belong to the group.
+
+(3) Sometimes command B will use values that can be set by command A.
+This means command A must precede command B in the input script if it
+is to have the desired effect.  For example, the
+"read_data"_read_data.html command initializes the system by setting
+up the simulation box and assigning atoms to processors.  If default
+values are not desired, the "processors"_processors.html and
+"boundary"_boundary.html commands need to be used before read_data to
+tell LAMMPS how to map processors to the simulation box.
+
+Many input script errors are detected by LAMMPS and an ERROR or
+WARNING message is printed.  The "Errors"_Errors.html doc page gives
+more information on what errors mean.  The documentation for each
+command lists restrictions on how the command can be used.
+

doc/src/Commands_kspace.txt

@@ -0,0 +1,37 @@
+"Higher level section"_Commands.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands.html)
+
+:line
+
+"General commands"_Commands_all.html,
+"Fix styles"_Commands_fix.html,
+"Compute styles"_Commands_compute.html,
+"Pair styles"_Commands_pair.html,
+"Bond styles"_Commands_bond.html,
+"Angle styles"_Commands_bond.html#angle,
+"Dihedral styles"_Commands_bond.html#dihedral,
+"Improper styles"_Commands_bond.html#improper,
+"KSpace styles"_Commands_kspace.html :tb(c=3,ea=c)
+
+KSpace solvers :h3
+
+All LAMMPS "kspace_style"_kspace_style.html solvers.  Some styles have
+accelerated versions.  This is indicated by additional letters in
+parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o = USER-OMP, t =
+OPT.
+
+"ewald (o)"_kspace_style.html,
+"ewald/disp"_kspace_style.html,
+"msm (o)"_kspace_style.html,
+"msm/cg (o)"_kspace_style.html,
+"pppm (gok)"_kspace_style.html,
+"pppm/cg (o)"_kspace_style.html,
+"pppm/disp (i)"_kspace_style.html,
+"pppm/disp/tip4p"_kspace_style.html,
+"pppm/stagger"_kspace_style.html,
+"pppm/tip4p (o)"_kspace_style.html,
+"scafacos"_kspace_style.html :tb(c=4,ea=c)

doc/src/Commands_pair.txt

@@ -0,0 +1,243 @@
+"Higher level section"_Commands.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+"General commands"_Commands_all.html,
+"Fix styles"_Commands_fix.html,
+"Compute styles"_Commands_compute.html,
+"Pair styles"_Commands_pair.html,
+"Bond styles"_Commands_bond.html,
+"Angle styles"_Commands_bond.html#angle,
+"Dihedral styles"_Commands_bond.html#dihedral,
+"Improper styles"_Commands_bond.html#improper,
+"KSpace styles"_Commands_kspace.html :tb(c=3,ea=c)
+
+Pair_style potentials :h3
+
+All LAMMPS "pair_style"_pair_style.html commands.  Some styles have
+accelerated versions.  This is indicated by additional letters in
+parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o = USER-OMP, t =
+OPT.
+
+"none"_pair_none.html,
+"zero"_pair_zero.html,
+"hybrid (k)"_pair_hybrid.html,
+"hybrid/overlay (k)"_pair_hybrid.html :tb(c=4,ea=c)
+
+"adp (o)"_pair_adp.html,
+"agni (o)"_pair_agni.html,
+"airebo (io)"_pair_airebo.html,
+"airebo/morse (io)"_pair_airebo.html,
+"atm"_pair_atm.html,
+"awpmd/cut"_pair_awpmd.html,
+"beck (go)"_pair_beck.html,
+"body/nparticle"_pair_body_nparticle.html,
+"body/rounded/polygon"_pair_body_rounded_polygon.html,
+"body/rounded/polyhedron"_pair_body_rounded_polyhedron.html,
+"bop"_pair_bop.html,
+"born (go)"_pair_born.html,
+"born/coul/dsf"_pair_born.html,
+"born/coul/dsf/cs"_pair_cs.html,
+"born/coul/long (go)"_pair_born.html,
+"born/coul/long/cs (g)"_pair_cs.html,
+"born/coul/msm (o)"_pair_born.html,
+"born/coul/wolf (go)"_pair_born.html,
+"born/coul/wolf/cs (g)"_pair_cs.html,
+"brownian (o)"_pair_brownian.html,
+"brownian/poly (o)"_pair_brownian.html,
+"buck (giko)"_pair_buck.html,
+"buck/coul/cut (giko)"_pair_buck.html,
+"buck/coul/long (giko)"_pair_buck.html,
+"buck/coul/long/cs"_pair_cs.html,
+"buck/coul/msm (o)"_pair_buck.html,
+"buck/long/coul/long (o)"_pair_buck_long.html,
+"buck/mdf"_pair_mdf.html,
+"buck6d/coul/gauss/dsf"_pair_buck6d_coul_gauss.html,
+"buck6d/coul/gauss/long"_pair_buck6d_coul_gauss.html,
+"colloid (go)"_pair_colloid.html,
+"comb (o)"_pair_comb.html,
+"comb3"_pair_comb.html,
+"coul/cut (gko)"_pair_coul.html,
+"coul/cut/soft (o)"_pair_fep_soft.html,
+"coul/debye (gko)"_pair_coul.html,
+"coul/diel (o)"_pair_coul_diel.html,
+"coul/dsf (gko)"_pair_coul.html,
+"coul/long (gko)"_pair_coul.html,
+"coul/long/cs (g)"_pair_cs.html,
+"coul/long/soft (o)"_pair_fep_soft.html,
+"coul/msm (o)"_pair_coul.html,
+"coul/shield"_pair_coul_shield.html,
+"coul/streitz"_pair_coul.html,
+"coul/wolf (ko)"_pair_coul.html,
+"coul/wolf/cs"_pair_cs.html,
+"dpd (gio)"_pair_dpd.html,
+"dpd/fdt"_pair_dpd_fdt.html,
+"dpd/fdt/energy (k)"_pair_dpd_fdt.html,
+"dpd/tstat (go)"_pair_dpd.html,
+"dsmc"_pair_dsmc.html,
+"eam (gikot)"_pair_eam.html,
+"eam/alloy (gikot)"_pair_eam.html,
+"eam/cd (o)"_pair_eam.html,
+"eam/cd/old (o)"_pair_eam.html,
+"eam/fs (gikot)"_pair_eam.html,
+"edip (o)"_pair_edip.html,
+"edip/multi"_pair_edip.html,
+"edpd"_pair_meso.html,
+"eff/cut"_pair_eff.html,
+"eim (o)"_pair_eim.html,
+"exp6/rx (k)"_pair_exp6_rx.html,
+"extep"_pair_extep.html,
+"gauss (go)"_pair_gauss.html,
+"gauss/cut (o)"_pair_gauss.html,
+"gayberne (gio)"_pair_gayberne.html,
+"gran/hertz/history (o)"_pair_gran.html,
+"gran/hooke (o)"_pair_gran.html,
+"gran/hooke/history (ko)"_pair_gran.html,
+"gw"_pair_gw.html,
+"gw/zbl"_pair_gw.html,
+"hbond/dreiding/lj (o)"_pair_hbond_dreiding.html,
+"hbond/dreiding/morse (o)"_pair_hbond_dreiding.html,
+"ilp/graphene/hbn"_pair_ilp_graphene_hbn.html,
+"kim"_pair_kim.html,
+"kolmogorov/crespi/full"_pair_kolmogorov_crespi_full.html,
+"kolmogorov/crespi/z"_pair_kolmogorov_crespi_z.html,
+"lcbop"_pair_lcbop.html,
+"lebedeva/z"_pair_lebedeva_z.html,
+"lennard/mdf"_pair_mdf.html,
+"line/lj"_pair_line_lj.html,
+"list"_pair_list.html,
+"lj/charmm/coul/charmm (iko)"_pair_charmm.html,
+"lj/charmm/coul/charmm/implicit (ko)"_pair_charmm.html,
+"lj/charmm/coul/long (gikot)"_pair_charmm.html,
+"lj/charmm/coul/long/soft (o)"_pair_fep_soft.html,
+"lj/charmm/coul/msm (o)"_pair_charmm.html,
+"lj/charmmfsw/coul/charmmfsh"_pair_charmm.html,
+"lj/charmmfsw/coul/long"_pair_charmm.html,
+"lj/class2 (gko)"_pair_class2.html,
+"lj/class2/coul/cut (ko)"_pair_class2.html,
+"lj/class2/coul/cut/soft"_pair_fep_soft.html,
+"lj/class2/coul/long (gko)"_pair_class2.html,
+"lj/class2/coul/long/soft"_pair_fep_soft.html,
+"lj/class2/soft"_pair_fep_soft.html,
+"lj/cubic (go)"_pair_lj_cubic.html,
+"lj/cut (gikot)"_pair_lj.html,
+"lj/cut/coul/cut (gko)"_pair_lj.html,
+"lj/cut/coul/cut/soft (o)"_pair_fep_soft.html,
+"lj/cut/coul/debye (gko)"_pair_lj.html,
+"lj/cut/coul/dsf (gko)"_pair_lj.html,
+"lj/cut/coul/long (gikot)"_pair_lj.html,
+"lj/cut/coul/long/cs"_pair_cs.html,
+"lj/cut/coul/long/soft (o)"_pair_fep_soft.html,
+"lj/cut/coul/msm (go)"_pair_lj.html,
+"lj/cut/coul/wolf (o)"_pair_lj.html,
+"lj/cut/dipole/cut (go)"_pair_dipole.html,
+"lj/cut/dipole/long (g)"_pair_dipole.html,
+"lj/cut/dipole/sf (go)"_pair_dipole.html,
+"lj/cut/soft (o)"_pair_fep_soft.html,
+"lj/cut/thole/long (o)"_pair_thole.html,
+"lj/cut/tip4p/cut (o)"_pair_lj.html,
+"lj/cut/tip4p/long (ot)"_pair_lj.html,
+"lj/cut/tip4p/long/soft (o)"_pair_fep_soft.html,
+"lj/expand (gko)"_pair_lj_expand.html,
+"lj/expand/coul/long (g)"_pair_lj_expand.html,
+"lj/gromacs (gko)"_pair_gromacs.html,
+"lj/gromacs/coul/gromacs (ko)"_pair_gromacs.html,
+"lj/long/coul/long (iot)"_pair_lj_long.html,
+"lj/long/dipole/long"_pair_dipole.html,
+"lj/long/tip4p/long (o)"_pair_lj_long.html,
+"lj/mdf"_pair_mdf.html,
+"lj/sdk (gko)"_pair_sdk.html,
+"lj/sdk/coul/long (go)"_pair_sdk.html,
+"lj/sdk/coul/msm (o)"_pair_sdk.html,
+"lj/sf/dipole/sf (go)"_pair_dipole.html,
+"lj/smooth (o)"_pair_lj_smooth.html,
+"lj/smooth/linear (o)"_pair_lj_smooth_linear.html,
+"lj/switch3/coulgauss/long"_pair_lj_switch3_coulgauss.html,
+"lj96/cut (go)"_pair_lj96.html,
+"lubricate (o)"_pair_lubricate.html,
+"lubricate/poly (o)"_pair_lubricate.html,
+"lubricateU"_pair_lubricateU.html,
+"lubricateU/poly"_pair_lubricateU.html,
+"mdpd"_pair_meso.html,
+"mdpd/rhosum"_pair_meso.html,
+"meam/c"_pair_meamc.html,
+"meam/spline (o)"_pair_meam_spline.html,
+"meam/sw/spline"_pair_meam_sw_spline.html,
+"mgpt"_pair_mgpt.html,
+"mie/cut (g)"_pair_mie.html,
+"momb"_pair_momb.html,
+"morse (gkot)"_pair_morse.html,
+"morse/smooth/linear (o)"_pair_morse.html,
+"morse/soft"_pair_fep_soft.html,
+"multi/lucy"_pair_multi_lucy.html,
+"multi/lucy/rx (k)"_pair_multi_lucy_rx.html,
+"nb3b/harmonic"_pair_nb3b_harmonic.html,
+"nm/cut (o)"_pair_nm.html,
+"nm/cut/coul/cut (o)"_pair_nm.html,
+"nm/cut/coul/long (o)"_pair_nm.html,
+"oxdna/coaxstk"_pair_oxdna.html,
+"oxdna/excv"_pair_oxdna.html,
+"oxdna/hbond"_pair_oxdna.html,
+"oxdna/stk"_pair_oxdna.html,
+"oxdna/xstk"_pair_oxdna.html,
+"oxdna2/coaxstk"_pair_oxdna2.html,
+"oxdna2/dh"_pair_oxdna2.html,
+"oxdna2/excv"_pair_oxdna2.html,
+"oxdna2/hbond"_pair_oxdna2.html,
+"oxdna2/stk"_pair_oxdna2.html,
+"oxdna2/xstk"_pair_oxdna2.html,
+"peri/eps"_pair_peri.html,
+"peri/lps (o)"_pair_peri.html,
+"peri/pmb (o)"_pair_peri.html,
+"peri/ves"_pair_peri.html,
+"polymorphic"_pair_polymorphic.html,
+"python"_pair_python.html,
+"quip"_pair_quip.html,
+"reax/c (ko)"_pair_reaxc.html,
+"rebo (io)"_pair_airebo.html,
+"resquared (go)"_pair_resquared.html,
+"sdpd/taitwater/isothermal"_pair_sdpd_taitwater_isothermal.html,
+"smd/hertz"_pair_smd_hertz.html,
+"smd/tlsph"_pair_smd_tlsph.html,
+"smd/tri_surface"_pair_smd_triangulated_surface.html,
+"smd/ulsph"_pair_smd_ulsph.html,
+"smtbq"_pair_smtbq.html,
+"snap (k)"_pair_snap.html,
+"snap (k)"_pair_snap.html,
+"soft (go)"_pair_soft.html,
+"sph/heatconduction"_pair_sph_heatconduction.html,
+"sph/idealgas"_pair_sph_idealgas.html,
+"sph/lj"_pair_sph_lj.html,
+"sph/rhosum"_pair_sph_rhosum.html,
+"sph/taitwater"_pair_sph_taitwater.html,
+"sph/taitwater/morris"_pair_sph_taitwater_morris.html,
+"spin/dmi"_pair_spin_dmi.html,
+"spin/exchange"_pair_spin_exchange.html,
+"spin/magelec"_pair_spin_magelec.html,
+"spin/neel"_pair_spin_neel.html,
+"srp"_pair_srp.html,
+"sw (giko)"_pair_sw.html,
+"table (gko)"_pair_table.html,
+"table/rx (k)"_pair_table_rx.html,
+"tdpd"_pair_meso.html,
+"tersoff (giko)"_pair_tersoff.html,
+"tersoff/mod (gko)"_pair_tersoff_mod.html,
+"tersoff/mod/c (o)"_pair_tersoff_mod.html,
+"tersoff/table (o)"_pair_tersoff.html,
+"tersoff/zbl (gko)"_pair_tersoff_zbl.html,
+"thole"_pair_thole.html,
+"tip4p/cut (o)"_pair_coul.html,
+"tip4p/long (o)"_pair_coul.html,
+"tip4p/long/soft (o)"_pair_fep_soft.html,
+"tri/lj"_pair_tri_lj.html,
+"ufm (got)"_pair_ufm.html,
+"vashishta (gko)"_pair_vashishta.html,
+"vashishta/table (o)"_pair_vashishta.html,
+"yukawa (gko)"_pair_yukawa.html,
+"yukawa/colloid (go)"_pair_yukawa_colloid.html,
+"zbl (gko)"_pair_zbl.html :tb(c=4,ea=c)

doc/src/Commands_parse.txt

@@ -0,0 +1,136 @@
+"Higher level section"_Commands.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+Parsing rules for input scripts :h3
+
+Each non-blank line in the input script is treated as a command.
+LAMMPS commands are case sensitive.  Command names are lower-case, as
+are specified command arguments.  Upper case letters may be used in
+file names or user-chosen ID strings.
+
+Here are 6 rules for how each line in the input script is parsed by
+LAMMPS:
+
+(1) If the last printable character on the line is a "&" character,
+the command is assumed to continue on the next line.  The next line is
+concatenated to the previous line by removing the "&" character and
+line break.  This allows long commands to be continued across two or
+more lines.  See the discussion of triple quotes in (6) for how to
+continue a command across multiple line without using "&" characters.
+
+(2) All characters from the first "#" character onward are treated as
+comment and discarded.  See an exception in (6).  Note that a
+comment after a trailing "&" character will prevent the command from
+continuing on the next line.  Also note that for multi-line commands a
+single leading "#" will comment out the entire command.
+
+(3) The line is searched repeatedly for $ characters, which indicate
+variables that are replaced with a text string.  See an exception in
+(6).
+
+If the $ is followed by curly brackets, then the variable name is the
+text inside the curly brackets.  If no curly brackets follow the $,
+then the variable name is the single character immediately following
+the $.  Thus $\{myTemp\} and $x refer to variable names "myTemp" and
+"x".
+
+How the variable is converted to a text string depends on what style
+of variable it is; see the "variable"_variable.html doc page for details.
+It can be a variable that stores multiple text strings, and return one
+of them.  The returned text string can be multiple "words" (space
+separated) which will then be interpreted as multiple arguments in the
+input command.  The variable can also store a numeric formula which
+will be evaluated and its numeric result returned as a string.
+
+As a special case, if the $ is followed by parenthesis, then the text
+inside the parenthesis is treated as an "immediate" variable and
+evaluated as an "equal-style variable"_variable.html.  This is a way
+to use numeric formulas in an input script without having to assign
+them to variable names.  For example, these 3 input script lines:
+
+variable X equal (xlo+xhi)/2+sqrt(v_area)
+region 1 block $X 2 INF INF EDGE EDGE
+variable X delete :pre
+
+can be replaced by
+
+region 1 block $((xlo+xhi)/2+sqrt(v_area)) 2 INF INF EDGE EDGE :pre
+
+so that you do not have to define (or discard) a temporary variable X.
+
+Additionally, the "immediate" variable expression may be followed by a
+colon, followed by a C-style format string, e.g. ":%f" or ":%.10g".
+The format string must be appropriate for a double-precision
+floating-point value.  The format string is used to output the result
+of the variable expression evaluation.  If a format string is not
+specified a high-precision "%.20g" is used as the default.
+
+This can be useful for formatting print output to a desired precision:
+
+print "Final energy per atom: $(pe/atoms:%10.3f) eV/atom" :pre
+
+Note that neither the curly-bracket or immediate form of variables can
+contain nested $ characters for other variables to substitute for.
+Thus you cannot do this:
+
+variable        a equal 2
+variable        b2 equal 4
+print           "B2 = $\{b$a\}" :pre
+
+Nor can you specify this $($x-1.0) for an immediate variable, but
+you could use $(v_x-1.0), since the latter is valid syntax for an
+"equal-style variable"_variable.html.
+
+See the "variable"_variable.html command for more details of how
+strings are assigned to variables and evaluated, and how they can be
+used in input script commands.
+
+(4) The line is broken into "words" separated by white-space (tabs,
+spaces).  Note that words can thus contain letters, digits,
+underscores, or punctuation characters.
+
+(5) The first word is the command name.  All successive words in the
+line are arguments.
+
+(6) If you want text with spaces to be treated as a single argument,
+it can be enclosed in either single or double or triple quotes.  A
+long single argument enclosed in single or double quotes can span
+multiple lines if the "&" character is used, as described above.  When
+the lines are concatenated together (and the "&" characters and line
+breaks removed), the text will become a single line.  If you want
+multiple lines of an argument to retain their line breaks, the text
+can be enclosed in triple quotes, in which case "&" characters are not
+needed.  For example:
+
+print "Volume = $v"
+print 'Volume = $v'
+if "$\{steps\} > 1000" then quit
+variable a string "red green blue &
+                   purple orange cyan"
+print """
+System volume = $v
+System temperature = $t
+""" :pre
+
+In each case, the single, double, or triple quotes are removed when
+the single argument they enclose is stored internally.
+
+See the "dump modify format"_dump_modify.html, "print"_print.html,
+"if"_if.html, and "python"_python.html commands for examples.
+
+A "#" or "$" character that is between quotes will not be treated as a
+comment indicator in (2) or substituted for as a variable in (3).
+
+NOTE: If the argument is itself a command that requires a quoted
+argument (e.g. using a "print"_print.html command as part of an
+"if"_if.html or "run every"_run.html command), then single, double, or
+triple quotes can be nested in the usual manner.  See the doc pages
+for those commands for examples.  Only one of level of nesting is
+allowed, but that should be sufficient for most use cases.
+

doc/src/Commands_structure.txt

@@ -0,0 +1,95 @@
+"Higher level section"_Commands.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+Input script structure :h3
+
+This page describes the structure of a typical LAMMPS input script.
+The examples directory in the LAMMPS distribution contains many sample
+input scripts; it is discussed on the "Examples"_Examples.html doc
+page.
+
+A LAMMPS input script typically has 4 parts:
+
+Initialization
+Atom definition
+Settings
+Run a simulation :ol
+
+The last 2 parts can be repeated as many times as desired.  I.e. run a
+simulation, change some settings, run some more, etc.  Each of the 4
+parts is now described in more detail.  Remember that almost all
+commands need only be used if a non-default value is desired.
+
+(1) Initialization
+
+Set parameters that need to be defined before atoms are created or
+read-in from a file.
+
+The relevant commands are "units"_units.html,
+"dimension"_dimension.html, "newton"_newton.html,
+"processors"_processors.html, "boundary"_boundary.html,
+"atom_style"_atom_style.html, "atom_modify"_atom_modify.html.
+
+If force-field parameters appear in the files that will be read, these
+commands tell LAMMPS what kinds of force fields are being used:
+"pair_style"_pair_style.html, "bond_style"_bond_style.html,
+"angle_style"_angle_style.html, "dihedral_style"_dihedral_style.html,
+"improper_style"_improper_style.html.
+
+(2) Atom definition
+
+There are 3 ways to define atoms in LAMMPS.  Read them in from a data
+or restart file via the "read_data"_read_data.html or
+"read_restart"_read_restart.html commands.  These files can contain
+molecular topology information.  Or create atoms on a lattice (with no
+molecular topology), using these commands: "lattice"_lattice.html,
+"region"_region.html, "create_box"_create_box.html,
+"create_atoms"_create_atoms.html.  The entire set of atoms can be
+duplicated to make a larger simulation using the
+"replicate"_replicate.html command.
+
+(3) Settings
+
+Once atoms and molecular topology are defined, a variety of settings
+can be specified: force field coefficients, simulation parameters,
+output options, etc.
+
+Force field coefficients are set by these commands (they can also be
+set in the read-in files): "pair_coeff"_pair_coeff.html,
+"bond_coeff"_bond_coeff.html, "angle_coeff"_angle_coeff.html,
+"dihedral_coeff"_dihedral_coeff.html,
+"improper_coeff"_improper_coeff.html,
+"kspace_style"_kspace_style.html, "dielectric"_dielectric.html,
+"special_bonds"_special_bonds.html.
+
+Various simulation parameters are set by these commands:
+"neighbor"_neighbor.html, "neigh_modify"_neigh_modify.html,
+"group"_group.html, "timestep"_timestep.html,
+"reset_timestep"_reset_timestep.html, "run_style"_run_style.html,
+"min_style"_min_style.html, "min_modify"_min_modify.html.
+
+Fixes impose a variety of boundary conditions, time integration, and
+diagnostic options.  The "fix"_fix.html command comes in many flavors.
+
+Various computations can be specified for execution during a
+simulation using the "compute"_compute.html,
+"compute_modify"_compute_modify.html, and "variable"_variable.html
+commands.
+
+Output options are set by the "thermo"_thermo.html, "dump"_dump.html,
+and "restart"_restart.html commands.
+
+(4) Run a simulation
+
+A molecular dynamics simulation is run using the "run"_run.html
+command.  Energy minimization (molecular statics) is performed using
+the "minimize"_minimize.html command.  A parallel tempering
+(replica-exchange) simulation can be run using the
+"temper"_temper.html command.
+

doc/src/Developer/.gitignore

@@ -0,0 +1,3 @@
+/developer.aux
+/developer.log
+/developer.toc

doc/src/Developer/developer.tex

@@ -22,10 +22,10 @@ users.
 LAMMPS source files are in two directories of the distribution
 tarball.  The src directory has the majority of them, all of which are
 C++ files (*.cpp and *.h).  Many of these files are in the src
-directory itself.  There are also dozens of "packages", which can be
+directory itself.  There are also dozens of ``packages'', which can be
 included or excluded when LAMMPS is built.  See the
 doc/Section\_build.html section of the manual for more information
-about packages, or type "make" from within the src directory, which
+about packages, or type ``make'' from within the src directory, which
 lists package-related commands, such as ``make package-status''.  The
 source files for each package are in an all-uppercase sub-directory of
 src, like src/MOLECULE or src/USER-CUDA.  If the package is currently
@@ -38,17 +38,17 @@ The lib directory also contains source code for external libraries,
 used by a few of the packages.  Each sub-directory, like meam or gpu,
 contains the source files, some of which are in different languages
 such as Fortran.  The files are compiled into libraries from within
-each sub-directory, e.g. performing a "make" in the lib/meam directory
+each sub-directory, e.g. performing a ``make'' in the lib/meam directory
 creates a libmeam.a file.  These libraries are linked to during a
 LAMMPS build, if the corresponding package is installed.
 
 LAMMPS C++ source files almost always come in pairs, such as run.cpp
 and run.h.  The pair of files defines a C++ class, the Run class in
-this case, which contains the code invoked by the "run" command in a
+this case, which contains the code invoked by the ``run'' command in a
 LAMMPS input script.  As this example illustrates, source file and
 class names often have a one-to-one correspondence with a command used
 in a LAMMPS input script.  Some source files and classes do not have a
-corresponding input script command, e.g. force.cpp and the Force
+corresponding input script command, e.g. ``force.cpp'' and the Force
 class.  They are discussed in the next section.
 
 \pagebreak
@@ -57,12 +57,12 @@ class.  They are discussed in the next section.
 Though LAMMPS has a lot of source files and classes, its class
 hierarchy is quite simple, as outlined in Fig \ref{fig:classes}.  Each
 boxed name refers to a class and has a pair of associated source files
-in lammps/src, e.g. memory.cpp and memory.h.  More details on the
+in lammps/src, e.g. ``memory.cpp'' and ``memory.h''.  More details on the
 class and its methods and data structures can be found by examining
 its *.h file.
 
 LAMMPS (lammps.cpp/h) is the top-level class for the entire code.  It
-holds an "instance" of LAMMPS and can be instantiated one or more
+holds an ``instance'' of LAMMPS and can be instantiated one or more
 times by a calling code.  For example, the file src/main.cpp simply
 instantiates one instance of LAMMPS and passes it the input script.
 
@@ -81,7 +81,7 @@ enabled by a bit of cleverness in the Pointers class (see
 src/pointers.h) which every class inherits from.
 
 There are a handful of virtual parent classes in LAMMPS that define
-what LAMMPS calls "styles".  They are shaded red in Fig
+what LAMMPS calls ``styles''.  They are shaded red in Fig
 \ref{fig:classes}.  Each of these are parents of a number of child
 classes that implement the interface defined by the parent class.  For
 example, the fix style has around 100 child classes.  They are the
@@ -89,17 +89,17 @@ possible fixes that can be specified by the fix command in an input
 script, e.g. fix nve, fix shake, fix ave/time, etc.  The corresponding
 classes are Fix (for the parent class), FixNVE, FixShake, FixAveTime,
 etc.  The source files for these classes are easy to identify in the
-src directory, since they begin with the word "fix", e,g,
+src directory, since they begin with the word ``fix'', e,g,
 fix\_nve.cpp, fix\_shake,cpp, fix\_ave\_time.cpp, etc.
 
-The one exception is child class files for the "command" style.  These
+The one exception is child class files for the ``command'' style.  These
 implement specific commands in the input script that can be invoked
 before/after/between runs or which launch a simulation.  Examples are
 the create\_box, minimize, run, and velocity commands which encode the
 CreateBox, Minimize, Run, and Velocity classes.  The corresponding
 files are create\_box,cpp, minimize.cpp, run.cpp, and velocity.cpp.
-The list of command style files can be found by typing "grep
-COMMAND\_CLASS *.h" from within the src directory, since that word in
+The list of command style files can be found by typing ``grep
+COMMAND\_CLASS *.h'' from within the src directory, since that word in
 the header file identifies the class as an input script command.
 Similar words can be grepped to list files for the other LAMMPS
 styles.  E.g. ATOM\_CLASS, PAIR\_CLASS, BOND\_CLASS, REGION\_CLASS,
@@ -471,13 +471,13 @@ FixStyle(your/fix/name,FixMine)
   \end{verbatim}
  \end{center}
 
-Where "your/fix/name" is a name of your fix in the script and FixMine
+Where ``your/fix/name'' is a name of your fix in the script and FixMine
 is the name of the class. This code allows LAMMPS to find your fix
 when it parses input script. In addition, your fix header must be
-included in the file "style\_fix.h". In case if you use LAMMPS make,
+included in the file ``style\_fix.h''. In case if you use LAMMPS make,
 this file is generated automatically - all files starting with prefix
 fix\_ are included, so call your header the same way. Otherwise, don't
-forget to add your include into "style\_fix.h".
+forget to add your include into ``style\_fix.h''.
 
 Let's write a simple fix which will print average velocity at the end
 of each timestep. First of all, implement a constructor:
@@ -567,11 +567,11 @@ void FixPrintVel::end_of_step()
 \end{center}
 
 In the code above, we use MathExtra routines defined in
-"math\_extra.h".  There are bunch of math functions to work with
+``math\_extra.h''.  There are bunch of math functions to work with
 arrays of doubles as with math vectors.
 
 In this code we use an instance of Atom class. This object is stored
-in the Pointers class (see "pointers.h"). This object contains all
+in the Pointers class (see ``pointers.h''). This object contains all
 global information about the simulation system. Data from Pointers
 class available to all classes inherited from it using protected
 inheritance. Hence when you write you own class, which is going to use
@@ -689,7 +689,7 @@ int FixSavePos::unpack_exchange(int nlocal, double *buf)
 
 Now, a little bit about memory allocation. We used Memory class which
 is just a bunch of template functions for allocating 1D and 2D
-arrays. So you need to add include "memory.h" to have access to them.
+arrays. So you need to add include ``memory.h'' to have access to them.
 
 Finally, if you need to write/read some global information used in
 your fix to the restart file, you might do it by setting flag

doc/src/Eqs/angle_cross.tex

@@ -0,0 +1,9 @@
+\documentclass[12pt]{article}
+
+\begin{document}
+\thispagestyle{empty}
+$$
+  E = K_{SS} \left(r_{12}-r_{12,0}\right)\left(r_{32}-r_{32,0}\right) + K_{BS0}\left(r_{12}-r_{12,0}\right)\left(\theta-\theta_0\right) + K_{BS1}\left(r_{32}-r_{32,0}\right)\left(\theta-\theta_0\right)
+$$
+
+\end{document}

doc/src/Eqs/angle_mm3.tex

@@ -0,0 +1,9 @@
+\documentclass[12pt]{article}
+
+\begin{document}
+\thispagestyle{empty}
+$$
+  E = K (\theta - \theta_0)^2 \left[ 1 - 0.014(\theta - \theta_0) + 5.6(10)^{-5} (\theta - \theta_0)^2 - 7.0(10)^{-7} (\theta - \theta_0)^3 + 9(10)^{-10} (\theta - \theta_0)^4 \right]
+$$
+
+\end{document}

doc/src/Eqs/bond_mm3.tex

@@ -0,0 +1,9 @@
+\documentclass[12pt]{article}
+
+\begin{document}
+\thispagestyle{empty}
+$$
+  E = K (r - r_0)^2 \left[ 1 - 2.55(r-r_0) + (7/12) 2.55^2(r-r_0)^2 \right]
+$$
+
+\end{document}

doc/src/Eqs/improper_distharm.tex

@@ -0,0 +1,9 @@
+\documentclass[12pt]{article}
+
+\begin{document}
+\thispagestyle{empty}
+$$
+  E = K (d - d_0)^2
+$$
+
+\end{document}

doc/src/Eqs/improper_sqdistharm.tex

@@ -0,0 +1,9 @@
+\documentclass[12pt]{article}
+
+\begin{document}
+\thispagestyle{empty}
+$$
+  E = K (d^2 - d_0^2)^2
+$$
+
+\end{document}

doc/src/Eqs/pair_atm.tex

@@ -0,0 +1,9 @@
+\documentclass[12pt]{article}
+
+\begin{document}
+
+\begin{equation}
+E=\nu\frac{1+3\cos\gamma_1\cos\gamma_2\cos\gamma_3}{r_{12}^3r_{23}^3r_{31}^3}
+\end{equation}
+
+\end{document}

doc/src/Eqs/pair_coulgauss.tex

@@ -0,0 +1,9 @@
+\documentclass[12pt]{article}
+
+\begin{document}
+  \thispagestyle{empty}
+\begin{eqnarray*}
+  E &=& \frac{q_i q_j \mathrm{erf}\left( r/\sqrt{\gamma_1^2+\gamma_2^2} \right) }{\epsilon r_{ij}}
+\end{eqnarray*}
+
+\end{document}

doc/src/Eqs/pair_lj_switch3.tex

@@ -0,0 +1,11 @@
+\documentclass[12pt]{article}
+
+\begin{document}
+  \thispagestyle{empty}
+
+\begin{eqnarray*}
+  E = 4\epsilon \left[ \left(\frac{\sigma}{r}\right)^{12}-\left(\frac{\sigma}{r}\right)^{6} \right]
+% \qquad r < r_c \\
+\end{eqnarray*}
+
+\end{document}

doc/src/Eqs/pair_mm3_switch3.tex

@@ -0,0 +1,11 @@
+\documentclass[12pt]{article}
+
+\begin{document}
+  \thispagestyle{empty}
+\begin{eqnarray*}
+  E &=& \epsilon_{ij} \left[ -2.25 \left(\frac{r_{v,ij}}{r_{ij}}\right)^6 + 1.84(10)^5 \exp\left[-12.0 r_{ij}/r_{v,ij}\right] \right] S_3(r_{ij}) \\
+  r_{v,ij} &=& r_{v,i} + r_{v,j} \\ 
+  \epsilon_{ij} &=& \sqrt{\epsilon_i \epsilon_j}
+\end{eqnarray*}
+
+\end{document}

doc/src/Eqs/pair_switch3.tex

@@ -0,0 +1,14 @@
+\documentclass[12pt]{article}
+
+\begin{document}
+\thispagestyle{empty}
+
+\begin{eqnarray*}
+ S_3(r) = \left\lbrace \begin{array}{ll}
+                     1 & \quad\mathrm{if}\quad r < r_\mathrm{c} - w \\
+                     3x^2 - 2x^3 & \quad\mathrm{if}\quad r < r_\mathrm{c} \quad\mathrm{with\quad} x=\frac{r_\mathrm{c} - r}{w} \\
+                     0 & \quad\mathrm{if}\quad r >= r_\mathrm{c}
+                 \end{array} \right.
+\end{eqnarray*}
+
+\end{document}

doc/src/Eqs/ptm_rmsd.tex

@@ -0,0 +1,21 @@
+\documentclass[12pt,article]{article}
+
+\usepackage{indentfirst}
+\usepackage{amsmath}
+
+\newcommand{\set}[1]{\ensuremath{\mathbf{#1}}}
+\newcommand{\mean}[1]{\ensuremath{\overline{#1}}}
+\newcommand{\norm}[1]{\ensuremath{\left|\left|{#1}\right|\right|}}
+
+\begin{document}
+
+\begin{equation*}
+\text{RMSD}(\set{u}, \set{v}) = \min_{s, \set{Q}} \sqrt{\frac{1}{N} \sum\limits_{i=1}^{N}
+\norm{
+s[\vec{u_i} - \mean{\set{u}}]
+-
+\set{Q} \vec{v_i}
+}^2}
+\end{equation*}
+
+\end{document}

doc/src/Errors.txt

@@ -1,10 +1,10 @@
-"Previous Section"_Python.html - "LAMMPS WWW Site"_lws -
+"Previous Section"_Python_head.html - "LAMMPS WWW Site"_lws -
 "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
-Section"_Section_history.html :c
+Section"_Manual.html :c
 
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
 
 :line
 
@@ -19,6 +19,7 @@ additional details for many of them.
 <!-- RST
 
 .. toctree::
+   :maxdepth: 1
 
    Errors_common
    Errors_bugs
@@ -31,7 +32,7 @@ END_RST -->
 
 "Common problems"_Errors_common.html
 "Reporting bugs"_Errors_bugs.html
-"Error messages"_Errors_messages.html 
+"Error messages"_Errors_messages.html
 "Warning messages"_Errors_warnings.html :all(b)
 
 <!-- END_HTML_ONLY -->

doc/src/Errors_bugs.txt

@@ -3,7 +3,7 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
 
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
 
 :line
 

doc/src/Errors_common.txt

@@ -3,7 +3,7 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
 
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
 
 :line
 
@@ -58,9 +58,9 @@ style", with ... being fix, compute, pair, etc, it means that you
 mistyped the style name or that the command is part of an optional
 package which was not compiled into your executable.  The list of
 available styles in your executable can be listed by using "the -h
-command-line argument"_Section_start.html#start_6.  The installation
-and compilation of optional packages is explained in the "installation
-instructions"_Section_start.html#start_3.
+command-line swith"_Run_options.html.  The installation and
+compilation of optional packages is explained on the "Build
+packages"_Build_package.html doc page.
 
 For a given command, LAMMPS expects certain arguments in a specified
 order.  If you mess this up, LAMMPS will often flag the error, but it
@@ -74,7 +74,7 @@ is an integer or floating-point number, respectively, and reject the
 input with an error message (for instance, when an integer is required,
 but a floating-point number 1.0 is provided):
 
-ERROR: Expected integer parameter in input script or data file :pre
+ERROR: Expected integer parameter instead of '1.0' in input script or data file :pre
 
 Some commands allow for using variable references in place of numeric
 constants so that the value can be evaluated and may change over the
@@ -85,6 +85,9 @@ reading the input and before parsing commands,
 
 NOTE: Using a variable reference (i.e. {v_name}) is only allowed if
 the documentation of the corresponding command explicitly says it is.
+Otherwise, you will receive an error message of this kind:
+
+ERROR: Expected floating point parameter instead of 'v_name' in input script or data file :pre
 
 Generally, LAMMPS will print a message to the screen and logfile and
 exit gracefully when it encounters a fatal error.  Sometimes it will
@@ -93,7 +96,7 @@ decide if the WARNING is important or not.  A WARNING message that is
 generated in the middle of a run is only printed to the screen, not to
 the logfile, to avoid cluttering up thermodynamic output.  If LAMMPS
 crashes or hangs without spitting out an error message first then it
-could be a bug (see "this section"_#err_2) or one of the following
+could be a bug (see "this section"_Errors_bugs.html) or one of the following
 cases:
 
 LAMMPS runs in the available memory a processor allows to be

doc/src/Errors_messages.txt

@@ -3,7 +3,7 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
 
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
 
 :line
 
@@ -279,12 +279,6 @@ multibody joint).  The bodies you have defined exceed this limit. :dd
 This is an internal LAMMPS error.  Please report it to the
 developers. :dd
 
-{Atom sorting has bin size = 0.0} :dt
-
-The neighbor cutoff is being used as the bin size, but it is zero.
-Thus you must explicitly list a bin size in the atom_modify sort
-command or turn off sorting. :dd
-
 {Atom style hybrid cannot have hybrid as an argument} :dt
 
 Self-explanatory. :dd
@@ -421,9 +415,9 @@ This is an internal error.  It should normally not occur. :dd
 
 This is an internal error.  It should normally not occur. :dd
 
-{Bad real space Coulomb cutoff in fix tune/kspace} :dt
+{Bad real space Coulombic cutoff in fix tune/kspace} :dt
 
-Fix tune/kspace tried to find the optimal real space Coulomb cutoff using
+Fix tune/kspace tried to find the optimal real space Coulombic cutoff using
 the Newton-Rhaphson method, but found a non-positive or NaN cutoff :dd
 
 {Balance command before simulation box is defined} :dt
@@ -460,7 +454,7 @@ compute. :dd
 
 {Big particle in fix srd cannot be point particle} :dt
 
-Big particles must be extended spheriods or ellipsoids. :dd
+Big particles must be extended spheroids or ellipsoids. :dd
 
 {Bigint setting in lmptype.h is invalid} :dt
 
@@ -743,7 +737,7 @@ Self-explanatory. :dd
 
 Self-explanatory. :dd
 
-{Cannot (yet) use single precision with MSM (remove -DFFT_SINGLE from Makefile and recompile)} :dt
+{Cannot (yet) use single precision with MSM (remove -DFFT_SINGLE from Makefile and re-compile)} :dt
 
 Single precision cannot be used with MSM. :dd
 
@@ -780,7 +774,7 @@ Cannot use tilt factors unless the simulation box is non-orthogonal. :dd
 
 Self-explanatory. :dd
 
-{Cannot change box z boundary to nonperiodic for a 2d simulation} :dt
+{Cannot change box z boundary to non-periodic for a 2d simulation} :dt
 
 Self-explanatory. :dd
 
@@ -1092,11 +1086,6 @@ correct. :dd
 The specified file cannot be opened.  Check that the path and name are
 correct. :dd
 
-{Cannot open fix ave/spatial file %s} :dt
-
-The specified file cannot be opened.  Check that the path and name are
-correct. :dd
-
 {Cannot open fix ave/time file %s} :dt
 
 The specified file cannot be opened.  Check that the path and name are
@@ -1293,7 +1282,7 @@ are defined. :dd
 You cannot reset the timestep when a fix that keeps track of elapsed
 time is in place. :dd
 
-{Cannot run 2d simulation with nonperiodic Z dimension} :dt
+{Cannot run 2d simulation with non-periodic Z dimension} :dt
 
 Use the boundary command to make the z dimension periodic in order to
 run a 2d simulation. :dd
@@ -1677,10 +1666,6 @@ provided by an atom map.  An atom map does not exist (by default) for
 non-molecular problems.  Using the atom_modify map command will force
 an atom map to be created. :dd
 
-{Cannot use fix ave/spatial z for 2 dimensional model} :dt
-
-Self-explanatory. :dd
-
 {Cannot use fix bond/break with non-molecular systems} :dt
 
 Only systems with bonds that can be changed can be used.  Atom_style
@@ -2125,29 +2110,29 @@ Self-explanatory. :dd
 Fix setforce cannot be used in this manner.  Use fix addforce
 instead. :dd
 
-{Cannot use nonperiodic boundares with fix ttm} :dt
+{Cannot use non-periodic boundares with fix ttm} :dt
 
 This fix requires a fully periodic simulation box. :dd
 
-{Cannot use nonperiodic boundaries with Ewald} :dt
+{Cannot use non-periodic boundaries with Ewald} :dt
 
 For kspace style ewald, all 3 dimensions must have periodic boundaries
 unless you use the kspace_modify command to define a 2d slab with a
 non-periodic z dimension. :dd
 
-{Cannot use nonperiodic boundaries with EwaldDisp} :dt
+{Cannot use non-periodic boundaries with EwaldDisp} :dt
 
 For kspace style ewald/disp, all 3 dimensions must have periodic
 boundaries unless you use the kspace_modify command to define a 2d
 slab with a non-periodic z dimension. :dd
 
-{Cannot use nonperiodic boundaries with PPPM} :dt
+{Cannot use non-periodic boundaries with PPPM} :dt
 
 For kspace style pppm, all 3 dimensions must have periodic boundaries
 unless you use the kspace_modify command to define a 2d slab with a
 non-periodic z dimension. :dd
 
-{Cannot use nonperiodic boundaries with PPPMDisp} :dt
+{Cannot use non-periodic boundaries with PPPMDisp} :dt
 
 For kspace style pppm/disp, all 3 dimensions must have periodic
 boundaries unless you use the kspace_modify command to define a 2d
@@ -2425,10 +2410,6 @@ Self-explanatory. :dd
 
 Self-explanatory. :dd
 
-{Compute ID for fix ave/spatial does not exist} :dt
-
-Self-explanatory. :dd
-
 {Compute ID for fix ave/time does not exist} :dt
 
 Self-explanatory. :dd
@@ -3364,21 +3345,21 @@ probably due to errors in the Python code. :dd
 The default minimum order is 2.  This can be reset by the
 kspace_modify minorder command. :dd
 
-{Coulomb cut not supported in pair_style buck/long/coul/coul} :dt
+{Coulombic cutoff not supported in pair_style buck/long/coul/coul} :dt
 
 Must use long-range Coulombic interactions. :dd
 
-{Coulomb cut not supported in pair_style lj/long/coul/long} :dt
+{Coulombic cutoff not supported in pair_style lj/long/coul/long} :dt
 
 Must use long-range Coulombic interactions. :dd
 
-{Coulomb cut not supported in pair_style lj/long/tip4p/long} :dt
+{Coulombic cutoff not supported in pair_style lj/long/tip4p/long} :dt
 
 Must use long-range Coulombic interactions. :dd
 
-{Coulomb cutoffs of pair hybrid sub-styles do not match} :dt
+{Coulombic cutoffs of pair hybrid sub-styles do not match} :dt
 
-If using a Kspace solver, all Coulomb cutoffs of long pair styles must
+If using a Kspace solver, all Coulombic cutoffs of long pair styles must
 be the same. :dd
 
 {Coulombic cut not supported in pair_style lj/long/dipole/long} :dt
@@ -4074,10 +4055,6 @@ Self-explanatory. :dd
 
 Self-explanatory. :dd
 
-{Fix ID for fix ave/spatial does not exist} :dt
-
-Self-explanatory. :dd
-
 {Fix ID for fix ave/time does not exist} :dt
 
 Self-explanatory. :dd
@@ -4379,51 +4356,6 @@ same style. :dd
 
 Self-explanatory. :dd
 
-{Fix ave/spatial compute does not calculate a per-atom array} :dt
-
-Self-explanatory. :dd
-
-{Fix ave/spatial compute does not calculate a per-atom vector} :dt
-
-A compute used by fix ave/spatial must generate per-atom values. :dd
-
-{Fix ave/spatial compute does not calculate per-atom values} :dt
-
-A compute used by fix ave/spatial must generate per-atom values. :dd
-
-{Fix ave/spatial compute vector is accessed out-of-range} :dt
-
-The index for the vector is out of bounds. :dd
-
-{Fix ave/spatial fix does not calculate a per-atom array} :dt
-
-Self-explanatory. :dd
-
-{Fix ave/spatial fix does not calculate a per-atom vector} :dt
-
-A fix used by fix ave/spatial must generate per-atom values. :dd
-
-{Fix ave/spatial fix does not calculate per-atom values} :dt
-
-A fix used by fix ave/spatial must generate per-atom values. :dd
-
-{Fix ave/spatial fix vector is accessed out-of-range} :dt
-
-The index for the vector is out of bounds. :dd
-
-{Fix ave/spatial for triclinic boxes requires units reduced} :dt
-
-Self-explanatory. :dd
-
-{Fix ave/spatial settings invalid with changing box size} :dt
-
-If the box size changes, only the units reduced option can be
-used. :dd
-
-{Fix ave/spatial variable is not atom-style variable} :dt
-
-A variable used by fix ave/spatial must generate per-atom values. :dd
-
 {Fix ave/time cannot set output array intensive/extensive from these inputs} :dt
 
 One of more of the vector inputs has individual elements which are
@@ -5078,7 +5010,7 @@ Self-explanatory. :dd
 
 Occurs when number of neighbor atoms for an atom increased too much
 during a run.  Increase SAFE_ZONE and MIN_CAP in fix_qeq.h and
-recompile. :dd
+re-compile. :dd
 
 {Fix qeq/point requires atom attribute q} :dt
 
@@ -5092,7 +5024,7 @@ Self-explanatory. :dd
 
 Occurs when number of neighbor atoms for an atom increased too much
 during a run.  Increase SAFE_ZONE and MIN_CAP in fix_qeq.h and
-recompile. :dd
+re-compile. :dd
 
 {Fix qeq/shielded requires atom attribute q} :dt
 
@@ -5110,7 +5042,7 @@ Self-explanatory. :dd
 
 Occurs when number of neighbor atoms for an atom increased too much
 during a run.  Increase SAFE_ZONE and MIN_CAP in fix_qeq.h and
-recompile. :dd
+re-compile. :dd
 
 {Fix qeq/slater requires atom attribute q} :dt
 
@@ -5541,7 +5473,7 @@ See the package gpu command. :dd
 
 {GPUs are requested but Kokkos has not been compiled for CUDA} :dt
 
-Recompile Kokkos with CUDA support to use GPUs. :dd
+Re-compile Kokkos with CUDA support to use GPUs. :dd
 
 {Ghost velocity forward comm not yet implemented with Kokkos} :dt
 
@@ -6000,9 +5932,9 @@ map command will force an atom map to be created. :dd
 
 Self-explanatory. :dd
 
-{Input line quote not followed by whitespace} :dt
+{Input line quote not followed by white-space} :dt
 
-An end quote must be followed by whitespace. :dd
+An end quote must be followed by white-space. :dd
 
 {Insertion region extends outside simulation box} :dt
 
@@ -6985,7 +6917,7 @@ types. :dd
 
 {Invalid use of library file() function} :dt
 
-This function is called thru the library interface.  This
+This function is called through the library interface.  This
 error should not occur.  Contact the developers if it does. :dd
 
 {Invalid value in set command} :dt
@@ -7076,7 +7008,7 @@ The kspace accuracy designated in the input must be greater than zero. :dd
 
 {KSpace accuracy too large to estimate G vector} :dt
 
-Reduce the accuracy request or specify gwald explicitly
+Reduce the accuracy request or specify gewald explicitly
 via the kspace_modify command. :dd
 
 {KSpace accuracy too low} :dt
@@ -7911,8 +7843,8 @@ Atom IDs must be positive integers. :dd
 {One or more atom IDs is too big} :dt
 
 The limit on atom IDs is set by the SMALLBIG, BIGBIG, SMALLSMALL
-setting in your Makefile.  See Section_start 2.2 of the manual for
-more details. :dd
+setting in your LAMMPS build.  See the "Build
+settings"_Build_settings.html doc page for more info. :dd
 
 {One or more atom IDs is zero} :dt
 
@@ -8076,7 +8008,7 @@ Self-explanatory. :dd
 
 {Package command after simulation box is defined} :dt
 
-The package command cannot be used afer a read_data, read_restart, or
+The package command cannot be used after a read_data, read_restart, or
 create_box command. :dd
 
 {Package gpu command without GPU package installed} :dt
@@ -9260,7 +9192,7 @@ creates one large file for all processors. :dd
 {Restart file byte ordering is not recognized} :dt
 
 The file does not appear to be a LAMMPS restart file since it doesn't
-contain a recognized byte-orderomg flag at the beginning. :dd
+contain a recognized byte-ordering flag at the beginning. :dd
 
 {Restart file byte ordering is swapped} :dt
 
@@ -9472,7 +9404,7 @@ You may also want to boost the page size. :dd
 
 {Small to big integers are not sized correctly} :dt
 
-This error occurs whenthe sizes of smallint, imageint, tagint, bigint,
+This error occurs when the sizes of smallint, imageint, tagint, bigint,
 as defined in src/lmptype.h are not what is expected.  Contact
 the developers if this occurs. :dd
 

doc/src/Errors_warnings.txt

@@ -3,7 +3,7 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
 
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
 
 :line
 
@@ -13,7 +13,7 @@ This is an alphabetic list of the WARNING messages LAMMPS prints out
 and the reason why.  If the explanation here is not sufficient, the
 documentation for the offending command may help.  Warning messages
 also list the source file and line number where the warning was
-generated.  For example, a message lile this:
+generated.  For example, a message like this:
 
 WARNING: Bond atom missing in box size check (domain.cpp:187) :pre
 
@@ -291,24 +291,6 @@ This may cause accuracy problems. :dd
 
 This may cause accuracy problems. :dd
 
-{Fix thermal/conductivity comes before fix ave/spatial} :dt
-
-The order of these 2 fixes in your input script is such that fix
-thermal/conductivity comes first.  If you are using fix ave/spatial to
-measure the temperature profile induced by fix viscosity, then this
-may cause a glitch in the profile since you are averaging immediately
-after swaps have occurred.  Flipping the order of the 2 fixes
-typically helps. :dd
-
-{Fix viscosity comes before fix ave/spatial} :dt
-
-The order of these 2 fixes in your input script is such that
-fix viscosity comes first.  If you are using fix ave/spatial
-to measure the velocity profile induced by fix viscosity, then
-this may cause a glitch in the profile since you are averaging
-immediately after swaps have occurred.  Flipping the order
-of the 2 fixes typically helps. :dd
-
 {Fixes cannot send data in Kokkos communication, switching to classic communication} :dt
 
 This is current restriction with Kokkos. :dd
@@ -775,7 +757,7 @@ Self-explanatory. :dd
 
 This may indicate the shell command did not operate as expected. :dd
 
-{Should not allow rigid bodies to bounce off relecting walls} :dt
+{Should not allow rigid bodies to bounce off reflecting walls} :dt
 
 LAMMPS allows this, but their dynamics are not computed correctly. :dd
 
@@ -868,10 +850,10 @@ Most FENE models need this setting for the special_bonds command. :dd
 
 Most FENE models need this setting for the special_bonds command. :dd
 
-{Using a manybody potential with bonds/angles/dihedrals and special_bond exclusions} :dt
+{Using a many-body potential with bonds/angles/dihedrals and special_bond exclusions} :dt
 
 This is likely not what you want to do.  The exclusion settings will
-eliminate neighbors in the neighbor list, which the manybody potential
+eliminate neighbors in the neighbor list, which the many-body potential
 needs to calculated its terms correctly. :dd
 
 {Using compute temp/deform with inconsistent fix deform remap option} :dt

doc/src/Examples.txt

@@ -1,10 +1,10 @@
-"Previous Section"_Section_howto.html - "LAMMPS WWW Site"_lws -
-"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
-Section"_Section_perf.html :c
+"Previous Section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc - "Next
+Section"_Tools.html :c
 
 :link(lws,http://lammps.sandia.gov)
 :link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
+:link(lc,Commands_all.html)
 
 :line
 
@@ -78,7 +78,7 @@ micelle:  self-assembly of small lipid-like molecules into 2d bilayers
 min:      energy minimization of 2d LJ melt
 mscg:     parameterize a multi-scale coarse-graining (MSCG) model
 msst:     MSST shock dynamics
-nb3b:     use of nonbonded 3-body harmonic pair style
+nb3b:     use of non-bonded 3-body harmonic pair style
 neb:      nudged elastic band (NEB) calculation for barrier finding
 nemd:     non-equilibrium MD of 2d sheared system
 obstacle: flow around two voids in a 2d channel
@@ -112,10 +112,10 @@ web site.
 
 If you uncomment the "dump image"_dump_image.html line(s) in the input
 script a series of JPG images will be produced by the run (assuming
-you built LAMMPS with JPG support; see "Section
-2.2"_Section_start.html#start_2 for details).  These can be viewed
-individually or turned into a movie or animated by tools like
-ImageMagick or QuickTime or various Windows-based tools.  See the
+you built LAMMPS with JPG support; see the
+"Build_settings"_Build_settings.html doc page for details).  These can
+be viewed individually or turned into a movie or animated by tools
+like ImageMagick or QuickTime or various Windows-based tools.  See the
 "dump image"_dump_image.html doc page for more details.  E.g. this
 Imagemagick command would create a GIF file suitable for viewing in a
 browser.

doc/src/Howto.txt

@@ -0,0 +1,191 @@
+"Previous Section"_Performance.html - "LAMMPS WWW Site"_lws -
+"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
+Section"_Examples.html :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands.html#comm)
+
+:line
+
+Howto discussions :h2
+
+These doc pages describe how to perform various tasks with LAMMPS,
+both for users and developers.  The
+"glossary"_http://lammps.sandia.gov website page also lists MD
+terminology with links to corresponding LAMMPS manual pages.  The
+example input scripts included in the examples dir of the LAMMPS
+distribution and highlighted on the "Examples"_Examples.html doc page
+also show how to setup and run various kinds of simulations.
+
+Tutorials howto :h3
+
+<!-- RST
+
+.. toctree::
+   :name: tutorials
+   :maxdepth: 1
+
+   Howto_github
+   Howto_pylammps
+   Howto_bash
+
+END_RST -->
+
+<!-- HTML_ONLY -->
+
+"Using GitHub with LAMMPS"_Howto_github.html
+"PyLAMMPS interface to LAMMPS"_Howto_pylammps.html
+"Using LAMMPS with bash on Windows"_Howto_bash.html :all(b)
+
+<!-- END_HTML_ONLY -->
+
+General howto :h3
+
+<!-- RST
+
+.. toctree::
+   :name: general_howto
+   :maxdepth: 1
+
+   Howto_restart
+   Howto_viz
+   Howto_multiple
+   Howto_replica
+   Howto_library
+   Howto_couple
+   Howto_client_server
+
+END_RST -->
+
+<!-- HTML_ONLY -->
+
+"Restart a simulation"_Howto_restart.html
+"Visualize LAMMPS snapshots"_Howto_viz.html
+"Run multiple simulations from one input script"_Howto_multiple.html
+"Multi-replica simulations"_Howto_replica.html
+"Library interface to LAMMPS"_Howto_library.html
+"Couple LAMMPS to other codes"_Howto_couple.html
+"Using LAMMPS in client/server mode"_Howto_client_server.html :all(b)
+
+<!-- END_HTML_ONLY -->
+
+Settings howto :h3
+
+<!-- RST
+
+.. toctree::
+   :name: settings
+   :maxdepth: 1
+
+   Howto_2d
+   Howto_triclinic
+   Howto_thermostat
+   Howto_barostat
+   Howto_walls
+   Howto_nemd
+   Howto_dispersion
+
+END_RST -->
+
+<!-- HTML_ONLY -->
+
+"2d simulations"_Howto_2d.html
+"Triclinic (non-orthogonal) simulation boxes"_Howto_triclinic.html
+"Thermostats"_Howto_thermostat.html
+"Barostats"_Howto_barostat.html
+"Walls"_Howto_walls.html
+"NEMD simulations"_Howto_nemd.html
+"Long-range dispersion settings"_Howto_dispersion.html :all(b)
+
+<!-- END_HTML_ONLY -->
+
+
+Analysis howto :h3
+
+<!-- RST
+
+.. toctree::
+   :name: analysis
+   :maxdepth: 1
+
+   Howto_output
+   Howto_chunk
+   Howto_temperature
+   Howto_elastic
+   Howto_kappa
+   Howto_viscosity
+   Howto_diffusion
+
+END_RST -->
+
+<!-- HTML_ONLY -->
+
+"Output from LAMMPS (thermo, dumps, computes, fixes, variables)"_Howto_output.html
+"Use chunks to calculate system properties"_Howto_chunk.html :all(b)
+"Calculate temperature"_Howto_temperature.html
+"Calculate elastic constants"_Howto_elastic.html
+"Calculate thermal conductivity"_Howto_kappa.html
+"Calculate viscosity"_Howto_viscosity.html
+"Calculate a diffusion coefficient"_Howto_diffusion.html :all(b)
+
+<!-- END_HTML_ONLY -->
+
+Force fields howto :h3
+
+<!-- RST
+
+.. toctree::
+   :name: force
+   :maxdepth: 1
+
+   Howto_bioFF
+   Howto_tip3p
+   Howto_tip4p
+   Howto_spc
+
+END_RST -->
+
+<!-- HTML_ONLY -->
+
+"CHARMM, AMBER, and DREIDING force fields"_Howto_bioFF.html
+"TIP3P water model"_Howto_tip3p.html
+"TIP4P water model"_Howto_tip4p.html
+"SPC water model"_Howto_spc.html :all(b)
+
+<!-- END_HTML_ONLY -->
+
+Packages howto :h3
+
+<!-- RST
+
+.. toctree::
+   :name: packages
+   :maxdepth: 1
+
+   Howto_spherical
+   Howto_granular
+   Howto_body
+   Howto_polarizable
+   Howto_coreshell
+   Howto_drude
+   Howto_drude2
+   Howto_manifold
+   Howto_spins
+
+END_RST -->
+
+
+<!-- HTML_ONLY -->
+
+"Finite-size spherical and aspherical particles"_Howto_spherical.html
+"Granular models"_Howto_granular.html
+"Body style particles"_Howto_body.html
+"Polarizable models"_Howto_polarizable.html
+"Adiabatic core/shell model"_Howto_coreshell.html
+"Drude induced dipoles"_Howto_drude.html
+"Drude induced dipoles (extended)"_Howto_drude2.html
+"Manifolds (surfaces)"_Howto_manifold.html
+"Magnetic spins"_Howto_spins.html :all(b)
+
+<!-- END_HTML_ONLY -->

doc/src/Howto_2d.txt

@@ -0,0 +1,48 @@
+"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+2d simulations :h3
+
+Use the "dimension"_dimension.html command to specify a 2d simulation.
+
+Make the simulation box periodic in z via the "boundary"_boundary.html
+command.  This is the default.
+
+If using the "create box"_create_box.html command to define a
+simulation box, set the z dimensions narrow, but finite, so that the
+create_atoms command will tile the 3d simulation box with a single z
+plane of atoms - e.g.
+
+"create box"_create_box.html 1 -10 10 -10 10 -0.25 0.25 :pre
+
+If using the "read data"_read_data.html command to read in a file of
+atom coordinates, set the "zlo zhi" values to be finite but narrow,
+similar to the create_box command settings just described.  For each
+atom in the file, assign a z coordinate so it falls inside the
+z-boundaries of the box - e.g. 0.0.
+
+Use the "fix enforce2d"_fix_enforce2d.html command as the last
+defined fix to insure that the z-components of velocities and forces
+are zeroed out every timestep.  The reason to make it the last fix is
+so that any forces induced by other fixes will be zeroed out.
+
+Many of the example input scripts included in the LAMMPS distribution
+are for 2d models.
+
+NOTE: Some models in LAMMPS treat particles as finite-size spheres, as
+opposed to point particles.  See the "atom_style
+sphere"_atom_style.html and "fix nve/sphere"_fix_nve_sphere.html
+commands for details.  By default, for 2d simulations, such particles
+will still be modeled as 3d spheres, not 2d discs (circles), meaning
+their moment of inertia will be that of a sphere.  If you wish to
+model them as 2d discs, see the "set density/disc"_set.html command
+and the {disc} option for the "fix nve/sphere"_fix_nve_sphere.html,
+"fix nvt/sphere"_fix_nvt_sphere.html, "fix
+nph/sphere"_fix_nph_sphere.html, "fix npt/sphere"_fix_npt_sphere.html
+commands.

doc/src/Howto_barostat.txt

@@ -0,0 +1,75 @@
+"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+Barostats :h3
+
+Barostatting means controlling the pressure in an MD simulation.
+"Thermostatting"_Howto_thermostat.html means controlling the
+temperature of the particles.  Since the pressure includes a kinetic
+component due to particle velocities, both these operations require
+calculation of the temperature.  Typically a target temperature (T)
+and/or pressure (P) is specified by the user, and the thermostat or
+barostat attempts to equilibrate the system to the requested T and/or
+P.
+
+Barostatting in LAMMPS is performed by "fixes"_fix.html.  Two
+barostatting methods are currently available: Nose-Hoover (npt and
+nph) and Berendsen:
+
+"fix npt"_fix_nh.html
+"fix npt/sphere"_fix_npt_sphere.html
+"fix npt/asphere"_fix_npt_asphere.html
+"fix nph"_fix_nh.html
+"fix press/berendsen"_fix_press_berendsen.html :ul
+
+The "fix npt"_fix_nh.html commands include a Nose-Hoover thermostat
+and barostat.  "Fix nph"_fix_nh.html is just a Nose/Hoover barostat;
+it does no thermostatting.  Both "fix nph"_fix_nh.html and "fix
+press/berendsen"_fix_press_berendsen.html can be used in conjunction
+with any of the thermostatting fixes.
+
+As with the "thermostats"_Howto_thermostat.html, "fix npt"_fix_nh.html
+and "fix nph"_fix_nh.html only use translational motion of the
+particles in computing T and P and performing thermo/barostatting.
+"Fix npt/sphere"_fix_npt_sphere.html and "fix
+npt/asphere"_fix_npt_asphere.html thermo/barostat using not only
+translation velocities but also rotational velocities for spherical
+and aspherical particles.
+
+All of the barostatting fixes use the "compute
+pressure"_compute_pressure.html compute to calculate a current
+pressure.  By default, this compute is created with a simple "compute
+temp"_compute_temp.html (see the last argument of the "compute
+pressure"_compute_pressure.html command), which is used to calculated
+the kinetic component of the pressure.  The barostatting fixes can
+also use temperature computes that remove bias for the purpose of
+computing the kinetic component which contributes to the current
+pressure.  See the doc pages for the individual fixes and for the
+"fix_modify"_fix_modify.html command for instructions on how to assign
+a temperature or pressure compute to a barostatting fix.
+
+NOTE: As with the thermostats, the Nose/Hoover methods ("fix
+npt"_fix_nh.html and "fix nph"_fix_nh.html) perform time integration.
+"Fix press/berendsen"_fix_press_berendsen.html does NOT, so it should
+be used with one of the constant NVE fixes or with one of the NVT
+fixes.
+
+Thermodynamic output, which can be setup via the
+"thermo_style"_thermo_style.html command, often includes pressure
+values.  As explained on the doc page for the
+"thermo_style"_thermo_style.html command, the default pressure is
+setup by the thermo command itself.  It is NOT the pressure associated
+with any barostatting fix you have defined or with any compute you
+have defined that calculates a pressure.  The doc pages for the
+barostatting fixes explain the ID of the pressure compute they create.
+Thus if you want to view these pressures, you need to specify them
+explicitly via the "thermo_style custom"_thermo_style.html command.
+Or you can use the "thermo_modify"_thermo_modify.html command to
+re-define what pressure compute is used for default thermodynamic
+output.

doc/src/Howto_bash.txt

@@ -0,0 +1,204 @@
+"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+Using LAMMPS with Bash on Windows :h3
+[written by Richard Berger]
+
+:line
+
+Starting with Windows 10 you can install Linux tools directly in Windows. This
+allows you to compile LAMMPS following the same procedure as on a real Ubuntu
+Linux installation. Software can be easily installed using the package manager
+via apt-get and all files are accessible in both the Windows Explorer and your
+Linux shell (bash). This avoids switching to a different operating system or
+installing a virtual machine. Everything runs on Windows.
+
+Installing Bash on Windows :h4
+
+Prerequisites :h5
+
+Windows 10 (64bit only)
+Latest updates installed :ul
+
+Enable developer mode :h5
+You enable this feature by first opening Windows Settings and enabling
+Developer mode. Go to the Windows settings and search for "developer". This
+will allow you to install software which comes from outside of the Windows
+Store.  You might be prompted to reboot your compute. Please do so.
+
+:image(JPG/bow_tutorial_01_small.png,JPG/bow_tutorial_01.png)
+:image(JPG/bow_tutorial_02_small.png,JPG/bow_tutorial_02.png)
+:image(JPG/bow_tutorial_03_small.png,JPG/bow_tutorial_03.png)
+
+Install Windows Subsystem for Linux :h5
+
+Next you must ensure that the Window Subsystem for Linux is installed. Again,
+search for "enable windows features" in the Settings dialog. This opens a
+dialog with a list of features you can install. Add a checkmark to Windows
+Subsystem for Linux (Beta) and press OK.
+
+:image(JPG/bow_tutorial_04_small.png,JPG/bow_tutorial_04.png)
+:image(JPG/bow_tutorial_05.png,JPG/bow_tutorial_05.png)
+
+Install Bash for Windows :h5
+
+After installation completes, type "bash" in the Windows Start menu search.
+Select the first found option. This will launch a command-line window which
+will prompt you about installing Ubuntu on Windows. Confirm with "y" and press
+enter. This will then download Ubuntu for Windows.
+
+:image(JPG/bow_tutorial_06.png)
+:image(JPG/bow_tutorial_07.png)
+
+During installation, you will be asked for a new password. This will be used
+for installing new software and running commands with sudo.
+
+:image(JPG/bow_tutorial_08.png)
+
+Type exit to close the command-line window.
+
+Go to the Start menu and type "bash" again. This time you will see a "Bash on
+Ubuntu on Windows" Icon. Start this program.
+
+:image(JPG/bow_tutorial_09.png)
+
+Congratulations, you have installed [Bash on Ubuntu on Windows].
+
+:image(JPG/bow_tutorial_10.png)
+
+:line
+
+Compiling LAMMPS in Bash on Windows :h4
+
+The installation of LAMMPS in this environment is identical to working inside
+of a real Ubuntu Linux installation. At the time writing, it uses Ubuntu 16.04.
+
+Installing prerequisite packages :h5
+
+First upgrade all existing packages using
+
+sudo apt update
+sudo apt upgrade -y :pre
+
+Next install the following packages, which include compilers and libraries
+needed for various LAMMPS features:
+
+sudo apt install -y build-essential ccache gfortran openmpi-bin libopenmpi-dev libfftw3-dev libjpeg-dev libpng12-dev python-dev python-virtualenv libblas-dev liblapack-dev libhdf5-serial-dev hdf5-tools :pre
+
+Files in Ubuntu on Windows :h5
+
+When you launch "Bash on Ubuntu on Windows" you will start out in your Linux
+user home directory /home/[username]. You can access your Windows user directory
+using the /mnt/c/Users/[username] folder.
+
+
+Download LAMMPS :h5
+
+Obtain a copy of the LAMMPS code and go into it using "cd"
+
+Option 1: Downloading LAMMPS tarball using wget :h6
+
+wget http://lammps.sandia.gov/tars/lammps-stable.tar.gz
+tar xvzf lammps-stable.tar.gz
+cd lammps-31Mar17 :pre
+
+Option 2: Obtaining LAMMPS code from GitHub :h6
+
+git clone https://github.com/lammps/lammps.git
+cd lammps :pre
+
+Compiling LAMMPS :h5
+
+At this point you can compile LAMMPS like on Ubuntu Linux.
+
+Compiling serial version :h6
+
+cd src/
+make -j 4 serial :pre
+
+This will create an executable called lmp_serial in the src/ directory
+
+Compiling MPI version :h6
+
+cd src/
+make -j 4 mpi :pre
+
+This will create an executable called lmp_mpi in the src/ directory
+
+:line
+
+Finally, please note the absolute path of your src folder. You can get this using
+
+pwd :pre
+
+or
+
+echo $PWD :pre
+
+To run any examples you need the location of the executable. For now, let us
+save this location in a temporary variable
+
+LAMMPS_DIR=$PWD :pre
+
+:line
+
+Running an example script :h5
+
+Once compiled you can execute some of the LAMMPS examples. Switch into the
+examples/melt folder
+
+cd ../examples/melt :pre
+
+The full path of the serial executable is $LAMMPS_DIR/lmp_serial, while the mpi
+version is $LAMMPS_DIR/lmp_mpi. You can run the melt example with either
+version as follows:
+
+$LAMMPS_DIR/lmp_serial -in in.melt :pre
+
+or
+
+mpirun -np 4 $LAMMPS_DIR/lmp_mpi -in in.melt :pre
+
+Note the use of our variable $LAMMPS_DIR, which expands into the full path of
+the LAMMPS src folder we saved earlier.
+
+Adding your executable directory to your PATH :h6
+
+You can avoid having to type the full path of your LAMMPS binary by adding its
+parent folder to the PATH environment variable as follows:
+
+export PATH=$LAMMPS_DIR:$PATH :pre
+
+Input scripts can then be run like this:
+
+lmp_serial -in in.melt :pre
+
+or
+
+mpirun -np 4 lmp_mpi -in in.melt :pre
+
+However, this PATH variable will not persist if you close your bash window.
+To persist this setting edit the $HOME/.bashrc file using your favorite editor
+and add this line
+
+export PATH=/full/path/to/your/lammps/src:$PATH :pre
+
+[Example:]
+
+For an executable lmp_serial with a full path
+
+/home/richard/lammps/src/lmp_serial :pre
+
+the PATH variable should be
+
+export PATH=/home/richard/lammps/src:$PATH :pre
+
+NOTE: This should give you a jump start when trying to run LAMMPS on Windows.
+To become effective in this environment I encourage you to look into Linux
+tutorials explaining Bash and Basic Unix commands (e.g., "Linux
+Journey"_https://linuxjourney.com)

doc/src/Howto_bioFF.txt

@@ -0,0 +1,105 @@
+"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+CHARMM, AMBER, and DREIDING force fields :h3
+
+A force field has 2 parts: the formulas that define it and the
+coefficients used for a particular system.  Here we only discuss
+formulas implemented in LAMMPS that correspond to formulas commonly
+used in the CHARMM, AMBER, and DREIDING force fields.  Setting
+coefficients is done in the input data file via the
+"read_data"_read_data.html command or in the input script with
+commands like "pair_coeff"_pair_coeff.html or
+"bond_coeff"_bond_coeff.html.  See the "Tools"_Tools.html doc page for
+additional tools that can use CHARMM or AMBER to assign force field
+coefficients and convert their output into LAMMPS input.
+
+See "(MacKerell)"_#howto-MacKerell for a description of the CHARMM force
+field.  See "(Cornell)"_#howto-Cornell for a description of the AMBER force
+field.
+
+:link(charmm,http://www.scripps.edu/brooks)
+:link(amber,http://amber.scripps.edu)
+
+These style choices compute force field formulas that are consistent
+with common options in CHARMM or AMBER.  See each command's
+documentation for the formula it computes.
+
+"bond_style"_bond_harmonic.html harmonic
+"angle_style"_angle_charmm.html charmm
+"dihedral_style"_dihedral_charmm.html charmmfsh
+"dihedral_style"_dihedral_charmm.html charmm
+"pair_style"_pair_charmm.html lj/charmmfsw/coul/charmmfsh
+"pair_style"_pair_charmm.html lj/charmmfsw/coul/long
+"pair_style"_pair_charmm.html lj/charmm/coul/charmm
+"pair_style"_pair_charmm.html lj/charmm/coul/charmm/implicit
+"pair_style"_pair_charmm.html lj/charmm/coul/long :ul
+
+"special_bonds"_special_bonds.html charmm
+"special_bonds"_special_bonds.html amber :ul
+
+NOTE: For CHARMM, newer {charmmfsw} or {charmmfsh} styles were
+released in March 2017.  We recommend they be used instead of the
+older {charmm} styles.  See discussion of the differences on the "pair
+charmm"_pair_charmm.html and "dihedral charmm"_dihedral_charmm.html
+doc pages.
+
+DREIDING is a generic force field developed by the "Goddard
+group"_http://www.wag.caltech.edu at Caltech and is useful for
+predicting structures and dynamics of organic, biological and
+main-group inorganic molecules. The philosophy in DREIDING is to use
+general force constants and geometry parameters based on simple
+hybridization considerations, rather than individual force constants
+and geometric parameters that depend on the particular combinations of
+atoms involved in the bond, angle, or torsion terms. DREIDING has an
+"explicit hydrogen bond term"_pair_hbond_dreiding.html to describe
+interactions involving a hydrogen atom on very electronegative atoms
+(N, O, F).
+
+See "(Mayo)"_#howto-Mayo for a description of the DREIDING force field
+
+These style choices compute force field formulas that are consistent
+with the DREIDING force field.  See each command's
+documentation for the formula it computes.
+
+"bond_style"_bond_harmonic.html harmonic
+"bond_style"_bond_morse.html morse :ul
+
+"angle_style"_angle_harmonic.html harmonic
+"angle_style"_angle_cosine.html cosine
+"angle_style"_angle_cosine_periodic.html cosine/periodic :ul
+
+"dihedral_style"_dihedral_charmm.html charmm
+"improper_style"_improper_umbrella.html umbrella :ul
+
+"pair_style"_pair_buck.html buck
+"pair_style"_pair_buck.html buck/coul/cut
+"pair_style"_pair_buck.html buck/coul/long
+"pair_style"_pair_lj.html lj/cut
+"pair_style"_pair_lj.html lj/cut/coul/cut
+"pair_style"_pair_lj.html lj/cut/coul/long :ul
+
+"pair_style"_pair_hbond_dreiding.html hbond/dreiding/lj
+"pair_style"_pair_hbond_dreiding.html hbond/dreiding/morse :ul
+
+"special_bonds"_special_bonds.html dreiding :ul
+
+:line
+
+:link(howto-MacKerell)
+[(MacKerell)] MacKerell, Bashford, Bellott, Dunbrack, Evanseck, Field,
+Fischer, Gao, Guo, Ha, et al, J Phys Chem, 102, 3586 (1998).
+
+:link(howto-Cornell)
+[(Cornell)] Cornell, Cieplak, Bayly, Gould, Merz, Ferguson,
+Spellmeyer, Fox, Caldwell, Kollman, JACS 117, 5179-5197 (1995).
+
+:link(howto-Mayo)
+[(Mayo)] Mayo, Olfason, Goddard III, J Phys Chem, 94, 8897-8909
+(1990).

doc/src/Howto_body.txt

@@ -0,0 +1,456 @@
+"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+Body particles :h3
+
+[Overview:]
+
+In LAMMPS, body particles are generalized finite-size particles.
+Individual body particles can represent complex entities, such as
+surface meshes of discrete points, collections of sub-particles,
+deformable objects, etc.  Note that other kinds of finite-size
+spherical and aspherical particles are also supported by LAMMPS, such
+as spheres, ellipsoids, line segments, and triangles, but they are
+simpler entities that body particles.  See the "Howto
+spherical"_Howto_spherical.html doc page for a general overview of all
+these particle types.
+
+Body particles are used via the "atom_style body"_atom_style.html
+command.  It takes a body style as an argument.  The current body
+styles supported by LAMMPS are as follows.  The name in the first
+column is used as the {bstyle} argument for the "atom_style
+body"_atom_style.html command.
+
+{nparticle} : rigid body with N sub-particles
+{rounded/polygon} : 2d polygons with N vertices
+{rounded/polyhedron} : 3d polyhedra with N vertices, E edges and F faces :tb(s=:)
+
+The body style determines what attributes are stored for each body and
+thus how they can be used to compute pairwise body/body or
+bond/non-body (point particle) interactions.  More details of each
+style are described below.
+
+More styles may be added in the future.  See the "Modify
+body"_Modify_body.html doc page for details on how to add a new body
+style to the code.
+
+:line
+
+[When to use body particles:]
+
+You should not use body particles to model a rigid body made of
+simpler particles (e.g. point, sphere, ellipsoid, line segment,
+triangular particles), if the interaction between pairs of rigid
+bodies is just the summation of pairwise interactions between the
+simpler particles.  LAMMPS already supports this kind of model via the
+"fix rigid"_fix_rigid.html command.  Any of the numerous pair styles
+that compute interactions between simpler particles can be used.  The
+"fix rigid"_fix_rigid.html command time integrates the motion of the
+rigid bodies.  All of the standard LAMMPS commands for thermostatting,
+adding constraints, performing output, etc will operate as expected on
+the simple particles.
+
+By contrast, when body particles are used, LAMMPS treats an entire
+body as a single particle for purposes of computing pairwise
+interactions, building neighbor lists, migrating particles between
+processors, output of particles to a dump file, etc.  This means that
+interactions between pairs of bodies or between a body and non-body
+(point) particle need to be encoded in an appropriate pair style.  If
+such a pair style were to mimic the "fix rigid"_fix_rigid.html model,
+it would need to loop over the entire collection of interactions
+between pairs of simple particles within the two bodies, each time a
+single body/body interaction was computed.
+
+Thus it only makes sense to use body particles and develop such a pair
+style, when particle/particle interactions are more complex than what
+the "fix rigid"_fix_rigid.html command can already calculate.  For
+example, consider particles with one or more of the following
+attributes:
+
+represented by a surface mesh
+represented by a collection of geometric entities (e.g. planes + spheres)
+deformable
+internal stress that induces fragmentation :ul
+
+For these models, the interaction between pairs of particles is likely
+to be more complex than the summation of simple pairwise interactions.
+An example is contact or frictional forces between particles with
+planar surfaces that inter-penetrate.  Likewise, the body particle may
+store internal state, such as a stress tensor used to compute a
+fracture criterion.
+
+These are additional LAMMPS commands that can be used with body
+particles of different styles
+
+"fix nve/body"_fix_nve_body.html : integrate motion of a body particle in NVE ensemble
+"fix nvt/body"_fix_nvt_body.html : ditto for NVT ensemble
+"fix npt/body"_fix_npt_body.html : ditto for NPT ensemble
+"fix nph/body"_fix_nph_body.html : ditto for NPH ensemble
+"compute body/local"_compute_body_local.html : store sub-particle attributes of a body particle
+"compute temp/body"_compute_temp_body.html : compute temperature of body particles
+"dump local"_dump.html : output sub-particle attributes of a body particle
+"dump image"_dump_image.html : output body particle attributes as an image :tb(s=:)
+
+The pair styles defined for use with specific body styles are listed
+in the sections below.
+
+:line
+
+[Specifics of body style nparticle:]
+
+The {nparticle} body style represents body particles as a rigid body
+with a variable number N of sub-particles.  It is provided as a
+vanilla, prototypical example of a body particle, although as
+mentioned above, the "fix rigid"_fix_rigid.html command already
+duplicates its functionality.
+
+The atom_style body command for this body style takes two additional
+arguments:
+
+atom_style body nparticle Nmin Nmax
+Nmin = minimum # of sub-particles in any body in the system
+Nmax = maximum # of sub-particles in any body in the system :pre
+
+The Nmin and Nmax arguments are used to bound the size of data
+structures used internally by each particle.
+
+When the "read_data"_read_data.html command reads a data file for this
+body style, the following information must be provided for each entry
+in the {Bodies} section of the data file:
+
+atom-ID 1 M
+N
+ixx iyy izz ixy ixz iyz
+x1 y1 z1
+...
+xN yN zN :pre
+
+where M = 6 + 3*N, and N is the number of sub-particles in the body
+particle.
+
+The integer line has a single value N.  The floating point line(s)
+list 6 moments of inertia followed by the coordinates of the N
+sub-particles (x1 to zN) as 3N values.  These values can be listed on
+as many lines as you wish; see the "read_data"_read_data.html command
+for more details.
+
+The 6 moments of inertia (ixx,iyy,izz,ixy,ixz,iyz) should be the
+values consistent with the current orientation of the rigid body
+around its center of mass.  The values are with respect to the
+simulation box XYZ axes, not with respect to the principal axes of the
+rigid body itself.  LAMMPS performs the latter calculation internally.
+The coordinates of each sub-particle are specified as its x,y,z
+displacement from the center-of-mass of the body particle.  The
+center-of-mass position of the particle is specified by the x,y,z
+values in the {Atoms} section of the data file, as is the total mass
+of the body particle.
+
+The "pair_style body/nparticle"_pair_body_nparticle.html command can be used
+with this body style to compute body/body and body/non-body interactions.
+
+For output purposes via the "compute
+body/local"_compute_body_local.html and "dump local"_dump.html
+commands, this body style produces one datum for each of the N
+sub-particles in a body particle.  The datum has 3 values:
+
+1 = x position of sub-particle
+2 = y position of sub-particle
+3 = z position of sub-particle :pre
+
+These values are the current position of the sub-particle within the
+simulation domain, not a displacement from the center-of-mass (COM) of
+the body particle itself.  These values are calculated using the
+current COM and orientation of the body particle.
+
+For images created by the "dump image"_dump_image.html command, if the
+{body} keyword is set, then each body particle is drawn as a
+collection of spheres, one for each sub-particle.  The size of each
+sphere is determined by the {bflag1} parameter for the {body} keyword.
+The {bflag2} argument is ignored.
+
+:line
+
+[Specifics of body style rounded/polygon:]
+
+The {rounded/polygon} body style represents body particles as a 2d
+polygon with a variable number of N vertices.  This style can only be
+used for 2d models; see the "boundary"_boundary.html command.  See the
+"pair_style body/rounded/polygon" doc page for a diagram of two
+squares with rounded circles at the vertices.  Special cases for N = 1
+(circle) and N = 2 (rod with rounded ends) can also be specified.
+
+One use of this body style is for 2d discrete element models, as
+described in "Fraige"_#body-Fraige.
+
+Similar to body style {nparticle}, the atom_style body command for
+this body style takes two additional arguments:
+
+atom_style body rounded/polygon Nmin Nmax
+Nmin = minimum # of vertices in any body in the system
+Nmax = maximum # of vertices in any body in the system :pre
+
+The Nmin and Nmax arguments are used to bound the size of data
+structures used internally by each particle.
+
+When the "read_data"_read_data.html command reads a data file for this
+body style, the following information must be provided for each entry
+in the {Bodies} section of the data file:
+
+atom-ID 1 M
+N
+ixx iyy izz ixy ixz iyz
+x1 y1 z1
+...
+xN yN zN
+i j j k k ...
+diameter :pre
+
+where M = 6 + 3*N + 2*N + 1, and N is the number of vertices in the
+body particle.
+
+The integer line has a single value N.  The floating point line(s)
+list 6 moments of inertia followed by the coordinates of the N
+vertices (x1 to zN) as 3N values (with z = 0.0 for each), followed by
+2N vertex indices corresponding to the end points of the N edges,
+followed by a single diameter value = the rounded diameter of the
+circle that surrounds each vertex. The diameter value can be different
+for each body particle. These floating-point values can be listed on
+as many lines as you wish; see the "read_data"_read_data.html command
+for more details.
+
+The 6 moments of inertia (ixx,iyy,izz,ixy,ixz,iyz) should be the
+values consistent with the current orientation of the rigid body
+around its center of mass.  The values are with respect to the
+simulation box XYZ axes, not with respect to the principal axes of the
+rigid body itself.  LAMMPS performs the latter calculation internally.
+The coordinates of each vertex are specified as its x,y,z displacement
+from the center-of-mass of the body particle.  The center-of-mass
+position of the particle is specified by the x,y,z values in the
+{Atoms} section of the data file.
+
+For example, the following information would specify a square particle
+whose edge length is sqrt(2) and rounded diameter is 1.0.  The
+orientation of the square is aligned with the xy coordinate axes which
+is consistent with the 6 moments of inertia: ixx iyy izz ixy ixz iyz =
+1 1 4 0 0 0. Note that only Izz matters in 2D simulations.
+
+3 1 27
+4
+1 1 4 0 0 0
+-0.7071 -0.7071 0
+-0.7071 0.7071 0
+0.7071 0.7071 0
+0.7071 -0.7071 0
+0 1
+1 2
+2 3
+3 0
+1.0 :pre
+
+A rod in 2D, whose length is 4.0, mass 1.0, rounded at two ends
+by circles of diameter 0.5, is specified as follows:
+
+1 1 13
+2
+1 1 1.33333 0 0 0
+-2 0 0
+2 0 0
+0.5 :pre
+
+A disk, whose diameter is 3.0, mass 1.0, is specified as follows:
+
+1 1 10
+1
+1 1 4.5 0 0 0
+0 0 0
+3.0 :pre
+
+The "pair_style body/rounded/polygon"_pair_body_rounded_polygon.html
+command can be used with this body style to compute body/body
+interactions.  The "fix wall/body/polygon"_fix_wall_body_polygon.html
+command can be used with this body style to compute the interaction of
+body particles with a wall.
+
+:line
+
+[Specifics of body style rounded/polyhedron:]
+
+The {rounded/polyhedron} body style represents body particles as a 3d
+polyhedron with a variable number of N vertices, E edges and F faces.
+This style can only be used for 3d models; see the
+"boundary"_boundary.html command.  See the "pair_style
+body/rounded/polygon" doc page for a diagram of a two 2d squares with
+rounded circles at the vertices.  A 3d cube with rounded spheres at
+the 8 vertices and 12 rounded edges would be similar.  Special cases
+for N = 1 (sphere) and N = 2 (rod with rounded ends) can also be
+specified.
+
+This body style is for 3d discrete element models, as described in
+"Wang"_#body-Wang.
+
+Similar to body style {rounded/polygon}, the atom_style body command
+for this body style takes two additional arguments:
+
+atom_style body rounded/polyhedron Nmin Nmax
+Nmin = minimum # of vertices in any body in the system
+Nmax = maximum # of vertices in any body in the system :pre
+
+The Nmin and Nmax arguments are used to bound the size of data
+structures used internally by each particle.
+
+When the "read_data"_read_data.html command reads a data file for this
+body style, the following information must be provided for each entry
+in the {Bodies} section of the data file:
+
+atom-ID 3 M
+N E F
+ixx iyy izz ixy ixz iyz
+x1 y1 z1
+...
+xN yN zN
+0 1
+1 2
+2 3
+...
+0 1 2 -1
+0 2 3 -1
+...
+1 2 3 4
+diameter :pre
+
+where M = 6 + 3*N + 2*E + 4*F + 1, and N is the number of vertices in
+the body particle, E = number of edges, F = number of faces.
+
+The integer line has three values: number of vertices (N), number of
+edges (E) and number of faces (F). The floating point line(s) list 6
+moments of inertia followed by the coordinates of the N vertices (x1
+to zN) as 3N values, followed by 2N vertex indices corresponding to
+the end points of the E edges, then 4*F vertex indices defining F
+faces.  The last value is the diameter value = the rounded diameter of
+the sphere that surrounds each vertex. The diameter value can be
+different for each body particle. These floating-point values can be
+listed on as many lines as you wish; see the
+"read_data"_read_data.html command for more details.  Because the
+maximum number of vertices per face is hard-coded to be 4
+(i.e. quadrilaterals), faces with more than 4 vertices need to be
+split into triangles or quadrilaterals.  For triangular faces, the
+last vertex index should be set to -1.
+
+The ordering of the 4 vertices within a face should follow
+the right-hand rule so that the normal vector of the face points
+outwards from the center of mass.
+
+The 6 moments of inertia (ixx,iyy,izz,ixy,ixz,iyz) should be the
+values consistent with the current orientation of the rigid body
+around its center of mass.  The values are with respect to the
+simulation box XYZ axes, not with respect to the principal axes of the
+rigid body itself.  LAMMPS performs the latter calculation internally.
+The coordinates of each vertex are specified as its x,y,z displacement
+from the center-of-mass of the body particle.  The center-of-mass
+position of the particle is specified by the x,y,z values in the
+{Atoms} section of the data file.
+
+For example, the following information would specify a cubic particle
+whose edge length is 2.0 and rounded diameter is 0.5.
+The orientation of the cube is aligned with the xyz coordinate axes
+which is consistent with the 6 moments of inertia: ixx iyy izz ixy ixz
+iyz = 0.667 0.667 0.667 0 0 0.
+
+1 3 79
+8 12 6
+0.667 0.667 0.667 0 0 0
+1 1 1
+1 -1 1
+-1 -1 1
+-1 1 1
+1 1 -1
+1 -1 -1
+-1 -1 -1
+-1 1 -1
+0 1
+1 2
+2 3
+3 0
+4 5
+5 6
+6 7
+7 4
+0 4
+1 5
+2 6
+3 7
+0 1 2 3
+4 5 6 7
+0 1 5 4
+1 2 6 5
+2 3 7 6
+3 0 4 7
+0.5 :pre
+
+A rod in 3D, whose length is 4.0, mass 1.0 and rounded at two ends
+by circles of diameter 0.5, is specified as follows:
+
+1 1 13
+2
+0 1.33333 1.33333 0 0 0
+-2 0 0
+2 0 0
+0.5 :pre
+
+A sphere whose diameter is 3.0 and mass 1.0, is specified as follows:
+
+1 1 10
+1
+0.9 0.9 0.9 0 0 0
+0 0 0
+3.0 :pre
+
+The "pair_style
+body/rounded/polhedron"_pair_body_rounded_polyhedron.html command can
+be used with this body style to compute body/body interactions.  The
+"fix wall/body/polyhedron"_fix_wall_body_polygon.html command can be
+used with this body style to compute the interaction of body particles
+with a wall.
+
+:line
+
+For output purposes via the "compute
+body/local"_compute_body_local.html and "dump local"_dump.html
+commands, this body style produces one datum for each of the N
+sub-particles in a body particle.  The datum has 3 values:
+
+1 = x position of vertex
+2 = y position of vertex
+3 = z position of vertex :pre
+
+These values are the current position of the vertex within the
+simulation domain, not a displacement from the center-of-mass (COM) of
+the body particle itself.  These values are calculated using the
+current COM and orientation of the body particle.
+
+For images created by the "dump image"_dump_image.html command, if the
+{body} keyword is set, then each body particle is drawn as a polygon
+consisting of N line segments.  Note that the line segments are drawn
+between the N vertices, which does not correspond exactly to the
+physical extent of the body (because the "pair_style
+rounded/polygon"_pair_body_rounded_polygon.html defines finite-size
+spheres at those point and the line segments between the spheres are
+tangent to the spheres).  The drawn diameter of each line segment is
+determined by the {bflag1} parameter for the {body} keyword.  The
+{bflag2} argument is ignored.
+
+:line
+
+:link(body-Fraige)
+[(Fraige)] F. Y. Fraige, P. A. Langston, A. J. Matchett, J. Dodds,
+Particuology, 6, 455 (2008).
+
+:link(body-Wang)
+[(Wang)] J. Wang, H. S. Yu, P. A. Langston, F. Y. Fraige, Granular
+Matter, 13, 1 (2011).

doc/src/Howto_chunk.txt

@@ -0,0 +1,195 @@
+"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+Use chunks to calculate system properties :h3
+
+In LAMMS, "chunks" are collections of atoms, as defined by the
+"compute chunk/atom"_compute_chunk_atom.html command, which assigns
+each atom to a chunk ID (or to no chunk at all).  The number of chunks
+and the assignment of chunk IDs to atoms can be static or change over
+time.  Examples of "chunks" are molecules or spatial bins or atoms
+with similar values (e.g. coordination number or potential energy).
+
+The per-atom chunk IDs can be used as input to two other kinds of
+commands, to calculate various properties of a system:
+
+"fix ave/chunk"_fix_ave_chunk.html
+any of the "compute */chunk"_compute.html commands :ul
+
+Here a brief overview for each of the 4 kinds of chunk-related commands
+is provided.  Then some examples are given of how to compute different
+properties with chunk commands.
+
+Compute chunk/atom command: :h4
+
+This compute can assign atoms to chunks of various styles.  Only atoms
+in the specified group and optional specified region are assigned to a
+chunk.  Here are some possible chunk definitions:
+
+atoms in same molecule | chunk ID = molecule ID |
+atoms of same atom type | chunk ID = atom type |
+all atoms with same atom property (charge, radius, etc) | chunk ID = output of compute property/atom |
+atoms in same cluster | chunk ID = output of "compute cluster/atom"_compute_cluster_atom.html command |
+atoms in same spatial bin | chunk ID = bin ID |
+atoms in same rigid body | chunk ID = molecule ID used to define rigid bodies |
+atoms with similar potential energy | chunk ID = output of "compute pe/atom"_compute_pe_atom.html |
+atoms with same local defect structure | chunk ID = output of "compute centro/atom"_compute_centro_atom.html or "compute coord/atom"_compute_coord_atom.html command :tb(s=|,c=2)
+
+Note that chunk IDs are integer values, so for atom properties or
+computes that produce a floating point value, they will be truncated
+to an integer.  You could also use the compute in a variable that
+scales the floating point value to spread it across multiple integers.
+
+Spatial bins can be of various kinds, e.g. 1d bins = slabs, 2d bins =
+pencils, 3d bins = boxes, spherical bins, cylindrical bins.
+
+This compute also calculates the number of chunks {Nchunk}, which is
+used by other commands to tally per-chunk data.  {Nchunk} can be a
+static value or change over time (e.g. the number of clusters).  The
+chunk ID for an individual atom can also be static (e.g. a molecule
+ID), or dynamic (e.g. what spatial bin an atom is in as it moves).
+
+Note that this compute allows the per-atom output of other
+"computes"_compute.html, "fixes"_fix.html, and
+"variables"_variable.html to be used to define chunk IDs for each
+atom.  This means you can write your own compute or fix to output a
+per-atom quantity to use as chunk ID.  See the "Modify"_Modify.html
+doc pages for info on how to do this.  You can also define a "per-atom
+variable"_variable.html in the input script that uses a formula to
+generate a chunk ID for each atom.
+
+Fix ave/chunk command: :h4
+
+This fix takes the ID of a "compute
+chunk/atom"_compute_chunk_atom.html command as input.  For each chunk,
+it then sums one or more specified per-atom values over the atoms in
+each chunk.  The per-atom values can be any atom property, such as
+velocity, force, charge, potential energy, kinetic energy, stress,
+etc.  Additional keywords are defined for per-chunk properties like
+density and temperature.  More generally any per-atom value generated
+by other "computes"_compute.html, "fixes"_fix.html, and "per-atom
+variables"_variable.html, can be summed over atoms in each chunk.
+
+Similar to other averaging fixes, this fix allows the summed per-chunk
+values to be time-averaged in various ways, and output to a file.  The
+fix produces a global array as output with one row of values per
+chunk.
+
+Compute */chunk commands: :h4
+
+The following computes operate on chunks of atoms to produce per-chunk
+values.  Any compute whose style name ends in "/chunk" is in this
+category:
+
+"compute com/chunk"_compute_com_chunk.html
+"compute gyration/chunk"_compute_gyration_chunk.html
+"compute inertia/chunk"_compute_inertia_chunk.html
+"compute msd/chunk"_compute_msd_chunk.html
+"compute property/chunk"_compute_property_chunk.html
+"compute temp/chunk"_compute_temp_chunk.html
+"compute torque/chunk"_compute_vcm_chunk.html
+"compute vcm/chunk"_compute_vcm_chunk.html :ul
+
+They each take the ID of a "compute
+chunk/atom"_compute_chunk_atom.html command as input.  As their names
+indicate, they calculate the center-of-mass, radius of gyration,
+moments of inertia, mean-squared displacement, temperature, torque,
+and velocity of center-of-mass for each chunk of atoms.  The "compute
+property/chunk"_compute_property_chunk.html command can tally the
+count of atoms in each chunk and extract other per-chunk properties.
+
+The reason these various calculations are not part of the "fix
+ave/chunk command"_fix_ave_chunk.html, is that each requires a more
+complicated operation than simply summing and averaging over per-atom
+values in each chunk.  For example, many of them require calculation
+of a center of mass, which requires summing mass*position over the
+atoms and then dividing by summed mass.
+
+All of these computes produce a global vector or global array as
+output, wih one or more values per chunk.  The output can be used in
+various ways:
+
+As input to the "fix ave/time"_fix_ave_time.html command, which can
+write the values to a file and optionally time average them. :ulb,l
+
+As input to the "fix ave/histo"_fix_ave_histo.html command to
+histogram values across chunks.  E.g. a histogram of cluster sizes or
+molecule diffusion rates. :l
+
+As input to special functions of "equal-style
+variables"_variable.html, like sum() and max() and ave().  E.g. to
+find the largest cluster or fastest diffusing molecule or average
+radius-of-gyration of a set of molecules (chunks). :l,ule
+
+Other chunk commands: :h4
+
+"compute chunk/spread/atom"_compute_chunk_spread_atom.html
+"compute reduce/chunk"_compute_reduce_chunk.html :ul
+
+The "compute chunk/spread/atom"_compute_chunk_spread_atom.html command
+spreads per-chunk values to each atom in the chunk, producing per-atom
+values as its output.  This can be useful for outputting per-chunk
+values to a per-atom "dump file"_dump.html.  Or for using an atom's
+associated chunk value in an "atom-style variable"_variable.html.
+
+The "compute reduce/chunk"_compute_reduce_chunk.html command reduces a
+peratom value across the atoms in each chunk to produce a value per
+chunk.  When used with the "compute
+chunk/spread/atom"_compute_chunk_spread_atom.html command it can
+create peratom values that induce a new set of chunks with a second
+"compute chunk/atom"_compute_chunk_atom.html command.
+
+Example calculations with chunks :h4
+
+Here are examples using chunk commands to calculate various
+properties:
+
+(1) Average velocity in each of 1000 2d spatial bins:
+
+compute cc1 all chunk/atom bin/2d x 0.0 0.1 y lower 0.01 units reduced
+fix 1 all ave/chunk 100 10 1000 cc1 vx vy file tmp.out :pre
+
+(2) Temperature in each spatial bin, after subtracting a flow
+velocity:
+
+compute cc1 all chunk/atom bin/2d x 0.0 0.1 y lower 0.1 units reduced
+compute vbias all temp/profile 1 0 0 y 10
+fix 1 all ave/chunk 100 10 1000 cc1 temp bias vbias file tmp.out :pre
+
+(3) Center of mass of each molecule:
+
+compute cc1 all chunk/atom molecule
+compute myChunk all com/chunk cc1
+fix 1 all ave/time 100 1 100 c_myChunk\[*\] file tmp.out mode vector :pre
+
+(4) Total force on each molecule and ave/max across all molecules:
+
+compute cc1 all chunk/atom molecule
+fix 1 all ave/chunk 1000 1 1000 cc1 fx fy fz file tmp.out
+variable xave equal ave(f_1\[2\])
+variable xmax equal max(f_1\[2\])
+thermo 1000
+thermo_style custom step temp v_xave v_xmax :pre
+
+(5) Histogram of cluster sizes:
+
+compute cluster all cluster/atom 1.0
+compute cc1 all chunk/atom c_cluster compress yes
+compute size all property/chunk cc1 count
+fix 1 all ave/histo 100 1 100 0 20 20 c_size mode vector ave running beyond ignore file tmp.histo :pre
+
+(6) An example of using a per-chunk value to apply per-atom forces to
+compress individual polymer chains (molecules) in a mixture, is
+explained on the "compute
+chunk/spread/atom"_compute_chunk_spread_atom.html command doc page.
+
+(7) An example of using one set of per-chunk values for molecule
+chunks, to create a 2nd set of micelle-scale chunks (clustered
+molecules, due to hydrophobicity), is explained on the "compute
+chunk/reduce"_compute_reduce_chunk.html command doc page.

doc/src/Howto_client_server.txt

@@ -0,0 +1,131 @@
+"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+Using LAMMPS in client/server mode :h3
+
+Client/server coupling of two codes is where one code is the "client"
+and sends request messages to a "server" code.  The server responds to
+each request with a reply message.  This enables the two codes to work
+in tandem to perform a simulation.  LAMMPS can act as either a client
+or server code.
+
+Some advantages of client/server coupling are that the two codes run
+as stand-alone executables; they are not linked together.  Thus
+neither code needs to have a library interface.  This often makes it
+easier to run the two codes on different numbers of processors.  If a
+message protocol (format and content) is defined for a particular kind
+of simulation, then in principle any code that implements the
+client-side protocol can be used in tandem with any code that
+implements the server-side protocol, without the two codes needing to
+know anything more specific about each other.
+
+A simple example of client/server coupling is where LAMMPS is the
+client code performing MD timestepping.  Each timestep it sends a
+message to a server quantum code containing current coords of all the
+atoms.  The quantum code computes energy and forces based on the
+coords.  It returns them as a message to LAMMPS, which completes the
+timestep.
+
+Alternate methods for code coupling with LAMMPS are described on
+the "Howto couple"_Howto_couple.html doc page.
+
+LAMMPS support for client/server coupling is in its "MESSAGE
+package"_Packages_details.html#PKG-MESSAGE which implements several
+commands that enable LAMMPS to act as a client or server, as discussed
+below.  The MESSAGE package also wraps a client/server library called
+CSlib which enables two codes to exchange messages in different ways,
+either via files, sockets, or MPI.  The CSlib is provided with LAMMPS
+in the lib/message dir.  The CSlib has its own
+"website"_http://cslib.sandia.gov with documentation and test
+programs.
+
+NOTE: For client/server coupling to work between LAMMPS and another
+code, the other code also has to use the CSlib.  This can sometimes be
+done without any modifications to the other code by simply wrapping it
+with a Python script that exchanges CSlib messages with LAMMPS and
+prepares input for or processes output from the other code.  The other
+code also has to implement a matching protocol for the format and
+content of messages that LAMMPS exchanges with it.
+
+These are the commands currently in the MESSAGE package for two
+protocols, MD and MC (Monte Carlo).  New protocols can easily be
+defined and added to this directory, where LAMMPS acts as either the
+client or server.
+
+"message"_message.html
+"fix client md"_fix_client_md.html = LAMMPS is a client for running MD
+"server md"_server_md.html = LAMMPS is a server for computing MD forces
+"server mc"_server_mc.html = LAMMPS is a server for computing a Monte Carlo energy :ul
+
+The server doc files give details of the message protocols
+for data that is exchanged between the client and server.
+
+These example directories illustrate how to use LAMMPS as either a
+client or server code:
+
+examples/message
+examples/COUPLE/README
+examples/COUPLE/lammps_mc
+examples/COUPLE/lammps_vasp :ul
+
+The examples/message dir couples a client instance of LAMMPS to a
+server instance of LAMMPS.
+
+The lammps_mc dir shows how to couple LAMMPS as a server to a simple
+Monte Carlo client code as the driver.
+
+The lammps_vasp dir shows how to couple LAMMPS as a client code
+running MD timestepping to VASP acting as a server providing quantum
+DFT forces, through a Python wrapper script on VASP.
+
+Here is how to launch a client and server code together for any of the
+4 modes of message exchange that the "message"_message.html command
+and the CSlib support.  Here LAMMPS is used as both the client and
+server code.  Another code could be substituted for either.
+
+The examples below show launching both codes from the same window (or
+batch script), using the "&" character to launch the first code in the
+background.  For all modes except {mpi/one}, you could also launch the
+codes in separate windows on your desktop machine.  It does not
+matter whether you launch the client or server first.
+
+In these examples either code can be run on one or more processors.
+If running in a non-MPI mode (file or zmq) you can launch a code on a
+single processor without using mpirun.
+
+IMPORTANT: If you run in mpi/two mode, you must launch both codes via
+mpirun, even if one or both of them runs on a single processor.  This
+is so that MPI can figure out how to connect both MPI processes
+together to exchange MPI messages between them.
+
+For message exchange in {file}, {zmq}, or {mpi/two} modes:
+
+% mpirun -np 1 lmp_mpi -log log.client < in.client &
+% mpirun -np 2 lmp_mpi -log log.server < in.server :pre
+
+% mpirun -np 4 lmp_mpi -log log.client < in.client &
+% mpirun -np 1 lmp_mpi -log log.server < in.server :pre
+
+% mpirun -np 2 lmp_mpi -log log.client < in.client &
+% mpirun -np 4 lmp_mpi -log log.server < in.server :pre
+
+For message exchange in {mpi/one} mode:
+
+Launch both codes in a single mpirun command:
+
+mpirun -np 2 lmp_mpi -mpicolor 0 -in in.message.client -log log.client : -np 4 lmp_mpi -mpicolor 1 -in in.message.server -log log.server :pre
+
+The two -np values determine how many procs the client and the server
+run on.
+
+A LAMMPS executable run in this manner must use the -mpicolor color
+command-line option as their its option, where color is an integer
+label that will be used to distinguish one executable from another in
+the multiple executables that the mpirun command launches.  In this
+example the client was colored with a 0, and the server with a 1.

doc/src/Howto_coreshell.txt

@@ -0,0 +1,253 @@
+"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+Adiabatic core/shell model :h3
+
+The adiabatic core-shell model by "Mitchell and
+Fincham"_#MitchellFincham is a simple method for adding polarizability
+to a system.  In order to mimic the electron shell of an ion, a
+satellite particle is attached to it. This way the ions are split into
+a core and a shell where the latter is meant to react to the
+electrostatic environment inducing polarizability.  See the "Howto
+polarizable"_Howto_polarizable.html doc page for a discussion of all
+the polarizable models available in LAMMPS.
+
+Technically, shells are attached to the cores by a spring force f =
+k*r where k is a parameterized spring constant and r is the distance
+between the core and the shell. The charges of the core and the shell
+add up to the ion charge, thus q(ion) = q(core) + q(shell). This
+setup introduces the ion polarizability (alpha) given by
+alpha = q(shell)^2 / k. In a
+similar fashion the mass of the ion is distributed on the core and the
+shell with the core having the larger mass.
+
+To run this model in LAMMPS, "atom_style"_atom_style.html {full} can
+be used since atom charge and bonds are needed.  Each kind of
+core/shell pair requires two atom types and a bond type.  The core and
+shell of a core/shell pair should be bonded to each other with a
+harmonic bond that provides the spring force. For example, a data file
+for NaCl, as found in examples/coreshell, has this format:
+
+432   atoms  # core and shell atoms
+216   bonds  # number of core/shell springs :pre
+
+4     atom types  # 2 cores and 2 shells for Na and Cl
+2     bond types :pre
+
+0.0 24.09597 xlo xhi
+0.0 24.09597 ylo yhi
+0.0 24.09597 zlo zhi :pre
+
+Masses       # core/shell mass ratio = 0.1 :pre
+
+1 20.690784  # Na core
+2 31.90500   # Cl core
+3 2.298976   # Na shell
+4 3.54500    # Cl shell :pre
+
+Atoms :pre
+
+1    1    2   1.5005    0.00000000   0.00000000   0.00000000 # core of core/shell pair 1
+2    1    4  -2.5005    0.00000000   0.00000000   0.00000000 # shell of core/shell pair 1
+3    2    1   1.5056    4.01599500   4.01599500   4.01599500 # core of core/shell pair 2
+4    2    3  -0.5056    4.01599500   4.01599500   4.01599500 # shell of core/shell pair 2
+(...) :pre
+
+Bonds   # Bond topology for spring forces :pre
+
+1     2     1     2   # spring for core/shell pair 1
+2     2     3     4   # spring for core/shell pair 2
+(...) :pre
+
+Non-Coulombic (e.g. Lennard-Jones) pairwise interactions are only
+defined between the shells.  Coulombic interactions are defined
+between all cores and shells.  If desired, additional bonds can be
+specified between cores.
+
+The "special_bonds"_special_bonds.html command should be used to
+turn-off the Coulombic interaction within core/shell pairs, since that
+interaction is set by the bond spring.  This is done using the
+"special_bonds"_special_bonds.html command with a 1-2 weight = 0.0,
+which is the default value.  It needs to be considered whether one has
+to adjust the "special_bonds"_special_bonds.html weighting according
+to the molecular topology since the interactions of the shells are
+bypassed over an extra bond.
+
+Note that this core/shell implementation does not require all ions to
+be polarized.  One can mix core/shell pairs and ions without a
+satellite particle if desired.
+
+Since the core/shell model permits distances of r = 0.0 between the
+core and shell, a pair style with a "cs" suffix needs to be used to
+implement a valid long-range Coulombic correction.  Several such pair
+styles are provided in the CORESHELL package.  See "this doc
+page"_pair_cs.html for details.  All of the core/shell enabled pair
+styles require the use of a long-range Coulombic solver, as specified
+by the "kspace_style"_kspace_style.html command.  Either the PPPM or
+Ewald solvers can be used.
+
+For the NaCL example problem, these pair style and bond style settings
+are used:
+
+pair_style      born/coul/long/cs 20.0 20.0
+pair_coeff      * *      0.0 1.000   0.00  0.00   0.00
+pair_coeff      3 3    487.0 0.23768 0.00  1.05   0.50 #Na-Na
+pair_coeff      3 4 145134.0 0.23768 0.00  6.99   8.70 #Na-Cl
+pair_coeff      4 4 405774.0 0.23768 0.00 72.40 145.40 #Cl-Cl :pre
+
+bond_style      harmonic
+bond_coeff      1 63.014 0.0
+bond_coeff      2 25.724 0.0 :pre
+
+When running dynamics with the adiabatic core/shell model, the
+following issues should be considered.  The relative motion of
+the core and shell particles corresponds to the polarization,
+hereby an instantaneous relaxation of the shells is approximated
+and a fast core/shell spring frequency ensures a nearly constant
+internal kinetic energy during the simulation.
+Thermostats can alter this polarization behavior, by scaling the
+internal kinetic energy, meaning the shell will not react freely to
+its electrostatic environment.
+Therefore it is typically desirable to decouple the relative motion of
+the core/shell pair, which is an imaginary degree of freedom, from the
+real physical system.  To do that, the "compute
+temp/cs"_compute_temp_cs.html command can be used, in conjunction with
+any of the thermostat fixes, such as "fix nvt"_fix_nh.html or "fix
+langevin"_fix_langevin.html.  This compute uses the center-of-mass velocity
+of the core/shell pairs to calculate a temperature, and insures that
+velocity is what is rescaled for thermostatting purposes.  This
+compute also works for a system with both core/shell pairs and
+non-polarized ions (ions without an attached satellite particle).  The
+"compute temp/cs"_compute_temp_cs.html command requires input of two
+groups, one for the core atoms, another for the shell atoms.
+Non-polarized ions which might also be included in the treated system
+should not be included into either of these groups, they are taken
+into account by the {group-ID} (2nd argument) of the compute.  The
+groups can be defined using the "group {type}"_group.html command.
+Note that to perform thermostatting using this definition of
+temperature, the "fix modify temp"_fix_modify.html command should be
+used to assign the compute to the thermostat fix.  Likewise the
+"thermo_modify temp"_thermo_modify.html command can be used to make
+this temperature be output for the overall system.
+
+For the NaCl example, this can be done as follows:
+
+group cores type 1 2
+group shells type 3 4
+compute CSequ all temp/cs cores shells
+fix thermoberendsen all temp/berendsen 1427 1427 0.4    # thermostat for the true physical system
+fix thermostatequ all nve                               # integrator as needed for the berendsen thermostat
+fix_modify thermoberendsen temp CSequ
+thermo_modify temp CSequ                                # output of center-of-mass derived temperature :pre
+
+The pressure for the core/shell system is computed via the regular
+LAMMPS convention by "treating the cores and shells as individual
+particles"_#MitchellFincham2. For the thermo output of the pressure
+as well as for the application of a barostat, it is necessary to
+use an additional "pressure"_compute_pressure.html compute based on
+the default "temperature"_compute_temp.html and specifying it as a
+second argument in "fix modify"_fix_modify.html and
+"thermo_modify"_thermo_modify.html resulting in:
+
+(...)
+compute CSequ all temp/cs cores shells
+compute thermo_press_lmp all pressure thermo_temp       # pressure for individual particles
+thermo_modify temp CSequ press thermo_press_lmp         # modify thermo to regular pressure
+fix press_bar all npt temp 300 300 0.04 iso 0 0 0.4
+fix_modify press_bar temp CSequ press thermo_press_lmp  # pressure modification for correct kinetic scalar :pre
+
+If "compute temp/cs"_compute_temp_cs.html is used, the decoupled
+relative motion of the core and the shell should in theory be
+stable.  However numerical fluctuation can introduce a small
+momentum to the system, which is noticeable over long trajectories.
+Therefore it is recommendable to use the "fix
+momentum"_fix_momentum.html command in combination with "compute
+temp/cs"_compute_temp_cs.html when equilibrating the system to
+prevent any drift.
+
+When initializing the velocities of a system with core/shell pairs, it
+is also desirable to not introduce energy into the relative motion of
+the core/shell particles, but only assign a center-of-mass velocity to
+the pairs.  This can be done by using the {bias} keyword of the
+"velocity create"_velocity.html command and assigning the "compute
+temp/cs"_compute_temp_cs.html command to the {temp} keyword of the
+"velocity"_velocity.html command, e.g.
+
+velocity all create 1427 134 bias yes temp CSequ
+velocity all scale 1427 temp CSequ :pre
+
+To maintain the correct polarizability of the core/shell pairs, the
+kinetic energy of the internal motion shall remain nearly constant.
+Therefore the choice of spring force and mass ratio need to ensure
+much faster relative motion of the 2 atoms within the core/shell pair
+than their center-of-mass velocity. This allows the shells to
+effectively react instantaneously to the electrostatic environment and
+limits energy transfer to or from the core/shell oscillators.
+This fast movement also dictates the timestep that can be used.
+
+The primary literature of the adiabatic core/shell model suggests that
+the fast relative motion of the core/shell pairs only allows negligible
+energy transfer to the environment.
+The mentioned energy transfer will typically lead to a small drift
+in total energy over time.  This internal energy can be monitored
+using the "compute chunk/atom"_compute_chunk_atom.html and "compute
+temp/chunk"_compute_temp_chunk.html commands.  The internal kinetic
+energies of each core/shell pair can then be summed using the sum()
+special function of the "variable"_variable.html command.  Or they can
+be time/averaged and output using the "fix ave/time"_fix_ave_time.html
+command.  To use these commands, each core/shell pair must be defined
+as a "chunk".  If each core/shell pair is defined as its own molecule,
+the molecule ID can be used to define the chunks.  If cores are bonded
+to each other to form larger molecules, the chunks can be identified
+by the "fix property/atom"_fix_property_atom.html via assigning a
+core/shell ID to each atom using a special field in the data file read
+by the "read_data"_read_data.html command.  This field can then be
+accessed by the "compute property/atom"_compute_property_atom.html
+command, to use as input to the "compute
+chunk/atom"_compute_chunk_atom.html command to define the core/shell
+pairs as chunks.
+
+For example if core/shell pairs are the only molecules:
+
+read_data NaCl_CS_x0.1_prop.data
+compute prop all property/atom molecule
+compute cs_chunk all chunk/atom c_prop
+compute cstherm all temp/chunk cs_chunk temp internal com yes cdof 3.0     # note the chosen degrees of freedom for the core/shell pairs
+fix ave_chunk all ave/time 10 1 10 c_cstherm file chunk.dump mode vector :pre
+
+For example if core/shell pairs and other molecules are present:
+
+fix csinfo all property/atom i_CSID                       # property/atom command
+read_data NaCl_CS_x0.1_prop.data fix csinfo NULL CS-Info  # atom property added in the data-file
+compute prop all property/atom i_CSID
+(...) :pre
+
+The additional section in the date file would be formatted like this:
+
+CS-Info         # header of additional section :pre
+
+1   1           # column 1 = atom ID, column 2 = core/shell ID
+2   1
+3   2
+4   2
+5   3
+6   3
+7   4
+8   4
+(...) :pre
+
+:line
+
+:link(MitchellFincham)
+[(Mitchell and Fincham)] Mitchell, Fincham, J Phys Condensed Matter,
+5, 1031-1038 (1993).
+
+:link(MitchellFincham2)
+[(Fincham)] Fincham, Mackrodt and Mitchell, J Phys Condensed Matter,
+6, 393-404 (1994).

doc/src/Howto_couple.txt

@@ -0,0 +1,116 @@
+"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+Coupling LAMMPS to other codes :h3
+
+LAMMPS is designed to allow it to be coupled to other codes.  For
+example, a quantum mechanics code might compute forces on a subset of
+atoms and pass those forces to LAMMPS.  Or a continuum finite element
+(FE) simulation might use atom positions as boundary conditions on FE
+nodal points, compute a FE solution, and return interpolated forces on
+MD atoms.
+
+LAMMPS can be coupled to other codes in at least 4 ways.  Each has
+advantages and disadvantages, which you'll have to think about in the
+context of your application.
+
+:line
+
+(1) Define a new "fix"_fix.html command that calls the other code.  In
+this scenario, LAMMPS is the driver code.  During its timestepping,
+the fix is invoked, and can make library calls to the other code,
+which has been linked to LAMMPS as a library.  This is the way the
+"POEMS"_poems package that performs constrained rigid-body motion on
+groups of atoms is hooked to LAMMPS.  See the "fix
+poems"_fix_poems.html command for more details.  See the
+"Modify"_Modify.html doc pages for info on how to add a new fix to
+LAMMPS.
+
+:link(poems,http://www.rpi.edu/~anderk5/lab)
+
+:line
+
+(2) Define a new LAMMPS command that calls the other code.  This is
+conceptually similar to method (1), but in this case LAMMPS and the
+other code are on a more equal footing.  Note that now the other code
+is not called during the timestepping of a LAMMPS run, but between
+runs.  The LAMMPS input script can be used to alternate LAMMPS runs
+with calls to the other code, invoked via the new command.  The
+"run"_run.html command facilitates this with its {every} option, which
+makes it easy to run a few steps, invoke the command, run a few steps,
+invoke the command, etc.
+
+In this scenario, the other code can be called as a library, as in
+(1), or it could be a stand-alone code, invoked by a system() call
+made by the command (assuming your parallel machine allows one or more
+processors to start up another program).  In the latter case the
+stand-alone code could communicate with LAMMPS through files that the
+command writes and reads.
+
+See the "Modify command"_Modify_command.html doc page for info on how
+to add a new command to LAMMPS.
+
+:line
+
+(3) Use LAMMPS as a library called by another code.  In this case the
+other code is the driver and calls LAMMPS as needed.  Or a wrapper
+code could link and call both LAMMPS and another code as libraries.
+Again, the "run"_run.html command has options that allow it to be
+invoked with minimal overhead (no setup or clean-up) if you wish to do
+multiple short runs, driven by another program.
+
+Examples of driver codes that call LAMMPS as a library are included in
+the examples/COUPLE directory of the LAMMPS distribution; see
+examples/COUPLE/README for more details:
+
+simple: simple driver programs in C++ and C which invoke LAMMPS as a
+library :ulb,l
+
+lammps_quest: coupling of LAMMPS and "Quest"_quest, to run classical
+MD with quantum forces calculated by a density functional code :l
+
+lammps_spparks: coupling of LAMMPS and "SPPARKS"_spparks, to couple
+a kinetic Monte Carlo model for grain growth using MD to calculate
+strain induced across grain boundaries :l
+:ule
+
+:link(quest,http://dft.sandia.gov/Quest)
+:link(spparks,http://www.sandia.gov/~sjplimp/spparks.html)
+
+The "Build basics"_Build_basics.html doc page describes how to build
+LAMMPS as a library.  Once this is done, you can interface with LAMMPS
+either via C++, C, Fortran, or Python (or any other language that
+supports a vanilla C-like interface).  For example, from C++ you could
+create one (or more) "instances" of LAMMPS, pass it an input script to
+process, or execute individual commands, all by invoking the correct
+class methods in LAMMPS.  From C or Fortran you can make function
+calls to do the same things.  See the "Python"_Python_head.html doc
+pages for a description of the Python wrapper provided with LAMMPS
+that operates through the LAMMPS library interface.
+
+The files src/library.cpp and library.h contain the C-style interface
+to LAMMPS.  See the "Howto library"_Howto_library.html doc page for a
+description of the interface and how to extend it for your needs.
+
+Note that the lammps_open() function that creates an instance of
+LAMMPS takes an MPI communicator as an argument.  This means that
+instance of LAMMPS will run on the set of processors in the
+communicator.  Thus the calling code can run LAMMPS on all or a subset
+of processors.  For example, a wrapper script might decide to
+alternate between LAMMPS and another code, allowing them both to run
+on all the processors.  Or it might allocate half the processors to
+LAMMPS and half to the other code and run both codes simultaneously
+before syncing them up periodically.  Or it might instantiate multiple
+instances of LAMMPS to perform different calculations.
+
+:line
+
+(4) Couple LAMMPS with another code in a client/server mode.  This is
+described on the "Howto client/server"_Howto_client_server.html doc
+page.

doc/src/Howto_diffusion.txt

@@ -0,0 +1,31 @@
+"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+Calculate diffusion coefficients :h3
+
+The diffusion coefficient D of a material can be measured in at least
+2 ways using various options in LAMMPS.  See the examples/DIFFUSE
+directory for scripts that implement the 2 methods discussed here for
+a simple Lennard-Jones fluid model.
+
+The first method is to measure the mean-squared displacement (MSD) of
+the system, via the "compute msd"_compute_msd.html command.  The slope
+of the MSD versus time is proportional to the diffusion coefficient.
+The instantaneous MSD values can be accumulated in a vector via the
+"fix vector"_fix_vector.html command, and a line fit to the vector to
+compute its slope via the "variable slope"_variable.html function, and
+thus extract D.
+
+The second method is to measure the velocity auto-correlation function
+(VACF) of the system, via the "compute vacf"_compute_vacf.html
+command.  The time-integral of the VACF is proportional to the
+diffusion coefficient.  The instantaneous VACF values can be
+accumulated in a vector via the "fix vector"_fix_vector.html command,
+and time integrated via the "variable trap"_variable.html function,
+and thus extract D.

doc/src/Howto_dispersion.txt

@@ -0,0 +1,108 @@
+"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+Long-range dispersion settings :h3
+
+The PPPM method computes interactions by splitting the pair potential
+into two parts, one of which is computed in a normal pairwise fashion,
+the so-called real-space part, and one of which is computed using the
+Fourier transform, the so called reciprocal-space or kspace part.  For
+both parts, the potential is not computed exactly but is approximated.
+Thus, there is an error in both parts of the computation, the
+real-space and the kspace error. The just mentioned facts are true
+both for the PPPM for Coulomb as well as dispersion interactions. The
+deciding difference - and also the reason why the parameters for
+pppm/disp have to be selected with more care - is the impact of the
+errors on the results: The kspace error of the PPPM for Coulomb and
+dispersion interaction and the real-space error of the PPPM for
+Coulomb interaction have the character of noise. In contrast, the
+real-space error of the PPPM for dispersion has a clear physical
+interpretation: the underprediction of cohesion. As a consequence, the
+real-space error has a much stronger effect than the kspace error on
+simulation results for pppm/disp.  Parameters must thus be chosen in a
+way that this error is much smaller than the kspace error.
+
+When using pppm/disp and not making any specifications on the PPPM
+parameters via the kspace modify command, parameters will be tuned
+such that the real-space error and the kspace error are equal.  This
+will result in simulations that are either inaccurate or slow, both of
+which is not desirable. For selecting parameters for the pppm/disp
+that provide fast and accurate simulations, there are two approaches,
+which both have their up- and downsides.
+
+The first approach is to set desired real-space an kspace accuracies
+via the {kspace_modify force/disp/real} and {kspace_modify
+force/disp/kspace} commands. Note that the accuracies have to be
+specified in force units and are thus dependent on the chosen unit
+settings. For real units, 0.0001 and 0.002 seem to provide reasonable
+accurate and efficient computations for the real-space and kspace
+accuracies.  0.002 and 0.05 work well for most systems using lj
+units. PPPM parameters will be generated based on the desired
+accuracies. The upside of this approach is that it usually provides a
+good set of parameters and will work for both the {kspace_modify diff
+ad} and {kspace_modify diff ik} options.  The downside of the method
+is that setting the PPPM parameters will take some time during the
+initialization of the simulation.
+
+The second approach is to set the parameters for the pppm/disp
+explicitly using the {kspace_modify mesh/disp}, {kspace_modify
+order/disp}, and {kspace_modify gewald/disp} commands. This approach
+requires a more experienced user who understands well the impact of
+the choice of parameters on the simulation accuracy and
+performance. This approach provides a fast initialization of the
+simulation. However, it is sensitive to errors: A combination of
+parameters that will perform well for one system might result in
+far-from-optimal conditions for other simulations. For example,
+parameters that provide accurate and fast computations for
+all-atomistic force fields can provide insufficient accuracy or
+united-atomistic force fields (which is related to that the latter
+typically have larger dispersion coefficients).
+
+To avoid inaccurate or inefficient simulations, the pppm/disp stops
+simulations with an error message if no action is taken to control the
+PPPM parameters. If the automatic parameter generation is desired and
+real-space and kspace accuracies are desired to be equal, this error
+message can be suppressed using the {kspace_modify disp/auto yes}
+command.
+
+A reasonable approach that combines the upsides of both methods is to
+make the first run using the {kspace_modify force/disp/real} and
+{kspace_modify force/disp/kspace} commands, write down the PPPM
+parameters from the output, and specify these parameters using the
+second approach in subsequent runs (which have the same composition,
+force field, and approximately the same volume).
+
+Concerning the performance of the pppm/disp there are two more things
+to consider. The first is that when using the pppm/disp, the cutoff
+parameter does no longer affect the accuracy of the simulation
+(subject to that gewald/disp is adjusted when changing the cutoff).
+The performance can thus be increased by examining different values
+for the cutoff parameter. A lower bound for the cutoff is only set by
+the truncation error of the repulsive term of pair potentials.
+
+The second is that the mixing rule of the pair style has an impact on
+the computation time when using the pppm/disp. Fastest computations
+are achieved when using the geometric mixing rule. Using the
+arithmetic mixing rule substantially increases the computational cost.
+The computational overhead can be reduced using the {kspace_modify
+mix/disp geom} and {kspace_modify splittol} commands. The first
+command simply enforces geometric mixing of the dispersion
+coefficients in kspace computations.  This introduces some error in
+the computations but will also significantly speed-up the
+simulations. The second keyword sets the accuracy with which the
+dispersion coefficients are approximated using a matrix factorization
+approach.  This may result in better accuracy then using the first
+command, but will usually also not provide an equally good increase of
+efficiency.
+
+Finally, pppm/disp can also be used when no mixing rules apply.
+This can be achieved using the {kspace_modify mix/disp none} command.
+Note that the code does not check automatically whether any mixing
+rule is fulfilled. If mixing rules do not apply, the user will have
+to specify this command explicitly.

doc/src/Howto_drude.txt

@@ -0,0 +1,77 @@
+"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+Drude induced dipoles :h3
+
+The thermalized Drude model represents induced dipoles by a pair of
+charges (the core atom and the Drude particle) connected by a harmonic
+spring.  See the "Howto polarizable"_Howto_polarizable.html doc page
+for a discussion of all the polarizable models available in LAMMPS.
+
+The Drude model has a number of features aimed at its use in
+molecular systems ("Lamoureux and Roux"_#howto-Lamoureux):
+
+Thermostatting of the additional degrees of freedom associated with the
+induced dipoles at very low temperature, in terms of the reduced
+coordinates of the Drude particles with respect to their cores. This
+makes the trajectory close to that of relaxed induced dipoles. :ulb,l
+
+Consistent definition of 1-2 to 1-4 neighbors. A core-Drude particle
+pair represents a single (polarizable) atom, so the special screening
+factors in a covalent structure should be the same for the core and
+the Drude particle.  Drude particles have to inherit the 1-2, 1-3, 1-4
+special neighbor relations from their respective cores. :l
+
+Stabilization of the interactions between induced dipoles. Drude
+dipoles on covalently bonded atoms interact too strongly due to the
+short distances, so an atom may capture the Drude particle of a
+neighbor, or the induced dipoles within the same molecule may align
+too much. To avoid this, damping at short range can be done by Thole
+functions (for which there are physical grounds). This Thole damping
+is applied to the point charges composing the induced dipole (the
+charge of the Drude particle and the opposite charge on the core, not
+to the total charge of the core atom). :l,ule
+
+A detailed tutorial covering the usage of Drude induced dipoles in
+LAMMPS is on the "Howto drude2e"_Howto_drude2.html doc page.
+
+As with the core-shell model, the cores and Drude particles should
+appear in the data file as standard atoms. The same holds for the
+springs between them, which are described by standard harmonic bonds.
+The nature of the atoms (core, Drude particle or non-polarizable) is
+specified via the "fix drude"_fix_drude.html command.  The special
+list of neighbors is automatically refactored to account for the
+equivalence of core and Drude particles as regards special 1-2 to 1-4
+screening. It may be necessary to use the {extra/special/per/atom}
+keyword of the "read_data"_read_data.html command. If using "fix
+shake"_fix_shake.html, make sure no Drude particle is in this fix
+group.
+
+There are two ways to thermostat the Drude particles at a low
+temperature: use either "fix langevin/drude"_fix_langevin_drude.html
+for a Langevin thermostat, or "fix
+drude/transform/*"_fix_drude_transform.html for a Nose-Hoover
+thermostat. The former requires use of the command "comm_modify vel
+yes"_comm_modify.html. The latter requires two separate integration
+fixes like {nvt} or {npt}. The correct temperatures of the reduced
+degrees of freedom can be calculated using the "compute
+temp/drude"_compute_temp_drude.html. This requires also to use the
+command {comm_modify vel yes}.
+
+Short-range damping of the induced dipole interactions can be achieved
+using Thole functions through the "pair style
+thole"_pair_thole.html in "pair_style hybrid/overlay"_pair_hybrid.html
+with a Coulomb pair style. It may be useful to use {coul/long/cs} or
+similar from the CORESHELL package if the core and Drude particle come
+too close, which can cause numerical issues.
+
+:line
+
+:link(howto-Lamoureux)
+[(Lamoureux and Roux)] G. Lamoureux, B. Roux, J. Chem. Phys 119, 3025 (2003)

doc/src/Howto_drude2.txt

@@ -0,0 +1,472 @@
+<script type="text/javascript"
+  src="https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML">
+</script>
+<script type="text/x-mathjax-config">
+  MathJax.Hub.Config({ TeX: { equationNumbers: {autoNumber: "AMS"} } });
+</script>
+
+"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+Tutorial for Thermalized Drude oscillators in LAMMPS :h3
+
+This tutorial explains how to use Drude oscillators in LAMMPS to
+simulate polarizable systems using the USER-DRUDE package. As an
+illustration, the input files for a simulation of 250 phenol molecules
+are documented. First of all, LAMMPS has to be compiled with the
+USER-DRUDE package activated. Then, the data file and input scripts
+have to be modified to include the Drude dipoles and how to handle
+them.
+
+:line
+
+[Overview of Drude induced dipoles]
+
+Polarizable atoms acquire an induced electric dipole moment under the
+action of an external electric field, for example the electric field
+created by the surrounding particles.  Drude oscillators represent
+these dipoles by two fixed charges: the core (DC) and the Drude
+particle (DP) bound by a harmonic potential. The Drude particle can be
+thought of as the electron cloud whose center can be displaced from
+the position of the corresponding nucleus.
+
+The sum of the masses of a core-Drude pair should be the mass of the
+initial (unsplit) atom, \(m_C + m_D = m\).  The sum of their charges
+should be the charge of the initial (unsplit) atom, \(q_C + q_D = q\).
+A harmonic potential between the core and Drude partners should be
+present, with force constant \(k_D\) and an equilibrium distance of
+zero. The (half-)stiffness of the "harmonic bond"_bond_harmonic.html
+\(K_D = k_D/2\) and the Drude charge \(q_D\) are related to the atom
+polarizability \(\alpha\) by
+
+\begin\{equation\} K_D = \frac 1 2\, \frac \{q_D^2\} \alpha
+\end\{equation\}
+
+Ideally, the mass of the Drude particle should be small, and the
+stiffness of the harmonic bond should be large, so that the Drude
+particle remains close ot the core. The values of Drude mass, Drude
+charge, and force constant can be chosen following different
+strategies, as in the following examples of polarizable force
+fields:
+
+"Lamoureux and Roux"_#Lamoureux2 suggest adopting a global half-stiffness, \
+\(K_D\) = 500 kcal/(mol Ang \(\{\}^2\)) - which corresponds to a force \
+constant \(k_D\) = 4184 kJ/(mol Ang \(\{\}^2\)) - for all types of \
+core-Drude bond, a global mass \(m_D\) = 0.4 g/mol (or u) for all types \
+of Drude particles, and to calculate the Drude charges for individual \
+atom types from the atom polarizabilities using equation (1). This \
+choice is followed in the polarizable CHARMM force field. :ulb,l
+Alternately "Schroeder and Steinhauser"_#Schroeder suggest adopting a global \
+charge \(q_D\) = -1.0e and a global mass \(m_D\) = 0.1 g/mol (or u) \
+for all Drude particles, and to calculate the force constant for each \
+type of core-Drude bond from equation (1). The timesteps used by these \
+authors are between 0.5 and 2 fs, with the degrees of freedom of the \
+Drude oscillators kept cold at 1 K. :l
+In both these force fields hydrogen atoms are treated as non-polarizable. :l
+:ule
+
+
+The motion of of the Drude particles can be calculated by minimizing
+the energy of the induced dipoles at each timestep, by an iterative,
+self-consistent procedure. The Drude particles can be massless and
+therefore do not contribute to the kinetic energy. However, the
+relaxed method is computational slow. An extended-lagrangian method
+can be used to calculate the positions of the Drude particles, but
+this requires them to have mass. It is important in this case to
+decouple the degrees of freedom associated with the Drude oscillators
+from those of the normal atoms. Thermalizing the Drude dipoles at
+temperatures comparable to the rest of the simulation leads to several
+problems (kinetic energy transfer, very short timestep, etc.), which
+can be remedied by the "cold Drude" technique ("Lamoureux and
+Roux"_#Lamoureux2).
+
+Two closely related models are used to represent polarization through
+"charges on a spring": the core-shell model and the Drude
+model. Although the basic idea is the same, the core-shell model is
+normally used for ionic/crystalline materials, whereas the Drude model
+is normally used for molecular systems and fluid states. In ionic
+crystals the symmetry around each ion and the distance between them
+are such that the core-shell model is sufficiently stable. But to be
+applicable to molecular/covalent systems the Drude model includes two
+important features:
+
+The possibility to thermostat the additional degrees of freedom \
+associated with the induced dipoles at very low temperature, in terms \
+of the reduced coordinates of the Drude particles with respect to \
+their cores. This makes the trajectory close to that of relaxed \
+induced dipoles. :olb,l
+The Drude dipoles on covalently bonded atoms interact too strongly \
+due to the short distances, so an atom may capture the Drude particle \
+(shell) of a neighbor, or the induced dipoles within the same molecule \
+may align too much.  To avoid this, damping at short of the \
+interactions between the point charges composing the induced dipole \
+can be done by "Thole"_#Thole2 functions. :l
+:ole
+
+
+:line
+
+[Preparation of the data file]
+
+The data file is similar to a standard LAMMPS data file for
+{atom_style full}.  The DPs and the {harmonic bonds} connecting them
+to their DC should appear in the data file as normal atoms and bonds.
+
+You can use the {polarizer} tool (Python script distributed with the
+USER-DRUDE package) to convert a non-polarizable data file (here
+{data.102494.lmp}) to a polarizable data file ({data-p.lmp})
+
+polarizer -q -f phenol.dff data.102494.lmp data-p.lmp :pre
+
+This will automatically insert the new atoms and bonds.
+The masses and charges of DCs and DPs are computed
+from {phenol.dff}, as well as the DC-DP bond constants.  The file
+{phenol.dff} contains the polarizabilities of the atom types
+and the mass of the Drude particles, for instance:
+
+# units: kJ/mol, A, deg
+# kforce is in the form k/2 r_D^2
+# type  m_D/u   q_D/e    k_D   alpha/A3  thole
+OH      0.4    -1.0    4184.0   0.63     0.67
+CA      0.4    -1.0    4184.0   1.36     2.51
+CAI     0.4    -1.0    4184.0   1.09     2.51 :pre
+
+The hydrogen atoms are absent from this file, so they will be treated
+as non-polarizable atoms.  In the non-polarizable data file
+{data.102494.lmp}, atom names corresponding to the atom type numbers
+have to be specified as comments at the end of lines of the {Masses}
+section.  You probably need to edit it to add these names. It should
+look like
+
+Masses :pre
+
+1 12.011 # CAI
+2 12.011 # CA
+3 15.999 # OH
+4 1.008  # HA
+5 1.008  # HO :pre
+
+
+:line
+
+[Basic input file]
+
+The atom style should be set to (or derive from) {full}, so that you
+can define atomic charges and molecular bonds, angles, dihedrals...
+
+The {polarizer} tool also outputs certain lines related to the input
+script (the use of these lines will be explained below).  In order for
+LAMMPS to recognize that you are using Drude oscillators, you should
+use the fix {drude}. The command is
+
+fix DRUDE all drude C C C N N D D D :pre
+
+The N, C, D following the {drude} keyword have the following meaning:
+There is one tag for each atom type. This tag is C for DCs, D for DPs
+and N for non-polarizable atoms.  Here the atom types 1 to 3 (C and O
+atoms) are DC, atom types 4 and 5 (H atoms) are non-polarizable and
+the atom types 6 to 8 are the newly created DPs.
+
+By recognizing the fix {drude}, LAMMPS will find and store matching
+DC-DP pairs and will treat DP as equivalent to their DC in the
+{special bonds} relations.  It may be necessary to extend the space
+for storing such special relations.  In this case extra space should
+be reserved by using the {extra/special/per/atom} keyword of either
+the "read_data"_read_data.html or "create_box"_create_box.html
+command.  With our phenol, there is 1 more special neighbor for which
+space is required.  Otherwise LAMMPS crashes and gives the required
+value.
+
+read_data data-p.lmp extra/special/per/atom 1 :pre
+
+Let us assume we want to run a simple NVT simulation at 300 K.  Note
+that Drude oscillators need to be thermalized at a low temperature in
+order to approximate a self-consistent field (SCF), therefore it is not
+possible to simulate an NVE ensemble with this package.  Since dipoles
+are approximated by a charged DC-DP pair, the {pair_style} must
+include Coulomb interactions, for instance {lj/cut/coul/long} with
+{kspace_style pppm}. For example, with a cutoff of 10. and a precision
+1.e-4:
+
+pair_style lj/cut/coul/long 10.0
+kspace_style pppm 1.0e-4 :pre
+
+As compared to the non-polarizable input file, {pair_coeff} lines need
+to be added for the DPs.  Since the DPs have no Lennard-Jones
+interactions, their {epsilon} is 0. so the only {pair_coeff} line
+that needs to be added is
+
+pair_coeff * 6* 0.0 0.0 # All-DPs :pre
+
+Now for the thermalization, the simplest choice is to use the "fix
+langevin/drude"_fix_langevin_drude.html.
+
+fix LANG all langevin/drude 300. 100 12435 1. 20 13977 :pre
+
+This applies a Langevin thermostat at temperature 300. to the centers
+of mass of the DC-DP pairs, with relaxation time 100 and with random
+seed 12345.  This fix applies also a Langevin thermostat at temperature
+1. to the relative motion of the DPs around their DCs, with relaxation
+time 20 and random seed 13977.  Only the DCs and non-polarizable
+atoms need to be in this fix's group.  LAMMPS will thermostat the DPs
+together with their DC.  For this, ghost atoms need to know their
+velocities. Thus you need to add the following command:
+
+comm_modify vel yes :pre
+
+In order to avoid that the center of mass of the whole system
+drifts due to the random forces of the Langevin thermostat on DCs, you
+can add the {zero yes} option at the end of the fix line.
+
+If the fix {shake} is used to constrain the C-H bonds, it should be
+invoked after the fix {langevin/drude} for more accuracy.
+
+fix SHAKE ATOMS shake 0.0001 20 0 t 4 5 :pre
+
+NOTE: The group of the fix {shake} must not include the DPs.  If the
+group {ATOMS} is defined by non-DPs atom types, you could use
+
+Since the fix {langevin/drude} does not perform time integration (just
+modification of forces but no position/velocity updates), the fix
+{nve} should be used in conjunction.
+
+fix NVE all nve :pre
+
+Finally, do not forget to update the atom type elements if you use
+them in a {dump_modify ... element ...} command, by adding the element
+type of the DPs. Here for instance
+
+dump DUMP all custom 10 dump.lammpstrj id mol type element x y z ix iy iz
+dump_modify DUMP element C C O H H D D D :pre
+
+The input file should now be ready for use!
+
+You will notice that the global temperature {thermo_temp} computed by
+LAMMPS is not 300. K as wanted.  This is because LAMMPS treats DPs as
+standard atoms in his default compute.  If you want to output the
+temperatures of the DC-DP pair centers of mass and of the DPs relative
+to their DCs, you should use the "compute
+temp_drude"_compute_temp_drude.html
+
+compute TDRUDE all temp/drude :pre
+
+And then output the correct temperatures of the Drude oscillators
+using {thermo_style custom} with respectively {c_TDRUDE\[1\]} and
+{c_TDRUDE\[2\]}. These should be close to 300.0 and 1.0 on average.
+
+thermo_style custom step temp c_TDRUDE\[1\] c_TDRUDE\[2\] :pre
+
+
+:line
+
+[Thole screening]
+
+Dipolar interactions represented by point charges on springs may not
+be stable, for example if the atomic polarizability is too high for
+instance, a DP can escape from its DC and be captured by another DC,
+which makes the force and energy diverge and the simulation
+crash. Even without reaching this extreme case, the correlation
+between nearby dipoles on the same molecule may be exaggerated.  Often,
+special bond relations prevent bonded neighboring atoms to see the
+charge of each other's DP, so that the problem does not always appear.
+It is possible to use screened dipole dipole interactions by using the
+"{pair_style thole}"_pair_thole.html.  This is implemented as a
+correction to the Coulomb pair_styles, which dampens at short distance
+the interactions between the charges representing the induced dipoles.
+It is to be used as {hybrid/overlay} with any standard {coul} pair
+style.  In our example, we would use
+
+pair_style hybrid/overlay lj/cut/coul/long 10.0 thole 2.6 10.0 :pre
+
+This tells LAMMPS that we are using two pair_styles.  The first one is
+as above ({lj/cut/coul/long 10.0}).  The second one is a {thole}
+pair_style with default screening factor 2.6 ("Noskov"_#Noskov2) and
+cutoff 10.0.
+
+Since {hybrid/overlay} does not support mixing rules, the interaction
+coefficients of all the pairs of atom types with i < j should be
+explicitly defined.  The output of the {polarizer} script can be used
+to complete the {pair_coeff} section of the input file.  In our
+example, this will look like:
+
+pair_coeff    1    1 lj/cut/coul/long    0.0700   3.550
+pair_coeff    1    2 lj/cut/coul/long    0.0700   3.550
+pair_coeff    1    3 lj/cut/coul/long    0.1091   3.310
+pair_coeff    1    4 lj/cut/coul/long    0.0458   2.985
+pair_coeff    2    2 lj/cut/coul/long    0.0700   3.550
+pair_coeff    2    3 lj/cut/coul/long    0.1091   3.310
+pair_coeff    2    4 lj/cut/coul/long    0.0458   2.985
+pair_coeff    3    3 lj/cut/coul/long    0.1700   3.070
+pair_coeff    3    4 lj/cut/coul/long    0.0714   2.745
+pair_coeff    4    4 lj/cut/coul/long    0.0300   2.420
+pair_coeff    *    5 lj/cut/coul/long    0.0000   0.000
+pair_coeff    *   6* lj/cut/coul/long    0.0000   0.000
+pair_coeff    1    1 thole   1.090   2.510
+pair_coeff    1    2 thole   1.218   2.510
+pair_coeff    1    3 thole   0.829   1.590
+pair_coeff    1    6 thole   1.090   2.510
+pair_coeff    1    7 thole   1.218   2.510
+pair_coeff    1    8 thole   0.829   1.590
+pair_coeff    2    2 thole   1.360   2.510
+pair_coeff    2    3 thole   0.926   1.590
+pair_coeff    2    6 thole   1.218   2.510
+pair_coeff    2    7 thole   1.360   2.510
+pair_coeff    2    8 thole   0.926   1.590
+pair_coeff    3    3 thole   0.630   0.670
+pair_coeff    3    6 thole   0.829   1.590
+pair_coeff    3    7 thole   0.926   1.590
+pair_coeff    3    8 thole   0.630   0.670
+pair_coeff    6    6 thole   1.090   2.510
+pair_coeff    6    7 thole   1.218   2.510
+pair_coeff    6    8 thole   0.829   1.590
+pair_coeff    7    7 thole   1.360   2.510
+pair_coeff    7    8 thole   0.926   1.590
+pair_coeff    8    8 thole   0.630   0.670 :pre
+
+For the {thole} pair style the coefficients are
+
+the atom polarizability in units of cubic length :olb,l
+the screening factor of the Thole function (optional, default value
+specified by the pair_style command) :l
+the cutoff (optional, default value defined by the pair_style command) :l
+:ole
+
+The special neighbors have charge-charge and charge-dipole
+interactions screened by the {coul} factors of the {special_bonds}
+command (0.0, 0.0, and 0.5 in the example above).  Without using the
+pair_style {thole}, dipole-dipole interactions are screened by the
+same factor.  By using the pair_style {thole}, dipole-dipole
+interactions are screened by Thole's function, whatever their special
+relationship (except within each DC-DP pair of course).  Consider for
+example 1-2 neighbors: using the pair_style {thole}, their dipoles
+will see each other (despite the {coul} factor being 0.) and the
+interactions between these dipoles will be damped by Thole's function.
+
+
+:line
+
+[Thermostats and barostats]
+
+Using a Nose-Hoover barostat with the {langevin/drude} thermostat is
+straightforward using fix {nph} instead of {nve}.  For example:
+
+fix NPH all nph iso 1. 1. 500 :pre
+
+It is also possible to use a Nose-Hoover instead of a Langevin
+thermostat.  This requires to use "{fix
+drude/transform}"_fix_drude_transform.html just before and after the
+time integration fixes.  The {fix drude/transform/direct} converts the
+atomic masses, positions, velocities and forces into a reduced
+representation, where the DCs transform into the centers of mass of
+the DC-DP pairs and the DPs transform into their relative position
+with respect to their DC. The {fix drude/transform/inverse} performs
+the reverse transformation.  For a NVT simulation, with the DCs and
+atoms at 300 K and the DPs at 1 K relative to their DC one would use
+
+fix DIRECT all drude/transform/direct
+fix NVT1 ATOMS nvt temp 300. 300. 100
+fix NVT2 DRUDES nvt temp 1. 1. 20
+fix INVERSE all drude/transform/inverse :pre
+
+For our phenol example, the groups would be defined as
+
+group ATOMS  type 1 2 3 4 5 # DCs and non-polarizable atoms
+group CORES  type 1 2 3     # DCs
+group DRUDES type 6 7 8     # DPs :pre
+
+Note that with the fixes {drude/transform}, it is not required to
+specify {comm_modify vel yes} because the fixes do it anyway (several
+times and for the forces also).  To avoid the flying ice cube artifact
+"(Lamoureux)"_#Lamoureux2, where the atoms progressively freeze and the
+center of mass of the whole system drifts faster and faster, the {fix
+momentum} can be used. For instance:
+
+fix MOMENTUM all momentum 100 linear 1 1 1 :pre
+
+It is a bit more tricky to run a NPT simulation with Nose-Hoover
+barostat and thermostat.  First, the volume should be integrated only
+once. So the fix for DCs and atoms should be {npt} while the fix for
+DPs should be {nvt} (or vice versa).  Second, the {fix npt} computes a
+global pressure and thus a global temperature whatever the fix group.
+We do want the pressure to correspond to the whole system, but we want
+the temperature to correspond to the fix group only.  We must then use
+the {fix_modify} command for this.  In the end, the block of
+instructions for thermostatting and barostatting will look like
+
+compute TATOMS ATOMS temp
+fix DIRECT all drude/transform/direct
+fix NPT ATOMS npt temp 300. 300. 100 iso 1. 1. 500
+fix_modify NPT temp TATOMS press thermo_press
+fix NVT DRUDES nvt temp 1. 1. 20
+fix INVERSE all drude/transform/inverse :pre
+
+
+:line
+
+[Rigid bodies]
+
+You may want to simulate molecules as rigid bodies (but polarizable).
+Common cases are water models such as "SWM4-NDP"_#SWM4-NDP, which is a
+kind of polarizable TIP4P water.  The rigid bodies and the DPs should
+be integrated separately, even with the Langevin thermostat.  Let us
+review the different thermostats and ensemble combinations.
+
+NVT ensemble using Langevin thermostat:
+
+comm_modify vel yes
+fix LANG all langevin/drude 300. 100 12435 1. 20 13977
+fix RIGID ATOMS rigid/nve/small molecule
+fix NVE DRUDES nve :pre
+
+NVT ensemble using Nose-Hoover thermostat:
+
+fix DIRECT all drude/transform/direct
+fix RIGID ATOMS rigid/nvt/small molecule temp 300. 300. 100
+fix NVT DRUDES nvt temp 1. 1. 20
+fix INVERSE all drude/transform/inverse :pre
+
+NPT ensemble with Langevin thermostat:
+
+comm_modify vel yes
+fix LANG all langevin/drude 300. 100 12435 1. 20 13977
+fix RIGID ATOMS rigid/nph/small molecule iso 1. 1. 500
+fix NVE DRUDES nve :pre
+
+NPT ensemble using Nose-Hoover thermostat:
+
+compute TATOM ATOMS temp
+fix DIRECT all drude/transform/direct
+fix RIGID ATOMS rigid/npt/small molecule temp 300. 300. 100 iso 1. 1. 500
+fix_modify RIGID temp TATOM press thermo_press
+fix NVT DRUDES nvt temp 1. 1. 20
+fix INVERSE all drude/transform/inverse :pre
+
+
+:line
+
+:link(Lamoureux2)
+[(Lamoureux)] Lamoureux and Roux, J Chem Phys, 119, 3025-3039 (2003)
+
+:link(Schroeder)
+[(Schroeder)]  Schroeder and Steinhauser, J Chem Phys, 133,
+154511 (2010).
+
+:link(Jiang2)
+[(Jiang)] Jiang, Hardy, Phillips, MacKerell, Schulten, and Roux,
+ J Phys Chem Lett, 2, 87-92 (2011).
+
+:link(Thole2)
+[(Thole)] Chem Phys, 59, 341 (1981).
+
+:link(Noskov2)
+[(Noskov)] Noskov, Lamoureux and Roux, J Phys Chem B, 109, 6705 (2005).
+
+:link(SWM4-NDP)
+[(SWM4-NDP)] Lamoureux, Harder, Vorobyov, Roux, MacKerell, Chem Phys
+Let, 418, 245-249 (2006)
+

doc/src/Howto_elastic.txt

@@ -0,0 +1,47 @@
+"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
+Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+Calculate elastic constants :h3
+
+Elastic constants characterize the stiffness of a material. The formal
+definition is provided by the linear relation that holds between the
+stress and strain tensors in the limit of infinitesimal deformation.
+In tensor notation, this is expressed as s_ij = C_ijkl * e_kl, where
+the repeated indices imply summation. s_ij are the elements of the
+symmetric stress tensor. e_kl are the elements of the symmetric strain
+tensor. C_ijkl are the elements of the fourth rank tensor of elastic
+constants. In three dimensions, this tensor has 3^4=81 elements. Using
+Voigt notation, the tensor can be written as a 6x6 matrix, where C_ij
+is now the derivative of s_i w.r.t. e_j. Because s_i is itself a
+derivative w.r.t. e_i, it follows that C_ij is also symmetric, with at
+most 7*6/2 = 21 distinct elements.
+
+At zero temperature, it is easy to estimate these derivatives by
+deforming the simulation box in one of the six directions using the
+"change_box"_change_box.html command and measuring the change in the
+stress tensor. A general-purpose script that does this is given in the
+examples/elastic directory described on the "Examples"_Examples.html
+doc page.
+
+Calculating elastic constants at finite temperature is more
+challenging, because it is necessary to run a simulation that performs
+time averages of differential properties. One way to do this is to
+measure the change in average stress tensor in an NVT simulations when
+the cell volume undergoes a finite deformation. In order to balance
+the systematic and statistical errors in this method, the magnitude of
+the deformation must be chosen judiciously, and care must be taken to
+fully equilibrate the deformed cell before sampling the stress
+tensor. Another approach is to sample the triclinic cell fluctuations
+that occur in an NPT simulation. This method can also be slow to
+converge and requires careful post-processing "(Shinoda)"_#Shinoda1
+
+:line
+
+:link(Shinoda1)
+[(Shinoda)] Shinoda, Shiga, and Mikami, Phys Rev B, 69, 134103 (2004).

doc/src/Howto_github.txt

@@ -0,0 +1,419 @@
+"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Commands_all.html)
+
+:line
+
+LAMMPS GitHub tutorial :h3
+[written by Stefan Paquay]
+
+:line
+
+This document describes the process of how to use GitHub to integrate
+changes or additions you have made to LAMMPS into the official LAMMPS
+distribution.  It uses the process of updating this very tutorial as
+an example to describe the individual steps and options.  You need to
+be familiar with git and you may want to have a look at the
+"Git book"_http://git-scm.com/book/ to reacquaint yourself with some
+of the more advanced git features used below.
+
+As of fall 2016, submitting contributions to LAMMPS via pull requests
+on GitHub is the preferred option for integrating contributed features
+or improvements to LAMMPS, as it significantly reduces the amount of
+work required by the LAMMPS developers. Consequently, creating a pull
+request will increase your chances to have your contribution included
+and will reduce the time until the integration is complete. For more
+information on the requirements to have your code included into LAMMPS
+please see the "Modify contribute"_Modify_contribute.html doc page.
+
+:line
+
+[Making an account]
+
+First of all, you need a GitHub account. This is fairly simple, just
+go to "GitHub"_https://github.com and create an account by clicking
+the "Sign up for GitHub" button. Once your account is created, you
+can sign in by clicking the button in the top left and filling in your
+username or e-mail address and password.
+
+:line
+
+[Forking the repository]
+
+To get changes into LAMMPS, you need to first fork the `lammps/lammps`
+repository on GitHub. At the time of writing, {master} is the preferred
+target branch. Thus go to "LAMMPS on GitHub"_https://github.com/lammps/lammps
+and make sure branch is set to "master", as shown in the figure below.
+
+:c,image(JPG/tutorial_branch.png)
+
+If it is not, use the button to change it to {master}. Once it is, use the
+fork button to create a fork.
+
+:c,image(JPG/tutorial_fork.png)
+
+
+This will create a fork (which is essentially a copy, but uses less
+resources) of the LAMMPS repository under your own GitHub account. You
+can make changes in this fork and later file {pull requests} to allow
+the upstream repository to merge changes from your own fork into the one
+we just forked from (or others that were forked from the same repository).
+At the same time, you can set things up, so you can include changes from
+upstream into your repository and thus keep it in sync with the ongoing
+LAMMPS development.
+
+:line
+
+[Adding changes to your own fork]
+
+Additions to the upstream version of LAMMPS are handled using {feature
+branches}.  For every new feature, a so-called feature branch is
+created, which contains only those modification relevant to one specific
+feature. For example, adding a single fix would consist of creating a
+branch with only the fix header and source file and nothing else.  It is
+explained in more detail here: "feature branch
+workflow"_https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow.
+
+[Feature branches]
+
+First of all, create a clone of your version on github on your local
+machine via HTTPS:
+
+  $ git clone https://github.com/<your user name>/lammps.git <some name> :pre
+
+or, if you have set up your GitHub account for using SSH keys, via SSH:
+
+  $ git clone git@github.com:<your user name>/lammps.git :pre
+
+You can find the proper URL by clicking the "Clone or download"-button:
+
+:c,image(JPG/tutorial_https_block.png)
+
+The above command copies ("clones") the git repository to your local
+machine to a directory with the name you chose. If none is given, it will
+default to "lammps". Typical names are "mylammps" or something similar.
+
+You can use this local clone to make changes and
+test them without interfering with the repository on GitHub.
+
+To pull changes from upstream into this copy, you can go to the directory
+and use git pull:
+
+  $ cd mylammps
+  $ git checkout master
+  $ git pull https://github.com/lammps/lammps :pre
+
+You can also add this URL as a remote:
+
+  $ git remote add lammps_upstream https://www.github.com/lammps/lammps :pre
+
+At this point, you typically make a feature branch from the updated master
+branch for the feature you want to work on. This tutorial contains the
+workflow that updated this tutorial, and hence we will call the branch
+"github-tutorial-update":
+
+ $ git checkout -b github-tutorial-update master :pre
+
+Now that we have changed branches, we can make our changes to our local
+repository. Just remember that if you want to start working on another,
+unrelated feature, you should switch branches!
+
+[After changes are made]
+
+After everything is done, add the files to the branch and commit them:
+
+ $ git add doc/src/Howto_github.txt
+ $ git add doc/src/JPG/tutorial*.png :pre
+
+IMPORTANT NOTE: Do not use {git commit -a} (or {git add -A}).  The -a
+flag (or -A flag) will automatically include _all_ modified or new files
+and that is rarely the behavior you want.  It can easily lead to
+accidentally adding unrelated and unwanted changes into the repository.
+Instead it is preferable to explicitly use {git add}, {git rm}, {git mv}
+for adding, removing, renaming individual files, respectively, and then
+{git commit} to finalize the commit.  Carefully check all pending
+changes with {git status} before committing them.  If you find doing
+this on the command line too tedious, consider using a GUI, for example
+the one included in git distributions written in Tk, i.e. use {git gui}
+(on some Linux distributions it may be required to install an additional
+package to use it).
+
+After adding all files, the change set can be committed with some
+useful message that explains the change.
+
+  $ git commit -m 'Finally updated the github tutorial' :pre
+
+After the commit, the changes can be pushed to the same branch on GitHub:
+
+$ git push :pre
+
+Git will ask you for your user name and password on GitHub if you have
+not configured anything. If your local branch is not present on GitHub yet,
+it will ask you to add it by running
+
+  $ git push --set-upstream origin github-tutorial-update :pre
+
+If you correctly type your user name and
+password, the feature branch should be added to your fork on GitHub.
+
+If you want to make really sure you push to the right repository
+(which is good practice), you can provide it explicitly:
+
+$ git push origin :pre
+
+or using an explicit URL:
+
+$ git push git@github.com:Pakketeretet2/lammps.git :pre
+
+:line
+
+[Filing a pull request]
+
+Up to this point in the tutorial, all changes were to {your} clones of
+LAMMPS.  Eventually, however, you want this feature to be included into
+the official LAMMPS version.  To do this, you will want to file a pull
+request by clicking on the "New pull request" button:
+
+:c,image(JPG/tutorial_new_pull_request.png)
+
+Make sure that the current branch is set to the correct one, which, in
+this case, is "github-tutorial-update". If done correctly, the only
+changes you will see are those that were made on this branch.
+
+This will open up a new window that lists changes made to the
+repository. If you are just adding new files, there is not much to do,
+but I suppose merge conflicts are to be resolved here if there are
+changes in existing files. If all changes can automatically be merged,
+green text at the top will say so and you can click the "Create pull
+request" button, see image.
+
+:c,image(JPG/tutorial_create_new_pull_request1.png)
+
+Before creating the pull request, make sure the short title is accurate
+and add a comment with details about your pull request.  Here you write
+what your modifications do and why they should be incorporated upstream.
+
+Note the checkbox that says "Allow edits from maintainers".
+This is checked by default checkbox (although in my version of Firefox, only the checkmark is visible):
+
+:c,image(JPG/tutorial_edits_maintainers.png)
+
+If it is checked, maintainers can immediately add their own edits to the
+pull request.  This helps the inclusion of your branch significantly, as
+simple/trivial changes can be added directly to your pull request branch
+by the LAMMPS maintainers.  The alternative would be that they make
+changes on their own version of the branch and file a reverse pull
+request to you.  Just leave this box checked unless you have a very good
+reason not to.
+
+Now just write some nice comments and click on "Create pull request".
+
+:c,image(JPG/tutorial_create_new_pull_request2.png)
+
+:line
+
+[After filing a pull request]
+
+NOTE: When you submit a pull request (or ask for a pull request) for the
+first time, you will receive an invitation to become a LAMMPS project
+collaborator. Please accept this invite as being a collaborator will
+simplify certain administrative tasks and will probably speed up the
+merging of your feature, too.
+
+You will notice that after filing the pull request, some checks are
+performed automatically:
+
+:c,image(JPG/tutorial_automated_checks.png)
+
+If all is fine, you will see this:
+
+:c,image(JPG/tutorial_automated_checks_passed.png)
+
+If any of the checks are failing, your pull request will not be
+processed, as your changes may break compilation for certain
+configurations or may not merge cleanly. It is your responsibility
+to remove the reason(s) for the failed test(s). If you need help
+with this, please contact the LAMMPS developers by adding a comment
+explaining your problems with resolving the failed tests.
+
+A few further interesting things (can) happen to pull requests before
+they are included.
+
+[Additional changes]
+
+First of all, any additional changes you push into your branch in your
+repository will automatically become part of the pull request:
+
+:c,image(JPG/tutorial_additional_changes.png)
+
+This means you can add changes that should be part of the feature after
+filing the pull request, which is useful in case you have forgotten
+them, or if a developer has requested that something needs to be changed
+before the feature can be accepted into the official LAMMPS version.
+After each push, the automated checks are run again.
+
+[Labels]
+
+LAMMPS developers may add labels to your pull request to assign it to
+categories (mostly for bookkeeping purposes), but a few of them are
+important: needs_work, work_in_progress, test-for-regression, and
+full-regression-test. The first two indicate, that your pull request
+is not considered to be complete. With "needs_work" the burden is on
+exclusively on you; while "work_in_progress" can also mean, that a
+LAMMPS developer may want to add changes. Please watch the comments
+to the pull requests. The two "test" labels are used to trigger
+extended tests before the code is merged. This is sometimes done by
+LAMMPS developers, if they suspect that there may be some subtle
+side effects from your changes. It is not done by default, because
+those tests are very time consuming.
+
+[Reviews]
+
+As of Summer 2018, a pull request needs at least 1 approving review
+from a LAMMPS developer with write access to the repository.
+In case your changes touch code that certain developers are associated
+with, they are auto-requested by the GitHub software.  Those associations
+are set in the file
+".github/CODEOWNERS"_https://github.com/lammps/lammps/blob/master/.github/CODEOWNERS
+Thus if you want to be automatically notified to review when anybody
+changes files or packages, that you have contributed to LAMMPS, you can
+add suitable patterns to that file, or a LAMMPS developer may add you.
+
+Otherwise, you can also manually request reviews from specific developers,
+or LAMMPS developers - in their assessment of your pull request - may
+determine who else should be reviewing your contribution and add that person.
+Through reviews, LAMMPS developers also may request specific changes from you.
+If those are not addressed, your pull requests cannot be merged.
+
+[Assignees]
+
+There is an assignee property for pull requests. If the request has not
+been reviewed by any developer yet, it is not assigned to anyone. After
+revision, a developer can choose to assign it to either a) you, b) a
+LAMMPS developer (including him/herself) or c) Axel Kohlmeyer (akohlmey).
+
+Case a) happens if changes are required on your part :ulb,l
+Case b) means that at the moment, it is being tested and reviewed by a
+LAMMPS developer with the expectation that some changes would be required.
+After the review, the developer can choose to implement changes directly
+or suggest them to you. :l
+Case c) means that the pull request has been assigned to the developer
+overseeing the merging of pull requests into the master branch. :ule,l
+
+In this case, Axel assigned the tutorial to Steve:
+
+:c,image(JPG/tutorial_steve_assignee.png)
+
+[Edits from LAMMPS maintainers]
+
+If you allowed edits from maintainers (the default), any LAMMPS
+maintainer can add changes to your pull request.  In this case, both
+Axel and Richard made changes to the tutorial:
+
+:c,image(JPG/tutorial_changes_others.png)
+
+[Reverse pull requests]
+
+Sometimes, however, you might not feel comfortable having other people
+push changes into your own branch, or maybe the maintainers are not sure
+their idea was the right one.  In such a case, they can make changes,
+reassign you as the assignee, and file a "reverse pull request", i.e.
+file a pull request in your GitHub repository to include changes in the
+branch, that you have submitted as a pull request yourself.  In that
+case, you can choose to merge their changes back into your branch,
+possibly make additional changes or corrections and proceed from there.
+It looks something like this:
+
+:c,image(JPG/tutorial_reverse_pull_request.png)
+
+For some reason, the highlighted button didn't work in my case, but I
+can go to my own repository and merge the pull request from there:
+
+:c,image(JPG/tutorial_reverse_pull_request2.png)
+
+Be sure to check the changes to see if you agree with them by clicking
+on the tab button:
+
+:c,image(JPG/tutorial_reverse_pull_request3.png)
+
+In this case, most of it is changes in the markup and a short rewrite of
+Axel's explanation of the "git gui" and "git add" commands.
+
+:c,image(JPG/tutorial_reverse_pull_request4.png)
+
+Because the changes are OK with us, we are going to merge by clicking on
+"Merge pull request".  After a merge it looks like this:
+
+:c,image(JPG/tutorial_reverse_pull_request5.png)
+
+Now, since in the meantime our local text for the tutorial also changed,
+we need to pull Axel's change back into our branch, and merge them:
+
+ $ git add Howto_github.txt
+ $ git add JPG/tutorial_reverse_pull_request*.png
+ $ git commit -m "Updated text and images on reverse pull requests"
+ $ git pull :pre
+
+In this case, the merge was painless because git could auto-merge:
+
+:c,image(JPG/tutorial_reverse_pull_request6.png)
+
+With Axel's changes merged in and some final text updates, our feature
+branch is now perfect as far as we are concerned, so we are going to
+commit and push again:
+
+ $ git add Howto_github.txt
+ $ git add JPG/tutorial_reverse_pull_request6.png
+ $ git commit -m "Merged Axel's suggestions and updated text"
+ $ git push git@github.com:Pakketeretet2/lammps :pre
+
+This merge also shows up on the lammps GitHub page:
+
+:c,image(JPG/tutorial_reverse_pull_request7.png)
+
+:line
+
+[After a merge]
+
+When everything is fine, the feature branch is merged into the master branch:
+
+:c,image(JPG/tutorial_merged.png)
+
+Now one question remains: What to do with the feature branch that got
+merged into upstream?
+
+It is in principle safe to delete them from your own fork. This helps
+keep it a bit more tidy. Note that you first have to switch to another
+branch!
+
+$ git checkout master
+$ git pull master
+$ git branch -d github-tutorial-update :pre
+
+If you do not pull first, it is not really a problem but git will warn
+you at the next statement that you are deleting a local branch that
+was not yet fully merged into HEAD. This is because git does not yet
+know your branch just got merged into LAMMPS upstream. If you
+first delete and then pull, everything should still be fine.
+
+Finally, if you delete the branch locally, you might want to push this
+to your remote(s) as well:
+
+$ git push origin :github-tutorial-update :pre
+
+[Recent changes in the workflow]
+
+Some changes to the workflow are not captured in this tutorial.  For
+example, in addition to the master branch, to which all new features
+should be submitted, there is now also an "unstable" and a "stable"
+branch; these have the same content as "master", but are only updated
+after a patch release or stable release was made.
+Furthermore, the naming of the patches now follow the pattern
+"patch_<Day><Month><Year>" to simplify comparisons between releases.
+Finally, all patches and submissions are subject to automatic testing
+and code checks to make sure they at the very least compile.
+
+A discussion of the LAMMPS developer GitHub workflow can be found in the file
+"doc/github-development-workflow.md"_https://github.com/lammps/lammps/blob/master/doc/github-development-workflow.md