patch 17Aug17

Collected small changes and bug fixes

.github/CODEOWNERS

@@ -0,0 +1,21 @@
+# This file contains file patterns that triggers automatic
+# code review requests from users that are owners of these files
+# Order matters, the last match has the highest precedence
+
+# library folders
+lib/colvars/*         @giacomofiorin
+lib/compress/*        @akohlmey
+lib/kokkos/*          @stanmoore1
+lib/molfile/*         @akohlmey
+lib/qmmm/*            @akohlmey
+lib/vtk/*             @rbberger
+
+# packages
+src/KOKKOS            @stanmoore1
+src/USER-CGSDK        @akohlmey
+src/USER-COLVARS      @giacomofiorin
+src/USER-OMP          @akohlmey
+src/USER-QMMM         @akohlmey
+
+# tools
+tools/msi2lmp/*       @akohlmey

.github/CONTRIBUTING.md

@@ -0,0 +1,112 @@
+# Contributing to LAMMPS via GitHub
+
+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.
+
+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)
+
+## Table of Contents
+
+[I don't want to read this whole thing, I just have a question!](#i-dont-want-to-read-this-whole-thing-i-just-have-a-question)
+
+[How Can I Contribute?](#how-can-i-contribute)
+* [Discussing How To Use LAMMPS](#discussing-how-to-use-lammps)
+* [Reporting Bugs](#reporting-bugs)
+* [Suggesting Enhancements](#suggesting-enhancements)
+* [Contributing Code](#contributing-code)
+
+[GitHub Workflows](#github-workflows)
+* [Issues](#issues)
+* [Pull Requests](#pull-requests)
+
+__
+
+## 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.
+
+## 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.
+
+### 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.
+
+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.
+
+If you post a message and you are a subscriber, your message will appear immediately. If you are not a subscriber, your message will be moderated, which typically takes one business day. Either way, when someone replies the reply will usually be sent to both, your personal email address and the mailing list. When replying to people, that responded to your post to the list, please always included the mailing list in your replies (i.e. use "Reply All" and **not** "Reply"). Responses will appear on the list in a few minutes, but it can take a few hours for postings and replies to show up in the SourceForge archive. Sending replies also to the mailing list is important, so that responses are archived and people with a similar issue can search for possible solutions in the mailing list archive.
+
+### 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.
+
+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).
+
+To be able to submit an issue on GitHub, you have to register for an account (for GitHub in general). If you do not want to do that, or have other reservations against submitting an issue there, you can - as an alternative and in decreasing preference - either send an e-mail to the lammps-users mailing list, the original authors of the feature that you suspect to be affected, or one or more of the core LAMMPS developers.
+
+### Suggesting Enhancements
+
+The LAMMPS developers welcome suggestions for enhancements or new features. These should be submitted using the [GitHub Issue Tracker](https://github.com/lammps/lammps/issues) of the LAMMPS project. This is particularly recommended, when you plan to implement the feature or enhancement yourself, as this allows to coordinate in case there are other similar or conflicting ongoing developments.
+The LAMMPS developers will review your submission and consider implementing it. Whether this will actually happen depends on many factors: how difficult it would be, how much effort it would take, how many users would benefit from it, how well the individual developer would understand the underlying physics of the feature, and whether this is a feature that would fit into a software like LAMMPS, or would be better implemented as a separate tool. Because of these factors, it matters how well the suggested enhancement is formulated and the overall benefit is argued convincingly.
+
+To be able to submit an issue on GitHub, you have to register for an account (for GitHub in general). If you do not want to do that, or have other reservations against submitting an issue there, you can - as an alternative - send an e-mail to the lammps-users mailing list.
+
+### Contributing Code
+
+We encourage users to submit new features or modifications for LAMMPS to the core developers so they can be added to the LAMMPS distribution. The preferred way to manage and coordinate this is by submitting a pull request at the LAMMPS project on GitHub. For any larger modifications or programming project, you are encouraged to contact the LAMMPS developers ahead of time, in order to discuss implementation strategies and coding guidelines, that will make it easier to integrate your contribution and result in less work for everybody involved. You are also encouraged to search through the list of open issues on GitHub and submit a new issue for a planned feature, so you would not duplicate the work of others (and possibly get scooped by them) or have your work duplicated by others.
+
+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)
+ 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.
+* If you want your contribution to be added as a user-contributed feature, and it is a single file (actually a `<name>.cpp` and `<name>.h` file) it can be rapidly added to the USER-MISC directory. Include the one-line entry to add to the USER-MISC/README file in that directory, along with the 2 source files. You can do this multiple times if you wish to contribute several individual features.
+* If you want your contribution to be added as a user-contribution and it is several related features, it is probably best to make it a user package directory with a name like USER-FOO. In addition to your new files, the directory should contain a README text file. The README should contain your name and contact information and a brief description of what your new package does. If your files depend on other LAMMPS style files also being installed (e.g. because your file is a derived class from the other LAMMPS class), then an Install.sh file is also needed to check for those dependencies. See other README and Install.sh files in other USER directories as examples. Send us a tarball of this USER-FOO directory.
+* Your new source files need to have the LAMMPS copyright, GPL notice, and your name and email address at the top, like other user-contributed LAMMPS source files. They need to create a class that is inside the LAMMPS namespace. If the file is for one of the USER packages, including USER-MISC, then we are not as picky about the coding style (see above). I.e. the files do not need to be in the same stylistic format and syntax as other LAMMPS files, though that would be nice for developers as well as users who try to read your code.
+* You **must** also create or extend a documentation file for each new command or style you are adding to LAMMPS. For simplicity and convenience, the documentation of groups of closely related commands or styles may be combined into a single file. This will be one file for a single-file feature. For a package, it might be several files. These are simple text files with a specific markup language, that are then auto-converted to HTML and PDF. The tools for this conversion are included in the source distribution, and the translation can be as simple as doing "make html pdf" in the doc folder. Thus the documentation source files must be in the same format and style as other `<name>.txt` files in the lammps/doc/src directory for similar commands and styles; use one or more of them as a starting point. A description of the markup can also be found in `lammps/doc/utils/txt2html/README.html` As appropriate, the text files can include links to equations (see doc/Eqs/*.tex for examples, we auto-create the associated JPG files), or figures (see doc/JPG for examples), or even additional PDF files with further details (see doc/PDF for examples). The doc page should also include literature citations as appropriate; see the bottom of doc/fix_nh.txt for examples and the earlier part of the same file for how to format the cite itself. The "Restrictions" section of the doc page should indicate that your command is only available if LAMMPS is built with the appropriate USER-MISC or USER-FOO package. See other user package doc files for examples of how to do this. The prerequisite for building the HTML format files are Python 3.x and virtualenv, the requirement for generating the PDF format manual is the htmldoc software. Please run at least "make html" and carefully inspect and proofread the resulting HTML format doc page before submitting your code.
+* For a new package (or even a single command) you should include one or more example scripts demonstrating its use. These should run in no more than a couple minutes, even on a single processor, and not require large data files as input. See directories under examples/USER for examples of input scripts other users provided for their packages. These example inputs are also required for validating memory accesses and testing for memory leaks with valgrind
+* If there is a paper of yours describing your feature (either the algorithm/science behind the feature itself, or its initial usage, or its implementation in LAMMPS), you can add the citation to the *.cpp source file. See src/USER-EFF/atom_vec_electron.cpp for an example. A LaTeX citation is stored in a variable at the top of the file and a single line of code that references the variable is added to the constructor of the class. Whenever a user invokes your feature from their input script, this will cause LAMMPS to output the citation to a log.cite file and prompt the user to examine the file. Note that you should only use this for a paper you or your group authored. E.g. adding a cite in the code for a paper by Nose and Hoover if you write a fix that implements their integrator is not the intended usage. That kind of citation should just be in the doc page you provide.
+
+Finally, as a general rule-of-thumb, the more clear and self-explanatory you make your documentation and README files, and the easier you make it for people to get started, e.g. by providing example scripts, the more likely it is that users will try out your new feature.
+
+If the new features/files are broadly useful we may add them as core files to LAMMPS or as part of a standard package. Else we will add them as a user-contributed file or package. Examples of user packages are in src sub-directories that start with USER. The USER-MISC package is simply a collection of (mostly) unrelated single files, which is the simplest way to have your contribution quickly added to the LAMMPS distribution. You can see a list of the both standard and user packages by typing "make package" in the LAMMPS src directory.
+
+Note that by providing us files to release, you are agreeing to make them open-source, i.e. we can release them under the terms of the GPL, used as a license for the rest of LAMMPS. See Section 1.4 for details.
+
+With user packages and files, all we are really providing (aside from the fame and fortune that accompanies having your name in the source code and on the Authors page of the LAMMPS WWW site), is a means for you to distribute your work to the LAMMPS user community, and a mechanism for others to easily try out your new feature. This may help you find bugs or make contact with new collaborators. Note that you are also implicitly agreeing to support your code which means answer questions, fix bugs, and maintain it if LAMMPS changes in some way that breaks it (an unusual event).
+
+To be able to submit an issue on GitHub, you have to register for an account (for GitHub in general). If you do not want to do that, or have other reservations or difficulties to submit a pull request, you can - as an alternative - contact one or more of the core LAMMPS developers and ask if one of them would be interested in manually merging your code into LAMMPS and send them your source code. Since the effort to merge a pull request is a small fraction of the effort of integrating source code manually (which would usually be done by converting the contribution into a pull request), your chances to have your new code included quickly are the best with a pull request.
+
+If you prefer to submit patches or full files, you should first make certain, that your code works correctly with the latest patch-level version of LAMMPS and contains all bug fixes from it. Then create a gzipped tar file of all changed or added files or a corresponding patch file using 'diff -u' or 'diff -c' and compress it with gzip. Please only use gzip compression, as this works well on all platforms.
+
+## GitHub Workflows
+
+This section briefly summarizes the steps that will happen **after** you have submitted either an issue or a pull request on the LAMMPS GitHub project page. 
+
+### Issues
+
+After submitting an issue, one or more of the LAMMPS developers will review it and categorize it by assigning labels. Confirmed bug reports will be labeled `bug`; if the bug report also contains a suggestion for how to fix it, it will be labeled `bugfix`; if the issue is a feature request, it will be labeled `enhancement`. Other labels may be attached as well, depending on which parts of the LAMMPS code are affected. If the assessment is, that the issue does not warrant any changes, the `wontfix` label will be applied and if the submission is incorrect or something that should not be submitted as an issue, the `invalid` label will be applied. In both of the last two cases, the issue will then be closed without further action.
+
+For feature requests, what happens next is that developers may comment on the viability or relevance of the request, discuss and make suggestions for how to implement it. If a LAMMPS developer or user is planning to implement the feature, the issue will be assigned to that developer. For developers, that are not yet listed as LAMMPS project collaborators, they will receive an invitation to be added to the LAMMPS project as a collaborator so they can get assigned. If the requested feature or enhancement is implemented, it will usually be submitted as a pull request, which will contain a reference to the issue number. And once the pull request is reviewed and accepted for inclusion into LAMMPS, the issue will be closed. For details on how pull requests are processed, please see below.
+
+For bug reports, the next step is that one of the core LAMMPS developers will self-assign to the issue and try to confirm the bug. If confirmed, the `bug` label and potentially other labels are added to classify the issue and its impact to LAMMPS. Before confirming, further questions may be asked or requests for providing additional input files or details about the steps required to reproduce the issue. Any bugfix is likely to be submitted as a pull request (more about that below) and since most bugs require only local changes, the bugfix may be included in a pull request specifically set up to collect such local bugfixes or small enhancements. Once the bugfix is included in the master branch, the issue will be closed.
+
+### 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.
+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.
+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.
+

.github/ISSUE_TEMPLATE.md

@@ -0,0 +1,31 @@
+## 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/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,29 @@
+## Purpose
+
+_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_
+
+## Author(s)
+
+_Please state name and affiliation of the author or authors that should be credited with the changes in 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 new documentation files and/or 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)_
+
+

LICENSE

@@ -3,7 +3,7 @@ GNU GENERAL PUBLIC LICENSE
 Version 2, June 1991 
 
 Copyright (C) 1989, 1991 Free Software Foundation, Inc.  
-59 Temple Place - Suite 330, Boston, MA  02111-1307, USA
+51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA
 
 Everyone is permitted to copy and distribute verbatim copies of this
 license document, but changing it is not allowed.

bench/FERMI/README

@@ -1,55 +1,21 @@
 These are input scripts used to run versions of several of the
-benchmarks in the top-level bench directory using the GPU and
-USER-CUDA accelerator packages.  The results of running these scripts
-on two different machines (a desktop with 2 Tesla GPUs and the ORNL
-Titan supercomputer) are shown on the "GPU (Fermi)" section of the
-Benchmark page of the LAMMPS WWW site: lammps.sandia.gov/bench.
+benchmarks in the top-level bench directory using the GPU accelerator
+package.  The results of running these scripts on two different machines
+(a desktop with 2 Tesla GPUs and the ORNL Titan supercomputer) are shown
+on the "GPU (Fermi)" section of the Benchmark page of the LAMMPS WWW
+site: lammps.sandia.gov/bench.
 
 Examples are shown below of how to run these scripts.  This assumes
-you have built 3 executables with both the GPU and USER-CUDA packages
+you have built 3 executables with the GPU package
 installed, e.g.
 
 lmp_linux_single
 lmp_linux_mixed
 lmp_linux_double
 
-The precision (single, mixed, double) refers to the GPU and USER-CUDA
-package precision.  See the README files in the lib/gpu and lib/cuda
-directories for instructions on how to build the packages with
-different precisions.  The GPU and USER-CUDA sub-sections of the
-doc/Section_accelerate.html file also describes this process.
-
-Make.py -d ~/lammps -j 16 -p #all orig -m linux -o cpu -a exe
-Make.py -d ~/lammps -j 16 -p #all opt orig -m linux -o opt -a exe
-Make.py -d ~/lammps -j 16 -p #all omp orig -m linux -o omp -a exe
-Make.py -d ~/lammps -j 16 -p #all gpu orig -m linux \
-        -gpu mode=double arch=20 -o gpu_double -a libs exe
-Make.py -d ~/lammps -j 16 -p #all gpu orig -m linux \
-        -gpu mode=mixed arch=20 -o gpu_mixed -a libs exe
-Make.py -d ~/lammps -j 16 -p #all gpu orig -m linux \
-        -gpu mode=single arch=20 -o gpu_single -a libs exe
-Make.py -d ~/lammps -j 16 -p #all cuda orig -m linux \
-        -cuda mode=double arch=20 -o cuda_double -a libs exe
-Make.py -d ~/lammps -j 16 -p #all cuda orig -m linux \
-        -cuda mode=mixed arch=20 -o cuda_mixed -a libs exe
-Make.py -d ~/lammps -j 16 -p #all cuda orig -m linux \
-        -cuda mode=single arch=20 -o cuda_single -a libs exe
-Make.py -d ~/lammps -j 16 -p #all intel orig -m linux -o intel_cpu -a exe
-Make.py -d ~/lammps -j 16 -p #all kokkos orig -m linux -o kokkos_omp -a exe
-Make.py -d ~/lammps -j 16 -p #all kokkos orig -kokkos cuda arch=20 \
-        -m cuda -o kokkos_cuda -a exe
-
-Make.py -d ~/lammps -j 16 -p #all opt omp gpu cuda intel kokkos orig \
-        -gpu mode=double arch=20 -cuda mode=double arch=20 -m linux \
-        -o all -a libs exe
-
-Make.py -d ~/lammps -j 16 -p #all opt omp gpu cuda intel kokkos orig \
-        -kokkos cuda arch=20 -gpu mode=double arch=20 \
-        -cuda mode=double arch=20 -m cuda -o all_cuda -a libs exe
-
 ------------------------------------------------------------------------
 
-To run on just CPUs (without using the GPU or USER-CUDA styles),
+To run on just CPUs (without using the GPU styles),
 do something like the following:
 
 mpirun -np 1 lmp_linux_double -v x 8 -v y 8 -v z 8 -v t 100 < in.lj
@@ -81,23 +47,5 @@ node via a "-ppn" setting.
 
 ------------------------------------------------------------------------
 
-To run with the USER-CUDA package, do something like the following:
-
-mpirun -np 1 lmp_linux_single -c on -sf cuda -v x 16 -v y 16 -v z 16 -v t 100 < in.lj
-mpirun -np 2 lmp_linux_double -c on -sf cuda -pk cuda 2 -v x 32 -v y 64 -v z 64 -v t 100 < in.eam
-
-The "xyz" settings determine the problem size.  The "t" setting
-determines the number of timesteps.  The "np" setting determines how
-many MPI tasks (per node) the problem will run on.  The numeric
-argument to the "-pk" setting is the number of GPUs (per node); 1 GPU
-is the default.  Note that the number of MPI tasks must equal the
-number of GPUs (both per node) with the USER-CUDA package.
-
-These mpirun commands run on a single node.  To run on multiple nodes,
-scale up the "-np" setting, and control the number of MPI tasks per
-node via a "-ppn" setting.
-
-------------------------------------------------------------------------
-
 If the script has "titan" in its name, it was run on the Titan
 supercomputer at ORNL.

bench/README

@@ -71,49 +71,33 @@ integration
 
 ----------------------------------------------------------------------
 
-Here is a src/Make.py command which will perform a parallel build of a
-LAMMPS executable "lmp_mpi" with all the packages needed by all the
-examples.  This assumes you have an MPI installed on your machine so
-that "mpicxx" can be used as the wrapper compiler.  It also assumes
-you have an Intel compiler to use as the base compiler.  You can leave
-off the "-cc mpi wrap=icc" switch if that is not the case.  You can
-also leave off the "-fft fftw3" switch if you do not have the FFTW
-(v3) installed as an FFT package, in which case the default KISS FFT
-library will be used.
-
-cd src
-Make.py -j 16 -p none molecule manybody kspace granular rigid orig \
-  -cc mpi wrap=icc -fft fftw3 -a file mpi
-
-----------------------------------------------------------------------
-
 Here is how to run each problem, assuming the LAMMPS executable is
 named lmp_mpi, and you are using the mpirun command to launch parallel
 runs:
 
 Serial (one processor runs):
 
-lmp_mpi < in.lj
-lmp_mpi < in.chain
-lmp_mpi < in.eam
-lmp_mpi < in.chute
-lmp_mpi < in.rhodo
+lmp_mpi -in in.lj
+lmp_mpi -in in.chain
+lmp_mpi -in in.eam
+lmp_mpi -in in.chute
+lmp_mpi -in in.rhodo
 
 Parallel fixed-size runs (on 8 procs in this case):
 
-mpirun -np 8 lmp_mpi < in.lj
-mpirun -np 8 lmp_mpi < in.chain
-mpirun -np 8 lmp_mpi < in.eam
-mpirun -np 8 lmp_mpi < in.chute
-mpirun -np 8 lmp_mpi < in.rhodo
+mpirun -np 8 lmp_mpi -in in.lj
+mpirun -np 8 lmp_mpi -in in.chain
+mpirun -np 8 lmp_mpi -in in.eam
+mpirun -np 8 lmp_mpi -in in.chute
+mpirun -np 8 lmp_mpi -in in.rhodo
 
 Parallel scaled-size runs (on 16 procs in this case):
 
-mpirun -np 16 lmp_mpi -var x 2 -var y 2 -var z 4 < in.lj
-mpirun -np 16 lmp_mpi -var x 2 -var y 2 -var z 4 < in.chain.scaled
-mpirun -np 16 lmp_mpi -var x 2 -var y 2 -var z 4 < in.eam
-mpirun -np 16 lmp_mpi -var x 4 -var y 4 < in.chute.scaled
-mpirun -np 16 lmp_mpi -var x 2 -var y 2 -var z 4 < in.rhodo.scaled
+mpirun -np 16 lmp_mpi -var x 2 -var y 2 -var z 4 -in in.lj
+mpirun -np 16 lmp_mpi -var x 2 -var y 2 -var z 4 -in in.chain.scaled
+mpirun -np 16 lmp_mpi -var x 2 -var y 2 -var z 4 -in in.eam
+mpirun -np 16 lmp_mpi -var x 4 -var y 4 -in in.chute.scaled
+mpirun -np 16 lmp_mpi -var x 2 -var y 2 -var z 4 -in in.rhodo.scaled
 
 For each of the scaled-size runs you must set 3 variables as -var
 command line switches.  The variables x,y,z are used in the input

doc/Makefile

@@ -100,6 +100,7 @@ epub: $(OBJECTS)
 
 pdf: utils/txt2html/txt2html.exe
 	@(\
+		set -e; \
 		cd src; \
 		../utils/txt2html/txt2html.exe -b *.txt; \
 		htmldoc --batch lammps.book;          \
@@ -158,7 +159,7 @@ $(VENV):
 	@( \
 		virtualenv -p $(PYTHON) $(VENV); \
 		. $(VENV)/bin/activate; \
-		pip install Sphinx; \
+		pip install Sphinx==1.5.6; \
 		pip install sphinxcontrib-images; \
 		deactivate;\
 	)

doc/src/Eqs/cnp_cutoff.tex

@@ -0,0 +1,14 @@
+\documentclass[12pt,article]{article}
+
+\usepackage{indentfirst}
+\usepackage{amsmath}
+
+\begin{document}
+
+\begin{eqnarray*}
+  r_{c}^{fcc} & = & \frac{1}{2} \left(\frac{\sqrt{2}}{2} + 1\right) \mathrm{a} \simeq 0.8536 \:\mathrm{a} \\
+  r_{c}^{bcc} & = & \frac{1}{2}(\sqrt{2} + 1) \mathrm{a} \simeq 1.207 \:\mathrm{a} \\
+  r_{c}^{hcp} & = & \frac{1}{2}\left(1+\sqrt{\frac{4+2x^{2}}{3}}\right) \mathrm{a}
+\end{eqnarray*}
+
+\end{document}

doc/src/Eqs/cnp_cutoff2.tex

@@ -0,0 +1,12 @@
+\documentclass[12pt,article]{article}
+
+\usepackage{indentfirst}
+\usepackage{amsmath}
+
+\begin{document}
+
+$$
+  Rc + Rs > 2*{\rm cutoff}
+$$
+
+\end{document}

doc/src/Eqs/cnp_eq.tex

@@ -0,0 +1,9 @@
+\documentclass[12pt]{article}
+
+\begin{document}
+
+$$
+   Q_{i} = \frac{1}{n_i}\sum_{j = 1}^{n_i} | \sum_{k = 1}^{n_{ij}}  \vec{R}_{ik} + \vec{R}_{jk} |^2
+$$
+
+\end{document}

doc/src/Eqs/fix_gcmc1.tex

@@ -0,0 +1,9 @@
+\documentclass[12pt]{article}
+
+\begin{document}
+
+\begin{eqnarray*}
+\mu &=&\mu^{id} + \mu^{ex}
+\end{eqnarray*}
+
+\end{document}

doc/src/Eqs/fix_gcmc2.tex

@@ -0,0 +1,10 @@
+\documentclass[12pt]{article}
+
+\begin{document}
+
+\begin{eqnarray*}
+\mu^{id} &=& k T \ln{\rho \Lambda^3} \\
+&=& k T \ln{\frac{\phi P \Lambda^3}{k T}} 
+\end{eqnarray*}
+
+\end{document}

doc/src/Eqs/fix_gcmc3.tex

@@ -0,0 +1,9 @@
+\documentclass[12pt]{article}
+
+\begin{document}
+
+\begin{eqnarray*}
+\Lambda &=& \sqrt{ \frac{h^2}{2 \pi m k T}}
+\end{eqnarray*}
+
+\end{document}

doc/src/Eqs/fix_wall_ees.tex

@@ -0,0 +1,10 @@
+\documentclass[12pt]{article}
+
+\begin{document}
+
+$$ 
+E = \epsilon \left[ \frac{2  \sigma_{LJ}^{12} \left(7 r^5+14 r^3 \sigma_{n}^2+3 r \sigma_{n}^4\right) }{945 \left(r^2-\sigma_{n}^2\right)^7} -\frac{ \sigma_{LJ}^6 \left(2 r \sigma_{n}^3+\sigma_{n}^2 \left(r^2-\sigma_{n}^2\right)\log{ \left[\frac{r-\sigma_{n}}{r+\sigma_{n}}\right]}\right) }{12 \sigma_{n}^5 \left(r^2-\sigma_{n}^2\right)} \right]\qquad \sigma_n < r < r_c
+$$
+
+
+\end{document}

doc/src/Eqs/pair_lj_sf.tex

@@ -1,11 +0,0 @@
-\documentclass[12pt]{article}
-
-\begin{document}
-
-\begin{eqnarray*}
- F & = & F_{\mathrm{LJ}}(r) - F_{\mathrm{LJ}}(r_{\mathrm{c}}) \qquad r < r_{\mathrm{c}} \\
- E & = & E_{\mathrm{LJ}}(r) - E_{\mathrm{LJ}}(r_{\mathrm{c}}) + (r - r_{\mathrm{c}}) F_{\mathrm{LJ}}(r_{\mathrm{c}}) \qquad r < r_{\mathrm{c}} \\
- \mathrm{with} \qquad E_{\mathrm{LJ}}(r) & = & 4 \epsilon \left[ \left(\frac{\sigma}{r}\right)^{12} - \left(\frac{\sigma}{r}\right)^6 \right] \qquad \mathrm{and} \qquad F_{\mathrm{LJ}}(r) = - E^\prime_{\mathrm{LJ}}(r)
-\end{eqnarray*}                           
-
-\end{document}

doc/src/Eqs/pair_meam_spline.tex

@@ -1,13 +1,14 @@
 \documentclass[12pt]{article}
+\usepackage{amsmath}
 
 \begin{document}
 
 $$
-   E=\sum_{ij}\phi(r_{ij})+\sum_{i}U(\rho_{i}),
+   E=\sum_{i<j}\phi(r_{ij})+\sum_{i}U(n_{i}),
 $$
 
 $$
-   \rho_{i}=\sum_{j}\rho(r_{ij})+\sum_{jk}f(r_{ij})f(r_{ik})g[\cos(\theta_{jik})]
+   n_{i}=\sum_{j}\rho(r_{ij})+\sum_{\substack{j<k,\\j,k\neq i}}f(r_{ij})f(r_{ik})g[\cos(\theta_{jik})]
 $$
 
 \end{document}

doc/src/Eqs/pair_meam_spline_multicomponent.tex

@@ -0,0 +1,14 @@
+\documentclass[12pt]{article}
+\usepackage{amsmath}
+
+\begin{document}
+
+$$
+   E=\sum_{i<j}\phi_{ij}(r_{ij})+\sum_{i}U_i(n_{i}),
+$$
+
+$$
+   n_{i}=\sum_{j\ne i}\rho_j(r_{ij})+\sum_{\substack{j<k,\\j,k\neq i}}f_{j}(r_{ij})f_{k}(r_{ik})g_{jk}[\cos(\theta_{jik})]
+$$
+
+\end{document}

doc/src/Manual.txt

@@ -1,7 +1,7 @@
 <!-- HTML_ONLY -->
 <HEAD>
 <TITLE>LAMMPS Users Manual</TITLE>
-<META NAME="docnumber" CONTENT="24 Mar 2017 version">
+<META NAME="docnumber" CONTENT="17 Aug 2017 version">
 <META NAME="author" CONTENT="http://lammps.sandia.gov - Sandia National Laboratories">
 <META NAME="copyright" CONTENT="Copyright (2003) Sandia Corporation.  This software and manual is distributed under the GNU General Public License.">
 </HEAD>
@@ -21,7 +21,7 @@
 <H1></H1>
 
 LAMMPS Documentation :c,h3
-24 Mar 2017 version :c,h4
+17 Aug 2017 version :c,h4
 
 Version info: :h4
 
@@ -79,7 +79,7 @@ bug reports and feature requests are mainly coordinated through the
 "LAMMPS project on GitHub."_https://github.com/lammps/lammps
 The lammps.org domain, currently hosting "public continuous integration
 testing"_https://ci.lammps.org/job/lammps/ and "precompiled Linux
-RPM and Windows installer packages"_http://rpm.lammps.org is located
+RPM and Windows installer packages"_http://packages.lammps.org is located
 at Temple University and managed by Richard Berger,
 richard.berger at temple.edu.
 
@@ -158,12 +158,11 @@ END_RST -->
   2.1 "What's in the LAMMPS distribution"_start_1 :ulb,b
   2.2 "Making LAMMPS"_start_2 :b
   2.3 "Making LAMMPS with optional packages"_start_3 :b
-  2.4 "Building LAMMPS via the Make.py script"_start_4 :b
-  2.5 "Building LAMMPS as a library"_start_5 :b
-  2.6 "Running LAMMPS"_start_6 :b
-  2.7 "Command-line options"_start_7 :b
-  2.8 "Screen output"_start_8 :b
-  2.9 "Tips for users of previous versions"_start_9 :ule,b
+  2.4 "Building LAMMPS as a library"_start_4 :b
+  2.5 "Running LAMMPS"_start_5 :b
+  2.6 "Command-line options"_start_6 :b
+  2.7 "Screen output"_start_7 :b
+  2.8 "Tips for users of previous versions"_start_8 :ule,b
 "Commands"_Section_commands.html :l
   3.1 "LAMMPS input script"_cmd_1 :ulb,b
   3.2 "Parsing rules"_cmd_2 :b
@@ -262,7 +261,6 @@ END_RST -->
 :link(start_6,Section_start.html#start_6)
 :link(start_7,Section_start.html#start_7)
 :link(start_8,Section_start.html#start_8)
-:link(start_9,Section_start.html#start_9)
 
 :link(cmd_1,Section_commands.html#cmd_1)
 :link(cmd_2,Section_commands.html#cmd_2)

doc/src/Section_accelerate.txt

@@ -56,7 +56,7 @@ timings; you can simply extrapolate from short runs.
 
 For the set of runs, look at the timing data printed to the screen and
 log file at the end of each LAMMPS run.  "This
-section"_Section_start.html#start_8 of the manual has an overview.
+section"_Section_start.html#start_7 of the manual has an overview.
 
 Running on one (or a few processors) should give a good estimate of
 the serial performance and what portions of the timestep are taking
@@ -226,16 +226,16 @@ re-build LAMMPS |
   make machine |
 prepare and test a regular LAMMPS simulation |
   lmp_machine -in in.script; mpirun -np 32 lmp_machine -in in.script |
-enable specific accelerator support via '-k on' "command-line switch"_Section_start.html#start_7, |
+enable specific accelerator support via '-k on' "command-line switch"_Section_start.html#start_6, |
   only needed for KOKKOS package |
-set any needed options for the package via "-pk" "command-line switch"_Section_start.html#start_7 or "package"_package.html command, |
+set any needed options for the package via "-pk" "command-line switch"_Section_start.html#start_6 or "package"_package.html command, |
   only if defaults need to be changed |
-use accelerated styles in your input via "-sf" "command-line switch"_Section_start.html#start_7 or "suffix"_suffix.html command | lmp_machine -in in.script -sf gpu
+use accelerated styles in your input via "-sf" "command-line switch"_Section_start.html#start_6 or "suffix"_suffix.html command | lmp_machine -in in.script -sf gpu
 :tb(c=2,s=|)
 
-Note that the first 4 steps can be done as a single command, using the
-src/Make.py tool.  This tool is discussed in "Section
-2.4"_Section_start.html#start_4 of the manual, and its use is
+Note that the first 4 steps can be done as a single command with
+suitable make command invocations. This is discussed in "Section
+4"_Section_packages.html of the manual, and its use is
 illustrated in the individual accelerator sections.  Typically these
 steps only need to be done once, to create an executable that uses one
 or more accelerator packages.

doc/src/Section_commands.txt

@@ -527,9 +527,9 @@ These are additional commands in USER packages, which can be used if
 "LAMMPS is built with the appropriate
 package"_Section_start.html#start_3.
 
-"dump custom/vtk"_dump_custom_vtk.html,
-"dump nc"_dump_nc.html,
-"dump nc/mpiio"_dump_nc.html,
+"dump netcdf"_dump_netcdf.html,
+"dump netcdf/mpiio"_dump_netcdf.html,
+"dump vtk"_dump_vtk.html,
 "group2ndx"_group2ndx.html,
 "ndx2group"_group2ndx.html,
 "temper/grem"_temper_grem.html :tb(c=3,ea=c)
@@ -618,6 +618,7 @@ USER-INTEL, k = KOKKOS, o = USER-OMP, t = OPT.
 "press/berendsen"_fix_press_berendsen.html,
 "print"_fix_print.html,
 "property/atom"_fix_property_atom.html,
+"python"_fix_python.html,
 "qeq/comb (o)"_fix_qeq_comb.html,
 "qeq/dynamic"_fix_qeq.html,
 "qeq/fire"_fix_qeq.html,
@@ -716,7 +717,7 @@ package"_Section_start.html#start_3.
 "phonon"_fix_phonon.html,
 "pimd"_fix_pimd.html,
 "qbmsst"_fix_qbmsst.html,
-"qeq/reax"_fix_qeq_reax.html,
+"qeq/reax (ko)"_fix_qeq_reax.html,
 "qmmm"_fix_qmmm.html,
 "qtb"_fix_qtb.html,
 "reax/c/bonds"_fix_reax_bonds.html,
@@ -733,7 +734,9 @@ package"_Section_start.html#start_3.
 "smd/wall/surface"_fix_smd_wall_surface.html,
 "temp/rescale/eff"_fix_temp_rescale_eff.html,
 "ti/spring"_fix_ti_spring.html,
-"ttm/mod"_fix_ttm.html :tb(c=6,ea=c)
+"ttm/mod"_fix_ttm.html,
+"wall/ees"_fix_wall_ees.html,
+"wall/region/ees"_fix_wall_ees.html :tb(c=6,ea=c)
 
 :line
 
@@ -830,6 +833,7 @@ package"_Section_start.html#start_3.
 
 "ackland/atom"_compute_ackland_atom.html,
 "basal/atom"_compute_basal_atom.html,
+"cnp/atom"_compute_cnp_atom.html,
 "dpd"_compute_dpd.html,
 "dpd/atom"_compute_dpd_atom.html,
 "fep"_compute_fep.html,
@@ -888,8 +892,8 @@ KOKKOS, o = USER-OMP, t = OPT.
 "hybrid"_pair_hybrid.html,
 "hybrid/overlay"_pair_hybrid.html,
 "adp (o)"_pair_adp.html,
-"airebo (o)"_pair_airebo.html,
-"airebo/morse (o)"_pair_airebo.html,
+"airebo (oi)"_pair_airebo.html,
+"airebo/morse (oi)"_pair_airebo.html,
 "beck (go)"_pair_beck.html,
 "body"_pair_body.html,
 "bop"_pair_bop.html,
@@ -923,22 +927,24 @@ KOKKOS, o = USER-OMP, t = OPT.
 "dpd/tstat (go)"_pair_dpd.html,
 "dsmc"_pair_dsmc.html,
 "eam (gkiot)"_pair_eam.html,
-"eam/alloy (gkot)"_pair_eam.html,
-"eam/fs (gkot)"_pair_eam.html,
+"eam/alloy (gkiot)"_pair_eam.html,
+"eam/fs (gkiot)"_pair_eam.html,
 "eim (o)"_pair_eim.html,
 "gauss (go)"_pair_gauss.html,
 "gayberne (gio)"_pair_gayberne.html,
 "gran/hertz/history (o)"_pair_gran.html,
 "gran/hooke (o)"_pair_gran.html,
 "gran/hooke/history (o)"_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,
 "kim"_pair_kim.html,
 "lcbop"_pair_lcbop.html,
 "line/lj"_pair_line_lj.html,
-"lj/charmm/coul/charmm (ko)"_pair_charmm.html,
+"lj/charmm/coul/charmm (kio)"_pair_charmm.html,
 "lj/charmm/coul/charmm/implicit (ko)"_pair_charmm.html,
-"lj/charmm/coul/long (giko)"_pair_charmm.html,
+"lj/charmm/coul/long (gkio)"_pair_charmm.html,
 "lj/charmm/coul/msm"_pair_charmm.html,
 "lj/charmmfsw/coul/charmmfsh"_pair_charmm.html,
 "lj/charmmfsw/coul/long"_pair_charmm.html,
@@ -960,7 +966,7 @@ KOKKOS, o = USER-OMP, t = OPT.
 "lj/expand (gko)"_pair_lj_expand.html,
 "lj/gromacs (gko)"_pair_gromacs.html,
 "lj/gromacs/coul/gromacs (ko)"_pair_gromacs.html,
-"lj/long/coul/long (o)"_pair_lj_long.html,
+"lj/long/coul/long (io)"_pair_lj_long.html,
 "lj/long/dipole/long"_pair_dipole.html,
 "lj/long/tip4p/long"_pair_lj_long.html,
 "lj/smooth (o)"_pair_lj_smooth.html,
@@ -982,8 +988,9 @@ KOKKOS, o = USER-OMP, t = OPT.
 "peri/pmb (o)"_pair_peri.html,
 "peri/ves"_pair_peri.html,
 "polymorphic"_pair_polymorphic.html,
+"python"_pair_python.html,
 "reax"_pair_reax.html,
-"rebo (o)"_pair_airebo.html,
+"rebo (oi)"_pair_airebo.html,
 "resquared (go)"_pair_resquared.html,
 "snap"_pair_snap.html,
 "soft (go)"_pair_soft.html,
@@ -1016,6 +1023,7 @@ package"_Section_start.html#start_3.
 "dpd/fdt/energy"_pair_dpd_fdt.html,
 "eam/cd (o)"_pair_eam.html,
 "edip (o)"_pair_edip.html,
+"edip/multi"_pair_edip.html,
 "eff/cut"_pair_eff.html,
 "exp6/rx"_pair_exp6_rx.html,
 "gauss/cut"_pair_gauss.html,
@@ -1033,7 +1041,7 @@ package"_Section_start.html#start_3.
 "lj/sdk (gko)"_pair_sdk.html,
 "lj/sdk/coul/long (go)"_pair_sdk.html,
 "lj/sdk/coul/msm (o)"_pair_sdk.html,
-"lj/sf (o)"_pair_lj_sf.html,
+"meam/c"_pair_meam.html,
 "meam/spline (o)"_pair_meam_spline.html,
 "meam/sw/spline"_pair_meam_sw_spline.html,
 "mgpt"_pair_mgpt.html,
@@ -1047,8 +1055,12 @@ package"_Section_start.html#start_3.
 "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/stk"_pair_oxdna2.html,
 "quip"_pair_quip.html,
-"reax/c (k)"_pair_reax_c.html,
+"reax/c (ko)"_pair_reaxc.html,
 "smd/hertz"_pair_smd_hertz.html,
 "smd/tlsph"_pair_smd_tlsph.html,
 "smd/triangulated/surface"_pair_smd_triangulated_surface.html,
@@ -1064,7 +1076,7 @@ package"_Section_start.html#start_3.
 "table/rx"_pair_table_rx.html,
 "tersoff/table (o)"_pair_tersoff.html,
 "thole"_pair_thole.html,
-"tip4p/long/soft (o)"_pair_lj_soft.html :tb(c=4,ea=c) 
+"tip4p/long/soft (o)"_pair_lj_soft.html :tb(c=4,ea=c)
 
 :line
 
@@ -1096,7 +1108,8 @@ package"_Section_start.html#start_3.
 
 "harmonic/shift (o)"_bond_harmonic_shift.html,
 "harmonic/shift/cut (o)"_bond_harmonic_shift_cut.html,
-"oxdna/fene"_bond_oxdna.html :tb(c=4,ea=c)
+"oxdna/fene"_bond_oxdna.html,
+"oxdna2/fene"_bond_oxdna.html :tb(c=4,ea=c)
 
 :line
 
@@ -1150,7 +1163,7 @@ USER-OMP, t = OPT.
 "zero"_dihedral_zero.html,
 "hybrid"_dihedral_hybrid.html,
 "charmm (ko)"_dihedral_charmm.html,
-"charmmfsh"_dihedral_charmm.html,
+"charmmfsw"_dihedral_charmm.html,
 "class2 (ko)"_dihedral_class2.html,
 "harmonic (io)"_dihedral_harmonic.html,
 "helix (o)"_dihedral_helix.html,
@@ -1215,7 +1228,7 @@ USER-OMP, t = OPT.
 "msm/cg (o)"_kspace_style.html,
 "pppm (go)"_kspace_style.html,
 "pppm/cg (o)"_kspace_style.html,
-"pppm/disp"_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 :tb(c=4,ea=c)

doc/src/Section_errors.txt

@@ -71,7 +71,7 @@ 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_7.  The installation
+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.
 
@@ -4696,9 +4696,9 @@ Self-explanatory. :dd
 
 {Fix bond/create induced too many angles/dihedrals/impropers per atom} :dt
 
-See the read_data command for info on setting the "extra angle per
-atom", etc header values to allow for additional angles, etc to be
-formed. :dd
+See the read_data command for info on using the "extra/angle/per/atom",
+(or dihedral, improper) keywords to allow for additional
+angles, dihedrals, and impropers to be formed. :dd
 
 {Fix bond/create needs ghost atoms from further away} :dt
 
@@ -7876,18 +7876,20 @@ See the setting for tagint in the src/lmptype.h file. :dd
 
 {New bond exceeded bonds per atom in create_bonds} :dt
 
-See the read_data command for info on setting the "extra bond per
-atom" header value to allow for additional bonds to be formed. :dd
+See the read_data command for info on using the "extra/bond/per/atom"
+keyword to allow for additional bonds to be formed
 
 {New bond exceeded bonds per atom in fix bond/create} :dt
 
-See the read_data command for info on setting the "extra bond per
-atom" header value to allow for additional bonds to be formed. :dd
+See the read_data command for info on using the "extra/bond/per/atom"
+keyword to allow for additional bonds to be formed :dd
 
 {New bond exceeded special list size in fix bond/create} :dt
 
-See the special_bonds extra command for info on how to leave space in
-the special bonds list to allow for additional bonds to be formed. :dd
+See the "read_data extra/special/per/atom" command
+(or the "create_box extra/special/per/atom" command)
+for info on how to leave space in the special bonds
+list to allow for additional bonds to be formed. :dd
 
 {Newton bond change after simulation box is defined} :dt
 
@@ -8890,6 +8892,14 @@ This is a requirement to use this potential. :dd
 
 See the newton command.  This is a restriction to use this potential. :dd
 
+{Pair style vashishta/gpu requires atom IDs} :dt
+
+This is a requirement to use this potential. :dd
+
+{Pair style vashishta/gpu requires newton pair off} :dt
+
+See the newton command.  This is a restriction to use this potential. :dd
+
 {Pair style tersoff/gpu requires atom IDs} :dt
 
 This is a requirement to use the tersoff/gpu potential. :dd
@@ -9656,9 +9666,10 @@ you are running. :dd
 
 {Special list size exceeded in fix bond/create} :dt
 
-See the read_data command for info on setting the "extra special per
-atom" header value to allow for additional special values to be
-stored. :dd
+See the "read_data extra/special/per/atom" command
+(or the "create_box extra/special/per/atom" command)
+for info on how to leave space in the special bonds
+list to allow for additional bonds to be formed. :dd
 
 {Specified processors != physical processors} :dt
 
@@ -9675,23 +9686,23 @@ Self-explanatory. :dd
 
 {Subsequent read data induced too many angles per atom} :dt
 
-See the create_box extra/angle/per/atom or read_data "extra angle per
-atom" header value to set this limit larger. :dd
+See the extra/angle/per/atom keyword for the create_box
+or the read_data command to set this limit larger :dd
 
 {Subsequent read data induced too many bonds per atom} :dt
 
-See the create_box extra/bond/per/atom or read_data "extra bond per
-atom" header value to set this limit larger. :dd
+See the extra/bond/per/atom keyword for the create_box
+or the read_data command to set this limit larger :dd
 
 {Subsequent read data induced too many dihedrals per atom} :dt
 
-See the create_box extra/dihedral/per/atom or read_data "extra
-dihedral per atom" header value to set this limit larger. :dd
+See the extra/dihedral/per/atom keyword for the create_box
+or the read_data command to set this limit larger :dd
 
 {Subsequent read data induced too many impropers per atom} :dt
 
-See the create_box extra/improper/per/atom or read_data "extra
-improper per atom" header value to set this limit larger. :dd
+See the extra/improper/per/atom keyword for the create_box
+or the read_data command to set this limit larger :dd
 
 {Substitution for illegal variable} :dt
 
@@ -11171,6 +11182,12 @@ Self-explanatory. :dd
 If the fix changes the timestep, the dump dcd file will not
 reflect the change. :dd
 
+{Energy due to X extra global DOFs will be included in minimizer energies} :dt
+
+When using fixes like box/relax, the potential energy used by the minimizer
+is augmented by an additional energy provided by the fix. Thus the printed
+converged energy may be different from the total potential energy. :dd
+
 {Energy tally does not account for 'zero yes'} :dt
 
 The energy removed by using the 'zero yes' flag is not accounted

doc/src/Section_example.txt

@@ -49,6 +49,7 @@ Lists of both kinds of directories are given below.
 Lowercase directories :h4
 
 accelerate: run with various acceleration options (OpenMP, GPU, Phi)
+airebo:   polyethylene with AIREBO potential
 balance:  dynamic load balancing, 2d system
 body:     body particles, 2d system
 cmap:     CMAP 5-body contributions to CHARMM force field

doc/src/Section_howto.txt

@@ -54,7 +54,7 @@ restart files can be saved to disk using the "restart"_restart.html
 command.  At a later time, these binary files can be read via a
 "read_restart"_read_restart.html command in a new script.  Or they can
 be converted to text data files using the "-r command-line
-switch"_Section_start.html#start_7 and read by a
+switch"_Section_start.html#start_6 and read by a
 "read_data"_read_data.html command in a new script.
 
 Here we give examples of 2 scripts that read either a binary restart
@@ -215,7 +215,7 @@ documentation for the formula it computes.
 "special_bonds"_special_bonds.html charmm
 "special_bonds"_special_bonds.html amber :ul
 
-NOTE: For CHARMM, the newer {charmmfsw} or {charmmfsh} styles were
+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
@@ -337,7 +337,7 @@ All of the above examples work whether you are running on 1 or
 multiple processors, but assumed you are running LAMMPS on a single
 partition of processors.  LAMMPS can be run on multiple partitions via
 the "-partition" command-line switch as described in "this
-section"_Section_start.html#start_7 of the manual.
+section"_Section_start.html#start_6 of the manual.
 
 In the last 2 examples, if LAMMPS were run on 3 partitions, the same
 scripts could be used if the "index" and "loop" variables were
@@ -387,7 +387,7 @@ for more info on packages.
 In all these cases, you must run with one or more processors per
 replica.  The processors assigned to each replica are determined at
 run-time by using the "-partition command-line
-switch"_Section_start.html#start_7 to launch LAMMPS on multiple
+switch"_Section_start.html#start_6 to launch LAMMPS on multiple
 partitions, which in this context are the same as replicas.  E.g.
 these commands:
 
@@ -395,7 +395,7 @@ mpirun -np 16 lmp_linux -partition 8x2 -in in.temper
 mpirun -np 8 lmp_linux -partition 8x1 -in in.neb :pre
 
 would each run 8 replicas, on either 16 or 8 processors.  Note the use
-of the "-in command-line switch"_Section_start.html#start_7 to specify
+of the "-in command-line switch"_Section_start.html#start_6 to specify
 the input script which is required when running in multi-replica mode.
 
 Also note that with MPI installed on a machine (e.g. your desktop),
@@ -759,23 +759,14 @@ LAMMPS itself does not do visualization, but snapshots from LAMMPS
 simulations can be visualized (and analyzed) in a variety of ways.
 
 LAMMPS snapshots are created by the "dump"_dump.html command which can
-create files in several formats.  The native LAMMPS dump format is a
+create files in several formats. The native LAMMPS dump format is a
 text file (see "dump atom" or "dump custom") which can be visualized
-by the "xmovie"_Section_tools.html#xmovie program, included with the
-LAMMPS package.  This produces simple, fast 2d projections of 3d
-systems, and can be useful for rapid debugging of simulation geometry
-and atom trajectories.
-
+by several popular visualization tools. The "dump image"_dump_image.html
+and "dump movie"_dump_image.html styles can output internally rendered
+images and convert a sequence of them to a movie during the MD run.
 Several programs included with LAMMPS as auxiliary tools can convert
-native LAMMPS dump files to other formats.  See the
-"Section 9"_Section_tools.html doc page for details.  The first is
-the "ch2lmp tool"_Section_tools.html#charmm, which contains a
-lammps2pdb Perl script which converts LAMMPS dump files into PDB
-files.  The second is the "lmp2arc tool"_Section_tools.html#arc which
-converts LAMMPS dump files into Accelrys' Insight MD program files.
-The third is the "lmp2cfg tool"_Section_tools.html#cfg which converts
-LAMMPS dump files into CFG files which can be read into the
-"AtomEye"_atomeye visualizer.
+between LAMMPS format files and other formats.
+See the "Section 9"_Section_tools.html doc page for details.
 
 A Python-based toolkit distributed by our group can read native LAMMPS
 dump files, including custom dump files with additional columns of
@@ -788,22 +779,7 @@ RasMol visualization programs.  Pizza.py has tools that do interactive
 3d OpenGL visualization and one that creates SVG images of dump file
 snapshots.
 
-LAMMPS can create XYZ files directly (via "dump xyz") which is a
-simple text-based file format used by many visualization programs
-including "VMD"_vmd.
-
-LAMMPS can create DCD files directly (via "dump dcd") which can be
-read by "VMD"_vmd in conjunction with a CHARMM PSF file.  Using this
-form of output avoids the need to convert LAMMPS snapshots to PDB
-files.  See the "dump"_dump.html command for more information on DCD
-files.
-
-LAMMPS can create XTC files directly (via "dump xtc") which is GROMACS
-file format which can also be read by "VMD"_vmd for visualization.
-See the "dump"_dump.html command for more information on XTC files.
-
 :link(pizza,http://www.sandia.gov/~sjplimp/pizza.html)
-:link(vmd,http://www.ks.uiuc.edu/Research/vmd)
 :link(ensight,http://www.ensight.com)
 :link(atomeye,http://mt.seas.upenn.edu/Archive/Graphics/A)
 
@@ -1710,7 +1686,7 @@ nph) and Berendsen:
 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/bernendsen"_fix_press_berendsen.html can be used in conjunction
+press/berendsen"_fix_press_berendsen.html can be used in conjunction
 with any of the thermostatting fixes.
 
 As with the thermostats, "fix npt"_fix_nh.html and "fix
@@ -1896,7 +1872,7 @@ void lammps_free(void *) :pre
 
 The lammps_open() function is used to initialize LAMMPS, passing in a
 list of strings as if they were "command-line
-arguments"_Section_start.html#start_7 when LAMMPS is run in
+arguments"_Section_start.html#start_6 when LAMMPS is run in
 stand-alone mode from the command line, and a MPI communicator for
 LAMMPS to run under.  It returns a ptr to the LAMMPS object that is
 created, and which is used in subsequent library calls.  The
@@ -1962,7 +1938,7 @@ documentation in the src/library.cpp file for details, including
 which quantities can be queried by name:
 
 void *lammps_extract_global(void *, char *)
-void lammps_extract_box(void *, double *, double *, 
+void lammps_extract_box(void *, double *, double *,
                         double *, double *, double *, int *, int *)
 void *lammps_extract_atom(void *, char *)
 void *lammps_extract_compute(void *, char *, int, int)
@@ -2013,6 +1989,11 @@ Both methods are thus a means to extract or assign (overwrite) any
 peratom quantities within LAMMPS.  See the extract() method in the
 src/atom.cpp file for a list of valid per-atom properties.  New names
 could easily be added if the property you want is not listed.
+A special treatment is applied for accessing image flags via the
+"image" property. Image flags are stored in a packed format with all
+three image flags stored in a single integer. When signaling to access
+the image flags as 3 individual values per atom instead of 1, the data
+is transparently packed or unpacked by the library interface.
 
 The lammps_create_atoms() function takes a list of N atoms as input
 with atom types and coords (required), an optionally atom IDs and
@@ -2701,14 +2682,14 @@ 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 
+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. 
+internal kinetic energy during the simulation.
 Thermostats can alter this polarization behaviour, 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 
+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
@@ -2740,13 +2721,13 @@ fix thermostatequ all nve                               # integrator as needed f
 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 compute based on the 
-default "temperature"_compute_temp and specifying it as a second 
-argument in "fix modify"_fix_modify.html and 
+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 compute based on the
+default "temperature"_compute_temp and specifying it as a second
+argument in "fix modify"_fix_modify.html and
 "thermo_modify"_thermo_modify.html resulting in:
 
 (...)
@@ -2776,18 +2757,18 @@ temp/cs"_compute_temp_cs.html command to the {temp} keyword of the
 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 
+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. 
+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
@@ -2809,7 +2790,7 @@ pairs as chunks.
 
 For example if core/shell pairs are the only molecules:
 
-read_data NaCl_CS_x0.1_prop.data 
+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

doc/src/Section_intro.txt

@@ -249,8 +249,12 @@ Pizza.py WWW site"_pizza. :l
 
 Specialized features :h5
 
-These are LAMMPS capabilities which you may not think of as typical
-molecular dynamics options:
+LAMMPS can be built with optional packages which implement a variety
+of additional capabilities.  An overview of all the packages is "given
+here"_Section_packages.html.
+
+These are some LAMMPS capabilities which you may not think of as
+typical classical molecular dynamics options:
 
 "static"_balance.html and "dynamic load-balancing"_fix_balance.html
 "generalized aspherical particles"_body.html
@@ -338,15 +342,13 @@ dynamics timestepping, particularly if the computations are not
 parallel, so it is often better to leave such analysis to
 post-processing codes.
 
-A very simple (yet fast) visualizer is provided with the LAMMPS
-package - see the "xmovie"_Section_tools.html#xmovie tool in "this
-section"_Section_tools.html.  It creates xyz projection views of
-atomic coordinates and animates them.  We find it very useful for
-debugging purposes.  For high-quality visualization we recommend the
+For high-quality visualization we recommend the
 following packages:
 
 "VMD"_http://www.ks.uiuc.edu/Research/vmd
 "AtomEye"_http://mt.seas.upenn.edu/Archive/Graphics/A
+"OVITO"_http://www.ovito.org/
+"ParaView"_http://www.paraview.org/
 "PyMol"_http://www.pymol.org
 "Raster3d"_http://www.bmsc.washington.edu/raster3d/raster3d.html
 "RasMol"_http://www.openrasmol.org :ul
@@ -517,7 +519,7 @@ the packages they have written are somewhat unique to LAMMPS and the
 code would not be as general-purpose as it is without their expertise
 and efforts.
 
-Axel Kohlmeyer (Temple U), akohlmey at gmail.com, SVN and Git repositories, indefatigable mail list responder, USER-CG-CMM and USER-OMP packages
+Axel Kohlmeyer (Temple U), akohlmey at gmail.com, SVN and Git repositories, indefatigable mail list responder, USER-CGSDK and USER-OMP packages
 Roy Pollock (LLNL), Ewald and PPPM solvers
 Mike Brown (ORNL), brownw at ornl.gov, GPU package
 Greg Wagner (Sandia), gjwagne at sandia.gov, MEAM package for MEAM potential

doc/src/Section_python.txt

@@ -118,18 +118,21 @@ check which version of Python you have installed, by simply typing
 
 11.2 Overview of using Python from a LAMMPS script :link(py_2),h4
 
-NOTE: It is not currently possible to use the "python"_python.html
-command described in this section with Python 3, only with Python 2.
-The C API changed from Python 2 to 3 and the LAMMPS code is not
-compatible with both.
+LAMMPS has several commands which can be used to invoke Python
+code directly from an input script:
 
-LAMMPS has a "python"_python.html command which can be used in an
-input script to define and execute a Python function that you write
-the code for.  The Python function can also be assigned to a LAMMPS
-python-style variable via the "variable"_variable.html command.  Each
-time the variable is evaluated, either in the LAMMPS input script
-itself, or by another LAMMPS command that uses the variable, this will
-trigger the Python function to be invoked.
+"python"_python.html
+"variable python"_variable.html
+"fix python"_fix_python.html
+"pair_style python"_pair_python.html :ul
+
+The "python"_python.html command which can be used to define and
+execute a Python function that you write the code for.  The Python
+function can also be assigned to a LAMMPS python-style variable via
+the "variable"_variable.html command.  Each time the variable is
+evaluated, either in the LAMMPS input script itself, or by another
+LAMMPS command that uses the variable, this will trigger the Python
+function to be invoked.
 
 The Python code for the function can be included directly in the input
 script or in an auxiliary file.  The function can have arguments which
@@ -162,8 +165,16 @@ doc page for its python-style variables for more info, including
 examples of Python code you can write for both pure Python operations
 and callbacks to LAMMPS.
 
-To run pure Python code from LAMMPS, you only need to build LAMMPS
-with the PYTHON package installed:
+The "fix python"_fix_python.html command can execute
+Python code at selected timesteps during a simulation run.
+
+The "pair_style python"_pair_python command allows you to define
+pairwise potentials as python code which encodes a single pairwise
+interaction.  This is useful for rapid-developement and debugging of a
+new potential.
+
+To use any of these commands, you only need to build LAMMPS with the
+PYTHON package installed:
 
 make yes-python
 make machine :pre
@@ -187,7 +198,7 @@ file and the shared library.
 11.3 Building LAMMPS as a shared library :link(py_3),h4
 
 Instructions on how to build LAMMPS as a shared library are given in
-"Section 2.5"_Section_start.html#start_5.  A shared library is one
+"Section 2.4"_Section_start.html#start_4.  A shared library is one
 that is dynamically loadable, which is what Python requires to wrap
 LAMMPS.  On Linux this is a library file that ends in ".so", not ".a".
 
@@ -206,7 +217,7 @@ NOTE: If you are building LAMMPS with an MPI or FFT library or other
 auxiliary libraries (used by various packages), then all of these
 extra libraries must also be shared libraries.  If the LAMMPS
 shared-library build fails with an error complaining about this, see
-"Section 2.5"_Section_start.html#start_5 for more details.
+"Section 2.4"_Section_start.html#start_4 for more details.
 
 :line
 
@@ -428,7 +439,7 @@ first importing from the lammps.py file:
 >>> CDLL("liblammps.so") :pre
 
 If an error occurs, carefully go thru the steps in "Section
-2.5"_Section_start.html#start_5 and above about building a shared
+2.4"_Section_start.html#start_4 and above about building a shared
 library and about insuring Python can find the necessary two files
 it needs.
 
@@ -698,7 +709,12 @@ method in the src/atom.cpp file for a list of valid names.  Again, new
 names could easily be added if the property you want is missing.  The
 vector can be used via normal Python subscripting.  If atom IDs are
 not consecutively ordered within LAMMPS, a None is returned as
-indication of an error.
+indication of an error. A special treatment is applied for image flags
+stored in the "image" property. All three image flags are stored in
+a packed format in a single integer, so count would be 1 to retrieve
+that integer, however also a count value of 3 can be used and then
+the image flags will be unpacked into 3 individual integers, ordered
+in a similar fashion as coordinates.
 
 Note that the data structure gather_atoms("x") returns is different
 from the data structure returned by extract_atom("x") in four ways.
@@ -727,6 +743,10 @@ corresponding properties for each atom inside LAMMPS.  This requires
 LAMMPS to have its "map" option enabled; see the
 "atom_modify"_atom_modify.html command for details.  If it is not, or
 if atom IDs are not consecutively ordered, no coordinates are reset.
+Similar as for gather_atoms() a special treatment is applied for image
+flags, which can be provided in packed (count = 1) or unpacked (count = 3)
+format and in the latter case, they will be packed before applied to
+atoms.
 
 The array of coordinates passed to scatter_atoms() must be a ctypes
 vector of ints or doubles, allocated and initialized something like

doc/src/Section_start.txt

@@ -14,12 +14,11 @@ experienced users.
 2.1 "What's in the LAMMPS distribution"_#start_1
 2.2 "Making LAMMPS"_#start_2
 2.3 "Making LAMMPS with optional packages"_#start_3
-2.4 "Building LAMMPS via the Make.py script"_#start_4
-2.5 "Building LAMMPS as a library"_#start_5
-2.6 "Running LAMMPS"_#start_6
-2.7 "Command-line options"_#start_7
-2.8 "Screen output"_#start_8
-2.9 "Tips for users of previous versions"_#start_9 :all(b)
+2.4 "Building LAMMPS as a library"_#start_4
+2.5 "Running LAMMPS"_#start_5
+2.6 "Command-line options"_#start_6
+2.7 "Screen output"_#start_7
+2.8 "Tips for users of previous versions"_#start_8 :all(b)
 
 :line
 
@@ -80,7 +79,7 @@ This section has the following sub-sections:
 
 Read this first :h5,link(start_2_1)
 
-If you want to avoid building LAMMPS yourself, read the preceding
+If you want to avoid building LAMMPS yourself, read the preceeding
 section about options available for downloading and installing
 executables.  Details are discussed on the "download"_download page.
 
@@ -96,7 +95,7 @@ make serial :pre
 Note that on a facility supercomputer, there are often "modules"
 loaded in your environment that provide the compilers and MPI you
 should use.  In this case, the "mpicxx" compile/link command in
-Makefile.mpi should just work by accessing those modules.
+Makefile.mpi should simply work by accessing those modules.
 
 It may be the case that one of the other Makefile.machine files in the
 src/MAKE sub-directories is a better match to your system (type "make"
@@ -107,33 +106,35 @@ make stampede :pre
 If any of these builds (with an existing Makefile.machine) works on
 your system, then you're done!
 
+If you need to install an optional package with a LAMMPS command you
+want to use, and the package does not depend on an extra library, you
+can simply type
+
+make name :pre
+
+before invoking (or re-invoking) the above steps.  "Name" is the
+lower-case name of the package, e.g. replica or user-misc.
+
 If you want to do one of the following:
 
-use optional LAMMPS features that require additional libraries
-use optional packages that require additional libraries
-use optional accelerator packages that require special compiler/linker settings
-run on a specialized platform that has its own compilers, settings, or other libs to use :ul
+use a LAMMPS command that requires an extra library (e.g. "dump image"_dump_image.html)
+build with a package that requires an extra library
+build with an accelerator package that requires special compiler/linker settings
+run on a machine that has its own compilers, settings, or libraries :ul
 
 then building LAMMPS is more complicated.  You may need to find where
-auxiliary libraries exist on your machine or install them if they
-don't.  You may need to build additional libraries that are part of
-the LAMMPS package, before building LAMMPS.  You may need to edit a
+extra libraries exist on your machine or install them if they don't.
+You may need to build extra libraries that are included in the LAMMPS
+distribution, before building LAMMPS itself.  You may need to edit a
 Makefile.machine file to make it compatible with your system.
 
-Note that there is a Make.py tool in the src directory that automates
-several of these steps, but you still have to know what you are doing.
-"Section 2.4"_#start_4 below describes the tool.  It is a convenient
-way to work with installing/un-installing various packages, the
-Makefile.machine changes required by some packages, and the auxiliary
-libraries some of them use.
-
 Please read the following sections carefully.  If you are not
 comfortable with makefiles, or building codes on a Unix platform, or
 running an MPI job on your machine, please find a local expert to help
-you.  Many compilation, linking, and run problems that users have are
-often not really LAMMPS issues - they are peculiar to the user's
-system, compilers, libraries, etc.  Such questions are better answered
-by a local expert.
+you.  Many compilation, linking, and run problems users experience are
+often not LAMMPS issues - they are peculiar to the user's system,
+compilers, libraries, etc.  Such questions are better answered by a
+local expert.
 
 If you have a build problem that you are convinced is a LAMMPS issue
 (e.g. the compiler complains about a line of LAMMPS source code), then
@@ -251,7 +252,7 @@ re-compile, after typing "make clean" (which will describe different
 clean options).
 
 The LMP_INC variable is used to include options that turn on ifdefs
-within the LAMMPS code.  The options that are currently recognized are:
+within the LAMMPS code.  The options that are currently recogized are:
 
 -DLAMMPS_GZIP
 -DLAMMPS_JPEG
@@ -362,7 +363,7 @@ installed on your platform.  If MPI is installed on your system in the
 usual place (under /usr/local), you also may not need to specify these
 3 variables, assuming /usr/local is in your path.  On some large
 parallel machines which use "modules" for their compile/link
-environments, you may simply need to include the correct module in
+environements, you may simply need to include the correct module in
 your build environment, before building LAMMPS.  Or the parallel
 machine may have a vendor-provided MPI which the compiler has no
 trouble finding.
@@ -430,27 +431,46 @@ use the KISS library described above.
 You may also need to set the FFT_INC, FFT_PATH, and FFT_LIB variables,
 so the compiler and linker can find the needed FFT header and library
 files.  Note that on some large parallel machines which use "modules"
-for their compile/link environments, you may simply need to include
+for their compile/link environements, you may simply need to include
 the correct module in your build environment.  Or the parallel machine
 may have a vendor-provided FFT library which the compiler has no
-trouble finding.
+trouble finding.  See the src/MAKE/OPTIONS/Makefile.fftw file for an
+example of how to specify these variables to use the FFTW3 library.
 
-FFTW is a fast, portable library that should also work on any
-platform.  You can download it from
+FFTW is fast, portable library that should also work on any platform
+and typically be faster than KISS FFT.  You can download it from
 "www.fftw.org"_http://www.fftw.org.  Both the legacy version 2.1.X and
 the newer 3.X versions are supported as -DFFT_FFTW2 or -DFFT_FFTW3.
-Building FFTW for your box should be as simple as ./configure; make.
-Note that on some platforms FFTW2 has been pre-installed, and uses
-renamed files indicating the precision it was compiled with,
-e.g. sfftw.h, or dfftw.h instead of fftw.h.  In this case, you can
-specify an additional define variable for FFT_INC called -DFFTW_SIZE,
-which will select the correct include file.  In this case, for FFT_LIB
-you must also manually specify the correct library, namely -lsfftw or
--ldfftw.
+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.
+
+If you wish to have FFTW support for single-precision FFTs (see below
+about -DFFT_SINGLE) in addition to the default double-precision FFTs,
+you will need to build FFTW a second time for single-precision.  For
+FFTW3, do this via:
+
+make clean
+./configure --enable-single; make; make install :pre
+
+which should produce the additional library libfftw3f.a.
+
+For FFTW2, do this:
+
+make clean
+./configure --enable-float --enable-type-prefix; make; make install :pre
+
+which should produce the additional library libsfftw.a and additional
+include file sfttw.a.  Note that on some platforms FFTW2 has been
+pre-installed for both single- and double-precision, and may already
+have these files as well as libdfftw.a and dfftw.h for double
+precision.
 
 The FFT_INC variable also allows for a -DFFT_SINGLE setting that will
 use single-precision FFTs with PPPM, which can speed-up long-range
-calculations, particularly in parallel or on GPUs.  Fourier transform
+calulations, particularly in parallel or on GPUs.  Fourier transform
 and related PPPM operations are somewhat insensitive to floating point
 truncation errors and thus do not always need to be performed in
 double precision.  Using the -DFFT_SINGLE setting trades off a little
@@ -458,6 +478,16 @@ accuracy for reduced memory use and parallel communication costs for
 transposing 3d FFT data.  Note that single precision FFTs have only
 been tested with the FFTW3, FFTW2, MKL, and KISS FFT options.
 
+When using -DFFT_SINGLE with FFTW3 or FFTW2, you need to build FFTW
+with support for single-precision, as explained above.  For FFTW3 you
+also need to include -lfftw3f with the FFT_LIB setting, in addition to
+-lfftw3.  For FFTW2, you also need to specify -DFFT_SIZE with the
+FFT_INC setting and -lsfftw with the FFT_LIB setting (in place of
+-lfftw).  Similarly, if FFTW2 has been preinstalled with an explicit
+double-precision library (libdfftw.a and not the default libfftw.a),
+then you can specify -DFFT_SIZE (and not -DFFT_SINGLE), and specify
+-ldfftw to use double-precision FFTs.
+
 Step 7 :h6
 
 The 3 JPG variables allow you to specify a JPEG and/or PNG library
@@ -508,13 +538,13 @@ You should get the executable lmp_foo when the build is complete.
 
 Errors that can occur when making LAMMPS: h5 :link(start_2_3)
 
-NOTE: If an error occurs when building LAMMPS, the compiler or linker
-will state very explicitly what the problem is.  The error message
-should give you a hint as to which of the steps above has failed, and
-what you need to do in order to fix it.  Building a code with a
-Makefile is a very logical process.  The compiler and linker need to
-find the appropriate files and those files need to be compatible with
-LAMMPS source files.  When a make fails, there is usually a very
+If an error occurs when building LAMMPS, the compiler or linker will
+state very explicitly what the problem is.  The error message should
+give you a hint as to which of the steps above has failed, and what
+you need to do in order to fix it.  Building a code with a Makefile is
+a very logical process.  The compiler and linker need to find the
+appropriate files and those files need to be compatible with LAMMPS
+settings and source files.  When a make fails, there is usually a very
 simple reason, which you or a local expert will need to fix.
 
 Here are two non-obvious errors that can occur:
@@ -628,22 +658,29 @@ utilities.
 For Cygwin and the MinGW cross-compilers, suitable makefiles are
 provided in src/MAKE/MACHINES. When using other compilers, like
 Visual C++ or Intel compilers for Windows, you may have to implement
-your own build system. Since none of the current LAMMPS core developers
-has significant experience building executables on Windows, we are
-happy to distribute contributed instructions and modifications, but
-we cannot provide support for those.
+your own build system. Due to differences between the Windows OS
+and Windows system libraries to Unix-like environments like Linux
+or MacOS, when compiling for Windows a few adjustments may be needed:
+
+Do [not] set the -DLAMMPS_MEMALIGN define (see LMP_INC makefile variable)
+Add -lwsock32 -lpsapi to the linker flags (see LIB makefile variable)
+Try adding -static-libgcc or -static or both to the linker flags when your LAMMPS executable complains about missing .dll files  :ul
+
+Since none of the current LAMMPS core developers has significant
+experience building executables on Windows, we are happy to distribute
+contributed instructions and modifications to improve the situation,
+but we cannot provide support for those.
 
 With the so-called "Anniversary Update" to Windows 10, there is a
 Ubuntu Linux subsystem available for Windows, that can be installed
 and then used to compile/install LAMMPS as if you are running on a
 Ubuntu Linux system instead of Windows.
 
-As an alternative, you can download "daily builds" (and some older
-versions) of the installer packages from
-"rpm.lammps.org/windows.html"_http://rpm.lammps.org/windows.html.
-These executables are built with most optional packages and the
-download includes documentation, potential files, some tools and
-many examples, but no source code.
+As an alternative, you can download pre-compiled installer packages from
+"packages.lammps.org/windows.html"_http://packages.lammps.org/windows.html.
+These executables are built with most optional packages included and the
+download includes documentation, potential files, some tools and many
+examples, but no source code.
 
 :line
 
@@ -653,13 +690,7 @@ This section has the following sub-sections:
 
 2.3.1 "Package basics"_#start_3_1
 2.3.2 "Including/excluding packages"_#start_3_2
-2.3.3 "Packages that require extra libraries"_#start_3_3
-2.3.4 "Packages that require Makefile.machine settings"_#start_3_4 :all(b)
-
-Note that the following "Section 2.4"_#start_4 describes the Make.py
-tool which can be used to install/un-install packages and build the
-auxiliary libraries which some of them use.  It can also auto-edit a
-Makefile.machine to add settings needed by some packages.
+2.3.3 "Packages that require extra libraries"_#start_3_3 :all(b)
 
 :line
 
@@ -670,235 +701,221 @@ are always included, plus optional packages.  Packages are groups of
 files that enable a specific set of features.  For example, force
 fields for molecular systems or granular systems are in packages.
 
-"Section 4"_Section_packages.html in the manual has details
-about all the packages, including specific instructions for building
-LAMMPS with each package, which are covered in a more general manner
+"Section 4"_Section_packages.html in the manual has details about all
+the packages, which come in two flavors: [standard] and [user]
+packages. It also has specific instructions for building LAMMPS with
+any package which requires an extra library.  General instructions are
 below.
 
 You can see the list of all packages by typing "make package" from
-within the src directory of the LAMMPS distribution.  This also lists
-various make commands that can be used to manipulate packages.
+within the src directory of the LAMMPS distribution.  It will also
+list various make commands that can be used to manage packages.
 
 If you use a command in a LAMMPS input script that is part of a
 package, you must have built LAMMPS with that package, else you will
 get an error that the style is invalid or the command is unknown.
-Every command's doc page specifies if it is part of a package.  You can
-also type
+Every command's doc page specfies if it is part of a package.  You can
+type
 
 lmp_machine -h :pre
 
 to run your executable with the optional "-h command-line
-switch"_#start_7 for "help", which will simply list the styles and
-commands known to your executable, and immediately exit.
-
-There are two kinds of packages in LAMMPS, standard and user packages.
-More information about the contents of standard and user packages is
-given in "Section 4"_Section_packages.html of the manual.  The
-difference between standard and user packages is as follows:
-
-Standard packages, such as molecule or kspace, are supported by the
-LAMMPS developers and are written in a syntax and style consistent
-with the rest of LAMMPS.  This means we will answer questions about
-them, debug and fix them if necessary, and keep them compatible with
-future changes to LAMMPS.
-
-User packages, such as user-atc or user-omp, have been contributed by
-users, and always begin with the user prefix.  If they are a single
-command (single file), they are typically in the user-misc package.
-Otherwise, they are a set of files grouped together which add a
-specific functionality to the code.
-
-User packages don't necessarily meet the requirements of the standard
-packages.  If you have problems using a feature provided in a user
-package, you may need to contact the contributor directly to get help.
-Information on how to submit additions you make to LAMMPS as single
-files or either a standard or user-contributed package are given in
-"this section"_Section_modify.html#mod_15 of the documentation.
+switch"_#start_6 for "help", which will list the styles and commands
+known to your executable, and immediately exit.
 
 :line
 
 Including/excluding packages :h5,link(start_3_2)
 
-To use (or not use) a package you must include it (or exclude it)
-before building LAMMPS.  From the src directory, this is typically as
-simple as:
+To use (or not use) a package you must install it (or un-install it)
+before building LAMMPS.  From the src directory, this is as simple as:
 
 make yes-colloid
 make mpi :pre
 
 or
 
-make no-manybody
+make no-user-omp
 make mpi :pre
 
-NOTE: You should NOT include/exclude packages and build LAMMPS in a
+NOTE: You should NOT install/un-install packages and build LAMMPS in a
 single make command using 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.
 
-Some packages have individual files that depend on other packages
-being included.  LAMMPS checks for this and does the right thing.
-I.e. individual files are only included if their dependencies are
-already included.  Likewise, if a package is excluded, other files
+Any package can be installed or not 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.  I.e. 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.
 
+NOTE: The one exception is that we do not recommend building with both
+the KOKKOS package installed and any of the other acceleration
+packages (GPU, OPT, USER-INTEL, USER-OMP) also installed.  This is
+because of how Kokkos sometimes builds using a wrapper compiler which
+can make it difficult to invoke all the compile/link flags correctly
+for both Kokkos and non-Kokkos files.
+
 If you will never run simulations that use the features in a
 particular packages, there is no reason to include it in your build.
-For some packages, this will keep you from having to build auxiliary
-libraries (see below), and will also produce a smaller executable
-which may run a bit faster.
+For some packages, this will keep you from having to build extra
+libraries, and will also produce a smaller executable which may run a
+bit faster.
 
-When you download a LAMMPS tarball, these packages are pre-installed
-in the src directory: KSPACE, MANYBODY,MOLECULE, because they are so
-commonly used.  When you download LAMMPS source files from the SVN or
-Git repositories, no packages are pre-installed.
+When you download a LAMMPS tarball, three packages are pre-installed
+in the src directory -- KSPACE, MANYBODY, MOLECULE -- because they are
+so commonly used.  When you download LAMMPS source files from the SVN
+or Git repositories, no packages are pre-installed.
 
-Packages are included or excluded by typing "make yes-name" or "make
-no-name", where "name" is the name of the package in lower-case, e.g.
-name = kspace for the KSPACE package or name = user-atc for the
-USER-ATC package.  You can also type "make yes-standard", "make
-no-standard", "make yes-std", "make no-std", "make yes-user", "make
-no-user", "make yes-lib", "make no-lib", "make yes-all", or "make
-no-all" to include/exclude various sets of packages.  Type "make
-package" to see all of the package-related make options.
+Packages are installed or un-installed by typing
 
-NOTE: Inclusion/exclusion of a package works by simply moving 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 seen or not seen when LAMMPS is built.  After you have included or
-excluded a package, you must re-build LAMMPS.
+make yes-name
+make no-name :pre
 
-Additional package-related make options exist to help manage LAMMPS
-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 have downloaded a patch from
-the LAMMPS WWW site.
+where "name" is the name of the package in lower-case, e.g.  name =
+kspace for the KSPACE package or name = user-atc for the USER-ATC
+package.  You can also type any of these commands:
 
-Typing "make package-update" or "make pu" will overwrite src files
-with files from the package sub-directories if the package has been
-included.  It should be used after a patch is installed, since patches
-only update the files in the package sub-directory, but not the src
-files.  Typing "make package-overwrite" will overwrite files in the
-package sub-directories with src files.
+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=|)
+
+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 moving
+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.
+After you have installed or un-installed a package, you must re-build
+LAMMPS for the action to take effect.
+
+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 have
+downloaded a patch from the LAMMPS web site.
 
 Typing "make package-status" or "make ps" will show which packages are
-currently included. For those that are included, it will list any
+currently installed. For those that are installed, it will list any
 files that are different in the src directory and package
-sub-directory.  Typing "make package-diff" lists all differences
-between these files.  Again, type "make package" to see all of the
-package-related make options.
+sub-directory.
+
+Typing "make package-update" or "make pu" will 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, since
+patches only update the files in the package sub-directory, but not
+the src files.
+
+Typing "make package-overwrite" will overwrite files in the package
+sub-directories with src files.
+
+Typing "make package-diff" lists all differences between these files.
+
+Again, just type "make package" to see all of the package-related make
+options.
 
 :line
 
 Packages that require extra libraries :h5,link(start_3_3)
 
-A few of the standard and user packages require additional auxiliary
-libraries.  Many of them are provided with LAMMPS, in which case they
-must be compiled first, before LAMMPS is built, if you wish to include
-that package.  If you get a LAMMPS build error about a missing
-library, this is likely the reason.  See the
-"Section 4"_Section_packages.html doc page for a list of
-packages that have these kinds of auxiliary libraries.
+A few of the standard and user packages require extra libraries.  See
+"Section 4"_Section_packages.html for two tables of packages which
+indicate which ones require libraries.  For each such package, the
+Section 4 doc page gives details on how to build the extra library,
+including how to download it if necessary.  The basic ideas are
+summarized here.
 
-The lib directory in the distribution has sub-directories with package
-names that correspond to the needed auxiliary libs, e.g. lib/gpu.
-Each sub-directory has a README file that gives more details.  Code
-for most of the auxiliary libraries is included in that directory.
-Examples are the USER-ATC and MEAM packages.
+[System libraries:]
 
-A few of the lib sub-directories do not include code, but do include
-instructions (and sometimes scripts) that automate the process of
-downloading the auxiliary library and installing it so LAMMPS can link
-to it.  Examples are the KIM, VORONOI, USER-MOLFILE, and USER-SMD
-packages.
+Packages in the tables "Section 4"_Section_packages.html with a "sys"
+in the last column link to system libraries that typically already
+exist on your machine.  E.g. the python package links to a system
+Python library.  If your machine does not have the required library,
+you will have to download and install it on your machine, in either
+the system or user space.
 
-The lib/python directory (for the PYTHON package) contains only a
-choice of Makefile.lammps.* files.  This is because no auxiliary code
-or libraries are needed, only the Python library and other system libs
-that should already available on your system.  However, the
-Makefile.lammps file is needed to tell LAMMPS which libs to use and
-where to find them.
+[Internal libraries:]
 
-For libraries with provided code, the sub-directory README file
-(e.g. lib/atc/README) has instructions on how to build that library.
-This information is also summarized in "Section
-4"_Section_packages.html.  Typically this is done by typing
-something like:
+Packages in the tables "Section 4"_Section_packages.html with an "int"
+in the last column link to internal libraries whose source code is
+included with LAMMPS, in the lib/name directory where name is the
+package name.  You must first build the library in that directory
+before building LAMMPS with that package installed.  E.g. the gpu
+package links to a library you build in the lib/gpu dir.  You can
+often do the build in one step by typing "make lib-name args=..."
+from the src dir, with appropriate arguments.  You can leave off the
+args to see a help message.  See "Section 4"_Section_packages.html for
+details for each package.
 
-make -f Makefile.g++ :pre
+[External libraries:]
 
-If one of the provided Makefiles is not appropriate for your system
-you will need to edit or add one.  Note that all the Makefiles have a
-setting for EXTRAMAKE at the top that specifies a Makefile.lammps.*
-file.
+Packages in the tables "Section 4"_Section_packages.html with an "ext"
+in the last column link to exernal libraries whose source code is not
+included with LAMMPS.  You must first download and install the library
+before building LAMMPS with that package installed.  E.g. the voronoi
+package links to the freely available "Voro++ library"_voro_home2.  You
+can often do the download/build in one step by typing "make lib-name
+args=..." from the src dir, with appropriate arguments.  You can leave
+off the args to see a help message.  See "Section
+4"_Section_packages.html for details for each package.
 
-If the library build is successful, it will produce 2 files in the lib
-directory:
+:link(voro_home2,http://math.lbl.gov/voro++)
 
-libpackage.a
-Makefile.lammps :pre
+[Possible errors:]
 
-The Makefile.lammps file will typically be a copy of one of the
-Makefile.lammps.* files in the library directory.
+There are various common errors which can occur when building extra
+libraries or when building LAMMPS with packages that require the extra
+libraries.
 
-Note that you must insure that the settings in Makefile.lammps are
-appropriate for your system.  If they are not, the LAMMPS build may
-fail.  To fix this, you can edit or create a new Makefile.lammps.*
-file for your system, and copy it to Makefile.lammps.
+If you cannot build the extra library itself successfully, you may
+need to edit or create an appropriate Makefile for your machine, e.g.
+with appropriate compiler or system settings.  Provided makefiles are
+typically in the lib/name directory.  E.g. see the Makefile.* files in
+lib/gpu.
 
-As explained in the lib/package/README files, the settings in
-Makefile.lammps are used to specify additional system libraries and
-their locations so that LAMMPS can build with the auxiliary library.
-For example, if the MEAM package is used, the auxiliary library
-consists of F90 code, built with a Fortran complier.  To link that
-library with LAMMPS (a C++ code) via whatever C++ compiler LAMMPS is
-built with, typically requires additional Fortran-to-C libraries be
-included in the link.  Another example are the BLAS and LAPACK
-libraries needed to use the USER-ATC or USER-AWPMD packages.
+The LAMMPS build often uses settings in a lib/name/Makefile.lammps
+file which either exists in the LAMMPS distribution or is created or
+copied from a lib/name/Makefile.lammps.* file when the library is
+built.  If those settings are not correct for your machine you will
+need to edit or create an appropriate Makefile.lammps file.
 
-For libraries without provided code, the sub-directory README file has
-information on where to download the library and how to build it,
-e.g. lib/voronoi/README and lib/smd/README.  The README files also
-describe how you must either (a) create soft links, via the "ln"
-command, in those directories to point to where you built or installed
-the packages, or (b) check or edit the Makefile.lammps file in the
-same directory to provide that information.
+Package-specific details for these steps are given in "Section
+4"_Section_packages.html an in README files in the lib/name
+directories.
 
-Some of the sub-directories, e.g. lib/voronoi, also have an install.py
-script which can be used to automate the process of
-downloading/building/installing the auxiliary library, and setting the
-needed soft links.  Type "python install.py" for further instructions.
+[Compiler options needed for accelerator packages:]
 
-As with the sub-directories containing library code, if the soft links
-or settings in the lib/package/Makefile.lammps files are not correct,
-the LAMMPS build will typically fail.
+Several packages contain code that is optimized for specific hardware,
+e.g. CPU, KNL, or GPU.  These are the OPT, GPU, KOKKOS, USER-INTEL,
+and USER-OMP packages.  Compiling and linking the source files in
+these accelerator packages for optimal performance requires specific
+settings in the Makefile.machine file you use.
 
-:line
-
-Packages that require Makefile.machine settings :h5,link(start_3_4)
-
-A few packages require specific settings in Makefile.machine, to
-either build or use the package effectively.  These are the
-USER-INTEL, KOKKOS, USER-OMP, and OPT packages, used for accelerating
-code performance on CPUs or other hardware, as discussed in "Section
-5.3"_Section_accelerate.html#acc_3.
-
-A summary of what Makefile.machine changes are needed for each of
-these packages is given in "Section 4"_Section_packages.html.
-The details are given on the doc pages that describe each of these
-accelerator packages in detail:
+A summary of the Makefile.machine settings needed for each of these
+packages is given in "Section 4"_Section_packages.html.  More info is
+given on the doc pages that describe each package in detail:
 
 5.3.1 "USER-INTEL package"_accelerate_intel.html
+5.3.2 "GPU package"_accelerate_intel.html
 5.3.3 "KOKKOS package"_accelerate_kokkos.html
 5.3.4 "USER-OMP package"_accelerate_omp.html
 5.3.5 "OPT package"_accelerate_opt.html :all(b)
 
-You can also look at the following machine Makefiles in
-src/MAKE/OPTIONS, which include the changes.  Note that the USER-INTEL
-and KOKKOS packages allow for settings that build LAMMPS for different
-hardware.  The USER-INTEL package builds for CPU and the Xeon Phi, the
-KOKKOS package builds for OpenMP, GPUs (Cuda), and the Xeon Phi.
+You can also use or examine the following machine Makefiles in
+src/MAKE/OPTIONS, which include the settings.  Note that the
+USER-INTEL and KOKKOS packages can use settings that build LAMMPS for
+different hardware.  The USER-INTEL package can be compiled for Intel
+CPUs and KNLs; the KOKKOS package builds for CPUs (OpenMP), GPUs
+(CUDA), and Intel KNLs.
 
 Makefile.intel_cpu
 Makefile.intel_phi
@@ -908,127 +925,9 @@ Makefile.kokkos_phi
 Makefile.omp
 Makefile.opt :ul
 
-Also note that the Make.py tool, described in the next "Section
-2.4"_#start_4 can automatically add the needed info to an existing
-machine Makefile, using simple command-line arguments.
-
 :line
 
-2.4 Building LAMMPS via the Make.py tool :h4,link(start_4)
-
-The src directory includes a Make.py script, written in Python, which
-can be used to automate various steps of the build process.  It is
-particularly useful for working with the accelerator packages, as well
-as other packages which require auxiliary libraries to be built.
-
-The goal of the Make.py tool is to allow any complex multi-step LAMMPS
-build to be performed as a single Make.py command.  And you can
-archive the commands, so they can be re-invoked later via the -r
-(redo) switch.  If you find some LAMMPS build procedure that can't be
-done in a single Make.py command, let the developers know, and we'll
-see if we can augment the tool.
-
-You can run Make.py from the src directory by typing either:
-
-Make.py -h
-python Make.py -h :pre
-
-which will give you help info about the tool.  For the former to work,
-you may need to edit the first line of Make.py to point to your local
-Python.  And you may need to insure the script is executable:
-
-chmod +x Make.py :pre
-
-Here are examples of build tasks you can perform with Make.py:
-
-Install/uninstall packages: Make.py -p no-lib kokkos omp intel
-Build specific auxiliary libs: Make.py -a lib-atc lib-meam
-Build libs for all installed packages: Make.py -p cuda gpu -gpu mode=double arch=31 -a lib-all
-Create a Makefile from scratch with compiler and MPI settings: Make.py -m none -cc g++ -mpi mpich -a file
-Augment Makefile.serial with settings for installed packages: Make.py -p intel -intel cpu -m serial -a file
-Add JPG and FFTW support to Makefile.mpi: Make.py -m mpi -jpg -fft fftw -a file
-Build LAMMPS with a parallel make using Makefile.mpi: Make.py -j 16 -m mpi -a exe
-Build LAMMPS and libs it needs using Makefile.serial with accelerator settings: Make.py -p gpu intel -intel cpu -a lib-all file serial :tb(s=:)
-
-The bench and examples directories give Make.py commands that can be
-used to build LAMMPS with the various packages and options needed to
-run all the benchmark and example input scripts.  See these files for
-more details:
-
-bench/README
-bench/FERMI/README
-bench/KEPLER/README
-bench/PHI/README
-examples/README
-examples/accelerate/README
-examples/accelerate/make.list :ul
-
-All of the Make.py options and syntax help can be accessed by using
-the "-h" switch.
-
-E.g. typing "Make.py -h" gives
-
-Syntax: Make.py switch args ...
-  switches can be listed in any order
-  help switch:
-    -h prints help and syntax for all other specified switches
-  switch for actions:
-    -a lib-all, lib-dir, clean, file, exe or machine
-    list one or more actions, in any order
-    machine is a Makefile.machine suffix, must be last if used
-  one-letter switches:
-    -d (dir), -j (jmake), -m (makefile), -o (output),
-    -p (packages), -r (redo), -s (settings), -v (verbose)
-  switches for libs:
-    -atc, -awpmd, -colvars, -cuda
-    -gpu, -meam, -poems, -qmmm, -reax
-  switches for build and makefile options:
-    -intel, -kokkos, -cc, -mpi, -fft, -jpg, -png :pre
-
-Using the "-h" switch with other switches and actions gives additional
-info on all the other specified switches or actions.  The "-h" can be
-anywhere in the command-line and the other switches do not need their
-arguments.  E.g. type "Make.py -h -d -atc -intel" will print:
-
--d dir
-  dir = LAMMPS home dir
-  if -d not specified, working dir must be lammps/src :pre
-
--atc make=suffix lammps=suffix2
-  all args are optional and can be in any order
-  make = use Makefile.suffix (def = g++)
-  lammps = use Makefile.lammps.suffix2 (def = EXTRAMAKE in makefile) :pre
-
--intel mode
-  mode = cpu or phi (def = cpu)
-    build Intel package for CPU or Xeon Phi :pre
-
-Note that Make.py never overwrites an existing Makefile.machine.
-Instead, it creates src/MAKE/MINE/Makefile.auto, which you can save or
-rename if desired.  Likewise it creates an executable named
-src/lmp_auto, which you can rename using the -o switch if desired.
-
-The most recently executed Make.py command is saved in
-src/Make.py.last.  You can use the "-r" switch (for redo) to re-invoke
-the last command, or you can save a sequence of one or more Make.py
-commands to a file and invoke the file of commands using "-r".  You
-can also label the commands in the file and invoke one or more of them
-by name.
-
-A typical use of Make.py is to start with a valid Makefile.machine for
-your system, that works for a vanilla LAMMPS build, i.e. when optional
-packages are not installed.  You can then use Make.py to add various
-settings (FFT, JPG, PNG) to the Makefile.machine as well as change its
-compiler and MPI options.  You can also add additional packages to the
-build, as well as build the needed supporting libraries.
-
-You can also use Make.py to create a new Makefile.machine from
-scratch, using the "-m none" switch, if you also specify what compiler
-and MPI options to use, via the "-cc" and "-mpi" switches.
-
-:line
-
-2.5 Building LAMMPS as a library :h4,link(start_5)
+2.4 Building LAMMPS as a library :h4,link(start_4)
 
 LAMMPS can be built as either a static or shared library, which can
 then be called from another application or a scripting language.  See
@@ -1064,7 +963,7 @@ src/MAKE/Makefile.foo and perform the build in the directory
 Obj_shared_foo.  This is so that each file can be compiled with the
 -fPIC flag which is required for inclusion in a shared library.  The
 build will create the file liblammps_foo.so which another application
-can link to dynamically.  It will also create a soft link liblammps.so,
+can link to dyamically.  It will also create a soft link liblammps.so,
 which will point to the most recently built shared library.  This is
 the file the Python wrapper loads by default.
 
@@ -1150,7 +1049,7 @@ interface and how to extend it for your needs.
 
 :line
 
-2.6 Running LAMMPS :h4,link(start_6)
+2.5 Running LAMMPS :h4,link(start_5)
 
 By default, LAMMPS runs by reading commands from standard input.  Thus
 if you run the LAMMPS executable by itself, e.g.
@@ -1194,7 +1093,7 @@ LAMMPS to be built with one or more of its optional packages.
 :line
 
 On a Windows box, you can skip making LAMMPS and simply download an
-installer package from "here"_http://rpm.lammps.org/windows.html
+installer package from "here"_http://packages.lammps.org/windows.html
 
 For running the non-MPI executable, follow these steps:
 
@@ -1206,18 +1105,27 @@ the [in.lj] input from the bench folder. (e.g. by typing: cd "Documents"). :l
 
 At the command prompt, type "lmp_serial -in in.lj", replacing [in.lj]
 with the name of your LAMMPS input script. :l
+
+The serial executable includes support for multi-threading
+parallelization from the styles in the USER-OMP packages.
+
+To run with, e.g. 4 threads, type "lmp_serial -in in.lj -pk omp 4 -sf omp"
 :ule
 
-For the MPI version, which allows you to run LAMMPS under Windows on
-multiple processors, follow these steps:
+For the MPI version, which allows you to run LAMMPS under Windows with
+the more general message passing parallel library (LAMMPS has been
+designed from ground up to use MPI efficiently), follow these steps:
 
-Download and install
-"MPICH2"_http://www.mcs.anl.gov/research/projects/mpich2/downloads/index.php?s=downloads
-for Windows. :ulb,l
+Download and install a compatible MPI library binary package:
+for 32-bit Windows
+"mpich2-1.4.1p1-win-ia32.msi"_download.lammps.org/thirdparty/mpich2-1.4.1p1-win-ia32.msi
+and for 64-bit Windows
+"mpich2-1.4.1p1-win-x86-64.msi"_download.lammps.org/thirdparty/mpich2-1.4.1p1-win-x86-64.msi
+:ulb,l
 
 The LAMMPS Windows installer packages will automatically adjust your
 path for the default location of this MPI package. After the installation
-of the MPICH software, it needs to be integrated into the system.
+of the MPICH2 software, it needs to be integrated into the system.
 For this you need to start a Command Prompt in {Administrator Mode}
 (right click on the icon and select it). Change into the MPICH2
 installation directory, then into the subdirectory [bin] and execute
@@ -1236,7 +1144,7 @@ or
 
 mpiexec -np 4 lmp_mpi -in in.lj :pre
 
-replacing in.lj with the name of your LAMMPS input script. For the latter
+replacing [in.lj] with the name of your LAMMPS input script. For the latter
 case, you may be prompted to enter your password. :l
 
 In this mode, output may not immediately show up on the screen, so if
@@ -1248,6 +1156,11 @@ something like:
 
 lmp_mpi -in in.lj :pre
 
+And the parallel executable also includes OpenMP multi-threading, which
+can be combined with MPI using something like:
+
+mpiexec -localonly 2 lmp_mpi -in in.lj -pk omp 2 -sf omp :pre
+
 :ule
 
 :line
@@ -1282,7 +1195,7 @@ more processors or setup a smaller problem.
 
 :line
 
-2.7 Command-line options :h4,link(start_7)
+2.6 Command-line options :h4,link(start_6)
 
 At run time, LAMMPS recognizes several optional command-line switches
 which may be used in any order.  Either the full word or a one-or-two
@@ -1416,8 +1329,8 @@ LAMMPS is compiled with CUDA=yes.
 numa Nm :pre
 
 This option is only relevant when using pthreads with hwloc support.
-In this case Nm defines the number of NUMA regions (typically sockets)
-on a node which will be utilized by a single MPI rank.  By default Nm
+In this case Nm defines the number of NUMA regions (typicaly sockets)
+on a node which will be utilizied by a single MPI rank.  By default Nm
 = 1.  If this option is used the total number of worker-threads per
 MPI rank is threads*numa.  Currently it is always almost better to
 assign at least one MPI rank per NUMA region, and leave numa set to
@@ -1481,7 +1394,7 @@ replica runs on on one or a few processors.  Note that with MPI
 installed on a machine (e.g. your desktop), you can run on more
 (virtual) processors than you have physical processors.
 
-To run multiple independent simulations from one input script, using
+To run multiple independent simulatoins from one input script, using
 multiple partitions, see "Section 6.4"_Section_howto.html#howto_4
 of the manual.  World- and universe-style "variables"_variable.html
 are useful in this context.
@@ -1712,7 +1625,7 @@ negative numeric value.  It is OK if the first value1 starts with a
 
 :line
 
-2.8 LAMMPS screen output :h4,link(start_8)
+2.7 LAMMPS screen output :h4,link(start_7)
 
 As LAMMPS reads an input script, it prints information to both the
 screen and a log file about significant actions it takes to setup a
@@ -1760,7 +1673,7 @@ The first section provides a global loop timing summary. The {loop time}
 is the total wall time for the section.  The {Performance} line is
 provided for convenience to help predicting the number of loop
 continuations required and for comparing performance with other,
-similar MD codes.  The {CPU use} line provides the CPU utilization per
+similar MD codes.  The {CPU use} line provides the CPU utilzation per
 MPI task; it should be close to 100% times the number of OpenMP
 threads (or 1 of no OpenMP). Lower numbers correspond to delays due
 to file I/O or insufficient thread utilization.
@@ -1868,7 +1781,7 @@ communication, roughly 75% in the example above.
 
 :line
 
-2.9 Tips for users of previous LAMMPS versions :h4,link(start_9)
+2.8 Tips for users of previous LAMMPS versions :h4,link(start_8)
 
 The current C++ began with a complete rewrite of LAMMPS 2001, which
 was written in F90.  Features of earlier versions of LAMMPS are listed

doc/src/Section_tools.txt

@@ -369,15 +369,18 @@ supports it.  It has its own WWW page at
 
 msi2lmp tool :h4,link(msi)
 
-The msi2lmp sub-directory contains a tool for creating LAMMPS input
-data files from BIOVIA's Materias Studio files (formerly Accelrys'
+The msi2lmp sub-directory contains a tool for creating LAMMPS template
+input and data files from BIOVIA's Materias Studio files (formerly Accelrys'
 Insight MD code, formerly MSI/Biosym and its Discover MD code).
 
 This tool was written by John Carpenter (Cray), Michael Peachey
 (Cray), and Steve Lustig (Dupont). Several people contributed changes
 to remove bugs and adapt its output to changes in LAMMPS.
 
-See the README file for more information.
+This tool has several known limitations and is no longer under active
+development, so there are no changes except for the occasional bugfix.
+
+See the README file in the tools/msi2lmp folder for more information.
 
 :line
 

doc/src/accelerate_gpu.txt

@@ -54,7 +54,7 @@ specify the # of GPUs per node
 use GPU styles in your input script :ul
 
 The latter two steps can be done using the "-pk gpu" and "-sf gpu"
-"command-line switches"_Section_start.html#start_7 respectively.  Or
+"command-line switches"_Section_start.html#start_6 respectively.  Or
 the effect of the "-pk" or "-sf" switches can be duplicated by adding
 the "package gpu"_package.html or "suffix gpu"_suffix.html commands
 respectively to your input script.
@@ -62,7 +62,7 @@ respectively to your input script.
 [Required hardware/software:]
 
 To use this package, you currently need to have an NVIDIA GPU and
-install the NVIDIA Cuda software on your system:
+install the NVIDIA CUDA software on your system:
 
 Check if you have an NVIDIA GPU: cat /proc/driver/nvidia/gpus/0/information
 Go to http://www.nvidia.com/object/cuda_get.html
@@ -74,13 +74,8 @@ Run lammps/lib/gpu/nvc_get_devices (after building the GPU library, see below) t
 This requires two steps (a,b): build the GPU library, then build
 LAMMPS with the GPU package.
 
-You can do both these steps in one line, using the src/Make.py script,
-described in "Section 2.4"_Section_start.html#start_4 of the manual.
-Type "Make.py -h" for help.  If run from the src directory, this
-command will create src/lmp_gpu using src/MAKE/Makefile.mpi as the
-starting Makefile.machine:
-
-Make.py -p gpu -gpu mode=single arch=31 -o gpu -a lib-gpu file mpi :pre
+You can do both these steps in one line as described in
+"Section 4"_Section_packages.html of the manual.
 
 Or you can follow these two (a,b) steps:
 
@@ -90,7 +85,7 @@ The GPU library is in lammps/lib/gpu.  Select a Makefile.machine (in
 lib/gpu) appropriate for your system.  You should pay special
 attention to 3 settings in this makefile.
 
-CUDA_HOME = needs to be where NVIDIA Cuda software is installed on your system
+CUDA_HOME = needs to be where NVIDIA CUDA software is installed on your system
 CUDA_ARCH = needs to be appropriate to your GPUs
 CUDA_PREC = precision (double, mixed, single) you desire :ul
 
@@ -151,9 +146,9 @@ automatically if you create more MPI tasks/node than there are
 GPUs/mode.  E.g. with 8 MPI tasks/node and 2 GPUs, each GPU will be
 shared by 4 MPI tasks.
 
-Use the "-sf gpu" "command-line switch"_Section_start.html#start_7,
+Use the "-sf gpu" "command-line switch"_Section_start.html#start_6,
 which will automatically append "gpu" to styles that support it.  Use
-the "-pk gpu Ng" "command-line switch"_Section_start.html#start_7 to
+the "-pk gpu Ng" "command-line switch"_Section_start.html#start_6 to
 set Ng = # of GPUs/node to use.
 
 lmp_machine -sf gpu -pk gpu 1 -in in.script                         # 1 MPI task uses 1 GPU
@@ -188,7 +183,7 @@ pair_style lj/cut/gpu 2.5 :pre
 
 You must also use the "package gpu"_package.html command to enable the
 GPU package, unless the "-sf gpu" or "-pk gpu" "command-line
-switches"_Section_start.html#start_7 were used.  It specifies the
+switches"_Section_start.html#start_6 were used.  It specifies the
 number of GPUs/node to use, as well as other options.
 
 [Speed-ups to expect:]

doc/src/accelerate_intel.txt

@@ -29,9 +29,11 @@ Bond Styles: fene, harmonic :l
 Dihedral Styles: charmm, harmonic, opls :l
 Fixes: nve, npt, nvt, nvt/sllod :l
 Improper Styles: cvff, harmonic :l
-Pair Styles: buck/coul/cut, buck/coul/long, buck, eam, gayberne,
-charmm/coul/long, lj/cut, lj/cut/coul/long, sw, tersoff :l
-K-Space Styles: pppm :l
+Pair Styles: airebo, airebo/morse, buck/coul/cut, buck/coul/long, 
+buck, eam, eam/alloy, eam/fs, gayberne, lj/charmm/coul/charmm, 
+lj/charmm/coul/long, lj/cut, lj/cut/coul/long, lj/long/coul/long, rebo,
+sw, tersoff :l
+K-Space Styles: pppm, pppm/disp :l
 :ule
 
 [Speed-ups to expect:]
@@ -42,61 +44,90 @@ precision mode. Performance improvements are shown compared to
 LAMMPS {without using other acceleration packages} as these are
 under active development (and subject to performance changes). The
 measurements were performed using the input files available in
-the src/USER-INTEL/TEST directory. These are scalable in size; the
-results given are with 512K particles (524K for Liquid Crystal).
-Most of the simulations are standard LAMMPS benchmarks (indicated
-by the filename extension in parenthesis) with modifications to the
-run length and to add a warmup run (for use with offload
-benchmarks).
+the src/USER-INTEL/TEST directory with the provided run script.
+These are scalable in size; the results given are with 512K
+particles (524K for Liquid Crystal). Most of the simulations are
+standard LAMMPS benchmarks (indicated by the filename extension in
+parenthesis) with modifications to the run length and to add a
+warmup run (for use with offload benchmarks).
 
 :c,image(JPG/user_intel.png)
 
 Results are speedups obtained on Intel Xeon E5-2697v4 processors
 (code-named Broadwell) and Intel Xeon Phi 7250 processors
-(code-named Knights Landing) with "18 Jun 2016" LAMMPS built with
-Intel Parallel Studio 2016 update 3. Results are with 1 MPI task
+(code-named Knights Landing) with "June 2017" LAMMPS built with
+Intel Parallel Studio 2017 update 2. Results are with 1 MPI task
 per physical core. See {src/USER-INTEL/TEST/README} for the raw
 simulation rates and instructions to reproduce.
 
 :line
 
+[Accuracy and order of operations:]
+
+In most molecular dynamics software, parallelization parameters
+(# of MPI, OpenMP, and vectorization) can change the results due
+to changing the order of operations with finite-precision
+calculations. The USER-INTEL package is deterministic. This means
+that the results should be reproducible from run to run with the
+{same} parallel configurations and when using determinstic
+libraries or library settings (MPI, OpenMP, FFT). However, there
+are differences in the USER-INTEL package that can change the
+order of operations compared to LAMMPS without acceleration:
+
+Neighbor lists can be created in a different order :ulb,l
+Bins used for sorting atoms can be oriented differently :l
+The default stencil order for PPPM is 7. By default, LAMMPS will
+calculate other PPPM parameters to fit the desired acuracy with
+this order :l
+The {newton} setting applies to all atoms, not just atoms shared
+between MPI tasks :l
+Vectorization can change the order for adding pairwise forces :l
+:ule
+
+The precision mode (described below) used with the USER-INTEL
+package can change the {accuracy} of the calculations. For the
+default {mixed} precision option, calculations between pairs or
+triplets of atoms are performed in single precision, intended to
+be within the inherent error of MD simulations. All accumulation
+is performed in double precision to prevent the error from growing
+with the number of atoms in the simulation. {Single} precision
+mode should not be used without appropriate validation.
+
+:line
+
 [Quick Start for Experienced Users:]
 
 LAMMPS should be built with the USER-INTEL package installed.
 Simulations should be run with 1 MPI task per physical {core},
 not {hardware thread}.
 
-For Intel Xeon CPUs:
-
 Edit src/MAKE/OPTIONS/Makefile.intel_cpu_intelmpi as necessary. :ulb,l
-If using {kspace_style pppm} in the input script, add "neigh_modify binsize 3" and "kspace_modify diff ad" to the input script for better
-performance. :l
-"-pk intel 0 omp 2 -sf intel" added to LAMMPS command-line :l
+Set the environment variable KMP_BLOCKTIME=0 :l
+"-pk intel 0 omp $t -sf intel" added to LAMMPS command-line :l
+$t should be 2 for Intel Xeon CPUs and 2 or 4 for Intel Xeon Phi :l
+For some of the simple 2-body potentials without long-range
+electrostatics, performance and scalability can be better with
+the "newton off" setting added to the input script :l
+For simulations on higher node counts, add "processors * * * grid 
+numa" to the beginning of the input script for better scalability :l
+If using {kspace_style pppm} in the input script, add
+"kspace_modify diff ad" for better performance :l
 :ule
 
-For Intel Xeon Phi CPUs for simulations without {kspace_style
-pppm} in the input script :
+For Intel Xeon Phi CPUs:
 
-Edit src/MAKE/OPTIONS/Makefile.knl as necessary. :ulb,l
-Runs should be performed using MCDRAM. :l
-"-pk intel 0 omp 2 -sf intel" {or} "-pk intel 0 omp 4 -sf intel"
-should be added to the LAMMPS command-line. Choice for best
-performance will depend on the simulation. :l
+Runs should be performed using MCDRAM. :ulb,l
 :ule
 
-For Intel Xeon Phi CPUs for simulations with {kspace_style
-pppm} in the input script:
+For simulations using {kspace_style pppm} on Intel CPUs
+supporting AVX-512:
 
-Edit src/MAKE/OPTIONS/Makefile.knl as necessary. :ulb,l
-Runs should be performed using MCDRAM. :l
-Add "neigh_modify binsize 3" to the input script for better
-performance. :l
-Add "kspace_modify diff ad" to the input script for better
-performance. :l
-export KMP_AFFINITY=none :l
-"-pk intel 0 omp 3 lrt yes -sf intel" or "-pk intel 0 omp 1 lrt yes
--sf intel" added to LAMMPS command-line. Choice for best performance
-will depend on the simulation. :l
+Add "kspace_modify diff ad" to the input script :ulb,l
+The command-line option should be changed to
+"-pk intel 0 omp $r lrt yes -sf intel" where $r is the number of
+threads minus 1. :l
+Do not use thread affinity (set KMP_AFFINITY=none) :l
+The "newton off" setting may provide better scalability :l
 :ule
 
 For Intel Xeon Phi coprocessors (Offload):
@@ -168,6 +199,10 @@ cat /proc/cpuinfo :pre
 
 [Building LAMMPS with the USER-INTEL package:]
 
+NOTE: See the src/USER-INTEL/README file for additional flags that
+might be needed for best performance on Intel server processors
+code-named "Skylake".
+
 The USER-INTEL package must be installed into the source directory:
 
 make yes-user-intel :pre
@@ -192,11 +227,9 @@ source /opt/intel/parallel_studio_xe_2016.3.067/psxevars.sh
 # or psxevars.csh for C-shell
 make intel_cpu_intelmpi :pre
 
-Alternatively, the build can be accomplished with the src/Make.py
-script, described in "Section 2.4"_Section_start.html#start_4 of the
-manual. Type "Make.py -h" for help. For an example:
-
-Make.py -v -p intel omp -intel cpu -a file intel_cpu_intelmpi :pre
+Alternatively this can be done as a single command with
+suitable make command invocations. This is discussed in "Section
+4"_Section_packages.html of the manual.
 
 Note that if you build with support for a Phi coprocessor, the same
 binary can be used on nodes with or without coprocessors installed.
@@ -211,8 +244,7 @@ highly recommended for CCFLAGS and LINKFLAGS. LIB should include
 is required for CCFLAGS and "-qoffload" is required for LINKFLAGS.
 Other recommended CCFLAG options for best performance are
 "-O2 -fno-alias -ansi-alias -qoverride-limits fp-model fast=2
--no-prec-div". The Make.py command will add all of these
-automatically.
+-no-prec-div".
 
 NOTE: The vectorization and math capabilities can differ depending on
 the CPU. For Intel compilers, the "-x" flag specifies the type of
@@ -268,7 +300,7 @@ Hyper-Threading technology disabled.
 
 To enable USER-INTEL optimizations for all available styles used in
 the input script, the "-sf intel"
-"command-line switch"_Section_start.html#start_7 can be used without
+"command-line switch"_Section_start.html#start_6 can be used without
 any requirement for editing the input script. This switch will
 automatically append "intel" to styles that support it. It also
 invokes a default command: "package intel 1"_package.html. This
@@ -281,7 +313,7 @@ support, that 1 coprocessor per node will be used with automatic
 balancing of work between the CPU and the coprocessor.
 
 You can specify different options for the USER-INTEL package by using
-the "-pk intel Nphi" "command-line switch"_Section_start.html#start_7
+the "-pk intel Nphi" "command-line switch"_Section_start.html#start_6
 with keyword/value pairs as specified in the documentation. Here,
 Nphi = # of Xeon Phi coprocessors/node (ignored without offload
 support). Common options to the USER-INTEL package include {omp} to
@@ -321,8 +353,8 @@ follow in the input script.
 
 NOTE: The USER-INTEL package will perform better with modifications
 to the input script when "PPPM"_kspace_style.html is used:
-"kspace_modify diff ad"_kspace_modify.html and "neigh_modify binsize
-3"_neigh_modify.html should be added to the input script.
+"kspace_modify diff ad"_kspace_modify.html should be added to the
+input script.
 
 Long-Range Thread (LRT) mode is an option to the "package
 intel"_package.html command that can improve performance when using
@@ -341,6 +373,10 @@ would normally perform best with "-pk intel 0 omp 4", instead use
 environment variable "KMP_AFFINITY=none". LRT mode is not supported
 when using offload.
 
+NOTE: Changing the "newton"_newton.html setting to off can improve
+performance and/or scalability for simple 2-body potentials such as
+lj/cut or when using LRT mode on processors supporting AVX-512.
+
 Not all styles are supported in the USER-INTEL package. You can mix
 the USER-INTEL package with styles from the "OPT"_accelerate_opt.html
 package or the "USER-OMP package"_accelerate_omp.html. Of course,
@@ -350,13 +386,17 @@ can performed automatically by using "-sf hybrid intel opt" or
 and "omp" suffixes can be appended manually in the input script. For
 the latter, the "package omp"_package.html command must be in the
 input script or the "-pk omp Nt" "command-line
-switch"_Section_start.html#start_7 must be used where Nt is the
+switch"_Section_start.html#start_6 must be used where Nt is the
 number of OpenMP threads. The number of OpenMP threads should not be
 set differently for the different packages. Note that the "suffix
 hybrid intel omp"_suffix.html command can also be used within the
 input script to automatically append the "omp" suffix to styles when
 USER-INTEL styles are not available.
 
+NOTE: For simulations on higher node counts, add "processors * * * 
+grid numa"_processors.html" to the beginning of the input script for
+better scalability.
+
 When running on many nodes, performance might be better when using
 fewer OpenMP threads and more MPI tasks. This will depend on the
 simulation and the machine. Using the "verlet/split"_run_style.html
@@ -445,7 +485,7 @@ sorting"_atom_modify.html is changed to 1 so that the per-atom data is
 effectively sorted at every rebuild of the neighbor lists. All the
 available coprocessor threads on each Phi will be divided among MPI
 tasks, unless the {tptask} option of the "-pk intel" "command-line
-switch"_Section_start.html#start_7 is used to limit the coprocessor
+switch"_Section_start.html#start_6 is used to limit the coprocessor
 threads per MPI task.
 
 [Restrictions:]
@@ -466,7 +506,7 @@ supported.
 
 Brown, W.M., Carrillo, J.-M.Y., Mishra, B., Gavhane, N., Thakker, F.M., De Kraker, A.R., Yamada, M., Ang, J.A., Plimpton, S.J., "Optimizing Classical Molecular Dynamics in LAMMPS," in Intel Xeon Phi Processor High Performance Programming: Knights Landing Edition, J. Jeffers, J. Reinders, A. Sodani, Eds. Morgan Kaufmann. :ulb,l
 
-Brown, W. M., Semin, A., Hebenstreit, M., Khvostov, S., Raman, K., Plimpton, S.J. Increasing Molecular Dynamics Simulation Rates with an 8-Fold Increase in Electrical Power Efficiency. 2016 International Conference for High Performance Computing. In press. :l
+Brown, W. M., Semin, A., Hebenstreit, M., Khvostov, S., Raman, K., Plimpton, S.J. "Increasing Molecular Dynamics Simulation Rates with an 8-Fold Increase in Electrical Power Efficiency."_http://dl.acm.org/citation.cfm?id=3014915 2016 High Performance Computing, Networking, Storage and Analysis, SC16: International Conference (pp. 82-95). :l
 
 Brown, W.M., Carrillo, J.-M.Y., Gavhane, N., Thakkar, F.M., Plimpton, S.J. Optimizing Legacy Molecular Dynamics Software with Directive-Based Offload. Computer Physics Communications. 2015. 195: p. 95-101. :l
 :ule

doc/src/accelerate_kokkos.txt

@@ -60,8 +60,7 @@ More details follow.
 use a C++11 compatible compiler
 make yes-kokkos
 make mpi KOKKOS_DEVICES=OpenMP                 # build with the KOKKOS package
-make kokkos_omp                                # or Makefile.kokkos_omp already has variable set
-Make.py -v -p kokkos -kokkos omp -o mpi -a file mpi   # or one-line build via Make.py :pre
+make kokkos_omp                                # or Makefile.kokkos_omp already has variable set :pre
 
 mpirun -np 16 lmp_mpi -k on -sf kk -in in.lj              # 1 node, 16 MPI tasks/node, no threads
 mpirun -np 2 -ppn 1 lmp_mpi -k on t 16 -sf kk -in in.lj   # 2 nodes, 1 MPI task/node, 16 threads/task
@@ -82,8 +81,7 @@ use a C++11 compatible compiler
 KOKKOS_DEVICES = Cuda, OpenMP
 KOKKOS_ARCH = Kepler35
 make yes-kokkos
-make machine
-Make.py -p kokkos -kokkos cuda arch=31 -o kokkos_cuda -a file kokkos_cuda :pre
+make machine :pre
 
 mpirun -np 1 lmp_cuda -k on t 6 -sf kk -in in.lj          # one MPI task, 6 threads on CPU
 mpirun -np 4 -ppn 1 lmp_cuda -k on t 6 -sf kk -in in.lj   # ditto on 4 nodes :pre
@@ -98,8 +96,7 @@ use a C++11 compatible compiler
 KOKKOS_DEVICES = OpenMP
 KOKKOS_ARCH = KNC
 make yes-kokkos
-make machine
-Make.py -p kokkos -kokkos phi -o kokkos_phi -a file mpi :pre
+make machine :pre
 
 host=MIC, Intel Phi with 61 cores (240 threads/phi via 4x hardware threading):
 mpirun -np 1 lmp_g++ -k on t 240 -sf kk -in in.lj           # 1 MPI task on 1 Phi, 1*240 = 240
@@ -116,7 +113,7 @@ To build with Kokkos support for CPUs, your compiler must support the
 OpenMP interface.  You should have one or more multi-core CPUs so that
 multiple threads can be launched by each MPI task running on a CPU.
 
-To build with Kokkos support for NVIDIA GPUs, NVIDIA Cuda software
+To build with Kokkos support for NVIDIA GPUs, NVIDIA CUDA software
 version 7.5 or later must be installed on your system.  See the
 discussion for the "GPU"_accelerate_gpu.html package for details of
 how to check and do this.
@@ -135,16 +132,16 @@ mode like the USER-INTEL package supports.
 You must choose at build time whether to build for CPUs (OpenMP),
 GPUs, or Phi.
 
-You can do any of these in one line, using the src/Make.py script,
-described in "Section 2.4"_Section_start.html#start_4 of the manual.
-Type "Make.py -h" for help.  If run from the src directory, these
+You can do any of these in one line, using the suitable make command
+line flags as described in "Section 4"_Section_packages.html of the
+manual. If run from the src directory, these
 commands will create src/lmp_kokkos_omp, lmp_kokkos_cuda, and
 lmp_kokkos_phi.  Note that the OMP and PHI options use
 src/MAKE/Makefile.mpi as the starting Makefile.machine.  The CUDA
 option uses src/MAKE/OPTIONS/Makefile.kokkos_cuda.
 
 The latter two steps can be done using the "-k on", "-pk kokkos" and
-"-sf kk" "command-line switches"_Section_start.html#start_7
+"-sf kk" "command-line switches"_Section_start.html#start_6
 respectively.  Or the effect of the "-pk" or "-sf" switches can be
 duplicated by adding the "package kokkos"_package.html or "suffix
 kk"_suffix.html commands respectively to your input script.
@@ -280,10 +277,10 @@ specify how many Phi coprocessors there are per node; each
 coprocessors is simply treated as running some number of MPI tasks.
 
 You must use the "-k on" "command-line
-switch"_Section_start.html#start_7 to enable the KOKKOS package.  It
+switch"_Section_start.html#start_6 to enable the KOKKOS package.  It
 takes additional arguments for hardware settings appropriate to your
 system.  Those arguments are "documented
-here"_Section_start.html#start_7.  The two most commonly used
+here"_Section_start.html#start_6.  The two most commonly used
 options are:
 
 -k on t Nt g Ng :pre
@@ -304,12 +301,12 @@ The "-k on" switch also issues a "package kokkos" command (with no
 additional arguments) which sets various KOKKOS options to default
 values, as discussed on the "package"_package.html command doc page.
 
-Use the "-sf kk" "command-line switch"_Section_start.html#start_7,
+Use the "-sf kk" "command-line switch"_Section_start.html#start_6,
 which will automatically append "kk" to styles that support it.  Use
-the "-pk kokkos" "command-line switch"_Section_start.html#start_7 if
+the "-pk kokkos" "command-line switch"_Section_start.html#start_6 if
 you wish to change any of the default "package kokkos"_package.html
 optionns set by the "-k on" "command-line
-switch"_Section_start.html#start_7.
+switch"_Section_start.html#start_6.
 
 
 
@@ -323,7 +320,7 @@ However, when running in MPI-only mode with 1 thread per MPI task, it
 will typically be faster to use "half" neighbor lists and set the
 Newton flag to "on", just as is the case for non-accelerated pair
 styles.  You can do this with the "-pk" "command-line
-switch"_Section_start.html#start_7.
+switch"_Section_start.html#start_6.
 
 [Or run with the KOKKOS package by editing an input script:]
 
@@ -332,7 +329,7 @@ appropriate thread and GPU values for host=OMP or host=MIC or
 device=CUDA are the same.
 
 You must still use the "-k on" "command-line
-switch"_Section_start.html#start_7 to enable the KOKKOS package, and
+switch"_Section_start.html#start_6 to enable the KOKKOS package, and
 specify its additional arguments for hardware options appropriate to
 your system, as documented above.
 
@@ -343,7 +340,7 @@ pair_style lj/cut/kk 2.5 :pre
 
 You only need to use the "package kokkos"_package.html command if you
 wish to change any of its option defaults, as set by the "-k on"
-"command-line switch"_Section_start.html#start_7.
+"command-line switch"_Section_start.html#start_6.
 
 [Speed-ups to expect:]
 
@@ -389,7 +386,7 @@ If N is the number of physical cores/node, then the number of MPI
 tasks/node * number of threads/task should not exceed N, and should
 typically equal N.  Note that the default threads/task is 1, as set by
 the "t" keyword of the "-k" "command-line
-switch"_Section_start.html#start_7.  If you do not change this, no
+switch"_Section_start.html#start_6.  If you do not change this, no
 additional parallelism (beyond MPI) will be invoked on the host
 CPU(s).
 
@@ -415,21 +412,21 @@ For binding threads with the KOKKOS OMP option, use thread affinity
 environment variables to force binding.  With OpenMP 3.1 (gcc 4.7 or
 later, intel 12 or later) setting the environment variable
 OMP_PROC_BIND=true should be sufficient.  For binding threads with the
-KOKKOS pthreads option, compile LAMMPS the KOKKOS HWLOC=yes option, as
-discussed in "Section 2.3.4"_Sections_start.html#start_3_4 of the
-manual.
+KOKKOS pthreads option, compile LAMMPS the KOKKOS HWLOC=yes option
+(see "this section"_Section_packages.html#KOKKOS of the manual for
+details).
 
 [Running on GPUs:]
 
 Insure the -arch setting in the machine makefile you are using,
-e.g. src/MAKE/Makefile.cuda, is correct for your GPU hardware/software
-(see "this section"_Section_start.html#start_3_4 of the manual for
+e.g. src/MAKE/Makefile.cuda, is correct for your GPU hardware/software.
+(see "this section"_Section_packages.html#KOKKOS of the manual for
 details).
 
 The -np setting of the mpirun command should set the number of MPI
 tasks/node to be equal to the # of physical GPUs on the node.
 
-Use the "-k" "command-line switch"_Section_commands.html#start_7 to
+Use the "-k" "command-line switch"_Section_commands.html#start_6 to
 specify the number of GPUs per node, and the number of threads per MPI
 task.  As above for multi-core CPUs (and no GPU), if N is the number
 of physical cores/node, then the number of MPI tasks/node * number of

doc/src/accelerate_omp.txt

@@ -23,8 +23,7 @@ one or more 16-core nodes.  More details follow.
 use -fopenmp with CCFLAGS and LINKFLAGS in Makefile.machine
 make yes-user-omp
 make mpi                                   # build with USER-OMP package, if settings added to Makefile.mpi
-make omp                                   # or Makefile.omp already has settings
-Make.py -v -p omp -o mpi -a file mpi       # or one-line build via Make.py :pre
+make omp                                   # or Makefile.omp already has settings :pre
 
 lmp_mpi -sf omp -pk omp 16 < in.script                         # 1 MPI task, 16 threads
 mpirun -np 4 lmp_mpi -sf omp -pk omp 4 -in in.script           # 4 MPI tasks, 4 threads/task
@@ -40,14 +39,11 @@ each MPI task running on a CPU.
 
 The lines above illustrate how to include/build with the USER-OMP
 package in two steps, using the "make" command.  Or how to do it with
-one command via the src/Make.py script, described in "Section
-2.4"_Section_start.html#start_4 of the manual.  Type "Make.py -h" for
-help.
+one command as described in "Section 4"_Section_packages.html of the manual.
 
 Note that the CCFLAGS and LINKFLAGS settings in Makefile.machine must
 include "-fopenmp".  Likewise, if you use an Intel compiler, the
-CCFLAGS setting must include "-restrict".  The Make.py command will
-add these automatically.
+CCFLAGS setting must include "-restrict".
 
 [Run with the USER-OMP package from the command line:]
 
@@ -62,14 +58,14 @@ threads/task should not exceed the physical number of cores (on a
 node), otherwise performance will suffer.
 
 As in the lines above, use the "-sf omp" "command-line
-switch"_Section_start.html#start_7, which will automatically append
+switch"_Section_start.html#start_6, which will automatically append
 "omp" to styles that support it.  The "-sf omp" switch also issues a
 default "package omp 0"_package.html command, which will set the
 number of threads per MPI task via the OMP_NUM_THREADS environment
 variable.
 
 You can also use the "-pk omp Nt" "command-line
-switch"_Section_start.html#start_7, to explicitly set Nt = # of OpenMP
+switch"_Section_start.html#start_6, to explicitly set Nt = # of OpenMP
 threads per MPI task to use, as well as additional options.  Its
 syntax is the same as the "package omp"_package.html command whose doc
 page gives details, including the default values used if it is not

doc/src/accelerate_opt.txt

@@ -21,8 +21,7 @@ Here is a quick overview of how to use the OPT package.  More details
 follow.
 
 make yes-opt
-make mpi                               # build with the OPT package
-Make.py -v -p opt -o mpi -a file mpi   # or one-line build via Make.py :pre
+make mpi                               # build with the OPT package :pre
 
 lmp_mpi -sf opt -in in.script                # run in serial
 mpirun -np 4 lmp_mpi -sf opt -in in.script   # run in parallel :pre
@@ -35,18 +34,15 @@ None.
 
 The lines above illustrate how to build LAMMPS with the OPT package in
 two steps, using the "make" command.  Or how to do it with one command
-via the src/Make.py script, described in "Section
-2.4"_Section_start.html#start_4 of the manual.  Type "Make.py -h" for
-help.
+as described in "Section 4"_Section_packages.html of the manual.
 
 Note that if you use an Intel compiler to build with the OPT package,
 the CCFLAGS setting in your Makefile.machine must include "-restrict".
-The Make.py command will add this automatically.
 
 [Run with the OPT package from the command line:]
 
 As in the lines above, use the "-sf opt" "command-line
-switch"_Section_start.html#start_7, which will automatically append
+switch"_Section_start.html#start_6, which will automatically append
 "opt" to styles that support it.
 
 [Or run with the OPT package by editing an input script:]

doc/src/angle_charmm.txt

@@ -63,7 +63,7 @@ LAMMPS"_Section_start.html#start_3 section for more info.
 
 You can specify the accelerated styles explicitly in your input script
 by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
 use the "suffix"_suffix.html command in your input script.
 
 See "Section 5"_Section_accelerate.html of the manual for

doc/src/angle_class2.txt

@@ -94,7 +94,7 @@ LAMMPS"_Section_start.html#start_3 section for more info.
 
 You can specify the accelerated styles explicitly in your input script
 by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
 use the "suffix"_suffix.html command in your input script.
 
 See "Section 5"_Section_accelerate.html of the manual for

doc/src/angle_cosine.txt

@@ -50,7 +50,7 @@ LAMMPS"_Section_start.html#start_3 section for more info.
 
 You can specify the accelerated styles explicitly in your input script
 by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
 use the "suffix"_suffix.html command in your input script.
 
 See "Section 5"_Section_accelerate.html of the manual for

doc/src/angle_cosine_delta.txt

@@ -55,7 +55,7 @@ LAMMPS"_Section_start.html#start_3 section for more info.
 
 You can specify the accelerated styles explicitly in your input script
 by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
 use the "suffix"_suffix.html command in your input script.
 
 See "Section 5"_Section_accelerate.html of the manual for

doc/src/angle_cosine_periodic.txt

@@ -63,7 +63,7 @@ LAMMPS"_Section_start.html#start_3 section for more info.
 
 You can specify the accelerated styles explicitly in your input script
 by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
 use the "suffix"_suffix.html command in your input script.
 
 See "Section 5"_Section_accelerate.html of the manual for

doc/src/angle_cosine_shift.txt

@@ -53,7 +53,7 @@ LAMMPS"_Section_start.html#start_3 section for more info.
 
 You can specify the accelerated styles explicitly in your input script
 by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
 use the "suffix"_suffix.html command in your input script.
 
 See "Section 5"_Section_accelerate.html of the manual for

doc/src/angle_cosine_shift_exp.txt

@@ -65,7 +65,7 @@ LAMMPS"_Section_start.html#start_3 section for more info.
 
 You can specify the accelerated styles explicitly in your input script
 by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
 use the "suffix"_suffix.html command in your input script.
 
 See "Section 5"_Section_accelerate.html of the manual for

doc/src/angle_cosine_squared.txt

@@ -55,7 +55,7 @@ LAMMPS"_Section_start.html#start_3 section for more info.
 
 You can specify the accelerated styles explicitly in your input script
 by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
 use the "suffix"_suffix.html command in your input script.
 
 See "Section 5"_Section_accelerate.html of the manual for

doc/src/angle_fourier.txt

@@ -51,7 +51,7 @@ LAMMPS"_Section_start.html#start_3 section for more info.
 
 You can specify the accelerated styles explicitly in your input script
 by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
 use the "suffix"_suffix.html command in your input script.
 
 See "Section 5"_Section_accelerate.html of the manual for

doc/src/angle_fourier_simple.txt

@@ -50,7 +50,7 @@ LAMMPS"_Section_start.html#start_3 section for more info.
 
 You can specify the accelerated styles explicitly in your input script
 by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
 use the "suffix"_suffix.html command in your input script.
 
 See "Section 5"_Section_accelerate.html of the manual for

doc/src/angle_harmonic.txt

@@ -57,7 +57,7 @@ LAMMPS"_Section_start.html#start_3 section for more info.
 
 You can specify the accelerated styles explicitly in your input script
 by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
 use the "suffix"_suffix.html command in your input script.
 
 See "Section 5"_Section_accelerate.html of the manual for

doc/src/angle_quartic.txt

@@ -57,7 +57,7 @@ LAMMPS"_Section_start.html#start_3 section for more info.
 
 You can specify the accelerated styles explicitly in your input script
 by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
 use the "suffix"_suffix.html command in your input script.
 
 See "Section 5"_Section_accelerate.html of the manual for

doc/src/angle_sdk.txt

@@ -46,7 +46,7 @@ from the pair_style.
 [Restrictions:]
 
 This angle style can only be used if LAMMPS was built with the
-USER-CG-CMM package.  See the "Making
+USER-CGSDK package.  See the "Making
 LAMMPS"_Section_start.html#start_3 section for more info on packages.
 
 [Related commands:]

doc/src/angle_table.txt

@@ -136,7 +136,7 @@ LAMMPS"_Section_start.html#start_3 section for more info.
 
 You can specify the accelerated styles explicitly in your input script
 by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
 use the "suffix"_suffix.html command in your input script.
 
 See "Section 5"_Section_accelerate.html of the manual for

doc/src/balance.txt

@@ -394,7 +394,7 @@ weights.  It assigns the same weight to each particle owned by a
 processor based on the total computational time spent by that
 processor.  See details below on what time window is used.  It uses
 the same timing information as is used for the "MPI task timing
-breakdown"_Section_start.html#start_8, namely, for sections {Pair},
+breakdown"_Section_start.html#start_7, namely, for sections {Pair},
 {Bond}, {Kspace}, and {Neigh}.  The time spent in those portions of
 the timestep are measured for each MPI rank, summed, then divided by
 the number of particles owned by that processor.  I.e. the weight is

doc/src/bond_class2.txt

@@ -56,7 +56,7 @@ LAMMPS"_Section_start.html#start_3 section for more info.
 
 You can specify the accelerated styles explicitly in your input script
 by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
 use the "suffix"_suffix.html command in your input script.
 
 See "Section 5"_Section_accelerate.html of the manual for

doc/src/bond_fene.txt

@@ -59,7 +59,7 @@ LAMMPS"_Section_start.html#start_3 section for more info.
 
 You can specify the accelerated styles explicitly in your input script
 by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
 use the "suffix"_suffix.html command in your input script.
 
 See "Section 5"_Section_accelerate.html of the manual for

doc/src/bond_fene_expand.txt

@@ -62,7 +62,7 @@ LAMMPS"_Section_start.html#start_3 section for more info.
 
 You can specify the accelerated styles explicitly in your input script
 by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
 use the "suffix"_suffix.html command in your input script.
 
 See "Section 5"_Section_accelerate.html of the manual for

doc/src/bond_harmonic.txt

@@ -54,7 +54,7 @@ LAMMPS"_Section_start.html#start_3 section for more info.
 
 You can specify the accelerated styles explicitly in your input script
 by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
 use the "suffix"_suffix.html command in your input script.
 
 See "Section 5"_Section_accelerate.html of the manual for

doc/src/bond_harmonic_shift.txt

@@ -55,7 +55,7 @@ LAMMPS"_Section_start.html#start_3 section for more info.
 
 You can specify the accelerated styles explicitly in your input script
 by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
 use the "suffix"_suffix.html command in your input script.
 
 See "Section 5"_Section_accelerate.html of the manual for

doc/src/bond_harmonic_shift_cut.txt

@@ -55,7 +55,7 @@ LAMMPS"_Section_start.html#start_3 section for more info.
 
 You can specify the accelerated styles explicitly in your input script
 by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
 use the "suffix"_suffix.html command in your input script.
 
 See "Section 5"_Section_accelerate.html of the manual for

doc/src/bond_morse.txt

@@ -53,7 +53,7 @@ LAMMPS"_Section_start.html#start_3 section for more info.
 
 You can specify the accelerated styles explicitly in your input script
 by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
 use the "suffix"_suffix.html command in your input script.
 
 See "Section 5"_Section_accelerate.html of the manual for

doc/src/bond_nonlinear.txt

@@ -53,7 +53,7 @@ LAMMPS"_Section_start.html#start_3 section for more info.
 
 You can specify the accelerated styles explicitly in your input script
 by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
 use the "suffix"_suffix.html command in your input script.
 
 See "Section 5"_Section_accelerate.html of the manual for

doc/src/bond_oxdna.txt

@@ -7,25 +7,30 @@
 :line
 
 bond_style oxdna/fene command :h3
+bond_style oxdna2/fene command :h3
 
 [Syntax:]
 
 bond_style oxdna/fene :pre
+bond_style oxdna2/fene :pre
 
 [Examples:]
 
 bond_style oxdna/fene
 bond_coeff * 2.0 0.25 0.7525 :pre
 
+bond_style oxdna2/fene
+bond_coeff * 2.0 0.25 0.7564 :pre
+
 [Description:]
 
-The {oxdna/fene} bond style uses the potential
+The {oxdna/fene} and {oxdna2/fene} bond styles use the potential
 
 :c,image(Eqs/bond_oxdna_fene.jpg)
 
 to define a modified finite extensible nonlinear elastic (FENE) potential
 "(Ouldridge)"_#oxdna_fene to model the connectivity of the phosphate backbone
-in the oxDNA force field for coarse-grained modelling of DNA. 
+in the oxDNA force field for coarse-grained modelling of DNA.
 
 The following coefficients must be defined for the bond type via the
 "bond_coeff"_bond_coeff.html command as given in the above example, or in
@@ -36,13 +41,14 @@ epsilon (energy)
 Delta (distance)
 r0 (distance) :ul
 
-NOTE: This bond style has to be used together with the corresponding oxDNA pair styles
+NOTE: The oxDNA bond style has to be used together with the corresponding oxDNA pair styles
 for excluded volume interaction {oxdna/excv}, stacking {oxdna/stk}, cross-stacking {oxdna/xstk}
-and coaxial stacking interaction {oxdna/coaxstk} as well as hydrogen-bonding interaction {oxdna/hbond} (see also documentation of 
-"pair_style oxdna/excv"_pair_oxdna.html). The coefficients 
-in the above example have to be kept fixed and cannot be changed without reparametrizing the entire model.
+and coaxial stacking interaction {oxdna/coaxstk} as well as hydrogen-bonding interaction {oxdna/hbond} (see also documentation of
+"pair_style oxdna/excv"_pair_oxdna.html). For the oxDNA2 "(Snodin)"_#oxdna2 bond style the analogous pair styles and an additional Debye-Hueckel pair
+style {oxdna2/dh} have to be defined.
+The coefficients in the above example have to be kept fixed and cannot be changed without reparametrizing the entire model.
 
-Example input and data files can be found in examples/USER/cgdna/examples/duplex1/ and /duplex2/.
+Example input and data files for DNA duplexes can be found in examples/USER/cgdna/examples/oxDNA/ and /oxDNA2/.
 A simple python setup tool which creates single straight or helical DNA strands,
 DNA duplexes or arrays of DNA duplexes can be found in examples/USER/cgdna/util/.
 A technical report with more information on the model, the structure of the input file,
@@ -60,7 +66,7 @@ LAMMPS"_Section_start.html#start_3 section for more info on packages.
 
 [Related commands:]
 
-"pair_style oxdna/excv"_pair_oxdna.html, "fix nve/dotc/langevin"_fix_nve_dotc_langevin.html, "bond_coeff"_bond_coeff.html 
+"pair_style oxdna/excv"_pair_oxdna.html, "pair_style oxdna2/excv"_pair_oxdna2.html, "fix nve/dotc/langevin"_fix_nve_dotc_langevin.html, "bond_coeff"_bond_coeff.html
 
 [Default:] none
 
@@ -68,3 +74,6 @@ LAMMPS"_Section_start.html#start_3 section for more info on packages.
 
 :link(oxdna_fene)
 [(Ouldridge)] T.E. Ouldridge, A.A. Louis, J.P.K. Doye, J. Chem. Phys. 134, 085101 (2011).
+
+:link(oxdna2)
+[(Snodin)] B.E. Snodin, F. Randisi, M. Mosayebi, et al., J. Chem. Phys. 142, 234901 (2015).

doc/src/bond_quartic.txt

@@ -88,7 +88,7 @@ LAMMPS"_Section_start.html#start_3 section for more info.
 
 You can specify the accelerated styles explicitly in your input script
 by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
 use the "suffix"_suffix.html command in your input script.
 
 See "Section 5"_Section_accelerate.html of the manual for

doc/src/bond_table.txt

@@ -133,7 +133,7 @@ LAMMPS"_Section_start.html#start_3 section for more info.
 
 You can specify the accelerated styles explicitly in your input script
 by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
 use the "suffix"_suffix.html command in your input script.
 
 See "Section 5"_Section_accelerate.html of the manual for

doc/src/commands.txt

@@ -32,12 +32,12 @@ Commands :h1
    dimension
    displace_atoms
    dump
-   dump_custom_vtk
    dump_h5md
    dump_image
    dump_modify
    dump_molfile
-   dump_nc
+   dump_netcdf
+   dump_vtk
    echo
    fix
    fix_modify

doc/src/compute_cna_atom.txt

@@ -26,7 +26,7 @@ Define a computation that calculates the CNA (Common Neighbor
 Analysis) pattern for each atom in the group.  In solid-state systems
 the CNA pattern is a useful measure of the local crystal structure
 around an atom.  The CNA methodology is described in "(Faken)"_#Faken
-and "(Tsuzuki)"_#Tsuzuki.
+and "(Tsuzuki)"_#Tsuzuki1.
 
 Currently, there are five kinds of CNA patterns LAMMPS recognizes:
 
@@ -93,5 +93,5 @@ above.
 :link(Faken)
 [(Faken)] Faken, Jonsson, Comput Mater Sci, 2, 279 (1994).
 
-:link(Tsuzuki)
+:link(Tsuzuki1)
 [(Tsuzuki)] Tsuzuki, Branicio, Rino, Comput Phys Comm, 177, 518 (2007).

doc/src/compute_cnp_atom.txt

@@ -0,0 +1,111 @@
+"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
+
+:link(lws,http://lammps.sandia.gov)
+:link(ld,Manual.html)
+:link(lc,Section_commands.html#comm)
+
+:line
+
+compute cnp/atom command :h3
+
+[Syntax:]
+
+compute ID group-ID cnp/atom cutoff :pre
+
+ID, group-ID are documented in "compute"_compute.html command
+cnp/atom = style name of this compute command
+cutoff = cutoff distance for nearest neighbors (distance units) :ul
+
+[Examples:]
+
+compute 1 all cnp/atom 3.08 :pre
+
+[Description:]
+
+Define a computation that calculates the Common Neighborhood
+Parameter (CNP) for each atom in the group.  In solid-state systems
+the CNP is a useful measure of the local crystal structure
+around an atom and can be used to characterize whether the
+atom is part of a perfect lattice, a local defect (e.g. a dislocation
+or stacking fault), or at a surface.
+
+The value of the CNP parameter will be 0.0 for atoms not in the
+specified compute group.  Note that normally a CNP calculation should
+only be performed on single component systems.
+
+This parameter is computed using the following formula from
+"(Tsuzuki)"_#Tsuzuki2
+
+:c,image(Eqs/cnp_eq.jpg)
+
+where the index {j} goes over the {n}i nearest neighbors of atom
+{i}, and the index {k} goes over the {n}ij common nearest neighbors
+between atom {i} and atom {j}. Rik and Rjk are the vectors connecting atom
+{k} to atoms {i} and {j}.  The quantity in the double sum is computed
+for each atom.
+
+The CNP calculation is sensitive to the specified cutoff value.
+You should ensure that the appropriate nearest neighbors of an atom are
+found within the cutoff distance for the presumed crystal structure.
+E.g. 12 nearest neighbor for perfect FCC and HCP crystals, 14 nearest
+neighbors for perfect BCC crystals.  These formulas can be used to
+obtain a good cutoff distance:
+
+:c,image(Eqs/cnp_cutoff.jpg)
+
+where a is the lattice constant for the crystal structure concerned
+and in the HCP case, x = (c/a) / 1.633, where 1.633 is the ideal c/a
+for HCP crystals.
+
+Also note that since the CNP calculation in LAMMPS uses the neighbors
+of an owned atom to find the nearest neighbors of a ghost atom, the
+following relation should also be satisfied:
+
+:c,image(Eqs/cnp_cutoff2.jpg)
+
+where Rc is the cutoff distance of the potential, Rs is the skin
+distance as specified by the "neighbor"_neighbor.html command, and
+cutoff is the argument used with the compute cnp/atom command.  LAMMPS
+will issue a warning if this is not the case.
+
+The neighbor list needed to compute this quantity is constructed each
+time the calculation is performed (e.g. each time a snapshot of atoms
+is dumped).  Thus it can be inefficient to compute/dump this quantity
+too frequently or to have multiple compute/dump commands, each with a
+{cnp/atom} style.
+
+[Output info:]
+
+This compute calculates a per-atom vector, which can be accessed by
+any command that uses per-atom values from a compute as input.  See
+"Section 6.15"_Section_howto.html#howto_15 for an overview of
+LAMMPS output options.
+
+The per-atom vector values will be real positive numbers. Some typical CNP
+values:
+
+FCC lattice = 0.0
+BCC lattice = 0.0
+HCP lattice = 4.4 :pre
+
+FCC (111) surface ~ 13.0
+FCC (100) surface ~ 26.5
+FCC dislocation core ~ 11 :pre
+
+[Restrictions:]
+
+This compute is part of the USER-MISC package.  It is only enabled if
+LAMMPS was built with that package.  See the "Making
+LAMMPS"_Section_start.html#start_3 section for more info.
+
+[Related commands:]
+
+"compute cna/atom"_compute_cna_atom.html
+"compute centro/atom"_compute_centro_atom.html
+
+[Default:] none
+
+:line
+
+:link(Tsuzuki2)
+[(Tsuzuki)] Tsuzuki, Branicio, Rino, Comput Phys Comm, 177, 518 (2007).

doc/src/compute_modify.txt

@@ -54,7 +54,7 @@ adding atoms or molecules to the system (see the "fix
 pour"_fix_pour.html, "fix deposit"_fix_deposit.html, and "fix
 gcmc"_fix_gcmc.html commands) or expect atoms or molecules to be lost
 (e.g. due to exiting the simulation box or via "fix
-evaporation"_fix_evaporation.html), then this option should be used to
+evaporate"_fix_evaporate.html), then this option should be used to
 insure the temperature is correctly normalized.
 
 NOTE: The {extra} and {dynamic} keywords should not be used as they

doc/src/compute_pair_local.txt

@@ -76,7 +76,9 @@ command for the types of the two atoms is used.  For the {radius}
 setting, the sum of the radii of the two particles is used as a
 cutoff.  For example, this is appropriate for granular particles which
 only interact when they are overlapping, as computed by "granular pair
-styles"_pair_gran.txt.
+styles"_pair_gran.txt.  Note that if a granular model defines atom
+types such that all particles of a specific type are monodisperse
+(same diameter), then the two settings are effectively identical.
 
 Note that as atoms migrate from processor to processor, there will be
 no consistent ordering of the entries within the local vector or array

doc/src/compute_pressure.txt

@@ -117,7 +117,7 @@ LAMMPS"_Section_start.html#start_3 section for more info.
 
 You can specify the accelerated styles explicitly in your input script
 by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
 use the "suffix"_suffix.html command in your input script.
 
 See "Section 5"_Section_accelerate.html of the manual for

doc/src/compute_property_local.txt

@@ -79,6 +79,9 @@ the two atoms is used.  For the {radius} setting, the sum of the radii
 of the two particles is used as a cutoff.  For example, this is
 appropriate for granular particles which only interact when they are
 overlapping, as computed by "granular pair styles"_pair_gran.html.
+Note that if a granular model defines atom types such that all
+particles of a specific type are monodisperse (same diameter), then
+the two settings are effectively identical.
 
 If the inputs are bond, angle, etc attributes, the local data is
 generated by looping over all the atoms owned on a processor and

doc/src/compute_rdf.txt

@@ -180,9 +180,18 @@ will register an arbitrarily large spike at whatever distance they
 happen to be at, and zero everywhere else.  Coord(r) will show a step
 change from zero to one at the location of the spike in g(r).
 
+NOTE: compute rdf can handle dynamic groups and systems where atoms
+are added or removed, but this causes that certain normalization
+parameters need to be recomputed in every step and include collective
+communication operations. This will reduce performance and limit
+parallel efficiency and scaling. For systems, where only the type
+of atoms changes (e.g. when using "fix atom/swap"_fix_atom_swap.html),
+you need to explicitly request the dynamic normalization updates
+via "compute_modify dynamic yes"_compute_modify.html
+
 [Related commands:]
 
-"fix ave/time"_fix_ave_time.html
+"fix ave/time"_fix_ave_time.html, "compute_modify"_compute_modify.html
 
 [Default:]
 

doc/src/compute_saed.txt

@@ -111,26 +111,26 @@ Coefficients parameterized by "(Fox)"_#Fox are assigned for each
 atom type designating the chemical symbol and charge of each atom
 type. Valid chemical symbols for compute saed are:
 
-         H:      He:      Li:      Be:       B:
-         C:       N:       O:       F:      Ne:
-        Na:      Mg:      Al:      Si:       P:
-         S:      Cl:      Ar:       K:      Ca:
-        Sc:      Ti:       V:      Cr:      Mn:
-        Fe:      Co:      Ni:      Cu:      Zn:
-        Ga:      Ge:      As:      Se:      Br:
-        Kr:      Rb:      Sr:       Y:      Zr:
-        Nb:      Mo:      Tc:      Ru:      Rh:
-        Pd:      Ag:      Cd:      In:      Sn:
-        Sb:      Te:       I:      Xe:      Cs:
-        Ba:      La:      Ce:      Pr:      Nd:
-        Pm:      Sm:      Eu:      Gd:      Tb:
-        Dy:      Ho:      Er:      Tm:      Yb:
-        Lu:      Hf:      Ta:       W:      Re:
-        Os:      Ir:      Pt:      Au:      Hg:
-        Tl:      Pb:      Bi:      Po:      At:
-        Rn:      Fr:      Ra:      Ac:      Th:
-        Pa:       U:      Np:      Pu:      Am:
-        Cm:      Bk:      Cf:tb(c=5,s=:)
+H:       He:      Li:      Be:       B:
+C:        N:       O:       F:      Ne:
+Na:      Mg:      Al:      Si:       P:
+S:       Cl:      Ar:       K:      Ca:
+Sc:      Ti:       V:      Cr:      Mn:
+Fe:      Co:      Ni:      Cu:      Zn:
+Ga:      Ge:      As:      Se:      Br:
+Kr:      Rb:      Sr:       Y:      Zr:
+Nb:      Mo:      Tc:      Ru:      Rh:
+Pd:      Ag:      Cd:      In:      Sn:
+Sb:      Te:       I:      Xe:      Cs:
+Ba:      La:      Ce:      Pr:      Nd:
+Pm:      Sm:      Eu:      Gd:      Tb:
+Dy:      Ho:      Er:      Tm:      Yb:
+Lu:      Hf:      Ta:       W:      Re:
+Os:      Ir:      Pt:      Au:      Hg:
+Tl:      Pb:      Bi:      Po:      At:
+Rn:      Fr:      Ra:      Ac:      Th:
+Pa:       U:      Np:      Pu:      Am:
+Cm:      Bk:      Cf:tb(c=5,s=:)
 
 
 If the {echo} keyword is specified, compute saed will provide extra

doc/src/compute_sna_atom.txt

@@ -24,7 +24,7 @@ twojmax = band limit for bispectrum components (non-negative integer) :l
 R_1, R_2,... = list of cutoff radii, one for each type (distance units) :l
 w_1, w_2,... = list of neighbor weights, one for each type  :l
 zero or more keyword/value pairs may be appended :l
-keyword = {diagonal} or {rmin0} or {switchflag} or {bzeroflag} :l
+keyword = {diagonal} or {rmin0} or {switchflag} or {bzeroflag} or {quadraticflag}:l
   {diagonal} value = {0} or {1} or {2} or {3}
      {0} = all j1, j2, j <= twojmax, j2 <= j1
      {1} = subset satisfying j1 == j2
@@ -36,7 +36,10 @@ keyword = {diagonal} or {rmin0} or {switchflag} or {bzeroflag} :l
      {1} = use switching function
   {bzeroflag} value = {0} or {1}
      {0} = do not subtract B0
-     {1} = subtract B0 :pre
+     {1} = subtract B0
+  {quadraticflag} value = {0} or {1}
+     {0} = do not generate quadratic terms
+     {1} = generate quadratic terms :pre
 :ule
 
 [Examples:]
@@ -151,7 +154,7 @@ linear mapping from radial distance to polar angle {theta0} on the
 The argument {twojmax} and the keyword {diagonal} define which
 bispectrum components are generated. See section below on output for a
 detailed explanation of the number of bispectrum components and the
-ordered in which they are listed
+ordered in which they are listed.
 
 The keyword {switchflag} can be used to turn off the switching
 function.
@@ -162,6 +165,14 @@ the calculated bispectrum components. This optional keyword is only
 available for compute {sna/atom}, as {snad/atom} and {snav/atom}
 are unaffected by the removal of constant terms.
 
+The keyword {quadraticflag} determines whether or not the
+quadratic analogs to the bispectrum quantities are generated.
+These are formed by taking the outer product of the vector
+of bispectrum components with itself.
+See section below on output for a
+detailed explanation of the number of quadratic terms and the
+ordered in which they are listed.
+
 NOTE: If you have a bonded system, then the settings of
 "special_bonds"_special_bonds.html command can remove pairwise
 interactions between atoms in the same bond, angle, or dihedral.  This
@@ -180,7 +191,7 @@ command that includes all pairs in the neighbor list.
 
 Compute {sna/atom} calculates a per-atom array, each column
 corresponding to a particular bispectrum component.  The total number
-of columns and the identities of the bispectrum component contained in
+of columns and the identity of the bispectrum component contained in
 each column depend on the values of {twojmax} and {diagonal}, as
 described by the following piece of python code:
 
@@ -213,6 +224,20 @@ block contains six sub-blocks corresponding to the {xx}, {yy}, {zz},
 notation.  Each of these sub-blocks contains one column for each
 bispectrum component, the same as for compute {sna/atom}
 
+For example, if {K}=30 and ntypes=1, the number of columns in the per-atom
+arrays generated by {sna/atom}, {snad/atom}, and {snav/atom}
+are 30, 90, and 180, respectively. With {quadratic} value=1,
+the numbers of columns are 930, 2790, and 5580, respectively.
+
+If the {quadratic} keyword value is set to 1, then additional
+columns are appended to each per-atom array, corresponding to
+the products of all distinct pairs of  bispectrum components. If the
+number of bispectrum components is {K}, then the number of distinct pairs
+is  {K}({K}+1)/2. These are output in subblocks of  {K}({K}+1)/2 columns, using the same
+ordering of sub-blocks as was used for the bispectrum
+components. Within each sub-block, the ordering is upper-triangular,
+(1,1),(1,2)...(1,{K}),(2,1)...({K}-1,{K}-1),({K}-1,{K}),({K},{K})
+
 These values can be accessed by any command that uses per-atom values
 from a compute as input.  See "Section
 6.15"_Section_howto.html#howto_15 for an overview of LAMMPS output
@@ -231,7 +256,7 @@ LAMMPS"_Section_start.html#start_3 section for more info.
 [Default:]
 
 The optional keyword defaults are {diagonal} = 0, {rmin0} = 0,
-{switchflag} = 1, {bzeroflag} = 0.
+{switchflag} = 1, {bzeroflag} = 1, {quadraticflag} = 0,
 
 :line
 

doc/src/compute_temp.txt

@@ -79,7 +79,7 @@ LAMMPS"_Section_start.html#start_3 section for more info.
 
 You can specify the accelerated styles explicitly in your input script
 by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
 use the "suffix"_suffix.html command in your input script.
 
 See "Section 5"_Section_accelerate.html of the manual for

doc/src/compute_temp_partial.txt

@@ -86,7 +86,7 @@ LAMMPS"_Section_start.html#start_3 section for more info.
 
 You can specify the accelerated styles explicitly in your input script
 by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
 use the "suffix"_suffix.html command in your input script.
 
 See "Section 5"_Section_accelerate.html of the manual for