patch 6Jul17

bugfix for fix msst

.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)_
+
+

doc/Makefile

@@ -6,6 +6,7 @@ BUILDDIR      = /tmp/lammps-docs-$(SHA1)
 RSTDIR        = $(BUILDDIR)/rst
 VENV          = $(BUILDDIR)/docenv
 TXT2RST       = $(VENV)/bin/txt2rst
+ANCHORCHECK   = $(VENV)/bin/doc_anchor_check
 
 PYTHON        = $(shell which python3)
 HAS_PYTHON3    = NO
@@ -22,7 +23,7 @@ endif
 SOURCES=$(wildcard src/*.txt)
 OBJECTS=$(SOURCES:src/%.txt=$(RSTDIR)/%.rst)
 
-.PHONY: help clean-all clean epub html pdf old venv spelling
+.PHONY: help clean-all clean epub html pdf old venv spelling anchor_check
 
 # ------------------------------------------
 
@@ -36,6 +37,7 @@ help:
 	@echo "  clean      remove all intermediate RST files"
 	@echo "  clean-all  reset the entire build environment"
 	@echo "  txt2html   build txt2html tool"
+	@echo "  anchor_check  scan for duplicate anchor labels"
 
 # ------------------------------------------
 
@@ -49,11 +51,14 @@ clean:
 clean-spelling:
 	rm -rf spelling
 
-html: $(OBJECTS)
+html: $(OBJECTS) $(ANCHORCHECK)
 	@(\
 		. $(VENV)/bin/activate ;\
 		cp -r src/* $(RSTDIR)/ ;\
 		sphinx-build -j 8 -b html -c utils/sphinx-config -d $(BUILDDIR)/doctrees $(RSTDIR) html ;\
+		echo "############################################" ;\
+		doc_anchor_check src/*.txt ;\
+		echo "############################################" ;\
 		deactivate ;\
 	)
 	-rm html/searchindex.js
@@ -95,6 +100,7 @@ epub: $(OBJECTS)
 
 pdf: utils/txt2html/txt2html.exe
 	@(\
+		set -e; \
 		cd src; \
 		../utils/txt2html/txt2html.exe -b *.txt; \
 		htmldoc --batch lammps.book;          \
@@ -127,6 +133,13 @@ fetch:
 
 txt2html: utils/txt2html/txt2html.exe
 
+anchor_check : $(ANCHORCHECK)
+	@(\
+		. $(VENV)/bin/activate ;\
+		doc_anchor_check src/*.txt ;\
+		deactivate ;\
+	)
+
 # ------------------------------------------
 
 utils/txt2html/txt2html.exe: utils/txt2html/txt2html.cpp
@@ -146,12 +159,12 @@ $(VENV):
 	@( \
 		virtualenv -p $(PYTHON) $(VENV); \
 		. $(VENV)/bin/activate; \
-		pip install Sphinx; \
+		pip install Sphinx==1.5.6; \
 		pip install sphinxcontrib-images; \
 		deactivate;\
 	)
 
-$(TXT2RST): $(VENV)
+$(TXT2RST) $(ANCHORCHECK): $(VENV)
 	@( \
 		. $(VENV)/bin/activate; \
 		(cd utils/converters;\

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/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/Eqs/pair_momb.tex

@@ -0,0 +1,13 @@
+\documentclass[12pt,fleqn]{article}
+\usepackage{amsmath}
+\thispagestyle{empty}
+
+\begin{document}
+
+\setlength{\jot}{2ex}
+\begin{gather*}
+  E = D_0 [\exp^{-2 \alpha (r-r_0)} - 2\exp^{-\alpha (r-r_0)}] - s_6 \frac{C_6}{r^6} f_{damp}(r,R_r) \\
+  f_{damp}(r,R_r) = \frac{1}{1 + \exp^{-d(r/R_r - 1)}}
+\end{gather*}
+
+\end{document}

doc/src/Manual.txt

@@ -1,7 +1,7 @@
 <!-- HTML_ONLY -->
 <HEAD>
 <TITLE>LAMMPS Users Manual</TITLE>
-<META NAME="docnumber" CONTENT="7 Mar 2017 version">
+<META NAME="docnumber" CONTENT="6 Jul 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
-7 Mar 2017 version :c,h4
+6 Jul 2017 version :c,h4
 
 Version info: :h4
 
@@ -39,7 +39,7 @@ directory name created when you unpack a tarball, and at the top of
 the first page of the manual (this page).
 
 If you browse the HTML doc pages on the LAMMPS WWW site, they always
-describe the most current version of LAMMPS. :ulb,l
+describe the most current [development] version of LAMMPS. :ulb,l
 
 If you browse the HTML doc pages included in your tarball, they
 describe the version you have. :l
@@ -67,7 +67,7 @@ Labs and Temple University:
 
 "Steve Plimpton"_sjp, sjplimp at sandia.gov :ulb,l
 Aidan Thompson, athomps at sandia.gov :l
-Stan Moore, stamoore at sandia.gov :l
+Stan Moore, stamoor at sandia.gov :l
 "Axel Kohlmeyer"_ako, akohlmey at gmail.com :l
 :ule
 
@@ -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

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,
@@ -687,6 +688,7 @@ package"_Section_start.html#start_3.
 "eos/cv"_fix_eos_cv.html,
 "eos/table"_fix_eos_table.html,
 "eos/table/rx"_fix_eos_table_rx.html,
+"filter/corotate"_fix_filter_corotate.html,
 "flow/gauss"_fix_flow_gauss.html,
 "gle"_fix_gle.html,
 "grem"_fix_grem.html,
@@ -715,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,
@@ -829,6 +831,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,
@@ -930,6 +933,8 @@ KOKKOS, o = USER-OMP, t = OPT.
 "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,
@@ -939,6 +944,8 @@ KOKKOS, o = USER-OMP, t = OPT.
 "lj/charmm/coul/charmm/implicit (ko)"_pair_charmm.html,
 "lj/charmm/coul/long (giko)"_pair_charmm.html,
 "lj/charmm/coul/msm"_pair_charmm.html,
+"lj/charmmfsw/coul/charmmfsh"_pair_charmm.html,
+"lj/charmmfsw/coul/long"_pair_charmm.html,
 "lj/class2 (gko)"_pair_class2.html,
 "lj/class2/coul/cut (ko)"_pair_class2.html,
 "lj/class2/coul/long (gko)"_pair_class2.html,
@@ -957,7 +964,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,
@@ -979,6 +986,7 @@ 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,
 "resquared (go)"_pair_resquared.html,
@@ -1013,6 +1021,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,
@@ -1030,10 +1039,11 @@ 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,
+"momb"_pair_momb.html,
 "morse/smooth/linear"_pair_morse.html,
 "morse/soft"_pair_morse.html,
 "multi/lucy"_pair_multi_lucy.html,
@@ -1043,8 +1053,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,
@@ -1092,7 +1106,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
 
@@ -1146,6 +1161,7 @@ USER-OMP, t = OPT.
 "zero"_dihedral_zero.html,
 "hybrid"_dihedral_hybrid.html,
 "charmm (ko)"_dihedral_charmm.html,
+"charmmfsw"_dihedral_charmm.html,
 "class2 (ko)"_dihedral_class2.html,
 "harmonic (io)"_dihedral_harmonic.html,
 "helix (o)"_dihedral_helix.html,
@@ -1210,7 +1226,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

@@ -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 "special_bonds extra" command
+(or the "read_data 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 special_bonds extra command
+(or the read_data 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

@@ -25,9 +25,7 @@ files and image files.
 
 If you uncomment the "dump"_dump.html command in the input script, a
 text dump file will be produced, which can be animated by various
-"visualization programs"_http://lammps.sandia.gov/viz.html.  It can
-also be animated using the xmovie tool described in the "Additional
-Tools"_Section_tools.html section of the LAMMPS documentation.
+"visualization programs"_http://lammps.sandia.gov/viz.html.
 
 If you uncomment the "dump image"_dump.html command in the input
 script, and assuming you have built LAMMPS with a JPG library, JPG
@@ -53,9 +51,11 @@ Lowercase directories :h4
 accelerate: run with various acceleration options (OpenMP, GPU, Phi)
 balance:  dynamic load balancing, 2d system
 body:     body particles, 2d system
+cmap:     CMAP 5-body contributions to CHARMM force field
 colloid:  big colloid particles in a small particle solvent, 2d system
 comb:     models using the COMB potential
 coreshell: core/shell model using CORESHELL package
+controller: use of fix controller as a thermostat
 crack:    crack propagation in a 2d solid
 deposit:  deposit atoms and molecules on a surface
 dipole:   point dipolar particles, 2d system
@@ -64,6 +64,8 @@ eim:      NaCl using the EIM potential
 ellipse:  ellipsoidal particles in spherical solvent, 2d system
 flow:     Couette and Poiseuille flow in a 2d channel
 friction: frictional contact of spherical asperities between 2d surfaces
+gcmc:     Grand Canonical Monte Carlo (GCMC) via the fix gcmc command
+granregion: use of fix wall/region/gran as boundary on granular particles
 hugoniostat: Hugoniostat shock dynamics
 indent:   spherical indenter into a 2d solid
 kim:      use of potentials in Knowledge Base for Interatomic Models (KIM)
@@ -71,6 +73,7 @@ meam:     MEAM test for SiC and shear (same as shear examples)
 melt:     rapid melt of 3d LJ system
 micelle:  self-assembly of small lipid-like molecules into 2d bilayers
 min:      energy minimization of 2d LJ melt
+mscg:     parameterize a multi-scale coarse-graining (MSCG) model
 msst:     MSST shock dynamics
 nb3b:     use of nonbonded 3-body harmonic pair style
 neb:      nudged elastic band (NEB) calculation for barrier finding
@@ -89,7 +92,8 @@ snap:     NVE dynamics for BCC tantalum crystal using SNAP potential
 srd:      stochastic rotation dynamics (SRD) particles as solvent
 streitz:  use of Streitz/Mintmire potential with charge equilibration
 tad:      temperature-accelerated dynamics of vacancy diffusion in bulk Si
-vashishta: use of the Vashishta potential :tb(s=:)
+vashishta: use of the Vashishta potential
+voronoi:  Voronoi tesselation via compute voronoi/atom command :tb(s=:)
 
 Here is how you can run and visualize one of the sample problems:
 

doc/src/Section_howto.txt

@@ -165,9 +165,16 @@ Many of the example input scripts included in the LAMMPS distribution
 are for 2d models.
 
 NOTE: Some models in LAMMPS treat particles as finite-size spheres, as
-opposed to point particles.  In 2d, the particles will still be
-spheres, not disks, meaning their moment of inertia will be the same
-as in 3d.
+opposed to point particles.  See the "atom_style
+sphere"_atom_style.html and "fix nve/sphere"_fix_nve_sphere.html
+commands for details.  By default, for 2d simulations, such particles
+will still be modeled as 3d spheres, not 2d discs (circles), meaning
+their moment of inertia will be that of a sphere.  If you wish to
+model them as 2d discs, see the "set density/disc"_set.html command
+and the {disc} option for the "fix nve/sphere"_fix_nve_sphere.html,
+"fix nvt/sphere"_fix_nvt_sphere.html, "fix
+nph/sphere"_fix_nph_sphere.html, "fix npt/sphere"_fix_npt_sphere.html
+commands.
 
 :line
 
@@ -197,7 +204,10 @@ documentation for the formula it computes.
 
 "bond_style"_bond_harmonic.html harmonic
 "angle_style"_angle_charmm.html charmm
+"dihedral_style"_dihedral_charmm.html charmmfsh
 "dihedral_style"_dihedral_charmm.html charmm
+"pair_style"_pair_charmm.html lj/charmmfsw/coul/charmmfsh
+"pair_style"_pair_charmm.html lj/charmmfsw/coul/long
 "pair_style"_pair_charmm.html lj/charmm/coul/charmm
 "pair_style"_pair_charmm.html lj/charmm/coul/charmm/implicit
 "pair_style"_pair_charmm.html lj/charmm/coul/long :ul
@@ -205,6 +215,12 @@ documentation for the formula it computes.
 "special_bonds"_special_bonds.html charmm
 "special_bonds"_special_bonds.html amber :ul
 
+NOTE: For CHARMM, newer {charmmfsw} or {charmmfsh} styles were
+released in March 2017.  We recommend they be used instead of the
+older {charmm} styles.  See discussion of the differences on the "pair
+charmm"_pair_charmm.html and "dihedral charmm"_dihedral_charmm.html
+doc pages.
+
 DREIDING is a generic force field developed by the "Goddard
 group"_http://www.wag.caltech.edu at Caltech and is useful for
 predicting structures and dynamics of organic, biological and
@@ -434,6 +450,12 @@ computations between frozen atoms by using this command:
 
 "neigh_modify"_neigh_modify.html exclude :ul
 
+NOTE: By default, for 2d systems, granular particles are still modeled
+as 3d spheres, not 2d discs (circles), meaning their moment of inertia
+will be the same as in 3d.  If you wish to model granular particles in
+2d as 2d discs, see the note on this topic in "Section
+6.2"_Section_howto.html#howto_2, where 2d simulations are disussed.
+
 :line
 
 6.7 TIP3P water model :link(howto_7),h4
@@ -451,7 +473,7 @@ atoms and the water molecule to run a rigid TIP3P-CHARMM model with a
 cutoff.  The K values can be used if a flexible TIP3P model (without
 fix shake) is desired.  If the LJ epsilon and sigma for HH and OH are
 set to 0.0, it corresponds to the original 1983 TIP3P model
-"(Jorgensen)"_#Jorgensen.
+"(Jorgensen)"_#Jorgensen1.
 
 O mass = 15.9994
 H mass = 1.008
@@ -469,7 +491,7 @@ K of HOH angle = 55
 theta of HOH angle = 104.52 :all(b),p
 
 These are the parameters to use for TIP3P with a long-range Coulombic
-solver (e.g. Ewald or PPPM in LAMMPS), see "(Price)"_#Price for
+solver (e.g. Ewald or PPPM in LAMMPS), see "(Price)"_#Price1 for
 details:
 
 O mass = 15.9994
@@ -513,7 +535,7 @@ using the "fix shake"_fix_shake.html command.
 
 These are the additional parameters (in real units) to set for O and H
 atoms and the water molecule to run a rigid TIP4P model with a cutoff
-"(Jorgensen)"_#Jorgensen.  Note that the OM distance is specified in
+"(Jorgensen)"_#Jorgensen1.  Note that the OM distance is specified in
 the "pair_style"_pair_style.html command, not as part of the pair
 coefficients.
 
@@ -737,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
@@ -766,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)
 
@@ -1032,6 +1030,10 @@ profile consistent with the applied shear strain rate.
 An alternative method for calculating viscosities is provided via the
 "fix viscosity"_fix_viscosity.html command.
 
+NEMD simulations can also be used to measure transport properties of a fluid
+through a pore or channel. Simulations of steady-state flow can be performed
+using the "fix flow/gauss"_fix_flow_gauss.html command.
+
 :line
 
 6.14 Finite-size spherical and aspherical particles :link(howto_14),h4
@@ -1684,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
@@ -1834,7 +1836,7 @@ the deformation must be chosen judiciously, and care must be taken to
 fully equilibrate the deformed cell before sampling the stress
 tensor. Another approach is to sample the triclinic cell fluctuations
 that occur in an NPT simulation. This method can also be slow to
-converge and requires careful post-processing "(Shinoda)"_#Shinoda
+converge and requires careful post-processing "(Shinoda)"_#Shinoda1
 
 :line
 
@@ -1936,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)
@@ -1957,9 +1959,12 @@ The extract functions return a pointer to various global or per-atom
 quantities stored in LAMMPS or to values calculated by a compute, fix,
 or variable.  The pointer returned by the extract_global() function
 can be used as a permanent reference to a value which may change.  For
-the other extract functions, the underlying storage may be reallocated
-as LAMMPS runs, so you need to re-call the function to assure a
-current pointer or returned value(s).
+the extract_atom() method, 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.  For the
+other extract functions, the underlying storage may be reallocated as
+LAMMPS runs, so you need to re-call the function to assure a current
+pointer or returned value(s).
 
 The lammps_reset_box() function resets the size and shape of the
 simulation box, e.g. as part of restoring a previously extracted and
@@ -1975,11 +1980,20 @@ keyword as a double precision value.
 The lammps_get_natoms() function returns the total number of atoms in
 the system and can be used by the caller to allocate space for the
 lammps_gather_atoms() and lammps_scatter_atoms() functions.  The
-gather function collects atom info of the requested type (atom coords,
-types, forces, etc) from all processors, orders them by atom ID, and
-returns a full list to each calling processor.  The scatter function
-does the inverse.  It distributes the same kinds of values, 
+gather function collects peratom info of the requested type (atom
+coords, types, forces, etc) from all processors, orders them by atom
+ID, and returns a full list to each calling processor.  The scatter
+function does the inverse.  It distributes the same peratom values,
 passed by the caller, to each atom owned by individual processors.
+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
@@ -2668,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
@@ -2707,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:
 
 (...)
@@ -2743,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
@@ -2776,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
@@ -2899,14 +2913,14 @@ Fischer, Gao, Guo, Ha, et al, J Phys Chem, 102, 3586 (1998).
 [(Mayo)] Mayo, Olfason, Goddard III, J Phys Chem, 94, 8897-8909
 (1990).
 
-:link(Jorgensen)
+:link(Jorgensen1)
 [(Jorgensen)] Jorgensen, Chandrasekhar, Madura, Impey, Klein, J Chem
 Phys, 79, 926 (1983).
 
-:link(Price)
+:link(Price1)
 [(Price)] Price and Brooks, J Chem Phys, 121, 10096 (2004).
 
-:link(Shinoda)
+:link(Shinoda1)
 [(Shinoda)] Shinoda, Shiga, and Mikami, Phys Rev B, 69, 134103 (2004).
 
 :link(MitchellFincham)

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
@@ -594,10 +605,10 @@ flag = lmp.set_variable(name,value)       # set existing named string-style vari
 value = lmp.get_thermo(name)              # return current value of a thermo keyword
 
 natoms = lmp.get_natoms()                 # total # of atoms as int
-data = lmp.gather_atoms(name,type,count)  # return atom attribute of all atoms gathered into data, ordered by atom ID
+data = lmp.gather_atoms(name,type,count)  # return per-atom property of all atoms gathered into data, ordered by atom ID
                                           # name = "x", "charge", "type", etc
                                           # count = # of per-atom values, 1 or 3, etc
-lmp.scatter_atoms(name,type,count,data)   # scatter atom attribute of all atoms from data, ordered by atom ID
+lmp.scatter_atoms(name,type,count,data)   # scatter per-atom property to all atoms from data, ordered by atom ID
                                           # name = "x", "charge", "type", etc
                                           # count = # of per-atom values, 1 or 3, etc :pre
 
@@ -656,10 +667,10 @@ argument.
 For extract_atom(), a pointer to internal LAMMPS atom-based data is
 returned, which you can use via normal Python subscripting.  See the
 extract() method in the src/atom.cpp file for a list of valid names.
-Again, new names could easily be added.  A pointer to a vector of
-doubles or integers, or a pointer to an array of doubles (double **)
-or integers (int **) is returned.  You need to specify the appropriate
-data type via the type argument.
+Again, new names could easily be added if the property you want is not
+listed.  A pointer to a vector of doubles or integers, or a pointer to
+an array of doubles (double **) or integers (int **) is returned.  You
+need to specify the appropriate data type via the type argument.
 
 For extract_compute() and extract_fix(), the global, per-atom, or
 local data calculated by the compute or fix can be accessed.  What is
@@ -689,12 +700,21 @@ specified group.
 The get_natoms() method returns the total number of atoms in the
 simulation, as an int.
 
-The gather_atoms() method returns a ctypes vector of ints or doubles
-as specified by type, of length count*natoms, for the property of all
-the atoms in the simulation specified by name, ordered by count and
-then by atom ID.  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.
+The gather_atoms() method allows any per-atom property (coordinates,
+velocities, etc) to be extracted from LAMMPS.  It returns a ctypes
+vector of ints or doubles as specified by type, of length
+count*natoms, for the named property for all atoms in the simulation.
+The data is ordered by count and then by atom ID.  See the extract()
+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. 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.
@@ -711,14 +731,22 @@ assigning a new values to the extract_atom() array.  To do this with
 the gather_atoms() vector, you need to change values in the vector,
 then invoke the scatter_atoms() method.
 
-The scatter_atoms() method takes a vector of ints or doubles as
-specified by type, of length count*natoms, for the property of all the
-atoms in the simulation specified by name, ordered by bount and then
-by atom ID.  It uses the vector of data to overwrite the 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.
+The scatter_atoms() method allows any per-atom property (coordinates,
+velocities, etc) to be inserted into LAMMPS, overwriting the current
+property.  It takes a vector of ints or doubles as specified by type,
+of length count*natoms, for the named property for all atoms in the
+simulation.  The data should be ordered by count and then by atom ID.
+See the extract() 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.  It uses the vector of data to overwrite the
+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
@@ -734,7 +762,7 @@ x\[2\] = z coord of atom with ID 1
 x\[3\] = x coord of atom with ID 2
 ...
 x\[n3-1\] = z coord of atom with ID natoms
-lmp.scatter_coords("x",1,3,x) :pre
+lmp.scatter_atoms("x",1,3,x) :pre
 
 Alternatively, you can just change values in the vector returned by
 gather_atoms("x",1,3), since it is a ctypes vector of doubles.

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.5 "Building LAMMPS as a library"_#start_4
+2.6 "Running LAMMPS"_#start_5
+2.7 "Command-line options"_#start_6
+2.8 "Screen output"_#start_7
+2.9 "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,7 +431,7 @@ 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.
@@ -450,7 +451,7 @@ you must also manually specify the correct library, namely -lsfftw or
 
 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
@@ -508,13 +509,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:
@@ -557,7 +558,8 @@ Typing "make clean-all" or "make clean-machine" will delete *.o object
 files created when LAMMPS is built, for either all builds or for a
 particular machine.
 
-Changing the LAMMPS size limits via -DLAMMPS_SMALLBIG or -DLAMMPS_BIGBIG or -DLAMMPS_SMALLSMALL :h6
+Changing the LAMMPS size limits via -DLAMMPS_SMALLBIG or
+-DLAMMPS_BIGBIG or -DLAMMPS_SMALLSMALL :h6
 
 As explained above, any of these 3 settings can be specified on the
 LMP_INC line in your low-level src/MAKE/Makefile.foo.
@@ -653,13 +655,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 +666,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_7 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 +890,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 +928,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 +1014,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.
@@ -1282,7 +1146,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 +1280,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 +1345,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 +1576,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 +1624,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 +1732,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

@@ -12,9 +12,12 @@ Section"_Section_modify.html :c
 
 LAMMPS is designed to be a computational kernel for performing
 molecular dynamics computations.  Additional pre- and post-processing
-steps are often necessary to setup and analyze a simulation.  A few
-additional tools are provided with the LAMMPS distribution and are
-described in this section.
+steps are often necessary to setup and analyze a simulation. A
+list of such tools can be found on the LAMMPS home page
+at "http://lammps.sandia.gov/prepost.html"_http://lammps.sandia.gov/prepost.html
+
+A few additional tools are provided with the LAMMPS distribution
+and are described in this section.
 
 Our group has also written and released a separate toolkit called
 "Pizza.py"_pizza which provides tools for doing setup, analysis,
@@ -36,16 +39,16 @@ authors.
 The source code for each of these codes is in the tools sub-directory
 of the LAMMPS distribution.  There is a Makefile (which you may need
 to edit for your platform) which will build several of the tools which
-reside in that directory.  Some of them are larger packages in their
-own sub-directories with their own Makefiles.
+reside in that directory.  Most of them are larger packages in their
+own sub-directories with their own Makefiles and/or README files.
 
 "amber2lmp"_#amber
 "binary2txt"_#binary
 "ch2lmp"_#charmm
 "chain"_#chain
 "colvars"_#colvars
-"createatoms"_#create
-"data2xmovie"_#data
+"createatoms"_#createatoms
+"drude"_#drude
 "eam database"_#eamdb
 "eam generate"_#eamgn
 "eff"_#eff
@@ -56,20 +59,18 @@ own sub-directories with their own Makefiles.
 "kate"_#kate
 "lmp2arc"_#arc
 "lmp2cfg"_#cfg
-"lmp2vmd"_#vmd
 "matlab"_#matlab
 "micelle2d"_#micelle
 "moltemplate"_#moltemplate
 "msi2lmp"_#msi
 "phonon"_#phonon
-"polymer bonding"_#polybond
+"polybond"_#polybond
 "pymol_asphere"_#pymol
 "python"_#pythontools
 "reax"_#reax_tool
-"restart2data"_#restart
+"smd"_#smd
 "vim"_#vim
 "xmgrace"_#xmgrace
-"xmovie"_#xmovie :ul
 
 :line
 
@@ -158,7 +159,7 @@ gmail.com) at ICTP, Italy.
 
 :line
 
-createatoms tool :h4,link(create)
+createatoms tool :h4,link(createatoms)
 
 The tools/createatoms directory contains a Fortran program called
 createAtoms.f which can generate a variety of interesting crystal
@@ -171,16 +172,16 @@ The tool is authored by Xiaowang Zhou (Sandia), xzhou at sandia.gov.
 
 :line
 
-data2xmovie tool :h4,link(data)
+drude tool :h4,link(drude)
 
-The file data2xmovie.c converts a LAMMPS data file into a snapshot
-suitable for visualizing with the "xmovie"_#xmovie tool, as if it had
-been output with a dump command from LAMMPS itself.  The syntax for
-running the tool is
+The tools/drude directory contains a Python script called
+polarizer.py which can add Drude oscillators to a LAMMPS
+data file in the required format.
 
-data2xmovie \[options\] < infile > outfile :pre
+See the header of the polarizer.py file for details.
 
-See the top of the data2xmovie.c file for a discussion of the options.
+The tool is authored by Agilio Padua and Alain Dequidt: agilio.padua
+at univ-bpclermont.fr, alain.dequidt at univ-bpclermont.fr
 
 :line
 
@@ -317,18 +318,6 @@ This tool was written by Ara Kooser at Sandia (askoose at sandia.gov).
 
 :line
 
-lmp2vmd tool :h4,link(vmd)
-
-The lmp2vmd sub-directory contains a README.txt file that describes
-details of scripts and plugin support within the "VMD
-package"_http://www.ks.uiuc.edu/Research/vmd for visualizing LAMMPS
-dump files.
-
-The VMD plugins and other supporting scripts were written by Axel
-Kohlmeyer (akohlmey at cmm.chem.upenn.edu) at U Penn.
-
-:line
-
 matlab tool :h4,link(matlab)
 
 The matlab sub-directory contains several "MATLAB"_matlabhome scripts for
@@ -380,17 +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 Accelrys' Insight MD code (formerly MSI/Biosym and
-its Discover MD code).  See the README file for more information.
+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).  John is now at the Mayo Clinic
-(jec at mayo.edu), but still fields questions about the tool.
+(Cray), and Steve Lustig (Dupont). Several people contributed changes
+to remove bugs and adapt its output to changes in LAMMPS.
 
-This tool may be out-of-date with respect to the current LAMMPS and
-Insight versions.  Since we don't use it at Sandia, you'll need to
-experiment with it yourself.
+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
 
@@ -409,7 +399,7 @@ University.
 
 :line
 
-polymer bonding tool :h4,link(polybond)
+polybond tool :h4,link(polybond)
 
 The polybond sub-directory contains a Python-based tool useful for
 performing "programmable polymer bonding".  The Python file
@@ -468,48 +458,19 @@ These tools were written by Aidan Thompson at Sandia.
 
 :line
 
-restart2data tool :h4,link(restart)
+smd tool :h4,link(smd)
 
-NOTE: This tool is now obsolete and is not included in the current
-LAMMPS distribution.  This is because there is now a
-"write_data"_write_data.html command, which can create a data file
-from within an input script.  Running LAMMPS with the "-r"
-"command-line switch"_Section_start.html#start_7 as follows:
+The smd sub-directory contains a C++ file dump2vtk_tris.cpp and
+Makefile which can be compiled and used to convert triangle output
+files created by the Smooth-Mach Dynamics (USER-SMD) package into a
+VTK-compatible unstructured grid file.  It could then be read in and
+visualized by VTK.
 
-lmp_g++ -r restartfile datafile
+See the header of dump2vtk.cpp for more details.
 
-is the same as running a 2-line input script:
-
-read_restart restartfile
-write_data datafile
-
-which will produce the same data file that the restart2data tool used
-to create.  The following information is included in case you have an
-older version of LAMMPS which still includes the restart2data tool.
-
-The file restart2data.cpp converts a binary LAMMPS restart file into
-an ASCII data file.  The syntax for running the tool is
-
-restart2data restart-file data-file (input-file) :pre
-
-Input-file is optional and if specified will contain LAMMPS input
-commands for the masses and force field parameters, instead of putting
-those in the data-file.  Only a few force field styles currently
-support this option.
-
-This tool must be compiled on a platform that can read the binary file
-created by a LAMMPS run, since binary files are not compatible across
-all platforms.
-
-Note that a text data file has less precision than a binary restart
-file.  Hence, continuing a run from a converted data file will
-typically not conform as closely to a previous run as will restarting
-from a binary restart file.
-
-If a "%" appears in the specified restart-file, the tool expects a set
-of multiple files to exist.  See the "restart"_restart.html and
-"write_restart"_write_restart.html commands for info on how such sets
-of files are written by LAMMPS, and how the files are named.
+This tool was written by the USER-SMD package author, Georg
+Ganzenmuller at the Fraunhofer-Institute for High-Speed Dynamics,
+Ernst Mach Institute in Germany (georg.ganzenmueller at emi.fhg.de).
 
 :line
 
@@ -537,32 +498,3 @@ See the README file for details.
 
 These files were provided by Vikas Varshney (vv0210 at gmail.com)
 
-:line
-
-xmovie tool :h4,link(xmovie)
-
-The xmovie tool is an X-based visualization package that can read
-LAMMPS dump files and animate them.  It is in its own sub-directory
-with the tools directory.  You may need to modify its Makefile so that
-it can find the appropriate X libraries to link against.
-
-The syntax for running xmovie is
-
-xmovie \[options\] dump.file1 dump.file2 ... :pre
-
-If you just type "xmovie" you will see a list of options.  Note that
-by default, LAMMPS dump files are in scaled coordinates, so you
-typically need to use the -scale option with xmovie.  When xmovie runs
-it opens a visualization window and a control window.  The control
-options are straightforward to use.
-
-Xmovie was mostly written by Mike Uttormark (U Wisconsin) while he
-spent a summer at Sandia.  It displays 2d projections of a 3d domain.
-While simple in design, it is an amazingly fast program that can
-render large numbers of atoms very quickly.  It's a useful tool for
-debugging LAMMPS input and output and making sure your simulation is
-doing what you think it should.  The animations on the Examples page
-of the "LAMMPS WWW site"_lws were created with xmovie.
-
-I've lost contact with Mike, so I hope he's comfortable with us
-distributing his great tool!

doc/src/accelerate_intel.txt

@@ -30,8 +30,8 @@ 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
+charmm/coul/long, lj/cut, lj/cut/coul/long, lj/long/coul/long, sw, tersoff :l
+K-Space Styles: pppm, pppm/disp :l
 :ule
 
 [Speed-ups to expect:]
@@ -42,61 +42,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 +197,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
@@ -321,8 +354,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 +374,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,
@@ -357,6 +394,10 @@ 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
@@ -464,9 +505,9 @@ supported.
 
 [References:]
 
-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., 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

@@ -415,15 +415,15 @@ 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

doc/src/angle_dipole.txt

@@ -41,7 +41,7 @@ angle.
 
 The torque on the dipole can be obtained by differentiating the
 potential using the 'chain rule' as in appendix C.3 of
-"(Allen)"_#Allen:
+"(Allen)"_#Allen1:
 
 :c,image(Eqs/angle_dipole_torque.jpg)
 
@@ -121,6 +121,6 @@ This angle style should not be used with SHAKE.
 [(Orsi)] Orsi & Essex, The ELBA force field for coarse-grain modeling of
 lipid membranes, PloS ONE 6(12): e28637, 2011.
 
-:link(Allen)
+:link(Allen1)
 [(Allen)] Allen & Tildesley, Computer Simulation of Liquids,
 Clarendon Press, Oxford, 1987.

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/atom_style.txt

@@ -110,7 +110,12 @@ basis.
 For the {sphere} style, the particles are spheres and each stores a
 per-particle diameter and mass.  If the diameter > 0.0, the particle
 is a finite-size sphere.  If the diameter = 0.0, it is a point
-particle.
+particle.  Note that by use of the {disc} keyword with the "fix
+nve/sphere"_fix_nve_sphere.html, "fix nvt/sphere"_fix_nvt_sphere.html,
+"fix nph/sphere"_fix_nph_sphere.html, "fix
+npt/sphere"_fix_npt_sphere.html commands, spheres can be effectively
+treated as 2d discs for a 2d simulation if desired.  See also the "set
+density/disc"_set.html command.
 
 For the {ellipsoid} style, the particles are ellipsoids and each
 stores a flag which indicates whether it is a finite-size ellipsoid or

doc/src/balance.txt

@@ -286,24 +286,32 @@ above.  It performs a recursive coordinate bisectioning (RCB) of the
 simulation domain. The basic idea is as follows.
 
 The simulation domain is cut into 2 boxes by an axis-aligned cut in
-the longest dimension, leaving one new box on either side of the cut.
-All the processors are also partitioned into 2 groups, half assigned
-to the box on the lower side of the cut, and half to the box on the
-upper side.  (If the processor count is odd, one side gets an extra
-processor.)  The cut is positioned so that the number of particles in
-the lower box is exactly the number that the processors assigned to
-that box should own for load balance to be perfect.  This also makes
-load balance for the upper box perfect.  The positioning is done
-iteratively, by a bisectioning method.  Note that counting particles
-on either side of the cut requires communication between all
-processors at each iteration.
+one of the dimensions, leaving one new sub-box on either side of the
+cut.  Which dimension is chosen for the cut depends on the particle
+(weight) distribution within the parent box.  Normally the longest
+dimension of the box is cut, but if all (or most) of the particles are
+at one end of the box, a cut may be performed in another dimension to
+induce sub-boxes that are more cube-ish (3d) or square-ish (2d) in
+shape.
+
+After the cut is made, all the processors are also partitioned into 2
+groups, half assigned to the box on the lower side of the cut, and
+half to the box on the upper side.  (If the processor count is odd,
+one side gets an extra processor.)  The cut is positioned so that the
+number of (weighted) particles in the lower box is exactly the number
+that the processors assigned to that box should own for load balance
+to be perfect.  This also makes load balance for the upper box
+perfect.  The positioning of the cut is done iteratively, by a
+bisectioning method (median search).  Note that counting particles on
+either side of the cut requires communication between all processors
+at each iteration.
 
 That is the procedure for the first cut.  Subsequent cuts are made
 recursively, in exactly the same manner.  The subset of processors
-assigned to each box make a new cut in the longest dimension of that
-box, splitting the box, the subset of processors, and the particles
-in the box in two.  The recursion continues until every processor is
-assigned a sub-box of the entire simulation domain, and owns the
+assigned to each box make a new cut in one dimension of that box,
+splitting the box, the subset of processors, and the particles in the
+box in two.  The recursion continues until every processor is assigned
+a sub-box of the entire simulation domain, and owns the (weighted)
 particles in that sub-box.
 
 :line

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/change_box.txt

@@ -101,11 +101,11 @@ Instead you could do something like this, assuming the simulation box
 is non-periodic and atoms extend from 0 to 20 in all dimensions:
 
 change_box all x final -10 20
-create_atoms 1 single -5 5 5   # this will fail to insert an atom :pre
+create_atoms 1 single -5 5 5       # this will fail to insert an atom :pre
 
 change_box all x final -10 20 boundary f s s
 create_atoms 1 single -5 5 5
-change_box boundary s s s      # this will work :pre
+change_box all boundary s s s      # this will work :pre
 
 NOTE: Unlike the earlier "displace_box" version of this command, atom
 remapping is NOT performed by default.  This command allows remapping

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_chunk_atom.txt

@@ -148,7 +148,9 @@ described further below where the keywords are discussed.
 The {binning} styles perform a spatial binning of atoms, and assign an
 atom the chunk ID corresponding to the bin number it is in.  {Nchunk}
 is set to the number of bins, which can change if the simulation box
-size changes.
+size changes.  This also depends on the setting of the {units}
+keyword; e.g. for {reduced} units the number of chunks may not change
+even if the box size does.
 
 The {bin/1d}, {bin/2d}, and {bin/3d} styles define bins as 1d layers
 (slabs), 2d pencils, or 3d boxes.  The {dim}, {origin}, and {delta}

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_coord_atom.txt

@@ -64,7 +64,7 @@ defined by the orientational order parameter calculated by the
 "compute orientorder/atom"_compute_orientorder_atom.html command.
 This {cstyle} thus allows one to apply the ten Wolde's criterion to
 identify crystal-like atoms in a system, as discussed in "ten
-Wolde"_#tenWolde.
+Wolde"_#tenWolde1.
 
 The ID of the previously specified "compute
 orientorder/atom"_compute_orientorder/atom command is specified as
@@ -127,6 +127,6 @@ explained above.
 
 :line
 
-:link(tenWolde)
+:link(tenWolde1)
 [(tenWolde)] P. R. ten Wolde, M. J. Ruiz-Montero, D. Frenkel,
 J. Chem. Phys. 104, 9932 (1996).

doc/src/compute_dpd.txt

@@ -64,7 +64,7 @@ command.
 
 :line
 
-:link(Larentzos)
+:link(Larentzos1)
 [(Larentzos)] J.P. Larentzos, J.K. Brennan, J.D. Moore, and
 W.D. Mattson, "LAMMPS Implementation of Constant Energy Dissipative
 Particle Dynamics (DPD-E)", ARL-TR-6863, U.S. Army Research

doc/src/compute_dpd_atom.txt

@@ -59,7 +59,7 @@ command.
 
 :line
 
-:link(Larentzos)
+:link(Larentzos2)
 [(Larentzos)] J.P. Larentzos, J.K. Brennan, J.D. Moore, and
 W.D. Mattson, "LAMMPS Implementation of Constant Energy Dissipative
 Particle Dynamics (DPD-E)", ARL-TR-6863, U.S. Army Research

doc/src/compute_modify.txt

@@ -14,27 +14,29 @@ compute_modify compute-ID keyword value ... :pre
 
 compute-ID = ID of the compute to modify :ulb,l
 one or more keyword/value pairs may be listed :l
-keyword = {extra} or {dynamic} :l
-  {extra} value = N
+keyword = {extra/dof} or {extra} or {dynamic/dof} or {dynamic} :l
+  {extra/dof} value = N
     N = # of extra degrees of freedom to subtract
-  {dynamic} value = {yes} or {no}
-    yes/no = do or do not recompute the number of atoms contributing to the temperature :pre
+  {extra} syntax is identical to {extra/dof}, will be disabled at some point
+  {dynamic/dof} value = {yes} or {no}
+    yes/no = do or do not recompute the number of degrees of freedom (DOF) contributing to the temperature
+  {dynamic} syntax is identical to {dynamic/dof}, will be disabled at some point :pre
 :ule
 
 [Examples:]
 
-compute_modify myTemp extra 0
-compute_modify newtemp dynamic yes extra 600 :pre
+compute_modify myTemp extra/dof 0
+compute_modify newtemp dynamic/dof yes extra/dof 600 :pre
 
 [Description:]
 
 Modify one or more parameters of a previously defined compute.  Not
 all compute styles support all parameters.
 
-The {extra} keyword refers to how many degrees-of-freedom are
-subtracted (typically from 3N) as a normalizing factor in a
-temperature computation.  Only computes that compute a temperature use
-this option.  The default is 2 or 3 for "2d or 3d
+The {extra/dof} or {extra} keyword refers to how many
+degrees-of-freedom are subtracted (typically from 3N) as a normalizing
+factor in a temperature computation.  Only computes that compute a
+temperature use this option.  The default is 2 or 3 for "2d or 3d
 systems"_dimension.html which is a correction factor for an ensemble
 of velocities with zero total linear momentum. For compute
 temp/partial, if one or more velocity components are excluded, the
@@ -43,14 +45,21 @@ number for the {extra} parameter if you need to add
 degrees-of-freedom.  See the "compute
 temp/asphere"_compute_temp_asphere.html command for an example.
 
-The {dynamic} keyword determines whether the number of atoms N in the
-compute group is re-computed each time a temperature is computed.
-Only compute styles that calculate a temperature use this option.  By
-default, N is assumed to be constant.  If you are adding atoms to the
-system (see the "fix pour"_fix_pour.html or "fix
-deposit"_fix_deposit.html commands) or expect atoms to be lost
-(e.g. due to evaporation), then this option should be used to insure
-the temperature is correctly normalized.
+The {dynamic/dof} or {dynamic} keyword determines whether the number
+of atoms N in the compute group and their associated degrees of
+freedom are re-computed each time a temperature is computed.  Only
+compute styles that calculate a temperature use this option.  By
+default, N and their DOF are assumed to be constant.  If you are
+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
+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
+are deprecated (March 2017) and will eventually be disabled.  Instead,
+use the equivalent {extra/dof} and {dynamic/dof} keywords.
 
 [Restrictions:] none
 
@@ -60,5 +69,5 @@ the temperature is correctly normalized.
 
 [Default:]
 
-The option defaults are extra = 2 or 3 for 2d or 3d systems and
-dynamic = no.
+The option defaults are extra/dof = 2 or 3 for 2d or 3d systems and
+dynamic/dof = no.

doc/src/compute_orientorder_atom.txt

@@ -78,7 +78,7 @@ normalized complex vector {Ybar_lm} of degree {ldegree}, which must be
 explicitly included in the keyword {degrees}. This option can be used
 in conjunction with "compute coord_atom"_compute_coord_atom.html to
 calculate the ten Wolde's criterion to identify crystal-like
-particles, as discussed in "ten Wolde"_#tenWolde.
+particles, as discussed in "ten Wolde"_#tenWolde2.
 
 The value of {Ql} is set to zero for atoms not in the
 specified compute group, as well as for atoms that have less than
@@ -143,6 +143,6 @@ Phys. Rev. B 28, 784 (1983).
 [(Mickel)] W. Mickel, S. C. Kapfer, G. E. Schroeder-Turkand, K. Mecke,
 J. Chem. Phys. 138, 044501 (2013).
 
-:link(tenWolde)
+:link(tenWolde2)
 [(tenWolde)] P. R. ten Wolde, M. J. Ruiz-Montero, D. Frenkel,
 J. Chem. Phys. 104, 9932 (1996).

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_pe_atom.txt

@@ -49,7 +49,7 @@ pairwise interactions between 1-4 atoms.  The energy contribution of
 these terms is included in the pair energy, not the dihedral energy.
 
 The KSpace contribution is calculated using the method in
-"(Heyes)"_#Heyes for the Ewald method and a related method for PPPM,
+"(Heyes)"_#Heyes1 for the Ewald method and a related method for PPPM,
 as specified by the "kspace_style pppm"_kspace_style.html command.
 For PPPM, the calculation requires 1 extra FFT each timestep that
 per-atom energy is calculated.  This "document"_PDF/kspace.pdf
@@ -97,5 +97,5 @@ stress/atom"_compute_stress_atom.html
 
 :line
 
-:link(Heyes)
+:link(Heyes1)
 [(Heyes)] Heyes, Phys Rev B 49, 755 (1994),

doc/src/compute_pressure.txt

@@ -70,7 +70,7 @@ means include all terms except the kinetic energy {ke}.
 Details of how LAMMPS computes the virial efficiently for the entire
 system, including for manybody potentials and accounting for the
 effects of periodic boundary conditions are discussed in
-"(Thompson)"_#Thompson.
+"(Thompson)"_#Thompson1.
 
 The temperature and kinetic energy tensor is not calculated by this
 compute, but rather by the temperature compute specified with the
@@ -150,5 +150,5 @@ stress/atom"_compute_stress_atom.html,
 
 :line
 
-:link(Thompson)
+:link(Thompson1)
 [(Thompson)] Thompson, Plimpton, Mattson, J Chem Phys, 131, 154107 (2009).

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_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} :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
@@ -33,7 +33,13 @@ keyword = {diagonal} or {rmin0} or {switchflag} :l
   {rmin0} value = parameter in distance to angle conversion (distance units)
   {switchflag} value = {0} or {1}
      {0} = do not use switching function
-     {1} = use switching function :pre
+     {1} = use switching function
+  {bzeroflag} value = {0} or {1}
+     {0} = do not subtract B0
+     {1} = subtract B0
+  {quadraticflag} value = {0} or {1}
+     {0} = do not generate quadratic terms
+     {1} = generate quadratic terms :pre
 :ule
 
 [Examples:]
@@ -50,12 +56,12 @@ for each atom in a group.
 Bispectrum components of an atom are order parameters characterizing
 the radial and angular distribution of neighbor atoms. The detailed
 mathematical definition is given in the paper by Thompson et
-al. "(Thompson)"_#Thompson2014
+al. "(Thompson)"_#Thompson20141
 
 The position of a neighbor atom {i'} relative to a central atom {i} is
 a point within the 3D ball of radius {R_ii' = rcutfac*(R_i + R_i')}
 
-Bartok et al. "(Bartok)"_#Bartok2010, proposed mapping this 3D ball
+Bartok et al. "(Bartok)"_#Bartok20101, proposed mapping this 3D ball
 onto the 3-sphere, the surface of the unit ball in a four-dimensional
 space.  The radial distance {r} within {R_ii'} is mapped on to a third
 polar angle {theta0} defined by,
@@ -92,7 +98,7 @@ The expansion coefficients {u^j_m,m'} are complex-valued and they are
 not directly useful as descriptors, because they are not invariant
 under rotation of the polar coordinate frame. However, the following
 scalar triple products of expansion coefficients can be shown to be
-real-valued and invariant under rotation "(Bartok)"_#Bartok2010.
+real-valued and invariant under rotation "(Bartok)"_#Bartok20101.
 
 :c,image(Eqs/compute_sna_atom3.jpg)
 
@@ -148,11 +154,25 @@ 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.
 
+The keyword {bzeroflag} determines whether or not {B0}, the bispectrum
+components of an atom with no neighbors, are subtracted from
+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
@@ -171,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:
 
@@ -204,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
@@ -222,15 +256,15 @@ LAMMPS"_Section_start.html#start_3 section for more info.
 [Default:]
 
 The optional keyword defaults are {diagonal} = 0, {rmin0} = 0,
-{switchflag} = 1.
+{switchflag} = 1, {bzeroflag} = 1, {quadraticflag} = 0,
 
 :line
 
-:link(Thompson2014)
+:link(Thompson20141)
 [(Thompson)] Thompson, Swiler, Trott, Foiles, Tucker, under review, preprint
 available at "arXiv:1409.3880"_http://arxiv.org/abs/1409.3880
 
-:link(Bartok2010)
+:link(Bartok20101)
 [(Bartok)] Bartok, Payne, Risi, Csanyi, Phys Rev Lett, 104, 136403 (2010).
 
 :link(Meremianin2006)

doc/src/compute_stress_atom.txt

@@ -74,7 +74,7 @@ other atoms in the simulation, not just with other atoms in the group.
 
 Details of how LAMMPS computes the virial for individual atoms for
 either pairwise or manybody potentials, and including the effects of
-periodic boundary conditions is discussed in "(Thompson)"_#Thompson.
+periodic boundary conditions is discussed in "(Thompson)"_#Thompson2.
 The basic idea for manybody potentials is to treat each component of
 the force computation between a small cluster of atoms in the same
 manner as in the formula above for bond, angle, dihedral, etc
@@ -89,8 +89,8 @@ pairwise interactions between 1-4 atoms.  The virial contribution of
 these terms is included in the pair virial, not the dihedral virial.
 
 The KSpace contribution is calculated using the method in
-"(Heyes)"_#Heyes for the Ewald method and by the methodology described
-in "(Sirk)"_#Sirk for PPPM.  The choice of KSpace solver is specified
+"(Heyes)"_#Heyes2 for the Ewald method and by the methodology described
+in "(Sirk)"_#Sirk1 for PPPM.  The choice of KSpace solver is specified
 by the "kspace_style pppm"_kspace_style.html command.  Note that for
 PPPM, the calculation requires 6 extra FFTs each timestep that
 per-atom stress is calculated.  Thus it can significantly increase the
@@ -159,11 +159,11 @@ The per-atom array values will be in pressure*volume
 
 :line
 
-:link(Heyes)
+:link(Heyes2)
 [(Heyes)] Heyes, Phys Rev B 49, 755 (1994),
 
-:link(Sirk)
+:link(Sirk1)
 [(Sirk)] Sirk, Moore, Brown, J Chem Phys, 138, 064505 (2013).
 
-:link(Thompson)
+:link(Thompson2)
 [(Thompson)] Thompson, Plimpton, Mattson, J Chem Phys, 131, 154107 (2009).

doc/src/compute_temp_cs.txt

@@ -27,7 +27,7 @@ compute core_shells all temp/cs cores shells :pre
 Define a computation that calculates the temperature of a system based
 on the center-of-mass velocity of atom pairs that are bonded to each
 other.  This compute is designed to be used with the adiabatic
-core/shell model of "(Mitchell and Finchham)"_#MitchellFinchham.  See
+core/shell model of "(Mitchell and Finchham)"_#MitchellFinchham1.  See
 "Section 6.25"_Section_howto.html#howto_25 of the manual for an
 overview of the model as implemented in LAMMPS.  Specifically, this
 compute enables correct temperature calculation and thermostatting of
@@ -114,6 +114,6 @@ temp/chunk"_compute_temp_chunk.html
 
 :line
 
-:link(MitchellFinchham)
+:link(MitchellFinchham1)
 [(Mitchell and Finchham)] Mitchell, Finchham, J Phys Condensed Matter,
 5, 1031-1038 (1993).

doc/src/compute_temp_profile.txt

@@ -43,7 +43,7 @@ atoms, after subtracting out a spatially-averaged center-of-mass
 velocity field, before computing the kinetic energy.  This can be
 useful for thermostatting a collection of atoms undergoing a complex
 flow, e.g. via a profile-unbiased thermostat (PUT) as described in
-"(Evans)"_#Evans.  A compute of this style can be used by any command
+"(Evans)"_#Evans1.  A compute of this style can be used by any command
 that computes a temperature, e.g. "thermo_modify"_thermo_modify.html,
 "fix temp/rescale"_fix_temp_rescale.html, "fix npt"_fix_nh.html, etc.
 
@@ -75,7 +75,7 @@ atoms (sum of 1/2 m v^2), dim = 2 or 3 = dimensionality of the
 simulation, N = number of atoms in the group, k = Boltzmann constant,
 and T = temperature.  The dim*Nx*Ny*Nz term are degrees of freedom
 subtracted to adjust for the removal of the center-of-mass velocity in
-each of Nx*Ny*Nz bins, as discussed in the "(Evans)"_#Evans paper.
+each of Nx*Ny*Nz bins, as discussed in the "(Evans)"_#Evans1 paper.
 
 If the {out} keyword is used with a {tensor} value, which is the
 default, a kinetic energy tensor, stored as a 6-element vector, is
@@ -126,7 +126,7 @@ See "this howto section"_Section_howto.html#howto_16 of the manual for
 a discussion of different ways to compute temperature and perform
 thermostatting.  Using this compute in conjunction with a
 thermostatting fix, as explained there, will effectively implement a
-profile-unbiased thermostat (PUT), as described in "(Evans)"_#Evans.
+profile-unbiased thermostat (PUT), as described in "(Evans)"_#Evans1.
 
 [Output info:]
 
@@ -178,5 +178,5 @@ The option default is out = tensor.
 
 :line
 
-:link(Evans)
+:link(Evans1)
 [(Evans)] Evans and Morriss, Phys Rev Lett, 56, 2172-2175 (1986).

doc/src/computes.txt

@@ -17,6 +17,7 @@ Computes :h1
    compute_chunk_atom
    compute_cluster_atom
    compute_cna_atom
+   compute_cnp_atom
    compute_com
    compute_com_chunk
    compute_contact_atom

doc/src/create_atoms.txt

@@ -134,6 +134,17 @@ not overlap existing atoms inappropriately, especially if molecules
 are being added.  The "delete_atoms"_delete_atoms.html command can be
 used to remove overlapping atoms or molecules.
 
+NOTE: You cannot use any of the styles explained above to create atoms
+that are outside the simulation box; they will just be ignored by
+LAMMPS.  This is true even if you are using shrink-wrapped box
+boundaries, as specified by the "boundary"_boundary.html command.
+However, you can first use the "change_box"_change_box.html command to
+temporarily expand the box, then add atoms via create_atoms, then
+finally use change_box command again if needed to re-shrink-wrap the
+new atoms.  See the "change_box"_change_box.html doc page for an
+example of how to do this, using the create_atoms {single} style to
+insert a new atom outside the current simulation box.
+
 :line
 
 Individual atoms are inserted by this command, unless the {mol}

doc/src/create_bonds.txt

@@ -10,53 +10,93 @@ create_bonds command :h3
 
 [Syntax:]
 
-create_bonds group-ID group2-ID btype rmin rmax :pre
+create_bonds style args ... keyword value ... :pre
 
-group-ID = ID of first group
-group2-ID = ID of second group, bonds will be between atoms in the 2 groups
-btype = bond type of created bonds
-rmin = minimum distance between pair of atoms to bond together
-rmax = minimum distance between pair of atoms to bond together :ul
+style = {many} or {single/bond} or {single/angle} or {single/dihedral} :ule,l
+  {many} args = group-ID group2-ID btype rmin rmax
+    group-ID = ID of first group
+    group2-ID = ID of second group, bonds will be between atoms in the 2 groups
+    btype = bond type of created bonds
+    rmin = minimum distance between pair of atoms to bond together
+    rmax = minimum distance between pair of atoms to bond together
+  {single/bond} args = btype batom1 batom2
+    btype = bond type of new bond
+    batom1,batom2 = atom IDs for two atoms in bond
+  {single/angle} args = atype aatom1 aatom2 aatom3
+    atype = bond type of new angle
+    aatom1,aatom2,aatom3 = atom IDs for three atoms in angle
+  {single/dihedral} args = dtype datom1 datom2 datom3 datom4
+    dtype = bond type of new dihedral
+    datom1,datom2,datom3,datom4 = atom IDs for four atoms in dihedral :pre
+zero or more keyword/value pairs may be appended :l
+keyword = {special} :l
+  {special} value = {yes} or {no} :pre
+:ule
 
 [Examples:]
 
-create_bonds all all 1 1.0 1.2
-create_bonds surf solvent 3 2.0 2.4 :pre
+create_bonds many all all 1 1.0 1.2
+create_bonds many surf solvent 3 2.0 2.4
+create_bond single/bond 1 1 2
+create_bond single/angle 5 52 98 107 special no :pre
 
 [Description:]
 
-Create bonds between pairs of atoms that meet specified distance
-criteria.  The bond interactions can then be computed during a
-simulation by the bond potential defined by the
-"bond_style"_bond_style.html and "bond_coeff"_bond_coeff.html
-commands.  This command is useful for adding bonds to a system,
-e.g. between nearest neighbors in a lattice of atoms, without having
-to enumerate all the bonds in the data file read by the
-"read_data"_read_data.html command.
+Create bonds between pairs of atoms that meet a specified distance
+criteria.  Or create a single bond, angle, or dihedral between 2, 3,
+or 4 specified atoms.
 
-Note that the flexibility of this command is limited.  It can be used
-several times to create different types of bond at different
-distances.  But it cannot typically create all the bonds that would
-normally be defined in a complex system of molecules.  Also note that
-this command does not add any 3-body or 4-body interactions which,
-depending on your model, may be induced by added bonds,
-e.g. "angle"_angle_style.html, "dihedral"_dihedral_style.html, or
-"improper"_improper_style.html interactions.
+The new bond (angle, dihedral) interactions will then be computed
+during a simulation by the bond (angle, dihedral) potential defined by
+the "bond_style"_bond_style.html, "bond_coeff"_bond_coeff.html,
+"angle_style"_angle_style.html, "angle_coeff"_angle_coeff.html,
+"dihedral_style"_dihedral_style.html,
+"dihedral_coeff"_dihedral_coeff.html commands.
 
-All created bonds will be between pairs of atoms I,J where I is in one
-of the two specified groups, and J is in the other.  The two groups
-can be the same, e.g. group "all".  The created bonds will be of bond
-type {btype}, where {btype} must be a value between 1 and the number
-of bond types defined.  This maximum value is set by the "bond types"
-field in the header of the data file read by the
-"read_data"_read_data.html command, or via the optional "bond/types"
-argument of the "create_box"_create_box.html command.
+The {many} style is useful for adding bonds to a system, e.g. between
+nearest neighbors in a lattice of atoms, without having to enumerate
+all the bonds in the data file read by the "read_data"_read_data.html
+command.
+
+The {single} styles are useful for adding bonds, angles, dihedrals
+to a system incrementally, then continuing a simulation.
+
+Note that this command does not auto-create any angle or dihedral
+interactions when a bond is added.  Nor does it auto-create any bonds
+when an angle or dihedral is added.  Or auto-create any angles when a
+dihedral is added.  Thus the flexibility of this command is limited.
+It can be used several times to create different types of bond at
+different distances.  But it cannot typically auto-create all the
+bonds or angles or dihedral that would normally be defined in a data
+file for a complex system of molecules.
+
+NOTE: If the system has no bonds (angles, dihedrals) to begin with, or
+if more bonds per atom are being added than currently exist, then you
+must insure that the number of bond types and the maximum number of
+bonds per atom are set to large enough values.  And similarly for
+angles and dihedrals.  Otherwise an error may occur when too many
+bonds (angles, dihedrals) are added to an atom.  If the
+"read_data"_read_data.html command is used to define the system, these
+parameters can be set via the "bond types" and "extra bond per atom"
+fields in the header section of the data file.  If the
+"create_box"_create_box.html command is used to define the system,
+these 2 parameters can be set via its optional "bond/types" and
+"extra/bond/per/atom" arguments.  And similarly for angles and
+dihedrals.  See the doc pages for these 2 commands for details.
+
+:line
+
+The {many} style will create bonds between pairs of atoms I,J where I
+is in one of the two specified groups, and J is in the other.  The two
+groups can be the same, e.g. group "all".  The created bonds will be
+of bond type {btype}, where {btype} must be a value between 1 and the
+number of bond types defined. 
 
 For a bond to be created, an I,J pair of atoms must be a distance D
 apart such that {rmin} <= D <= {rmax}.
 
-The following settings must have been made in an input
-script before this command is used:
+The following settings must have been made in an input script before
+this style is used:
 
 special_bonds weight for 1-2 interactions must be 0.0
 a "pair_style"_pair_style.html must be defined
@@ -69,8 +109,8 @@ cannot appear in the neighbor list, to avoid creation of duplicate
 bonds.  The neighbor list for all atom type pairs must also extend to
 a distance that encompasses the {rmax} for new bonds to create.
 
-An additional requirement is that your system must be ready to perform
-a simulation.  This means, for example, that all
+An additional requirement for this style is that your system must be
+ready to perform a simulation.  This means, for example, that all
 "pair_style"_pair_style.html coefficients be set via the
 "pair_coeff"_pair_coeff.html command.  A "bond_style"_bond_style.html
 command and all bond coefficients must also be set, even if no bonds
@@ -83,17 +123,58 @@ executes, e.g. if you wish to use long-range Coulombic interactions
 via the "kspace_style"_kspace_style.html command for your subsequent
 simulation.
 
-NOTE: If the system has no bonds to begin with, or if more bonds per
-atom are being added than currently exist, then you must insure that
-the number of bond types and the maximum number of bonds per atom are
-set to large enough values.  Otherwise an error may occur when too
-many bonds are added to an atom.  If the "read_data"_read_data.html
-command is used to define the system, these 2 parameters can be set
-via the "bond types" and "extra bond per atom" fields in the header
-section of the data file.  If the "create_box"_create_box.html command
-is used to define the system, these 2 parameters can be set via its
-optional "bond/types" and "extra/bond/per/atom" arguments.  See the
-doc pages for the 2 commands for details.
+:line
+
+The {single/bond} style creates a single bond of type {btype} between
+two atoms with IDs {batom1} and {batom2}.  {Btype} must be a value
+between 1 and the number of bond types defined.
+
+The {single/angle} style creates a single angle of type {atype}
+between three atoms with IDs {aatom1}, {aatom2}, and {aatom3}.  The
+ordering of the atoms is the same as in the {Angles} section of a data
+file read by the "read_data"_read_data command.  I.e. the 3 atoms are
+ordered linearly within the angle; the central atom is {aatom2}.
+{Atype} must be a value between 1 and the number of angle types
+defined.
+
+The {single/dihedral} style creates a single dihedral of type {btype}
+between two atoms with IDs {batom1} and {batom2}.  The ordering of the
+atoms is the same as in the {Dihedrals} section of a data file read by
+the "read_data"_read_data command.  I.e. the 4 atoms are ordered
+linearly within the dihedral.  {Dtype} must be a value between 1 and
+the number of dihedral types defined.
+
+:line
+
+The keyword {special} controls whether an internal list of special
+bonds is created after one or more bonds, or a single angle or
+dihedral is added to the system.
+
+The default value is {yes}.  A value of {no} cannot be used
+with the {many} style.
+
+This is an expensive operation since the bond topology for the system
+must be walked to find all 1-2, 1-3, 1-4 interactions to store in an
+internal list, which is used when pairwise interactions are weighted;
+see the "special_bonds"_special_bonds.html command for details.
+
+Thus if you are adding a few bonds or a large list of angles all at
+the same time, by using this command repeatedly, it is more efficient
+to only trigger the internal list to be created once, after the last
+bond (or angle, or dihedral) is added:
+
+create_bonds single/bond 5 52 98 special no
+create_bonds single/bond  5 73 74 special no
+...
+create_bonds single/bond 5 17 386 special no
+create_bonds single/bond 4 112 183 special yes :pre
+
+Note that you MUST insure the internal list is re-built after the last
+bond (angle, dihedral) is added, before performing a simulation.
+Otherwise pairwise interactions will not be properly excluded or
+weighted.  LAMMPS does NOT check that you have done this correctly.
+
+:line
 
 [Restrictions:]
 
@@ -105,4 +186,6 @@ molecule template files via the "molecule"_molecule.html and
 
 "create_atoms"_create_atoms.html, "delete_bonds"_delete_bonds.html
 
-[Default:] none
+[Default:]
+
+The keyword default is special = yes.

doc/src/dihedral_charmm.txt

@@ -10,21 +10,25 @@ dihedral_style charmm command :h3
 dihedral_style charmm/intel command :h3
 dihedral_style charmm/kk command :h3
 dihedral_style charmm/omp command :h3
+dihedral_style charmmfsw command :h3
 
 [Syntax:]
 
-dihedral_style charmm :pre
+dihedral_style style :pre
+
+style = {charmm} or {charmmfsw} :ul
 
 [Examples:]
 
 dihedral_style charmm
+dihedral_style charmmfsw
 dihedral_coeff  1 0.2 1 180 1.0
 dihedral_coeff  2 1.8 1   0 1.0
 dihedral_coeff  1 3.1 2 180 0.5 :pre
 
 [Description:]
 
-The {charmm} dihedral style uses the potential
+The {charmm} and {charmmfsw} dihedral styles use the potential
 
 :c,image(Eqs/dihedral_charmm.jpg)
 
@@ -34,6 +38,16 @@ field (see comment on weighting factors below).  See
 "(Cornell)"_#dihedral-Cornell for a description of the AMBER force
 field.
 
+NOTE: The newer {charmmfsw} style was released in March 2017.  We
+recommend it be used instead of the older {charmm} style when running
+a simulation with the CHARMM force field, either with long-range
+Coulombics or a Coulomb cutoff, via the "pair_style
+lj/charmmfsw/coul/long"_pair_charmm.html and "pair_style
+lj/charmmfsw/coul/charmmfsh"_pair_charmm.html commands respectively.
+Otherwise the older {charmm} style is fine to use.  See the discussion
+below and more details on the "pair_style charmm"_pair_charmm.html doc
+page.
+
 The following coefficients must be defined for each dihedral type via the
 "dihedral_coeff"_dihedral_coeff.html command as in the example above, or in
 the data file or restart files read by the "read_data"_read_data.html
@@ -73,13 +87,29 @@ special_bonds 1-4 scaling factor to 0.0 (which is the
 default). Otherwise 1-4 non-bonded interactions in dihedrals will be
 computed twice.
 
-Also note that for AMBER force fields, which use pair styles with
-"lj/cut", the special_bonds 1-4 scaling factor should be set to the
-AMBER defaults (1/2 and 5/6) and all the dihedral weighting factors
-(4th coeff above) must be set to 0.0. In this case, you can use any
-pair style you wish, since the dihedral does not need any
-Lennard-Jones parameter information and will not compute any 1-4
-non-bonded interactions.
+For simulations using the CHARMM force field with a Coulomb cutoff,
+the difference between the {charmm} and {charmmfsw} styles is in the
+computation of the 1-4 non-bond interactions, though only if the
+distance between the two atoms is within the switching region of the
+pairwise potential defined by the corresponding CHARMM pair style,
+i.e. within the outer cutoff specified for the pair style.  The
+{charmmfsw} style should only be used when using the corresponding
+"pair_style lj/charmmfsw/coul/charmmfsw"_pair_charmm.html or
+"pair_style lj/charmmfsw/coul/long"_pair_charmm.html commands.  Use
+the {charmm} style with the older "pair_style"_pair_charmm.html
+commands that have just "charmm" in their style name.  See the
+discussion on the "CHARMM pair_style"_pair_charmm.html doc page for
+details.
+
+Note that for AMBER force fields, which use pair styles with "lj/cut",
+the special_bonds 1-4 scaling factor should be set to the AMBER
+defaults (1/2 and 5/6) and all the dihedral weighting factors (4th
+coeff above) must be set to 0.0. In this case, you can use any pair
+style you wish, since the dihedral does not need any Lennard-Jones
+parameter information and will not compute any 1-4 non-bonded
+interactions.  Likewise the {charmm} or {charmmfsw} styles are
+identical in this case since no 1-4 non-bonded interactions are
+computed.
 
 :line
 
@@ -108,7 +138,15 @@ more instructions on how to use the accelerated styles effectively.
 
 [Restrictions:]
 
-This dihedral style can only be used if LAMMPS was built with the
+When using run_style "respa"_run_style.html, these dihedral styles
+must be assigned to the same r-RESPA level as {pair} or {outer}.
+
+When used in combination with CHARMM pair styles, the 1-4
+"special_bonds"_special_bonds.html scaling factors must be set to 0.0.
+Otherwise non-bonded contributions for these 1-4 pairs will be
+computed multiple times.
+
+These dihedral styles can only be used if LAMMPS was built with the
 MOLECULE package.  See the "Making
 LAMMPS"_Section_start.html#start_3 section for more info on packages.
 

doc/src/dihedral_spherical.txt

@@ -14,10 +14,11 @@ dihedral_style spherical :pre
 
 [Examples:]
 
-dihedral_coeff 1 1  286.1  1 124 1   1 90.0 0   1 90.0 0
-dihedral_coeff 1 3  286.1  1 114 1   1 90  0    1 90.0  0  &
-                    17.3   0 0.0 0   1 158 1    0 0.0   0  &
-                    15.1   0 0.0 0   0 0.0 0    1 167.3 1   :pre
+dihedral_coeff 1 1  286.1  1 124  1    1 90.0 0    1 90.0 0
+dihedral_coeff 1 3  69.3   1 93.9 1    1 90   0    1 90   0  &
+                    49.1   0 0.00 0    1 74.4 1    0 0.00 0  &
+                    25.2   0 0.00 0    0 0.00 0    1 48.1 1
+:pre
 
 [Description:]
 
@@ -35,13 +36,14 @@ the dihedral interaction even if it requires adding additional terms to
 the expansion (as was done in the second example).  A careful choice of
 parameters can prevent singularities that occur with traditional
 force-fields whenever theta1 or theta2 approach 0 or 180 degrees.
+
 The last example above corresponds to an interaction with a single energy
-minima located at phi=114, theta1=158, theta2=167.3 degrees, and it remains
+minima located near phi=93.9, theta1=74.4, theta2=48.1 degrees, and it remains
 numerically stable at all angles (phi, theta1, theta2). In this example,
-the coefficients 17.3, and 15.1 can be physically interpreted as the
+the coefficients 49.1, and 25.2 can be physically interpreted as the
 harmonic spring constants for theta1 and theta2 around their minima.
-The coefficient 286.1 is the harmonic spring constant for phi after
-division by sin(158)*sin(167.3) (the minima positions for theta1 and theta2).
+The coefficient 69.3 is the harmonic spring constant for phi after
+division by sin(74.4)*sin(48.1) (the minima positions for theta1 and theta2).
 
 The following coefficients must be defined for each dihedral type via the
 "dihedral_coeff"_dihedral_coeff.html command as in the example above, or in

doc/src/dump.txt

@@ -7,12 +7,12 @@
 :line
 
 dump command :h3
-"dump custom/vtk"_dump_custom_vtk.html command :h3
+"dump vtk"_dump_vtk.html command :h3
 "dump h5md"_dump_h5md.html command :h3
+"dump molfile"_dump_molfile.html command :h3
+"dump netcdf"_dump_netcdf.html command :h3
 "dump image"_dump_image.html command :h3
 "dump movie"_dump_image.html command :h3
-"dump molfile"_dump_molfile.html command :h3
-"dump nc"_dump_nc.html command :h3
 
 [Syntax:]
 
@@ -20,7 +20,7 @@ dump ID group-ID style N file args :pre
 
 ID = user-assigned name for the dump :ulb,l
 group-ID = ID of the group of atoms to be dumped :l
-style = {atom} or {atom/gz} or {atom/mpiio} or {cfg} or {cfg/gz} or {cfg/mpiio} or {dcd} or {xtc} or {xyz} or {xyz/gz} or {xyz/mpiio} or {h5md} or {image} or {movie} or {molfile} or {local} or {custom} or {custom/gz} or {custom/mpiio} :l
+style = {atom} or {atom/gz} or {atom/mpiio} or {cfg} or {cfg/gz} or {cfg/mpiio} or {custom} or {custom/gz} or {custom/mpiio} or {dcd} or {h5md} or {image} or or {local} or {molfile} or {movie} or {netcdf} or {netcdf/mpiio} or {vtk} or {xtc} or {xyz} or {xyz/gz} or {xyz/mpiio} :l
 N = dump every this many timesteps :l
 file = name of file to write dump info to :l
 args = list of arguments for a particular style :l
@@ -30,33 +30,22 @@ args = list of arguments for a particular style :l
   {cfg} args = same as {custom} args, see below
   {cfg/gz} args = same as {custom} args, see below
   {cfg/mpiio} args = same as {custom} args, see below
+  {custom}, {custom/gz}, {custom/mpiio} args = see below
   {dcd} args = none
+  {h5md} args = discussed on "dump h5md"_dump_h5md.html doc page
+  {image} args = discussed on "dump image"_dump_image.html doc page
+  {local} args = see below
+  {molfile} args = discussed on "dump molfile"_dump_molfile.html doc page
+  {movie} args = discussed on "dump image"_dump_image.html doc page
+  {netcdf} args = discussed on "dump netcdf"_dump_netcdf.html doc page
+  {netcdf/mpiio} args = discussed on "dump netcdf"_dump_netcdf.html doc page
+  {vtk} args = same as {custom} args, see below, also "dump vtk"_dump_vtk.html doc page
   {xtc} args = none
-  {xyz} args = none :pre
-  {xyz/gz} args = none :pre
+  {xyz} args = none
+  {xyz/gz} args = none
   {xyz/mpiio} args = none :pre
 
-  {custom/vtk} args = similar to custom args below, discussed on "dump custom/vtk"_dump_custom_vtk.html doc page :pre
-
-  {h5md} args = discussed on "dump h5md"_dump_h5md.html doc page :pre
-
-  {image} args = discussed on "dump image"_dump_image.html doc page :pre
-
-  {movie} args = discussed on "dump image"_dump_image.html doc page :pre
-
-  {molfile} args = discussed on "dump molfile"_dump_molfile.html doc page
-
-  {nc} args = discussed on "dump nc"_dump_nc.html doc page :pre
-
-  {local} args = list of local attributes
-    possible attributes = index, c_ID, c_ID\[I\], f_ID, f_ID\[I\]
-      index = enumeration of local values
-      c_ID = local vector calculated by a compute with ID
-      c_ID\[I\] = Ith column of local array calculated by a compute with ID, I can include wildcard (see below)
-      f_ID = local vector calculated by a fix with ID
-      f_ID\[I\] = Ith column of local array calculated by a fix with ID, I can include wildcard (see below) :pre
-
-  {custom} or {custom/gz} or {custom/mpiio} args = list of atom attributes
+{custom} or {custom/gz} or {custom/mpiio} args = list of atom attributes :l
     possible attributes = id, mol, proc, procp1, type, element, mass,
                           x, y, z, xs, ys, zs, xu, yu, zu,
                           xsu, ysu, zsu, ix, iy, iz,
@@ -94,6 +83,15 @@ args = list of arguments for a particular style :l
       v_name = per-atom vector calculated by an atom-style variable with name
       d_name = per-atom floating point vector with name, managed by fix property/atom
       i_name = per-atom integer vector with name, managed by fix property/atom :pre
+
+{local} args = list of local attributes :l
+    possible attributes = index, c_ID, c_ID\[I\], f_ID, f_ID\[I\]
+      index = enumeration of local values
+      c_ID = local vector calculated by a compute with ID
+      c_ID\[I\] = Ith column of local array calculated by a compute with ID, I can include wildcard (see below)
+      f_ID = local vector calculated by a fix with ID
+      f_ID\[I\] = Ith column of local array calculated by a fix with ID, I can include wildcard (see below) :pre
+
 :ule
 
 [Examples:]
@@ -331,10 +329,7 @@ bonds and colors.
 
 Note that {atom}, {custom}, {dcd}, {xtc}, and {xyz} style dump files
 can be read directly by "VMD"_http://www.ks.uiuc.edu/Research/vmd, a
-popular molecular viewing program.  See
-"Section 9"_Section_tools.html#vmd of the manual and the
-tools/lmp2vmd/README.txt file for more information about support in
-VMD for reading and visualizing LAMMPS dump files.
+popular molecular viewing program.
 
 :line
 

doc/src/dump_custom_vtk.txt

@@ -1,339 +0,0 @@
- "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
-
-dump custom/vtk command :h3
-
-[Syntax:]
-
-dump ID group-ID style N file args :pre
-
-ID = user-assigned name for the dump :ulb,l
-group-ID = ID of the group of atoms to be dumped :l
-style = {custom/vtk} :l
-N = dump every this many timesteps :l
-file = name of file to write dump info to :l
-args = list of arguments for a particular style :l
-  {custom/vtk} args = list of atom attributes
-    possible attributes = id, mol, proc, procp1, type, element, mass,
-                          x, y, z, xs, ys, zs, xu, yu, zu,
-                          xsu, ysu, zsu, ix, iy, iz,
-                          vx, vy, vz, fx, fy, fz,
-                          q, mux, muy, muz, mu,
-                          radius, diameter, omegax, omegay, omegaz,
-                          angmomx, angmomy, angmomz, tqx, tqy, tqz,
-                          spin, eradius, ervel, erforce,
-                          c_ID, c_ID\[N\], f_ID, f_ID\[N\], v_name :pre
-
-      id = atom ID
-      mol = molecule ID
-      proc = ID of processor that owns atom
-      procp1 = ID+1 of processor that owns atom
-      type = atom type
-      element = name of atom element, as defined by "dump_modify"_dump_modify.html command
-      mass = atom mass
-      x,y,z = unscaled atom coordinates
-      xs,ys,zs = scaled atom coordinates
-      xu,yu,zu = unwrapped atom coordinates
-      xsu,ysu,zsu = scaled unwrapped atom coordinates
-      ix,iy,iz = box image that the atom is in
-      vx,vy,vz = atom velocities
-      fx,fy,fz = forces on atoms
-      q = atom charge
-      mux,muy,muz = orientation of dipole moment of atom
-      mu = magnitude of dipole moment of atom
-      radius,diameter = radius,diameter of spherical particle
-      omegax,omegay,omegaz = angular velocity of spherical particle
-      angmomx,angmomy,angmomz = angular momentum of aspherical particle
-      tqx,tqy,tqz = torque on finite-size particles
-      c_ID = per-atom vector calculated by a compute with ID
-      c_ID\[N\] = Nth column of per-atom array calculated by a compute with ID
-      f_ID = per-atom vector calculated by a fix with ID
-      f_ID\[N\] = Nth column of per-atom array calculated by a fix with ID
-      v_name = per-atom vector calculated by an atom-style variable with name :pre
-:ule
-
-[Examples:]
-
-dump dmpvtk all custom/vtk 100 dump*.myforce.vtk id type vx fx
-dump dmpvtp flow custom/vtk 100 dump*.%.displace.vtp id type c_myD\[1\] c_myD\[2\] c_myD\[3\] v_ke
-dump e_data all custom/vtk 100 dump*.vtu id type spin eradius fx fy fz eforce :pre
-
-The style {custom/vtk} is similar to the "custom"_dump.html style but
-uses the VTK library to write data to VTK simple legacy or XML format
-depending on the filename extension specified. This can be either
-{*.vtk} for the legacy format or {*.vtp} and {*.vtu}, respectively,
-for the XML format; see the "VTK
-homepage"_http://www.vtk.org/VTK/img/file-formats.pdf for a detailed
-description of these formats.  Since this naming convention conflicts
-with the way binary output is usually specified (see below),
-"dump_modify binary"_dump_modify.html allows to set the binary
-flag for this dump style explicitly.
-
-[Description:]
-
-Dump a snapshot of atom quantities to one or more files every N
-timesteps in a format readable by the "VTK visualization
-toolkit"_http://www.vtk.org or other visualization tools that use it,
-e.g. "ParaView"_http://www.paraview.org.  The timesteps on which dump
-output is written can also be controlled by a variable; see the
-"dump_modify every"_dump_modify.html command for details.
-
-Only information for atoms in the specified group is dumped.  The
-"dump_modify thresh and region"_dump_modify.html commands can also
-alter what atoms are included; see details below.
-
-As described below, special characters ("*", "%") in the filename
-determine the kind of output.
-
-IMPORTANT NOTE: Because periodic boundary conditions are enforced only
-on timesteps when neighbor lists are rebuilt, the coordinates of an
-atom written to a dump file may be slightly outside the simulation
-box.
-
-IMPORTANT NOTE: Unless the "dump_modify sort"_dump_modify.html
-option is invoked, the lines of atom information written to dump files
-will be in an indeterminate order for each snapshot.  This is even
-true when running on a single processor, if the "atom_modify
-sort"_atom_modify.html option is on, which it is by default.  In this
-case atoms are re-ordered periodically during a simulation, due to
-spatial sorting.  It is also true when running in parallel, because
-data for a single snapshot is collected from multiple processors, each
-of which owns a subset of the atoms.
-
-For the {custom/vtk} style, sorting is off by default. See the
-"dump_modify"_dump_modify.html doc page for details.
-
-:line
-
-The dimensions of the simulation box are written to a separate file
-for each snapshot (either in legacy VTK or XML format depending on
-the format of the main dump file) with the suffix {_boundingBox}
-appended to the given dump filename.
-
-For an orthogonal simulation box this information is saved as a
-rectilinear grid (legacy .vtk or .vtr XML format).
-
-Triclinic simulation boxes (non-orthogonal) are saved as
-hexahedrons in either legacy .vtk or .vtu XML format.
-
-Style {custom/vtk} allows you to specify a list of atom attributes
-to be written to the dump file for each atom.  Possible attributes
-are listed above.  In contrast to the {custom} style, the attributes
-are rearranged to ensure correct ordering of vector components
-(except for computes and fixes - these have to be given in the right
-order) and duplicate entries are removed.
-
-You cannot specify a quantity that is not defined for a particular
-simulation - such as {q} for atom style {bond}, since that atom style
-doesn't assign charges.  Dumps occur at the very end of a timestep,
-so atom attributes will include effects due to fixes that are applied
-during the timestep.  An explanation of the possible dump custom/vtk attributes
-is given below. Since position data is required to write VTK files "x y z"
-do not have to be specified explicitly.
-
-The VTK format uses a single snapshot of the system per file, thus
-a wildcard "*" must be included in the filename, as discussed below.
-Otherwise the dump files will get overwritten with the new snapshot
-each time.
-
-:line
-
-Dumps are performed on timesteps that are a multiple of N (including
-timestep 0) and on the last timestep of a minimization if the
-minimization converges.  Note that this means a dump will not be
-performed on the initial timestep after the dump command is invoked,
-if the current timestep is not a multiple of N.  This behavior can be
-changed via the "dump_modify first"_dump_modify.html command, which
-can also be useful if the dump command is invoked after a minimization
-ended on an arbitrary timestep.  N can be changed between runs by
-using the "dump_modify every"_dump_modify.html command.
-The "dump_modify every"_dump_modify.html command
-also allows a variable to be used to determine the sequence of
-timesteps on which dump files are written.  In this mode a dump on the
-first timestep of a run will also not be written unless the
-"dump_modify first"_dump_modify.html command is used.
-
-Dump filenames can contain two wildcard characters.  If a "*"
-character appears in the filename, then one file per snapshot is
-written and the "*" character is replaced with the timestep value.
-For example, tmp.dump*.vtk becomes tmp.dump0.vtk, tmp.dump10000.vtk,
-tmp.dump20000.vtk, etc.  Note that the "dump_modify pad"_dump_modify.html
-command can be used to insure all timestep numbers are the same length
-(e.g. 00010), which can make it easier to read a series of dump files
-in order with some post-processing tools.
-
-If a "%" character appears in the filename, then each of P processors
-writes a portion of the dump file, and the "%" character is replaced
-with the processor ID from 0 to P-1 preceded by an underscore character.
-For example, tmp.dump%.vtp becomes tmp.dump_0.vtp, tmp.dump_1.vtp, ...
-tmp.dump_P-1.vtp, etc.  This creates smaller files and can be a fast
-mode of output on parallel machines that support parallel I/O for output.
-
-By default, P = the number of processors meaning one file per
-processor, but P can be set to a smaller value via the {nfile} or
-{fileper} keywords of the "dump_modify"_dump_modify.html command.
-These options can be the most efficient way of writing out dump files
-when running on large numbers of processors.
-
-For the legacy VTK format "%" is ignored and P = 1, i.e., only
-processor 0 does write files.
-
-Note that using the "*" and "%" characters together can produce a
-large number of small dump files!
-
-If {dump_modify binary} is used, the dump file (or files, if "*" or
-"%" is also used) is written in binary format.  A binary dump file
-will be about the same size as a text version, but will typically
-write out much faster.
-
-:line
-
-This section explains the atom attributes that can be specified as
-part of the {custom/vtk} style.
-
-The {id}, {mol}, {proc}, {procp1}, {type}, {element}, {mass}, {vx},
-{vy}, {vz}, {fx}, {fy}, {fz}, {q} attributes are self-explanatory.
-
-{id} is the atom ID.  {mol} is the molecule ID, included in the data
-file for molecular systems.  {type} is the atom type.  {element} is
-typically the chemical name of an element, which you must assign to
-each type via the "dump_modify element"_dump_modify.html command.
-More generally, it can be any string you wish to associate with an
-atom type.  {mass} is the atom mass.  {vx}, {vy}, {vz}, {fx}, {fy},
-{fz}, and {q} are components of atom velocity and force and atomic
-charge.
-
-There are several options for outputting atom coordinates.  The {x},
-{y}, {z} attributes are used to write atom coordinates "unscaled", in
-the appropriate distance "units"_units.html (Angstroms, sigma, etc).
-Additionally, you can use {xs}, {ys}, {zs} if you want to also save the
-coordinates "scaled" to the box size, so that each value is 0.0 to
-1.0.  If the simulation box is triclinic (tilted), then all atom
-coords will still be between 0.0 and 1.0.  Use {xu}, {yu}, {zu} if you
-want the coordinates "unwrapped" by the image flags for each atom.
-Unwrapped means that if the atom has passed through a periodic
-boundary one or more times, the value is printed for what the
-coordinate would be if it had not been wrapped back into the periodic
-box.  Note that using {xu}, {yu}, {zu} means that the coordinate
-values may be far outside the box bounds printed with the snapshot.
-Using {xsu}, {ysu}, {zsu} is similar to using {xu}, {yu}, {zu}, except
-that the unwrapped coordinates are scaled by the box size. Atoms that
-have passed through a periodic boundary will have the corresponding
-coordinate increased or decreased by 1.0.
-
-The image flags can be printed directly using the {ix}, {iy}, {iz}
-attributes.  For periodic dimensions, they specify which image of the
-simulation box the atom is considered to be in.  An image of 0 means
-it is inside the box as defined.  A value of 2 means add 2 box lengths
-to get the true value.  A value of -1 means subtract 1 box length to
-get the true value.  LAMMPS updates these flags as atoms cross
-periodic boundaries during the simulation.
-
-The {mux}, {muy}, {muz} attributes are specific to dipolar systems
-defined with an atom style of {dipole}.  They give the orientation of
-the atom's point dipole moment.  The {mu} attribute gives the
-magnitude of the atom's dipole moment.
-
-The {radius} and {diameter} attributes are specific to spherical
-particles that have a finite size, such as those defined with an atom
-style of {sphere}.
-
-The {omegax}, {omegay}, and {omegaz} attributes are specific to
-finite-size spherical particles that have an angular velocity.  Only
-certain atom styles, such as {sphere} define this quantity.
-
-The {angmomx}, {angmomy}, and {angmomz} attributes are specific to
-finite-size aspherical particles that have an angular momentum.  Only
-the {ellipsoid} atom style defines this quantity.
-
-The {tqx}, {tqy}, {tqz} attributes are for finite-size particles that
-can sustain a rotational torque due to interactions with other
-particles.
-
-The {spin}, {eradius}, {ervel}, and {erforce} attributes are for
-particles that represent nuclei and electrons modeled with the
-electronic force field (EFF).  See "atom_style
-electron"_atom_style.html and "pair_style eff"_pair_eff.html for more
-details.
-
-The {c_ID} and {c_ID\[N\]} attributes allow per-atom vectors or arrays
-calculated by a "compute"_compute.html to be output.  The ID in the
-attribute should be replaced by the actual ID of the compute that has
-been defined previously in the input script.  See the
-"compute"_compute.html command for details.  There are computes for
-calculating the per-atom energy, stress, centro-symmetry parameter,
-and coordination number of individual atoms.
-
-Note that computes which calculate global or local quantities, as
-opposed to per-atom quantities, cannot be output in a dump custom/vtk
-command.  Instead, global quantities can be output by the
-"thermo_style custom"_thermo_style.html command, and local quantities
-can be output by the dump local command.
-
-If {c_ID} is used as an attribute, then the per-atom vector calculated
-by the compute is printed.  If {c_ID\[N\]} is used, then N must be in
-the range from 1-M, which will print the Nth column of the M-length
-per-atom array calculated by the compute.
-
-The {f_ID} and {f_ID\[N\]} attributes allow vector or array per-atom
-quantities calculated by a "fix"_fix.html to be output.  The ID in the
-attribute should be replaced by the actual ID of the fix that has been
-defined previously in the input script.  The "fix
-ave/atom"_fix_ave_atom.html command is one that calculates per-atom
-quantities.  Since it can time-average per-atom quantities produced by
-any "compute"_compute.html, "fix"_fix.html, or atom-style
-"variable"_variable.html, this allows those time-averaged results to
-be written to a dump file.
-
-If {f_ID} is used as a attribute, then the per-atom vector calculated
-by the fix is printed.  If {f_ID\[N\]} is used, then N must be in the
-range from 1-M, which will print the Nth column of the M-length
-per-atom array calculated by the fix.
-
-The {v_name} attribute allows per-atom vectors calculated by a
-"variable"_variable.html to be output.  The name in the attribute
-should be replaced by the actual name of the variable that has been
-defined previously in the input script.  Only an atom-style variable
-can be referenced, since it is the only style that generates per-atom
-values.  Variables of style {atom} can reference individual atom
-attributes, per-atom atom attributes, thermodynamic keywords, or
-invoke other computes, fixes, or variables when they are evaluated, so
-this is a very general means of creating quantities to output to a
-dump file.
-
-See "Section 10"_Section_modify.html of the manual for information
-on how to add new compute and fix styles to LAMMPS to calculate
-per-atom quantities which could then be output into dump files.
-
-:line
-
-[Restrictions:]
-
-The {custom/vtk} style does not support writing of gzipped dump files.
-
-The {custom/vtk} dump style is part of the USER-VTK 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.
-
-To use this dump style, you also must link to the VTK library.  See
-the info in lib/vtk/README and insure the Makefile.lammps file in that
-directory is appropriate for your machine.
-
-The {custom/vtk} dump style neither supports buffering nor custom
-format strings.
-
-[Related commands:]
-
-"dump"_dump.html, "dump image"_dump_image.html,
-"dump_modify"_dump_modify.html, "undump"_undump.html
-
-[Default:]
-
-By default, files are written in ASCII format. If the file extension
-is not one of .vtk, .vtp or .vtu, the legacy VTK file format is used.
-

doc/src/dump_h5md.txt

@@ -17,9 +17,7 @@ group-ID = ID of the group of atoms to be imaged :l
 h5md = style of dump command (other styles {atom} or {cfg} or {dcd} or {xtc} or {xyz} or {local} or {custom} are discussed on the "dump"_dump.html doc page) :l
 N = dump every this many timesteps :l
 file.h5 = name of file to write to :l
-args = list of data elements to dump, with their dump "subintervals".
-At least one element must be given and image may only be present if
-position is specified first. :l
+args = list of data elements to dump, with their dump "subintervals"
   position options
   image
   velocity options
@@ -29,15 +27,17 @@ position is specified first. :l
   box value = {yes} or {no}
   create_group value = {yes} or {no}
   author value = quoted string :pre
+:ule
 
-For the elements {position}, {velocity}, {force} and {species}, one
-may specify a sub-interval to write the data only every N_element
+Note that at least one element must be specified and image may only be
+present if position is specified first.
+
+For the elements {position}, {velocity}, {force} and {species}, a
+sub-interval may be specified to write the data only every N_element
 iterations of the dump (i.e. every N*N_element time steps). This is
-specified by the option
+specified by this option directly following the element declaration:
 
-  every N_element :pre
-
-that follows directly the element declaration.
+every N_element :pre
 
 :ule
 

doc/src/dump_modify.txt

@@ -16,7 +16,8 @@ dump-ID = ID of dump to modify :ulb,l
 one or more keyword/value pairs may be appended :l
 these keywords apply to various dump styles :l
 keyword = {append} or {buffer} or {element} or {every} or {fileper} or {first} or {flush} or {format} or {image} or {label} or {nfile} or {pad} or {precision} or {region} or {scale} or {sort} or {thresh} or {unwrap} :l
-  {append} arg = {yes} or {no}
+  {append} arg = {yes} or {no} or {at} N
+    N = index of frame written upon first dump
   {buffer} arg = {yes} or {no}
   {element} args = E1 E2 ... EN, where N = # of atom types
     E1,...,EN = element name, e.g. C or Fe or Ga
@@ -41,6 +42,7 @@ keyword = {append} or {buffer} or {element} or {every} or {fileper} or {first} o
   {region} arg = region-ID or "none"
   {scale} arg = {yes} or {no}
   {sfactor} arg = coordinate scaling factor (> 0.0)
+  {thermo} arg = {yes} or {no}
   {tfactor} arg = time scaling factor (> 0.0)
   {sort} arg = {off} or {id} or N or -N
      off = no sorting of per-atom lines within a snapshot
@@ -139,12 +141,13 @@ and {dcd}.  It also applies only to text output files, not to binary
 or gzipped or image/movie files.  If specified as {yes}, then dump
 snapshots are appended to the end of an existing dump file.  If
 specified as {no}, then a new dump file will be created which will
-overwrite an existing file with the same name.  This keyword can only
-take effect if the dump_modify command is used after the
-"dump"_dump.html command, but before the first command that causes
-dump snapshots to be output, e.g. a "run"_run.html or
-"minimize"_minimize.html command.  Once the dump file has been opened,
-this keyword has no further effect.
+overwrite an existing file with the same name.  If the {at} option is present
+({netcdf} only), then the frame to append to can be specified.  Negative values
+are counted from the end of the file.  This keyword can only take effect if the
+dump_modify command is used after the "dump"_dump.html command, but before the
+first command that causes dump snapshots to be output, e.g. a "run"_run.html or
+"minimize"_minimize.html command.  Once the dump file has been opened, this
+keyword has no further effect.
 
 :line
 
@@ -413,6 +416,13 @@ most effective when the typical magnitude of position data is between
 
 :line
 
+The {thermo} keyword ({netcdf} only) triggers writing of "thermo"_thermo.html
+information to the dump file alongside per-atom data. The data included in the
+dump file is identical to the data specified by
+"thermo_style"_thermo_style.html.
+
+:line
+
 The {region} keyword only applies to the dump {custom}, {cfg},
 {image}, and {movie} styles.  If specified, only atoms in the region
 will be written to the dump file or included in the image/movie.  Only

doc/src/dump_molfile.txt

@@ -34,10 +34,7 @@ to one or more files every N timesteps in one of several formats.
 Only information for atoms in the specified group is dumped.  This
 specific dump style uses molfile plugins that are bundled with the
 "VMD"_http://www.ks.uiuc.edu/Research/vmd molecular visualization and
-analysis program.  See "Section 9"_Section_tools.html#vmd of the
-manual and the tools/lmp2vmd/README.txt file for more information
-about support in VMD for reading and visualizing native LAMMPS dump
-files.
+analysis program.
 
 Unless the filename contains a * character, the output will be written
 to one single file with the specified format. Otherwise there will be

doc/src/dump_nc.txt

@@ -1,66 +0,0 @@
-"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
-
-dump nc command :h3
-dump nc/mpiio command :h3
-
-[Syntax:]
-
-dump ID group-ID nc N file.nc args
-dump ID group-ID nc/mpiio N file.nc args :pre
-
-ID = user-assigned name for the dump :ulb,l
-group-ID = ID of the group of atoms to be imaged :l
-{nc} or {nc/mpiio}  = style of dump command (other styles {atom} or {cfg} or {dcd} or {xtc} or {xyz} or {local} or {custom} are discussed on the "dump"_dump.html doc page) :l
-N = dump every this many timesteps :l
-file.nc = name of file to write to :l
-args = list of per atom data elements to dump, same as for the 'custom' dump style. :l,ule
-
-[Examples:]
-
-dump 1 all nc 100 traj.nc type x y z vx vy vz
-dump_modify 1 append yes at -1 global c_thermo_pe c_thermo_temp c_thermo_press :pre
-
-dump 1 all nc/mpiio 1000 traj.nc id type x y z :pre
-
-[Description:]
-
-Dump a snapshot of atom coordinates every N timesteps in Amber-style
-NetCDF file format. NetCDF files are binary, portable and
-self-describing.  This dump style will write only one file on the root
-node.  The dump style {nc} uses the "standard NetCDF
-library"_netcdf-home all data is collected on one processor and then
-written to the dump file. Dump style {nc/mpiio} used the "parallel
-NetCDF library"_pnetcdf-home and MPI-IO; it has better performance on
-a larger number of processors. Note that 'nc' outputs all atoms sorted
-by atom tag while 'nc/mpiio' outputs in order of the MPI rank.
-
-In addition to per-atom data, also global (i.e. not per atom, but per
-frame) quantities can be included in the dump file. This can be
-variables, output from computes or fixes data prefixed with v_, c_ and
-f_, respectively.  These properties are included via
-"dump_modify"_dump_modify.html {global}.
-
-:link(netcdf-home,http://www.unidata.ucar.edu/software/netcdf/)
-:link(pnetcdf-home,http://trac.mcs.anl.gov/projects/parallel-netcdf/)
-
-:line
-
-[Restrictions:]
-
-The {nc} and {nc/mpiio} dump styles are part of the USER-NC-DUMP
-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.
-
-:line
-
-[Related commands:]
-
-"dump"_dump.html, "dump_modify"_dump_modify.html, "undump"_undump.html
-

doc/src/dump_netcdf.txt

@@ -0,0 +1,76 @@
+"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
+
+dump netcdf command :h3
+dump netcdf/mpiio command :h3
+
+[Syntax:]
+
+dump ID group-ID netcdf N file args
+dump ID group-ID netcdf/mpiio N file args :pre
+
+ID = user-assigned name for the dump :ulb,l
+group-ID = ID of the group of atoms to be imaged :l
+{netcdf} or {netcdf/mpiio}  = style of dump command (other styles {atom} or {cfg} or {dcd} or {xtc} or {xyz} or {local} or {custom} are discussed on the "dump"_dump.html doc page) :l
+N = dump every this many timesteps :l
+file = name of file to write dump info to :l
+args = list of atom attributes, same as for "dump_style custom"_dump.html :l,ule
+
+[Examples:]
+
+dump 1 all netcdf 100 traj.nc type x y z vx vy vz
+dump_modify 1 append yes at -1 thermo yes
+dump 1 all netcdf/mpiio 1000 traj.nc id type x y z :pre
+
+[Description:]
+
+Dump a snapshot of atom coordinates every N timesteps in Amber-style
+NetCDF file format.  NetCDF files are binary, portable and
+self-describing.  This dump style will write only one file on the root
+node.  The dump style {netcdf} uses the "standard NetCDF
+library"_netcdf-home.  All data is collected on one processor and then
+written to the dump file.  Dump style {netcdf/mpiio} uses the
+"parallel NetCDF library"_pnetcdf-home and MPI-IO to write to the dump
+file in parallel; it has better performance on a larger number of
+processors.  Note that style {netcdf} outputs all atoms sorted by atom
+tag while style {netcdf/mpiio} outputs atoms in order of their MPI
+rank.
+
+NetCDF files can be directly visualized via the following tools:
+
+Ovito (http://www.ovito.org/). Ovito supports the AMBER convention and
+all extensions of this dump style. :ule,b
+
+VMD (http://www.ks.uiuc.edu/Research/vmd/). :l
+
+AtomEye (http://www.libatoms.org/). The libAtoms version of AtomEye
+contains a NetCDF reader that is not present in the standard
+distribution of AtomEye. :l,ule
+
+In addition to per-atom data, "thermo"_thermo.html data can be included in the
+dump file. The data included in the dump file is identical to the data specified
+by "thermo_style"_thermo_style.html.
+
+:link(netcdf-home,http://www.unidata.ucar.edu/software/netcdf/)
+:link(pnetcdf-home,http://trac.mcs.anl.gov/projects/parallel-netcdf/)
+
+:line
+
+[Restrictions:]
+
+The {netcdf} and {netcdf/mpiio} dump styles are part of the
+USER-NETCDF package.  They are only enabled if LAMMPS was built with
+that package. See the "Making LAMMPS"_Section_start.html#start_3
+section for more info.
+
+:line
+
+[Related commands:]
+
+"dump"_dump.html, "dump_modify"_dump_modify.html, "undump"_undump.html
+

doc/src/dump_vtk.txt

@@ -0,0 +1,179 @@
+ "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
+
+dump vtk command :h3
+
+[Syntax:]
+
+dump ID group-ID vtk N file args :pre
+
+ID = user-assigned name for the dump
+group-ID = ID of the group of atoms to be dumped
+vtk = style of dump command (other styles {atom} or {cfg} or {dcd} or {xtc} or {xyz} or {local} or {custom} are discussed on the "dump"_dump.html doc page)
+N = dump every this many timesteps
+file = name of file to write dump info to
+args = same as arguments for "dump_style custom"_dump.html :ul
+
+[Examples:]
+
+dump dmpvtk all vtk 100 dump*.myforce.vtk id type vx fx
+dump dmpvtp flow vtk 100 dump*.%.displace.vtp id type c_myD\[1\] c_myD\[2\] c_myD\[3\] v_ke :pre
+
+[Description:]
+
+Dump a snapshot of atom quantities to one or more files every N
+timesteps in a format readable by the "VTK visualization
+toolkit"_http://www.vtk.org or other visualization tools that use it,
+e.g. "ParaView"_http://www.paraview.org.  The timesteps on which dump
+output is written can also be controlled by a variable; see the
+"dump_modify every"_dump_modify.html command for details.
+
+This dump style is similar to "dump_style custom"_dump.html but uses
+the VTK library to write data to VTK simple legacy or XML format
+depending on the filename extension specified for the dump file.  This
+can be either {*.vtk} for the legacy format or {*.vtp} and {*.vtu},
+respectively, for XML format; see the "VTK
+homepage"_http://www.vtk.org/VTK/img/file-formats.pdf for a detailed
+description of these formats.  Since this naming convention conflicts
+with the way binary output is usually specified (see below), the
+"dump_modify binary"_dump_modify.html command allows setting of a
+binary option for this dump style explicitly.
+
+Only information for atoms in the specified group is dumped.  The
+"dump_modify thresh and region"_dump_modify.html commands can also
+alter what atoms are included; see details below.
+
+As described below, special characters ("*", "%") in the filename
+determine the kind of output.
+
+IMPORTANT NOTE: Because periodic boundary conditions are enforced only
+on timesteps when neighbor lists are rebuilt, the coordinates of an
+atom written to a dump file may be slightly outside the simulation
+box.
+
+IMPORTANT NOTE: Unless the "dump_modify sort"_dump_modify.html option
+is invoked, the lines of atom information written to dump files will
+be in an indeterminate order for each snapshot.  This is even true
+when running on a single processor, if the "atom_modify
+sort"_atom_modify.html option is on, which it is by default.  In this
+case atoms are re-ordered periodically during a simulation, due to
+spatial sorting.  It is also true when running in parallel, because
+data for a single snapshot is collected from multiple processors, each
+of which owns a subset of the atoms.
+
+For the {vtk} style, sorting is off by default. See the
+"dump_modify"_dump_modify.html doc page for details.
+
+:line
+
+The dimensions of the simulation box are written to a separate file
+for each snapshot (either in legacy VTK or XML format depending on the
+format of the main dump file) with the suffix {_boundingBox} appended
+to the given dump filename.
+
+For an orthogonal simulation box this information is saved as a
+rectilinear grid (legacy .vtk or .vtr XML format).
+
+Triclinic simulation boxes (non-orthogonal) are saved as
+hexahedrons in either legacy .vtk or .vtu XML format.
+
+Style {vtk} allows you to specify a list of atom attributes to be
+written to the dump file for each atom.  The list of possible attributes
+is the same as for the "dump_style custom"_dump.html command; see
+its doc page for a listing and an explanation of each attribute.
+
+NOTE: Since position data is required to write VTK files the atom
+attributes "x y z" do not have to be specified explicitly; they will
+be included in the dump file regardless.  Also, in contrast to the
+{custom} style, the specified {vtk} attributes are rearranged to
+ensure correct ordering of vector components (except for computes and
+fixes - these have to be given in the right order) and duplicate
+entries are removed.
+
+The VTK format uses a single snapshot of the system per file, thus
+a wildcard "*" must be included in the filename, as discussed below.
+Otherwise the dump files will get overwritten with the new snapshot
+each time.
+
+:line
+
+Dumps are performed on timesteps that are a multiple of N (including
+timestep 0) and on the last timestep of a minimization if the
+minimization converges.  Note that this means a dump will not be
+performed on the initial timestep after the dump command is invoked,
+if the current timestep is not a multiple of N.  This behavior can be
+changed via the "dump_modify first"_dump_modify.html command, which
+can also be useful if the dump command is invoked after a minimization
+ended on an arbitrary timestep.  N can be changed between runs by
+using the "dump_modify every"_dump_modify.html command.
+The "dump_modify every"_dump_modify.html command
+also allows a variable to be used to determine the sequence of
+timesteps on which dump files are written.  In this mode a dump on the
+first timestep of a run will also not be written unless the
+"dump_modify first"_dump_modify.html command is used.
+
+Dump filenames can contain two wildcard characters.  If a "*"
+character appears in the filename, then one file per snapshot is
+written and the "*" character is replaced with the timestep value.
+For example, tmp.dump*.vtk becomes tmp.dump0.vtk, tmp.dump10000.vtk,
+tmp.dump20000.vtk, etc.  Note that the "dump_modify pad"_dump_modify.html
+command can be used to insure all timestep numbers are the same length
+(e.g. 00010), which can make it easier to read a series of dump files
+in order with some post-processing tools.
+
+If a "%" character appears in the filename, then each of P processors
+writes a portion of the dump file, and the "%" character is replaced
+with the processor ID from 0 to P-1 preceded by an underscore character.
+For example, tmp.dump%.vtp becomes tmp.dump_0.vtp, tmp.dump_1.vtp, ...
+tmp.dump_P-1.vtp, etc.  This creates smaller files and can be a fast
+mode of output on parallel machines that support parallel I/O for output.
+
+By default, P = the number of processors meaning one file per
+processor, but P can be set to a smaller value via the {nfile} or
+{fileper} keywords of the "dump_modify"_dump_modify.html command.
+These options can be the most efficient way of writing out dump files
+when running on large numbers of processors.
+
+For the legacy VTK format "%" is ignored and P = 1, i.e., only
+processor 0 does write files.
+
+Note that using the "*" and "%" characters together can produce a
+large number of small dump files!
+
+If {dump_modify binary} is used, the dump file (or files, if "*" or
+"%" is also used) is written in binary format.  A binary dump file
+will be about the same size as a text version, but will typically
+write out much faster.
+
+:line
+
+[Restrictions:]
+
+The {vtk} style does not support writing of gzipped dump files.
+
+The {vtk} dump style is part of the USER-VTK 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.
+
+To use this dump style, you also must link to the VTK library.  See
+the info in lib/vtk/README and insure the Makefile.lammps file in that
+directory is appropriate for your machine.
+
+The {vtk} dump style supports neither buffering or custom format
+strings.
+
+[Related commands:]
+
+"dump"_dump.html, "dump image"_dump_image.html,
+"dump_modify"_dump_modify.html, "undump"_undump.html
+
+[Default:]
+
+By default, files are written in ASCII format. If the file extension
+is not one of .vtk, .vtp or .vtu, the legacy VTK file format is used.
+

doc/src/fix_adapt.txt

@@ -22,6 +22,11 @@ attribute = {pair} or {kspace} or {atom} :l
     pparam = parameter to adapt over time
     I,J = type pair(s) to set parameter for
     v_name = variable with name that calculates value of pparam
+  {bond} args = bstyle bparam I v_name
+    bstyle = bond style name, e.g. harmonic
+    bparam = parameter to adapt over time
+    I = type bond to set parameter for
+    v_name = variable with name that calculates value of bparam
   {kspace} arg = v_name
     v_name = variable with name that calculates scale factor on K-space terms
   {atom} args = aparam v_name
@@ -44,6 +49,9 @@ fix 1 all adapt 1 pair soft a 2* 3 v_prefactor
 fix 1 all adapt 1 pair lj/cut epsilon * * v_scale1 coul/cut scale 3 3 v_scale2 scale yes reset yes
 fix 1 all adapt 10 atom diameter v_size :pre
 
+variable ramp_up equal "ramp(0.01,0.5)"
+fix stretch all adapt 1 bond harmonic r0 1 v_ramp_up :pre
+
 [Description:]
 
 Change or adapt one or more specific simulation attributes or settings
@@ -192,6 +200,19 @@ fix 1 all adapt 1 pair soft a * * v_prefactor :pre
 
 :line
 
+The {bond} keyword uses the specified variable to change the value of
+a bond coefficient over time, very similar to how the {pair} keyword
+operates. The only difference is that now a bond coefficient for a
+given bond type is adapted.
+
+Currently {bond} does not support bond_style hybrid nor bond_style
+hybrid/overlay as bond styles. The only bonds that currently are
+working with fix_adapt are
+
+"harmonic"_bond_harmonic.html: k,r0: type bonds :tb(c=3,s=:)
+
+:line
+
 The {kspace} keyword used the specified variable as a scale factor on
 the energy, forces, virial calculated by whatever K-Space solver is
 defined by the "kspace_style"_kspace_style.html command.  If the

doc/src/fix_ave_chunk.txt

@@ -191,8 +191,15 @@ remain constant for the duration of the simulation.  This fix forces
 the chunk/atom compute specified by chunkID to hold {Nchunk} constant
 for the appropriate time windows, by not allowing it to re-calculate
 {Nchunk}, which can also affect how it assigns chunk IDs to atoms.
-More details are given on the "compute
-chunk/atom"_compute_chunk_atom.html doc page.
+This is particularly important to understand if the chunks defined by
+the "compute chunk/atom"_compute_chunk_atom.html command are spatial
+bins.  If its {units} keyword is set to {box} or {lattice}, then the
+number of bins {Nchunk} and size of each bin will be fixed over the
+{Nfreq} time window, which can affect which atoms are discarded if the
+simulation box size changes.  If its {units} keyword is set to
+{reduced}, then the number of bins {Nchunk} will still be fixed, but
+the size of each bin can vary at each timestep if the simulation box
+size changes, e.g. for an NPT simulation.
 
 :line
 
@@ -290,24 +297,32 @@ It the {norm} setting is {all}, which is the default, a chunk value is
 summed over all atoms in all {Nrepeat} samples, as is the count of
 atoms in the chunk.  The averaged output value for the chunk on the
 {Nfreq} timesteps is Total-sum / Total-count.  In other words it is an
-average over atoms across the entire {Nfreq} timescale.
+average over atoms across the entire {Nfreq} timescale.  For the
+{density/number} and {density/mass} values, the volume (bin volume or
+system volume) used in the final normalization will be the volume at
+the final {Nfreq} timestep.
 
-If the {norm} setting is {sample}, the chunk value is summed over atoms
-for each sample, as is the count, and an "average sample value" is
-computed for each sample, i.e. Sample-sum / Sample-count.  The output
-value for the chunk on the {Nfreq} timesteps is the average of the
-{Nrepeat} "average sample values", i.e. the sum of {Nrepeat} "average
-sample values" divided by {Nrepeat}.  In other words it is an average
-of an average.
+If the {norm} setting is {sample}, the chunk value is summed over
+atoms for each sample, as is the count, and an "average sample value"
+is computed for each sample, i.e. Sample-sum / Sample-count.  The
+output value for the chunk on the {Nfreq} timesteps is the average of
+the {Nrepeat} "average sample values", i.e. the sum of {Nrepeat}
+"average sample values" divided by {Nrepeat}.  In other words it is an
+average of an average.  For the {density/number} and {density/mass}
+values, the volume (bin volume or system volume) used in the
+per-sample normalization will be the current volume at each sampling
+step.
 
 If the {norm} setting is {none}, a similar computation as for the
-{sample} setting is done, except the individual "average sample values"
-are "summed sample values".  A summed sample value is simply the chunk
-value summed over atoms in the sample, without dividing by the number
-of atoms in the sample.  The output value for the chunk on the
-{Nfreq} timesteps is the average of the {Nrepeat} "summed sample
+{sample} setting is done, except the individual "average sample
+values" are "summed sample values".  A summed sample value is simply
+the chunk value summed over atoms in the sample, without dividing by
+the number of atoms in the sample.  The output value for the chunk on
+the {Nfreq} timesteps is the average of the {Nrepeat} "summed sample
 values", i.e. the sum of {Nrepeat} "summed sample values" divided by
-{Nrepeat}.
+{Nrepeat}.  For the {density/number} and {density/mass} values, the
+volume (bin volume or system volume) used in the per-sample sum
+normalization will be the current volume at each sampling step.
 
 The {ave} keyword determines how the per-chunk values produced every
 {Nfreq} steps are averaged with values produced on previous steps that

doc/src/fix_box_relax.txt

@@ -245,8 +245,8 @@ appear the system is converging to your specified pressure.  The
 solution for this is to either (a) zero the velocities of all atoms
 before performing the minimization, or (b) make sure you are
 monitoring the pressure without its kinetic component.  The latter can
-be done by outputting the pressure from the fix this command creates
-(see below) or a pressure fix you define yourself.
+be done by outputting the pressure from the pressure compute this
+command creates (see below) or a pressure compute you define yourself.
 
 NOTE: Because pressure is often a very sensitive function of volume,
 it can be difficult for the minimizer to equilibrate the system the
@@ -308,7 +308,7 @@ thermo_modify command (or in two separate commands), then the order in
 which the keywords are specified is important.  Note that a "pressure
 compute"_compute_pressure.html defines its own temperature compute as
 an argument when it is specified.  The {temp} keyword will override
-this (for the pressure compute being used by fix npt), but only if the
+this (for the pressure compute being used by fix box/relax), but only if the
 {temp} keyword comes after the {press} keyword.  If the {temp} keyword
 comes before the {press} keyword, then the new pressure compute
 specified by the {press} keyword will be unaffected by the {temp}
@@ -316,18 +316,16 @@ setting.
 
 This fix computes a global scalar which can be accessed by various
 "output commands"_Section_howto.html#howto_15. The scalar is the
-pressure-volume energy, plus the strain energy, if it exists.
-
-This fix computes a global scalar which can be accessed by various
-"output commands"_Section_howto.html#howto_15. The scalar is given
-by the energy expression shown above. The energy values reported
-at the end of a minimization run under "Minimization stats" include
-this energy, and so differ from what LAMMPS normally reports as
-potential energy. This fix does not support the
-"fix_modify"_fix_modify.html {energy} option,
-because that would result in double-counting of the fix energy in the
-minimization energy. Instead, the fix energy can be explicitly
-added to the potential energy using one of these two variants:
+pressure-volume energy, plus the strain energy, if it exists,
+as described above.
+The energy values reported at the
+end of a minimization run under "Minimization stats" include this
+energy, and so differ from what LAMMPS normally reports as potential
+energy. This fix does not support the "fix_modify"_fix_modify.html
+{energy} option, because that would result in double-counting of the
+fix energy in the minimization energy. Instead, the fix energy can be
+explicitly added to the potential energy using one of these two
+variants:
 
 variable emin equal pe+f_1  :pre
 

doc/src/fix_cmap.txt

@@ -27,7 +27,7 @@ fix_modify     myCMAP energy yes :pre
 This command enables CMAP crossterms to be added to simulations which
 use the CHARMM force field.  These are relevant for any CHARMM model
 of a peptide or protein sequences that is 3 or more amino-acid
-residues long; see "(Buck)"_#Buck and "(Brooks)"_#Brooks for details,
+residues long; see "(Buck)"_#Buck and "(Brooks)"_#Brooks2 for details,
 including the analytic energy expressions for CMAP interactions.  The
 CMAP crossterms add additional potential energy contributions to pairs
 of overlapping phi-psi dihedrals of amino-acids, which are important
@@ -87,8 +87,11 @@ the note below about how to include the CMAP energy when performing an
 
 [Restart, fix_modify, output, run start/stop, minimize info:]
 
-No information about this fix is written to "binary restart
-files"_restart.html.
+This fix writes the list of CMAP crossterms to "binary restart
+files"_restart.html.  See the "read_restart"_read_restart.html command
+for info on how to re-specify a fix in an input script that reads a
+restart file, so that the operation of the fix continues in an
+uninterrupted fashion.
 
 The "fix_modify"_fix_modify.html {energy} option is supported by this
 fix to add the potential "energy" of the CMAP interactions system's
@@ -128,5 +131,5 @@ LAMMPS"_Section_start.html#start_3 section for more info on packages.
 [(Buck)] Buck, Bouguet-Bonnet, Pastor, MacKerell Jr., Biophys J, 90, L36
 (2006).
 
-:link(Brooks)
+:link(Brooks2)
 [(Brooks)] Brooks, Brooks, MacKerell Jr., J Comput Chem, 30, 1545 (2009).

doc/src/fix_deform.txt

@@ -565,8 +565,10 @@ more instructions on how to use the accelerated styles effectively.
 
 [Restart, fix_modify, output, run start/stop, minimize info:]
 
-No information about this fix is written to "binary restart
-files"_restart.html.  None of the "fix_modify"_fix_modify.html options
+This fix will restore the initial box settings from "binary restart
+files"_restart.html, which allows the fix to be properly continue
+deformation, when using the start/stop options of the "run"_run.html
+command.  None of the "fix_modify"_fix_modify.html options
 are relevant to this fix.  No global or per-atom quantities are stored
 by this fix for access by various "output
 commands"_Section_howto.html#howto_15.

doc/src/fix_deposit.txt

@@ -150,6 +150,12 @@ treated as rigid bodies, use the {rigid} keyword, specifying as its
 value the ID of a separate "fix rigid/small"_fix_rigid.html
 command which also appears in your input script.
 
+NOTE: If you wish the new rigid molecules (and other rigid molecules)
+to be thermostatted correctly via "fix rigid/small/nvt"_fix_rigid.html
+or "fix rigid/small/npt"_fix_rigid.html, then you need to use the
+"fix_modify dynamic/dof yes" command for the rigid fix.  This is to
+inform that fix that the molecule count will vary dynamically.
+
 If you wish to insert molecules via the {mol} keyword, that will have
 their bonds or angles constrained via SHAKE, use the {shake} keyword,
 specifying as its value the ID of a separate "fix

doc/src/fix_dpd_energy.txt

@@ -70,13 +70,13 @@ mesoparticle equation of state for each particle.
 
 :line
 
-:link(Lisal)
+:link(Lisal1)
 [(Lisal)] M. Lisal, J.K. Brennan, J. Bonet Avalos, "Dissipative
 particle dynamics at isothermal, isobaric, isoenergetic, and
 isoenthalpic conditions using Shardlow-like splitting algorithms.",
 J. Chem. Phys., 135, 204105 (2011).
 
-:link(Larentzos)
+:link(Larentzos3)
 [(Larentzos)] J.P. Larentzos, J.K. Brennan, J.D. Moore, and
 W.D. Mattson, "LAMMPS Implementation of Constant Energy Dissipative
 Particle Dynamics (DPD-E)", ARL-TR-6863, U.S. Army Research

doc/src/fix_drude_transform.txt

@@ -32,7 +32,7 @@ fix 1 all drude/transform/inverse :pre
 
 Transform the coordinates of Drude oscillators from real to reduced
 and back for thermalizing the Drude oscillators as described in
-"(Lamoureux)"_#Lamoureux using a Nose-Hoover thermostat.  This fix is
+"(Lamoureux)"_#Lamoureux1 using a Nose-Hoover thermostat.  This fix is
 designed to be used with the "thermalized Drude oscillator
 model"_tutorial_drude.html.  Polarizable models in LAMMPS are
 described in "this Section"_Section_howto.html#howto_25.
@@ -160,5 +160,5 @@ files"_restart.html.
 
 :line
 
-:link(Lamoureux)
+:link(Lamoureux1)
 [(Lamoureux)] Lamoureux and Roux, J Chem Phys, 119, 3025-3039 (2003).

doc/src/fix_eos_cv.txt

@@ -53,7 +53,7 @@ command.
 
 :line
 
-:link(Larentzos)
+:link(Larentzos4)
 [(Larentzos)] J.P. Larentzos, J.K. Brennan, J.D. Moore, and
 W.D. Mattson, "LAMMPS Implementation of Constant Energy Dissipative
 Particle Dynamics (DPD-E)", ARL-TR-6863, U.S. Army Research

doc/src/fix_eos_table_rx.txt

@@ -45,14 +45,14 @@ species {j} in particle {i}, {u_j} is the internal energy of species j,
 {DeltaH_f,j} is the heat of formation of species {j}, N is the number of
 molecules represented by the coarse-grained particle, kb is the
 Boltzmann constant, and T is the temperature of the system.  Additionally,
-it is possible to modify the concentration-dependent particle internal 
-energy relation by adding an energy correction, temperature-dependent 
+it is possible to modify the concentration-dependent particle internal
+energy relation by adding an energy correction, temperature-dependent
 correction, and/or a molecule-dependent correction.  An energy correction can
-be specified as a constant (in energy units).  A temperature correction can be 
-specified by multiplying a temperature correction coefficient by the 
-internal temperature.  A molecular correction can be specified by 
-by multiplying a molecule correction coefficient by the average number of 
-product gas particles in the coarse-grain particle. 
+be specified as a constant (in energy units).  A temperature correction can be
+specified by multiplying a temperature correction coefficient by the
+internal temperature.  A molecular correction can be specified by
+by multiplying a molecule correction coefficient by the average number of
+product gas particles in the coarse-grain particle.
 
 Fix {eos/table/rx} creates interpolation tables of length {N} from {m}
 internal energy values of each species {u_j} listed in a file as a
@@ -72,12 +72,12 @@ The second filename specifies a file containing heat of formation
 {DeltaH_f,j} for each species.
 
 In cases where the coarse-grain particle represents a single molecular
-species (i.e., no reactions occur and fix {rx} is not present in the input file), 
-fix {eos/table/rx} can be applied in a similar manner to fix {eos/table} 
-within a non-reactive DPD simulation.  In this case, the heat of formation 
+species (i.e., no reactions occur and fix {rx} is not present in the input file),
+fix {eos/table/rx} can be applied in a similar manner to fix {eos/table}
+within a non-reactive DPD simulation.  In this case, the heat of formation
 filename is replaced with the heat of formation value for the single species.
-Additionally, the energy correction and temperature correction coefficients may 
-also be specified as fix arguments.  
+Additionally, the energy correction and temperature correction coefficients may
+also be specified as fix arguments.
 
 :line
 
@@ -138,8 +138,8 @@ used as the species name must correspond with the tags used to define
 the reactions with the "fix rx"_fix_rx.html command.
 
 Alternatively, corrections to the EOS can be included by specifying
-three additional columns that correspond to the energy correction, 
-the temperature correction coefficient and molecule correction 
+three additional columns that correspond to the energy correction,
+the temperature correction coefficient and molecule correction
 coefficient.  In this case, the format of the file is as follows:
 
 # HEAT OF FORMATION TABLE     (one or more comment or blank lines) :pre

doc/src/fix_filter_corotate.txt

@@ -0,0 +1,87 @@
+"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
+
+fix filter/corotate command :h3
+
+[Syntax:]
+
+fix ID group-ID filter/corotate keyword value ... :pre
+
+ID, group-ID are documented in "fix"_fix.html command :ulb,l
+one or more constraint/value pairs are appended :l
+constraint = {b} or {a} or {t} or {m} :l
+  {b} values = one or more bond types
+  {a} values = one or more angle types
+  {t} values = one or more atom types
+  {m} value = one or more mass values :pre
+:ule
+
+[Examples:]
+
+timestep 8
+run_style respa 3 2 8 bond 1 pair 2 kspace 3
+fix cor all filter/corotate m 1.0 :pre
+
+fix cor all filter/corotate b 4 19 a 3 5 2 :pre
+
+[Description:]
+
+This fix implements a corotational filter for a mollified impulse
+method. In biomolecular simulations, it allows the usage of larger
+timesteps for long-range electrostatic interactions.  For details, see
+"(Fath)"_#Fath2017.
+
+When using "run_style respa"_run_style.html for a biomolecular
+simulation with high-frequency covalent bonds, the outer time-step is
+restricted to below ~ 4fs due to resonance problems. This fix filters
+the outer stage of the respa and thus a larger (outer) time-step can
+be used. Since in large biomolecular simulations the computation of
+the long-range electrostatic contributions poses a major bottleneck,
+this can significantly accelerate the simulation.
+
+The filter computes a cluster decomposition of the molecular structure
+following the criteria indicated by the options a, b, t and m. This
+process is similar to the approach in "fix shake"_fix_shake.html,
+however, the clusters are not kept contrained. Instead, the position
+is slightly modified only for the computation of long-range forces. A
+good cluster decomposition constitutes in building clusters which
+contain the fastest covalent bonds inside clusters.
+
+If the clusters are chosen suitably, the "run_style
+respa"_run_style.html is stable for outer time-steps of at least 8fs.
+
+:line
+
+[Restart, fix_modify, output, run start/stop, minimize info:]
+
+No information about these fixes is written to "binary restart
+files"_restart.html.  None of the "fix_modify"_fix_modify.html options
+are relevant to these fixes.  No global or per-atom quantities are
+stored by these fixes for access by various "output
+commands"_Section_howto.html#howto_15.  No parameter of these fixes
+can be used with the {start/stop} keywords of the "run"_run.html
+command.  These fixes are not invoked during "energy
+minimization"_minimize.html.
+
+[Restrictions:]
+
+This fix 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.
+
+Currently, it does not support "molecule templates"_molecule.html.
+
+[Related commands:]
+
+
+[Default:] none
+
+:line
+
+:link(Fath2017)
+[(Fath)] Fath, Hochbruck, Singh, J Comp Phys, 333, 180-198 (2017).

doc/src/fix_flow_gauss.txt

@@ -153,7 +153,7 @@ The option default for the {energy} keyword is energy = no.
 :link(Strong)
 [(Strong)] Strong and Eaves, J. Phys. Chem. B 121, 189 (2017).
 
-:link(Evans)
+:link(Evans2)
 [(Evans)] Evans and Morriss, Phys. Rev. Lett. 56, 2172 (1986).
 
 :link(Zhu)

doc/src/fix_gcmc.txt

@@ -23,9 +23,11 @@ T = temperature of the ideal gas reservoir (temperature units) :l
 mu = chemical potential of the ideal gas reservoir (energy units) :l
 displace = maximum Monte Carlo translation distance (length units) :l
 zero or more keyword/value pairs may be appended to args :l
-keyword = {mol}, {region}, {maxangle}, {pressure}, {fugacity_coeff}, {full_energy}, {charge}, {group}, {grouptype}, {intra_energy}, or {tfac_insert}
+keyword = {mol}, {region}, {maxangle}, {pressure}, {fugacity_coeff}, {full_energy}, {charge}, {group}, {grouptype}, {intra_energy}, {tfac_insert}, or {overlap_cutoff}
   {mol} value = template-ID
     template-ID = ID of molecule template specified in a separate "molecule"_molecule.html command
+  {rigid} value = fix-ID
+    fix-ID = ID of "fix rigid/small"_fix_rigid.html command
   {shake} value = fix-ID
     fix-ID = ID of "fix shake"_fix_shake.html command
   {region} value = region-ID
@@ -41,7 +43,8 @@ keyword = {mol}, {region}, {maxangle}, {pressure}, {fugacity_coeff}, {full_energ
     type = atom type (int)
     group-ID = group-ID for inserted atoms (string)
   {intra_energy} value = intramolecular energy (energy units)
-  {tfac_insert} value = scale up/down temperature of inserted atoms (unitless) :pre
+  {tfac_insert} value = scale up/down temperature of inserted atoms (unitless)
+  {overlap_cutoff} value = maximum pair distance for overlap rejection (distance units) :pre
 :ule
 
 [Examples:]
@@ -53,26 +56,25 @@ fix 4 my_gas gcmc 1 10 10 1 123456543 300.0 -12.5 1.0 region disk :pre
 [Description:]
 
 This fix performs grand canonical Monte Carlo (GCMC) exchanges of
-atoms or molecules of the given type with an imaginary ideal gas reservoir at
-the specified T and chemical potential (mu) as discussed in
-"(Frenkel)"_#Frenkel. If used with the "fix nvt"_fix_nh.html command,
-simulations in the grand canonical ensemble (muVT, constant chemical
-potential, constant volume, and constant temperature) can be
+atoms or molecules of the given type with an imaginary ideal gas
+reservoir at the specified T and chemical potential (mu) as discussed
+in "(Frenkel)"_#Frenkel. If used with the "fix nvt"_fix_nh.html
+command, simulations in the grand canonical ensemble (muVT, constant
+chemical potential, constant volume, and constant temperature) can be
 performed.  Specific uses include computing isotherms in microporous
 materials, or computing vapor-liquid coexistence curves.
 
-Every N timesteps the fix attempts a number of GCMC exchanges (insertions
-or deletions) of gas atoms or molecules of
-the given type between the simulation cell and the imaginary
-reservoir. It also attempts a number of Monte Carlo
-moves (translations and molecule rotations) of gas of the given type
-within the simulation cell or region.  The average number of
-attempted GCMC exchanges is X. The average number of attempted MC moves is M.
-M should typically be chosen to be
-approximately equal to the expected number of gas atoms or molecules
-of the given type within the simulation cell or region,
-which will result in roughly one
-MC translation per atom or molecule per MC cycle.
+Every N timesteps the fix attempts a number of GCMC exchanges
+(insertions or deletions) of gas atoms or molecules of the given type
+between the simulation cell and the imaginary reservoir. It also
+attempts a number of Monte Carlo moves (translations and molecule
+rotations) of gas of the given type within the simulation cell or
+region.  The average number of attempted GCMC exchanges is X. The
+average number of attempted MC moves is M.  M should typically be
+chosen to be approximately equal to the expected number of gas atoms
+or molecules of the given type within the simulation cell or region,
+which will result in roughly one MC translation per atom or molecule
+per MC cycle.
 
 For MC moves of molecular gasses, rotations and translations are each
 attempted with 50% probability. For MC moves of atomic gasses,
@@ -80,50 +82,50 @@ translations are attempted 100% of the time. For MC exchanges of
 either molecular or atomic gasses, deletions and insertions are each
 attempted with 50% probability.
 
-All inserted particles are always assigned to two groups: the default group
-"all" and the group specified in the fix gcmc command (which can also
-be "all"). In addition, particles are also added to any groups specified
-by the {group} and {grouptype} keywords.
-If inserted particles are individual atoms, they are
-assigned the atom type given by the type argument.  If they are molecules,
-the type argument has no effect and must be set to zero. Instead,
-the type of each atom in the inserted molecule is specified
-in the file read by the "molecule"_molecule.html command.
+All inserted particles are always assigned to two groups: the default
+group "all" and the group specified in the fix gcmc command (which can
+also be "all"). In addition, particles are also added to any groups
+specified by the {group} and {grouptype} keywords.  If inserted
+particles are individual atoms, they are assigned the atom type given
+by the type argument.  If they are molecules, the type argument has no
+effect and must be set to zero. Instead, the type of each atom in the
+inserted molecule is specified in the file read by the
+"molecule"_molecule.html command.
 
 This fix cannot be used to perform MC insertions of gas atoms or
 molecules other than the exchanged type, but MC deletions,
 translations, and rotations can be performed on any atom/molecule in
 the fix group.  All atoms in the simulation cell can be moved using
-regular time integration translations, e.g. via
-"fix nvt"_fix_nh.html, resulting in a hybrid GCMC+MD simulation. A
-smaller-than-usual timestep size may be needed when running such a
-hybrid simulation, especially if the inserted molecules are not well
-equilibrated.
+regular time integration translations, e.g. via "fix nvt"_fix_nh.html,
+resulting in a hybrid GCMC+MD simulation. A smaller-than-usual
+timestep size may be needed when running such a hybrid simulation,
+especially if the inserted molecules are not well equilibrated.
 
 This command may optionally use the {region} keyword to define an
 exchange and move volume.  The specified region must have been
 previously defined with a "region"_region.html command.  It must be
 defined with side = {in}.  Insertion attempts occur only within the
-specified region. For non-rectangular regions, random trial
-points are generated within the rectangular bounding box until a point is found
-that lies inside the region. If no valid point is generated after 1000 trials,
-no insertion is performed, but it is counted as an attempted insertion.
-Move and deletion attempt candidates are selected
-from gas atoms or molecules within the region. If there are no candidates,
-no move or deletion is performed, but it is counted as an attempt move
-or deletion. If an attempted move places the atom or molecule center-of-mass outside
-the specified region, a new attempted move is generated. This process is repeated
-until the atom or molecule center-of-mass is inside the specified region.
+specified region. For non-rectangular regions, random trial points are
+generated within the rectangular bounding box until a point is found
+that lies inside the region. If no valid point is generated after 1000
+trials, no insertion is performed, but it is counted as an attempted
+insertion.  Move and deletion attempt candidates are selected from gas
+atoms or molecules within the region. If there are no candidates, no
+move or deletion is performed, but it is counted as an attempt move or
+deletion. If an attempted move places the atom or molecule
+center-of-mass outside the specified region, a new attempted move is
+generated. This process is repeated until the atom or molecule
+center-of-mass is inside the specified region.
 
 If used with "fix nvt"_fix_nh.html, the temperature of the imaginary
 reservoir, T, should be set to be equivalent to the target temperature
-used in fix nvt. Otherwise, the imaginary reservoir
-will not be in thermal equilibrium with the simulation cell. Also,
-it is important that the temperature used by fix nvt be dynamic,
-which can be achieved as follows:
+used in fix nvt. Otherwise, the imaginary reservoir will not be in
+thermal equilibrium with the simulation cell. Also, it is important
+that the temperature used by fix nvt be dynamic/dof, which can be
+achieved as follows:
 
 compute mdtemp mdatoms temp
-compute_modify mdtemp dynamic yes
+compute_modify mdtemp dynamic/dof yes
 fix mdnvt mdatoms nvt temp 300.0 300.0 10.0
 fix_modify mdnvt temp mdtemp :pre
 
@@ -134,16 +136,16 @@ interactions. Specifically, avoid performing so many MC translations
 per timestep that atoms can move beyond the neighbor list skin
 distance. See the "neighbor"_neighbor.html command for details.
 
-When an atom or molecule is to be inserted, its
-coordinates are chosen at a random position within the current
-simulation cell or region, and new atom velocities are randomly chosen from
-the specified temperature distribution given by T. The effective
-temperature for new atom velocities can be increased or decreased
-using the optional keyword {tfac_insert} (see below). Relative
-coordinates for atoms in a molecule are taken from the template
-molecule provided by the user. The center of mass of the molecule
-is placed at the insertion point. The orientation of the molecule
-is chosen at random by rotating about this point.
+When an atom or molecule is to be inserted, its coordinates are chosen
+at a random position within the current simulation cell or region, and
+new atom velocities are randomly chosen from the specified temperature
+distribution given by T. The effective temperature for new atom
+velocities can be increased or decreased using the optional keyword
+{tfac_insert} (see below). Relative coordinates for atoms in a
+molecule are taken from the template molecule provided by the
+user. The center of mass of the molecule is placed at the insertion
+point. The orientation of the molecule is chosen at random by rotating
+about this point.
 
 Individual atoms are inserted, unless the {mol} keyword is used.  It
 specifies a {template-ID} previously defined using the
@@ -155,53 +157,97 @@ command for details.  The only settings required to be in this file
 are the coordinates and types of atoms in the molecule.
 
 When not using the {mol} keyword, you should ensure you do not delete
-atoms that are bonded to other atoms, or LAMMPS will
-soon generate an error when it tries to find bonded neighbors.  LAMMPS will
-warn you if any of the atoms eligible for deletion have a non-zero
-molecule ID, but does not check for this at the time of deletion.
+atoms that are bonded to other atoms, or LAMMPS will soon generate an
+error when it tries to find bonded neighbors.  LAMMPS will warn you if
+any of the atoms eligible for deletion have a non-zero molecule ID,
+but does not check for this at the time of deletion.
+
+If you wish to insert molecules via the {mol} keyword, that will be
+treated as rigid bodies, use the {rigid} keyword, specifying as its
+value the ID of a separate "fix rigid/small"_fix_rigid.html command
+which also appears in your input script.
+
+NOTE: If you wish the new rigid molecules (and other rigid molecules)
+to be thermostatted correctly via "fix rigid/small/nvt"_fix_rigid.html
+or "fix rigid/small/npt"_fix_rigid.html, then you need to use the
+"fix_modify dynamic/dof yes" command for the rigid fix.  This is to
+inform that fix that the molecule count will vary dynamically.
 
 If you wish to insert molecules via the {mol} keyword, that will have
 their bonds or angles constrained via SHAKE, use the {shake} keyword,
 specifying as its value the ID of a separate "fix
 shake"_fix_shake.html command which also appears in your input script.
 
-Optionally, users may specify the maximum rotation angle for
-molecular rotations using the {maxangle} keyword and specifying
-the angle in degrees. Rotations are performed by generating a random
-point on the unit sphere and a random rotation angle on the
-range \[0,maxangle). The molecule is then rotated by that angle about an
+Optionally, users may specify the maximum rotation angle for molecular
+rotations using the {maxangle} keyword and specifying the angle in
+degrees. Rotations are performed by generating a random point on the
+unit sphere and a random rotation angle on the range
+\[0,maxangle). The molecule is then rotated by that angle about an
 axis passing through the molecule center of mass. The axis is parallel
-to the unit vector defined by the point on the unit sphere.
-The same procedure is used for randomly rotating molecules when they
-are inserted, except that the maximum angle is 360 degrees.
+to the unit vector defined by the point on the unit sphere.  The same
+procedure is used for randomly rotating molecules when they are
+inserted, except that the maximum angle is 360 degrees.
 
-Note that fix GCMC does not use configurational bias
-MC or any other kind of sampling of intramolecular degrees of freedom.
-Inserted molecules can have different orientations, but they will all
-have the same intramolecular configuration,
-which was specified in the molecule command input.
+Note that fix GCMC does not use configurational bias MC or any other
+kind of sampling of intramolecular degrees of freedom.  Inserted
+molecules can have different orientations, but they will all have the
+same intramolecular configuration, which was specified in the molecule
+command input.
 
 For atomic gasses, inserted atoms have the specified atom type, but
-deleted atoms are any atoms that have been inserted or that belong
-to the user-specified fix group. For molecular gasses, exchanged
-molecules use the same atom types as in the template molecule
-supplied by the user.  In both cases, exchanged
-atoms/molecules are assigned to two groups: the default group "all"
-and the group specified in the fix gcmc command (which can also be
-"all").
+deleted atoms are any atoms that have been inserted or that belong to
+the user-specified fix group. For molecular gasses, exchanged
+molecules use the same atom types as in the template molecule supplied
+by the user.  In both cases, exchanged atoms/molecules are assigned to
+two groups: the default group "all" and the group specified in the fix
+gcmc command (which can also be "all").
 
-The gas reservoir pressure can be specified using the {pressure}
-keyword, in which case the user-specified chemical potential is
-ignored. For non-ideal gas reservoirs, the user may also specify the
-fugacity coefficient using the {fugacity_coeff} keyword.
+The chemical potential is a user-specified input parameter defined
+as:
+
+:c,image(Eqs/fix_gcmc1.jpg)
+
+The second term mu_ex is the excess chemical potential due to
+energetic interactions and is formally zero for the fictitious gas
+reservoir but is non-zero for interacting systems. So, while the
+chemical potential of the reservoir and the simulation cell are equal,
+mu_ex is not, and as a result, the densities of the two are generally
+quite different.  The first term mu_id is the ideal gas contribution
+to the chemical potential.  mu_id can be related to the density or
+pressure of the fictitious gas reservoir by:
+
+:c,image(Eqs/fix_gcmc2.jpg)
+
+where k is Boltzman's constant,
+T is the user-specified temperature, rho is the number density,
+P is the pressure, and phi is the fugacity coefficient.
+The constant Lambda is required for dimensional consistency.
+For all unit styles except {lj} it is defined as the thermal
+de Broglie wavelength
+
+:c,image(Eqs/fix_gcmc3.jpg)
+
+where h is Planck's constant, and m is the mass of the exchanged atom
+or molecule.  For unit style {lj}, Lambda is simply set to the
+unity. Note that prior to March 2017, lambda for unit style {lj} was
+calculated using the above formula with h set to the rather specific
+value of 0.18292026.  Chemical potential under the old definition can
+be converted to an equivalent value under the new definition by
+subtracting 3kTln(Lambda_old).
+
+As an alternative to specifying mu directly, the ideal gas reservoir
+can be defined by its pressure P using the {pressure} keyword, in
+which case the user-specified chemical potential is ignored. The user
+may also specify the fugacity coefficient phi using the
+{fugacity_coeff} keyword, which defaults to unity.
 
 The {full_energy} option means that fix GCMC will compute the total
 potential energy of the entire simulated system. The total system
 energy before and after the proposed GCMC move is then used in the
 Metropolis criterion to determine whether or not to accept the
-proposed GCMC move. By default, this option is off, in which case
-only partial energies are computed to determine the difference in
-energy that would be caused by the proposed GCMC move.
+proposed GCMC move. By default, this option is off, in which case only
+partial energies are computed to determine the difference in energy
+that would be caused by the proposed GCMC move.
 
 The {full_energy} option is needed for systems with complicated
 potential energy calculations, including the following:
@@ -210,7 +256,7 @@ potential energy calculations, including the following:
   many-body pair styles
   hybrid pair styles
   eam pair styles
-  triclinic systems
+  tail corrections
   need to include potential energy contributions from other fixes :ul
 
 In these cases, LAMMPS will automatically apply the {full_energy}
@@ -219,42 +265,43 @@ keyword and issue a warning message.
 When the {mol} keyword is used, the {full_energy} option also includes
 the intramolecular energy of inserted and deleted molecules. If this
 is not desired, the {intra_energy} keyword can be used to define an
-amount of energy that is subtracted from the final energy when a molecule
-is inserted, and added to the initial energy when a molecule is
-deleted. For molecules that have a non-zero intramolecular energy, this
-will ensure roughly the same behavior whether or not the {full_energy}
-option is used.
+amount of energy that is subtracted from the final energy when a
+molecule is inserted, and added to the initial energy when a molecule
+is deleted. For molecules that have a non-zero intramolecular energy,
+this will ensure roughly the same behavior whether or not the
+{full_energy} option is used.
 
-Inserted atoms and molecules are assigned random velocities based on the
-specified temperature T. Because the relative velocity of
-all atoms in the molecule is zero, this may result in inserted molecules
-that are systematically too cold. In addition, the intramolecular potential
-energy of the inserted molecule may cause the kinetic energy
-of the molecule to quickly increase or decrease after insertion.
-The {tfac_insert} keyword allows the user to counteract these effects
-by changing the temperature used to assign velocities to
-inserted atoms and molecules by a constant factor. For a
-particular application, some experimentation may be required
-to find a value of {tfac_insert} that results in inserted molecules that
-equilibrate quickly to the correct temperature.
+Inserted atoms and molecules are assigned random velocities based on
+the specified temperature T. Because the relative velocity of all
+atoms in the molecule is zero, this may result in inserted molecules
+that are systematically too cold. In addition, the intramolecular
+potential energy of the inserted molecule may cause the kinetic energy
+of the molecule to quickly increase or decrease after insertion.  The
+{tfac_insert} keyword allows the user to counteract these effects by
+changing the temperature used to assign velocities to inserted atoms
+and molecules by a constant factor. For a particular application, some
+experimentation may be required to find a value of {tfac_insert} that
+results in inserted molecules that equilibrate quickly to the correct
+temperature.
 
 Some fixes have an associated potential energy. Examples of such fixes
 include: "efield"_fix_efield.html, "gravity"_fix_gravity.html,
 "addforce"_fix_addforce.html, "langevin"_fix_langevin.html,
-"restrain"_fix_restrain.html, "temp/berendsen"_fix_temp_berendsen.html,
+"restrain"_fix_restrain.html,
+"temp/berendsen"_fix_temp_berendsen.html,
 "temp/rescale"_fix_temp_rescale.html, and "wall fixes"_fix_wall.html.
 For that energy to be included in the total potential energy of the
-system (the quantity used when performing GCMC moves),
-you MUST enable the "fix_modify"_fix_modify.html {energy} option for
-that fix.  The doc pages for individual "fix"_fix.html commands
-specify if this should be done.
+system (the quantity used when performing GCMC moves), you MUST enable
+the "fix_modify"_fix_modify.html {energy} option for that fix.  The
+doc pages for individual "fix"_fix.html commands specify if this
+should be done.
 
 Use the {charge} option to insert atoms with a user-specified point
-charge. Note that doing so will cause the system to become non-neutral.
-LAMMPS issues a warning when using long-range electrostatics (kspace)
-with non-neutral systems. See the
-"compute group/group"_compute_group_group.html documentation for more
-details about simulating non-neutral systems with kspace on.
+charge. Note that doing so will cause the system to become
+non-neutral.  LAMMPS issues a warning when using long-range
+electrostatics (kspace) with non-neutral systems. See the "compute
+group/group"_compute_group_group.html documentation for more details
+about simulating non-neutral systems with kspace on.
 
 Use of this fix typically will cause the number of atoms to fluctuate,
 therefore, you will want to use the
@@ -262,6 +309,24 @@ therefore, you will want to use the
 current number of atoms is used as a normalizing factor each time
 temperature is computed.  Here is the necessary command:
 
+NOTE: If the density of the cell is initially very small or zero, and
+increases to a much larger density after a period of equilibration,
+then certain quantities that are only calculated once at the start
+(kspace parameters, tail corrections) may no longer be accurate.  The
+solution is to start a new simulation after the equilibrium density
+has been reached.
+
+With some pair_styles, such as "Buckingham"_pair_buck.html,
+"Born-Mayer-Huggins"_pair_born.html and "ReaxFF"_pair_reaxc.html, two
+atoms placed close to each other may have an arbitrary large, negative
+potential energy due to the functional form of the potential.  While
+these unphysical configurations are inaccessible to typical dynamical
+trajectories, they can be generated by Monte Carlo moves. The
+{overlap_cutoff} keyword suppresses these moves by effectively
+assigning an infinite positive energy to all new configurations that
+place any pair of atoms closer than the specified overlap cutoff
+distance.
+
 compute_modify thermo_temp dynamic yes :pre
 
 If LJ units are used, note that a value of 0.18292026 is used by this
@@ -270,10 +335,10 @@ derived from LJ parameters for argon, where h* = h/sqrt(sigma^2 *
 epsilon * mass), sigma = 3.429 angstroms, epsilon/k = 121.85 K, and
 mass = 39.948 amu.
 
-The {group} keyword assigns all inserted atoms to the "group"_group.html
-of the group-ID value. The {grouptype} keyword assigns all
-inserted atoms of the specified type to the "group"_group.html
-of the group-ID value.
+The {group} keyword assigns all inserted atoms to the
+"group"_group.html of the group-ID value. The {grouptype} keyword
+assigns all inserted atoms of the specified type to the
+"group"_group.html of the group-ID value.
 
 [Restart, fix_modify, output, run start/stop, minimize info:]
 
@@ -321,19 +386,15 @@ well in parallel. Only usable for 3D simulations.
 Note that very lengthy simulations involving insertions/deletions of
 billions of gas molecules may run out of atom or molecule IDs and
 trigger an error, so it is better to run multiple shorter-duration
-simulations. Likewise, very large molecules have not been tested
-and may turn out to be problematic.
+simulations. Likewise, very large molecules have not been tested and
+may turn out to be problematic.
 
 Use of multiple fix gcmc commands in the same input script can be
 problematic if using a template molecule. The issue is that the
-user-referenced template molecule in the second fix gcmc command
-may no longer exist since it might have been deleted by the first
-fix gcmc command. An existing template molecule will need to be
-referenced by the user for each subsequent fix gcmc command.
-
-Because molecule insertion does not work in combination with
-fix rigid, simulataneous use of fix rigid or fix rigid/small
-with this fix is not allowed.
+user-referenced template molecule in the second fix gcmc command may
+no longer exist since it might have been deleted by the first fix gcmc
+command. An existing template molecule will need to be referenced by
+the user for each subsequent fix gcmc command.
 
 [Related commands:]
 
@@ -344,7 +405,8 @@ with this fix is not allowed.
 
 [Default:]
 
-The option defaults are mol = no, maxangle = 10, full_energy = no,
+The option defaults are mol = no, maxangle = 10, overlap_cutoff = 0.0,
+fugacity_coeff = 1, and full_energy = no,
 except for the situations where full_energy is required, as
 listed above.
 

doc/src/fix_gle.txt

@@ -67,9 +67,10 @@ target value as the {Tstart} and {Tstop} arguments, so that the diffusion
 matrix that gives canonical sampling for a given A is computed automatically.
 However, the GLE framework also allow for non-equilibrium sampling, that
 can be used for instance to model inexpensively zero-point energy
-effects "(Ceriotti2)"_#Ceriotti2. This is achieved specifying the
-{noneq} keyword followed by the name of the file that contains the
-static covariance matrix for the non-equilibrium dynamics.
+effects "(Ceriotti2)"_#Ceriotti2. This is achieved specifying the {noneq}
+keyword followed by the name of the file that contains the static covariance
+matrix for the non-equilibrium dynamics.  Please note, that the covariance
+matrix is expected to be given in [temperature units].
 
 Since integrating GLE dynamics can be costly when used together with
 simple potentials, one can use the {every} optional keyword to
@@ -148,7 +149,7 @@ dpd/tstat"_pair_dpd.html, "fix gld"_fix_gld.html
 1170-80 (2010)
 
 :link(GLE4MD)
-[(GLE4MD)] "http://epfl-cosmo.github.io/gle4md/"_http://epfl-cosmo.github.io/gle4md/
+[(GLE4MD)] "http://gle4md.org/"_http://gle4md.org/
 
 :link(Ceriotti2)
 [(Ceriotti2)] Ceriotti, Bussi and Parrinello, Phys Rev Lett 103,

doc/src/fix_grem.txt

@@ -85,13 +85,13 @@ No information about this fix is written to "binary restart
 files"_restart.html.
 
 The "thermo_modify"_thermo_modify.html {press} option is supported
-by this fix to add the rescaled kinetic pressure as part of 
+by this fix to add the rescaled kinetic pressure as part of
 "thermodynamic output"_thermo_style.html.
 
 [Restrictions:]
 
-This fix is part of the USER-MISC package. It is only enabled if 
-LAMMPS was built with that package. See the "Making 
+This fix 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:]

doc/src/fix_halt.txt

@@ -15,15 +15,16 @@ fix ID group-ID halt N attribute operator avalue keyword value ... :pre
 ID, group-ID are documented in "fix"_fix.html command :ulb,l
 halt = style name of this fix command :l
 N = check halt condition every N steps :l
-attribute = hstyle or v_name :l
-  hstyle = {bondmax}
+attribute = {bondmax} or {tlimit} or v_name :l
+  bondmax = length of longest bond in the system
+  tlimit = elapsed CPU time
   v_name = name of "equal-style variable"_variable.html :pre
 operator = "<" or "<=" or ">" or ">=" or "==" or "!=" or "|^" :l
 avalue = numeric value to compare attribute to :l
-string = text string to print with optional variable names :l
 zero or more keyword/value pairs may be appended :l
-keyword = {error} :l
-  {error} value = {hard} or {soft} or {continue} :pre
+keyword = {error} or {message} :l
+  {error} value = {hard} or {soft} or {continue}
+  {message} value = {yes} or {no} :pre
 :ule
 
 [Examples:]
@@ -40,14 +41,33 @@ specified by the "run"_run.html or "minimize"_minimize.html command.
 
 The specified group-ID is ignored by this fix.
 
-The specified {attribute} can be one of the {hstyle} options listed
-above, or an "equal-style variable"_variable.html referenced as
-{v_name}, where "name" is the name of a variable that has been defined
-previously in the input script.
+The specified {attribute} can be one of the options listed above,
+namely {bondmax} or {tlimit}, or an "equal-style
+variable"_variable.html referenced as {v_name}, where "name" is the
+name of a variable that has been defined previously in the input
+script.
 
-The only {hstyle} option currently implemented is {bondmax}.  This
-will loop over all bonds in the system, compute their current
-lengths, and set {attribute} to the longest bond distance.
+The {bondmax} attribute will loop over all bonds in the system,
+compute their current lengths, and set {attribute} to the longest bond
+distance.
+
+The {tlimit} attribute queries the elapsed CPU time (in seconds) since
+the current run began, and sets {attribute} to that value.  This is an
+alternative way to limit the length of a simulation run, similar to
+the "timer"_timer.html timeout command.  There are two differences in
+using this method versus the timer command option.  The first is that
+the clock starts at the beginning of the current run (not when the
+timer or fix command is specified), so that any setup time for the run
+is not included in the elapsed time.  The second is that the timer
+invocation and syncing across all processors (via MPI_Allreduce) is
+not performed once every {N} steps by this command.  Instead it is
+performed (typically) only a small number of times and the elapsed
+times are used to predict when the end-of-the-run will be.  Both of
+these attributes can be useful when performing benchmark calculations
+for a desired length of time with minmimal overhead.  For example, if
+a run is performing 1000s of timesteps/sec, the overhead for syncing
+the timer frequently across a large number of processors may be
+non-negligble.
 
 Equal-style variables evaluate to a numeric value.  See the
 "variable"_variable.html command for a description.  They calculate
@@ -100,6 +120,14 @@ Note that you may wish use the "unfix"_unfix.html command on the fix
 halt ID, so that the same condition is not immediately triggered in a
 subsequent run.
 
+The optional {message} keyword determines whether a message is printed
+to the screen and logfile when the halt condition is triggered.  If
+{message} is set to yes, a one line message with the values that
+triggered the halt is printed.  If {message} is set to no, no message
+is printed; the run simply exits.  The latter may be desirable for
+post-processing tools that extract thermodyanmic information from log
+files.
+
 [Restart, fix_modify, output, run start/stop, minimize info:]
 
 No information about this fix is written to "binary restart
@@ -118,4 +146,4 @@ This fix is not invoked during "energy minimization"_minimize.html.
 
 [Default:]
 
-The option defaults are error = hard.
+The option defaults are error = hard and message = yes.

doc/src/fix_ipi.txt

@@ -58,14 +58,14 @@ input are listed in the same order as in the data file of LAMMPS. The
 initial configuration is ignored, as it will be substituted with the
 coordinates received from i-PI before forces are ever evaluated.
 
-A note of caution when using potentials that contain long-range 
+A note of caution when using potentials that contain long-range
 electrostatics, or that contain parameters that depend on box size:
 all of these options will be initialized based on the cell size in the
-LAMMPS-side initial configuration and kept constant during the run. 
-This is required to e.g. obtain reproducible and conserved forces. 
-If the cell varies too wildly, it may be advisable to reinitialize 
-these interactions at each call. This behavior can be requested by 
-setting the {reset} switch. 
+LAMMPS-side initial configuration and kept constant during the run.
+This is required to e.g. obtain reproducible and conserved forces.
+If the cell varies too wildly, it may be advisable to reinitialize
+these interactions at each call. This behavior can be requested by
+setting the {reset} switch.
 
 [Restart, fix_modify, output, run start/stop, minimize info:]
 

doc/src/fix_langevin.txt

@@ -49,7 +49,7 @@ fix 1 all langevin 1.0 1.1 100.0 48279 angmom 3.333 :pre
 
 [Description:]
 
-Apply a Langevin thermostat as described in "(Schneider)"_#Schneider
+Apply a Langevin thermostat as described in "(Schneider)"_#Schneider1
 to a group of atoms which models an interaction with a background
 implicit solvent.  Used with "fix nve"_fix_nve.html, this command
 performs Brownian dynamics (BD), since the total force on each atom
@@ -80,7 +80,7 @@ dt damp), where Kb is the Boltzmann constant, T is the desired
 temperature, m is the mass of the particle, dt is the timestep size,
 and damp is the damping factor.  Random numbers are used to randomize
 the direction and magnitude of this force as described in
-"(Dunweg)"_#Dunweg, where a uniform random number is used (instead of
+"(Dunweg)"_#Dunweg1, where a uniform random number is used (instead of
 a Gaussian random number) for speed.
 
 Note that unless you use the {omega} or {angmom} keywords, the
@@ -332,10 +332,10 @@ types, tally = no, zero = no, gjf = no.
 
 :line
 
-:link(Dunweg)
+:link(Dunweg1)
 [(Dunweg)] Dunweg and Paul, Int J of Modern Physics C, 2, 817-27 (1991).
 
-:link(Schneider)
+:link(Schneider1)
 [(Schneider)] Schneider and Stoll, Phys Rev B, 17, 1302 (1978).
 
 :link(Gronbech-Jensen)

doc/src/fix_langevin_drude.txt

@@ -41,7 +41,7 @@ fix 1 all langevin/drude 298.15 100.0 19377 5.0 10.0 83451 zero yes :pre
 
 [Description:]
 
-Apply two Langevin thermostats as described in "(Jiang)"_#Jiang for
+Apply two Langevin thermostats as described in "(Jiang)"_#Jiang1 for
 thermalizing the reduced degrees of freedom of Drude oscillators.
 This link describes how to use the "thermalized Drude oscillator
 model"_tutorial_drude.html in LAMMPS and polarizable models in LAMMPS
@@ -67,11 +67,11 @@ The Langevin forces are computed as
 \(F_r'\) is a random force proportional to
 \(\sqrt \{ \frac \{2\, k_B \mathtt\{Tcom\}\, m'\}
                  \{\mathrm dt\, \mathtt\{damp\_com\} \}
-        \} \). :b
+        \} \).
 \(f_r'\) is a random force proportional to
 \(\sqrt \{ \frac \{2\, k_B \mathtt\{Tdrude\}\, m'\}
                  \{\mathrm dt\, \mathtt\{damp\_drude\} \}
-        \} \). :b
+        \} \).
 Then the real forces acting on the particles are computed from the inverse
 transform:
 \begin\{equation\} F = \frac M \{M'\}\, F' - f' \end\{equation\}
@@ -268,6 +268,6 @@ The option defaults are zero = no.
 
 :line
 
-:link(Jiang)
+:link(Jiang1)
 [(Jiang)] Jiang, Hardy, Phillips, MacKerell, Schulten, and Roux, J
 Phys Chem Lett, 2, 87-92 (2011).

doc/src/fix_langevin_eff.txt

@@ -37,7 +37,7 @@ fix 1 all langevin/eff 1.0 1.1 10.0 48279 scale 3 1.5 :pre
 
 [Description:]
 
-Apply a Langevin thermostat as described in "(Schneider)"_#Schneider
+Apply a Langevin thermostat as described in "(Schneider)"_#Schneider2
 to a group of nuclei and electrons in the "electron force
 field"_pair_eff.html model.  Used with "fix nve/eff"_fix_nve_eff.html,
 this command performs Brownian dynamics (BD), since the total force on
@@ -106,8 +106,8 @@ The option defaults are scale = 1.0 for all types and tally = no.
 
 :line
 
-:link(Dunweg)
+:link(Dunweg2)
 [(Dunweg)] Dunweg and Paul, Int J of Modern Physics C, 2, 817-27 (1991).
 
-:link(Schneider)
+:link(Schneider2)
 [(Schneider)] Schneider and Stoll, Phys Rev B, 17, 1302 (1978).

doc/src/fix_lb_pc.txt

@@ -24,7 +24,7 @@ fix 1 all lb/pc :pre
 Update the positions and velocities of the individual particles
 described by {group-ID}, experiencing velocity-dependent hydrodynamic
 forces, using the integration algorithm described in "Mackay et
-al."_#Mackay.  This integration algorithm should only be used if a
+al."_#Mackay1.  This integration algorithm should only be used if a
 user-specified value for the force-coupling constant used in "fix
 lb/fluid"_fix_lb_fluid.html has been set; do not use this integration
 algorithm if the force coupling constant has been set by default.
@@ -58,5 +58,5 @@ lb/rigid/pc/sphere"_fix_lb_rigid_pc_sphere.html
 
 :line
 
-:link(Mackay)
+:link(Mackay1)
 [(Mackay et al.)] Mackay, F. E., Ollila, S.T.T., and Denniston, C., Hydrodynamic Forces Implemented into LAMMPS through a lattice-Boltzmann fluid, Computer Physics Communications 184 (2013) 2021-2031.

doc/src/fix_lb_viscous.txt

@@ -44,7 +44,7 @@ hydrodynamic forces to the particles.
 :line
 
 For further details, as well as descriptions and results of several
-test runs, see "Mackay et al."_#Mackay.  Please include a citation to
+test runs, see "Mackay et al."_#Mackay3.  Please include a citation to
 this paper if this fix is used in work contributing to published
 research.
 
@@ -90,5 +90,5 @@ lb/rigid/pc/sphere"_fix_lb_rigid_pc_sphere.html
 
 :line
 
-:link(Mackay)
+:link(Mackay3)
 [(Mackay et al.)] Mackay, F. E., Ollila, S.T.T., and Denniston, C., Hydrodynamic Forces Implemented into LAMMPS through a lattice-Boltzmann fluid, Computer Physics Communications 184 (2013) 2021-2031.

doc/src/fix_modify.txt

@@ -14,11 +14,13 @@ fix_modify fix-ID keyword value ... :pre
 
 fix-ID = ID of the fix to modify :ulb,l
 one or more keyword/value pairs may be appended :l
-keyword = {temp} or {press} or {energy} or {respa} :l
+keyword = {temp} or {press} or {energy} or {respa} or {dynamic/dof} :l
   {temp} value = compute ID that calculates a temperature
   {press} value = compute ID that calculates a pressure
   {energy} value = {yes} or {no}
-  {respa} value = {1} to {max respa level} or {0} (for outermost level) :pre
+  {respa} value = {1} to {max respa level} or {0} (for outermost level)
+  {dynamic/dof} value = {yes} or {no}
+    yes/no = do or do not recompute the number of degrees of freedom (DOF) contributing to the temperature :pre
 :ule
 
 [Examples:]
@@ -78,6 +80,27 @@ enabled to support this feature; if not, {fix_modify} will report an
 error. Active fixes with a custom RESPA level setting are reported
 with their specified level at the beginning of a r-RESPA run.
 
+The {dynamic/dof} keyword determines whether the number of atoms N in
+the fix group and their associated degrees of freedom are re-computed
+each time a temperature is computed.  Only fix styles that calculate
+their own internal temperature use this option.  Currently this is
+only the "fix rigid/nvt/small"_fix_rigid.html and "fix
+rigid/npt/small"_fix_rigid.html commands for the purpose of
+thermostatting rigid body translation and rotation.  By default, N and
+their DOF are assumed to be constant.  If you are 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 evaporate"_fix_evaporate.html), then
+this option should be used to insure the temperature is correctly
+normalized.
+
+NOTE: Other thermostatting fixes, such as "fix nvt"_fix_nh.html, do
+not use the {dynamic/dof} keyword because they use a temperature
+compute to calculate temperature.  See the "compute_modify
+dynamic/dof"_compute_modify.html command for a similar way to insure
+correct temperature normalization for those thermostats.
+
 [Restrictions:] none
 
 [Related commands:]

doc/src/fix_mscg.txt

@@ -57,7 +57,7 @@ simulations is as follows:
 Perform all-atom simulations on the system to be coarse grained.
 Generate a trajectory mapped to the coarse-grained model.
 Create input files for the MS-CG library.
-Run the range finder functionality of the MS-CG library.  
+Run the range finder functionality of the MS-CG library.
 Run the force matching functionality of the MS-CG library.
 Check the results of the force matching.
 Run coarse-grained simulations using the new coarse-grained potentials. :ol
@@ -70,7 +70,7 @@ Step 2 can be performed using a Python script (what is the name?)
 provided with the MS-CG library which defines the coarse-grained model
 and converts a standard LAMMPS dump file for an all-atom simulation
 (step 1) into a LAMMPS dump file which has the positions of and forces
-on the coarse-grained beads.  
+on the coarse-grained beads.
 
 In step 3, an input file named "control.in" is needed by the MS-CG
 library which sets parameters for the range finding and force matching