patch 11Aug17

Fixes for stable

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

.gitignore

@@ -0,0 +1,34 @@
+*~
+*.o
+*.so
+*.cu_o
+*.ptx
+*_ptx.h
+*.a
+*.d
+*.x
+*.exe
+*.dll
+*.pyc
+__pycache__
+
+Obj_*
+log.lammps
+log.cite
+*.bz2
+*.gz
+*.tar
+.*.swp
+*.orig
+*.rej
+.vagrant
+\#*#
+.#*
+
+.DS_Store
+.DS_Store?
+._*
+.Spotlight-V100
+.Trashes
+ehthumbs.db
+Thumbs.db

LICENSE

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

bench/FERMI/README

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

bench/README

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

bench/log.15Feb16.chain.fixed.icc.1

@@ -1,78 +0,0 @@
-LAMMPS (15 Feb 2016)
-# FENE beadspring benchmark
-
-units		lj
-atom_style	bond
-special_bonds   fene
-
-read_data	data.chain
-  orthogonal box = (-16.796 -16.796 -16.796) to (16.796 16.796 16.796)
-  1 by 1 by 1 MPI processor grid
-  reading atoms ...
-  32000 atoms
-  reading velocities ...
-  32000 velocities
-  scanning bonds ...
-  1 = max bonds/atom
-  reading bonds ...
-  31680 bonds
-  2 = max # of 1-2 neighbors
-  2 = max # of special neighbors
-
-neighbor	0.4 bin
-neigh_modify	every 1 delay 1
-
-bond_style      fene
-bond_coeff	1 30.0 1.5 1.0 1.0
-
-pair_style	lj/cut 1.12
-pair_modify	shift yes
-pair_coeff	1 1 1.0 1.0 1.12
-
-fix		1 all nve
-fix		2 all langevin 1.0 1.0 10.0 904297
-
-thermo          100
-timestep	0.012
-
-run		100
-Neighbor list info ...
-  1 neighbor list requests
-  update every 1 steps, delay 1 steps, check yes
-  max neighbors/atom: 2000, page size: 100000
-  master list distance cutoff = 1.52
-  ghost atom cutoff = 1.52
-  binsize = 0.76 -> bins = 45 45 45
-Memory usage per processor = 11.5189 Mbytes
-Step Temp E_pair E_mol TotEng Press 
-       0   0.97029772   0.44484087    20.494523    22.394765    4.6721833 
-     100    0.9729966    0.4361122    20.507698     22.40326    4.6548819 
-Loop time of 0.978585 on 1 procs for 100 steps with 32000 atoms
-
-Performance: 105948.895 tau/day, 102.188 timesteps/s
-100.0% CPU use with 1 MPI tasks x no OpenMP threads
-
-MPI task timing breakdown:
-Section |  min time  |  avg time  |  max time  |%varavg| %total
----------------------------------------------------------------
-Pair    | 0.19562    | 0.19562    | 0.19562    |   0.0 | 19.99
-Bond    | 0.087475   | 0.087475   | 0.087475   |   0.0 |  8.94
-Neigh   | 0.44861    | 0.44861    | 0.44861    |   0.0 | 45.84
-Comm    | 0.032932   | 0.032932   | 0.032932   |   0.0 |  3.37
-Output  | 0.00010395 | 0.00010395 | 0.00010395 |   0.0 |  0.01
-Modify  | 0.19413    | 0.19413    | 0.19413    |   0.0 | 19.84
-Other   |            | 0.01972    |            |       |  2.02
-
-Nlocal:    32000 ave 32000 max 32000 min
-Histogram: 1 0 0 0 0 0 0 0 0 0
-Nghost:    9493 ave 9493 max 9493 min
-Histogram: 1 0 0 0 0 0 0 0 0 0
-Neighs:    155873 ave 155873 max 155873 min
-Histogram: 1 0 0 0 0 0 0 0 0 0
-
-Total # of neighbors = 155873
-Ave neighs/atom = 4.87103
-Ave special neighs/atom = 1.98
-Neighbor list builds = 25
-Dangerous builds = 0
-Total wall time: 0:00:01

bench/log.15Feb16.chain.fixed.icc.4

@@ -1,78 +0,0 @@
-LAMMPS (15 Feb 2016)
-# FENE beadspring benchmark
-
-units		lj
-atom_style	bond
-special_bonds   fene
-
-read_data	data.chain
-  orthogonal box = (-16.796 -16.796 -16.796) to (16.796 16.796 16.796)
-  1 by 2 by 2 MPI processor grid
-  reading atoms ...
-  32000 atoms
-  reading velocities ...
-  32000 velocities
-  scanning bonds ...
-  1 = max bonds/atom
-  reading bonds ...
-  31680 bonds
-  2 = max # of 1-2 neighbors
-  2 = max # of special neighbors
-
-neighbor	0.4 bin
-neigh_modify	every 1 delay 1
-
-bond_style      fene
-bond_coeff	1 30.0 1.5 1.0 1.0
-
-pair_style	lj/cut 1.12
-pair_modify	shift yes
-pair_coeff	1 1 1.0 1.0 1.12
-
-fix		1 all nve
-fix		2 all langevin 1.0 1.0 10.0 904297
-
-thermo          100
-timestep	0.012
-
-run		100
-Neighbor list info ...
-  1 neighbor list requests
-  update every 1 steps, delay 1 steps, check yes
-  max neighbors/atom: 2000, page size: 100000
-  master list distance cutoff = 1.52
-  ghost atom cutoff = 1.52
-  binsize = 0.76 -> bins = 45 45 45
-Memory usage per processor = 3.91518 Mbytes
-Step Temp E_pair E_mol TotEng Press 
-       0   0.97029772   0.44484087    20.494523    22.394765    4.6721833 
-     100   0.97145835   0.43803883    20.502691    22.397872     4.626988 
-Loop time of 0.271187 on 4 procs for 100 steps with 32000 atoms
-
-Performance: 382319.453 tau/day, 368.749 timesteps/s
-99.6% CPU use with 4 MPI tasks x no OpenMP threads
-
-MPI task timing breakdown:
-Section |  min time  |  avg time  |  max time  |%varavg| %total
----------------------------------------------------------------
-Pair    | 0.048621   | 0.050076   | 0.051229   |   0.4 | 18.47
-Bond    | 0.022254   | 0.022942   | 0.023567   |   0.3 |  8.46
-Neigh   | 0.11873    | 0.11881    | 0.11887    |   0.0 | 43.81
-Comm    | 0.019066   | 0.021357   | 0.024297   |   1.3 |  7.88
-Output  | 5.0068e-05 | 5.5015e-05 | 6.1035e-05 |   0.1 |  0.02
-Modify  | 0.048737   | 0.050198   | 0.051231   |   0.4 | 18.51
-Other   |            | 0.007751   |            |       |  2.86
-
-Nlocal:    8000 ave 8030 max 7974 min
-Histogram: 1 0 0 1 0 1 0 0 0 1
-Nghost:    4177 ave 4191 max 4160 min
-Histogram: 1 0 0 0 1 0 0 1 0 1
-Neighs:    38995.8 ave 39169 max 38852 min
-Histogram: 1 0 0 1 1 0 0 0 0 1
-
-Total # of neighbors = 155983
-Ave neighs/atom = 4.87447
-Ave special neighs/atom = 1.98
-Neighbor list builds = 25
-Dangerous builds = 0
-Total wall time: 0:00:00

bench/log.15Feb16.chain.scaled.icc.4

@@ -1,94 +0,0 @@
-LAMMPS (15 Feb 2016)
-# FENE beadspring benchmark
-
-variable	x index 1
-variable	y index 1
-variable	z index 1
-
-units		lj
-atom_style	bond
-atom_modify	map hash
-special_bonds   fene
-
-read_data	data.chain
-  orthogonal box = (-16.796 -16.796 -16.796) to (16.796 16.796 16.796)
-  1 by 2 by 2 MPI processor grid
-  reading atoms ...
-  32000 atoms
-  reading velocities ...
-  32000 velocities
-  scanning bonds ...
-  1 = max bonds/atom
-  reading bonds ...
-  31680 bonds
-  2 = max # of 1-2 neighbors
-  2 = max # of special neighbors
-
-replicate	$x $y $z
-replicate	2 $y $z
-replicate	2 2 $z
-replicate	2 2 1
-  orthogonal box = (-16.796 -16.796 -16.796) to (50.388 50.388 16.796)
-  2 by 2 by 1 MPI processor grid
-  128000 atoms
-  126720 bonds
-  2 = max # of 1-2 neighbors
-  2 = max # of special neighbors
-
-neighbor	0.4 bin
-neigh_modify	every 1 delay 1
-
-bond_style      fene
-bond_coeff	1 30.0 1.5 1.0 1.0
-
-pair_style	lj/cut 1.12
-pair_modify	shift yes
-pair_coeff	1 1 1.0 1.0 1.12
-
-fix		1 all nve
-fix		2 all langevin 1.0 1.0 10.0 904297
-
-thermo          100
-timestep	0.012
-
-run		100
-Neighbor list info ...
-  1 neighbor list requests
-  update every 1 steps, delay 1 steps, check yes
-  max neighbors/atom: 2000, page size: 100000
-  master list distance cutoff = 1.52
-  ghost atom cutoff = 1.52
-  binsize = 0.76 -> bins = 89 89 45
-Memory usage per processor = 12.8735 Mbytes
-Step Temp E_pair E_mol TotEng Press 
-       0   0.97027498   0.44484087    20.494523    22.394765    4.6721833 
-     100   0.97682955   0.44239968    20.500229    22.407862    4.6527025 
-Loop time of 1.20889 on 4 procs for 100 steps with 128000 atoms
-
-Performance: 85764.410 tau/day, 82.720 timesteps/s
-99.8% CPU use with 4 MPI tasks x no OpenMP threads
-
-MPI task timing breakdown:
-Section |  min time  |  avg time  |  max time  |%varavg| %total
----------------------------------------------------------------
-Pair    | 0.21738    | 0.23306    | 0.23926    |   1.9 | 19.28
-Bond    | 0.094536   | 0.10196    | 0.10534    |   1.4 |  8.43
-Neigh   | 0.52311    | 0.52392    | 0.52519    |   0.1 | 43.34
-Comm    | 0.090161   | 0.10022    | 0.12557    |   4.7 |  8.29
-Output  | 0.00012207 | 0.00017327 | 0.00019598 |   0.2 |  0.01
-Modify  | 0.19662    | 0.20262    | 0.20672    |   0.8 | 16.76
-Other   |            | 0.04694    |            |       |  3.88
-
-Nlocal:    32000 ave 32015 max 31983 min
-Histogram: 1 0 1 0 0 0 0 0 1 1
-Nghost:    9492 ave 9522 max 9432 min
-Histogram: 1 0 0 0 0 0 1 0 0 2
-Neighs:    155837 ave 156079 max 155506 min
-Histogram: 1 0 0 0 0 1 0 0 1 1
-
-Total # of neighbors = 623349
-Ave neighs/atom = 4.86991
-Ave special neighs/atom = 1.98
-Neighbor list builds = 25
-Dangerous builds = 0
-Total wall time: 0:00:01

bench/log.15Feb16.chute.fixed.icc.1

@@ -1,80 +0,0 @@
-LAMMPS (15 Feb 2016)
-# LAMMPS benchmark of granular flow
-# chute flow of 32000 atoms with frozen base at 26 degrees
-
-units		lj
-atom_style	sphere
-boundary	p p fs
-newton		off
-comm_modify	vel yes
-
-read_data	data.chute
-  orthogonal box = (0 0 0) to (40 20 37.2886)
-  1 by 1 by 1 MPI processor grid
-  reading atoms ...
-  32000 atoms
-  reading velocities ...
-  32000 velocities
-
-pair_style	gran/hooke/history 200000.0 NULL 50.0 NULL 0.5 0
-pair_coeff	* *
-
-neighbor	0.1 bin
-neigh_modify	every 1 delay 0
-
-timestep	0.0001
-
-group		bottom type 2
-912 atoms in group bottom
-group		active subtract all bottom
-31088 atoms in group active
-neigh_modify	exclude group bottom bottom
-
-fix		1 all gravity 1.0 chute 26.0
-fix		2 bottom freeze
-fix		3 active nve/sphere
-
-compute		1 all erotate/sphere
-thermo_style	custom step atoms ke c_1 vol
-thermo_modify	norm no
-thermo		100
-
-run		100
-Neighbor list info ...
-  2 neighbor list requests
-  update every 1 steps, delay 0 steps, check yes
-  max neighbors/atom: 2000, page size: 100000
-  master list distance cutoff = 1.1
-  ghost atom cutoff = 1.1
-  binsize = 0.55 -> bins = 73 37 68
-Memory usage per processor = 15.567 Mbytes
-Step Atoms KinEng 1 Volume 
-       0    32000    784139.13    1601.1263    29833.783 
-     100    32000    784292.08    1571.0968    29834.707 
-Loop time of 0.550482 on 1 procs for 100 steps with 32000 atoms
-
-Performance: 1569.534 tau/day, 181.659 timesteps/s
-100.1% CPU use with 1 MPI tasks x no OpenMP threads
-
-MPI task timing breakdown:
-Section |  min time  |  avg time  |  max time  |%varavg| %total
----------------------------------------------------------------
-Pair    | 0.33849    | 0.33849    | 0.33849    |   0.0 | 61.49
-Neigh   | 0.040353   | 0.040353   | 0.040353   |   0.0 |  7.33
-Comm    | 0.018023   | 0.018023   | 0.018023   |   0.0 |  3.27
-Output  | 0.00020385 | 0.00020385 | 0.00020385 |   0.0 |  0.04
-Modify  | 0.13155    | 0.13155    | 0.13155    |   0.0 | 23.90
-Other   |            | 0.02186    |            |       |  3.97
-
-Nlocal:    32000 ave 32000 max 32000 min
-Histogram: 1 0 0 0 0 0 0 0 0 0
-Nghost:    5463 ave 5463 max 5463 min
-Histogram: 1 0 0 0 0 0 0 0 0 0
-Neighs:    115133 ave 115133 max 115133 min
-Histogram: 1 0 0 0 0 0 0 0 0 0
-
-Total # of neighbors = 115133
-Ave neighs/atom = 3.59791
-Neighbor list builds = 2
-Dangerous builds = 0
-Total wall time: 0:00:00

bench/log.15Feb16.chute.fixed.icc.4

@@ -1,80 +0,0 @@
-LAMMPS (15 Feb 2016)
-# LAMMPS benchmark of granular flow
-# chute flow of 32000 atoms with frozen base at 26 degrees
-
-units		lj
-atom_style	sphere
-boundary	p p fs
-newton		off
-comm_modify	vel yes
-
-read_data	data.chute
-  orthogonal box = (0 0 0) to (40 20 37.2886)
-  2 by 1 by 2 MPI processor grid
-  reading atoms ...
-  32000 atoms
-  reading velocities ...
-  32000 velocities
-
-pair_style	gran/hooke/history 200000.0 NULL 50.0 NULL 0.5 0
-pair_coeff	* *
-
-neighbor	0.1 bin
-neigh_modify	every 1 delay 0
-
-timestep	0.0001
-
-group		bottom type 2
-912 atoms in group bottom
-group		active subtract all bottom
-31088 atoms in group active
-neigh_modify	exclude group bottom bottom
-
-fix		1 all gravity 1.0 chute 26.0
-fix		2 bottom freeze
-fix		3 active nve/sphere
-
-compute		1 all erotate/sphere
-thermo_style	custom step atoms ke c_1 vol
-thermo_modify	norm no
-thermo		100
-
-run		100
-Neighbor list info ...
-  2 neighbor list requests
-  update every 1 steps, delay 0 steps, check yes
-  max neighbors/atom: 2000, page size: 100000
-  master list distance cutoff = 1.1
-  ghost atom cutoff = 1.1
-  binsize = 0.55 -> bins = 73 37 68
-Memory usage per processor = 6.81783 Mbytes
-Step Atoms KinEng 1 Volume 
-       0    32000    784139.13    1601.1263    29833.783 
-     100    32000    784292.08    1571.0968    29834.707 
-Loop time of 0.13141 on 4 procs for 100 steps with 32000 atoms
-
-Performance: 6574.833 tau/day, 760.976 timesteps/s
-99.3% CPU use with 4 MPI tasks x no OpenMP threads
-
-MPI task timing breakdown:
-Section |  min time  |  avg time  |  max time  |%varavg| %total
----------------------------------------------------------------
-Pair    | 0.062505   | 0.067      | 0.07152    |   1.5 | 50.99
-Neigh   | 0.010041   | 0.0101     | 0.010178   |   0.1 |  7.69
-Comm    | 0.012347   | 0.012895   | 0.013444   |   0.5 |  9.81
-Output  | 6.3896e-05 | 0.00010294 | 0.00014091 |   0.3 |  0.08
-Modify  | 0.031802   | 0.032348   | 0.032897   |   0.3 | 24.62
-Other   |            | 0.008965   |            |       |  6.82
-
-Nlocal:    8000 ave 8008 max 7992 min
-Histogram: 2 0 0 0 0 0 0 0 0 2
-Nghost:    2439 ave 2450 max 2428 min
-Histogram: 2 0 0 0 0 0 0 0 0 2
-Neighs:    29500.5 ave 30488 max 28513 min
-Histogram: 2 0 0 0 0 0 0 0 0 2
-
-Total # of neighbors = 118002
-Ave neighs/atom = 3.68756
-Neighbor list builds = 2
-Dangerous builds = 0
-Total wall time: 0:00:00

bench/log.15Feb16.chute.scaled.icc.4

@@ -1,90 +0,0 @@
-LAMMPS (15 Feb 2016)
-# LAMMPS benchmark of granular flow
-# chute flow of 32000 atoms with frozen base at 26 degrees
-
-variable	x index 1
-variable	y index 1
-
-units		lj
-atom_style	sphere
-boundary	p p fs
-newton		off
-comm_modify	vel yes
-
-read_data	data.chute
-  orthogonal box = (0 0 0) to (40 20 37.2886)
-  2 by 1 by 2 MPI processor grid
-  reading atoms ...
-  32000 atoms
-  reading velocities ...
-  32000 velocities
-
-replicate	$x $y 1
-replicate	2 $y 1
-replicate	2 2 1
-  orthogonal box = (0 0 0) to (80 40 37.2922)
-  2 by 2 by 1 MPI processor grid
-  128000 atoms
-
-pair_style	gran/hooke/history 200000.0 NULL 50.0 NULL 0.5 0
-pair_coeff	* *
-
-neighbor	0.1 bin
-neigh_modify	every 1 delay 0
-
-timestep	0.0001
-
-group		bottom type 2
-3648 atoms in group bottom
-group		active subtract all bottom
-124352 atoms in group active
-neigh_modify	exclude group bottom bottom
-
-fix		1 all gravity 1.0 chute 26.0
-fix		2 bottom freeze
-fix		3 active nve/sphere
-
-compute		1 all erotate/sphere
-thermo_style	custom step atoms ke c_1 vol
-thermo_modify	norm no
-thermo		100
-
-run		100
-Neighbor list info ...
-  2 neighbor list requests
-  update every 1 steps, delay 0 steps, check yes
-  max neighbors/atom: 2000, page size: 100000
-  master list distance cutoff = 1.1
-  ghost atom cutoff = 1.1
-  binsize = 0.55 -> bins = 146 73 68
-Memory usage per processor = 15.7007 Mbytes
-Step Atoms KinEng 1 Volume 
-       0   128000    3136556.5    6404.5051    119335.13 
-     100   128000    3137168.3    6284.3873    119338.83 
-Loop time of 0.906913 on 4 procs for 100 steps with 128000 atoms
-
-Performance: 952.683 tau/day, 110.264 timesteps/s
-99.7% CPU use with 4 MPI tasks x no OpenMP threads
-
-MPI task timing breakdown:
-Section |  min time  |  avg time  |  max time  |%varavg| %total
----------------------------------------------------------------
-Pair    | 0.51454    | 0.53094    | 0.55381    |   2.0 | 58.54
-Neigh   | 0.042597   | 0.043726   | 0.045801   |   0.6 |  4.82
-Comm    | 0.063027   | 0.064657   | 0.067367   |   0.7 |  7.13
-Output  | 0.00024891 | 0.00059718 | 0.00086498 |   1.0 |  0.07
-Modify  | 0.16508    | 0.17656    | 0.1925     |   2.6 | 19.47
-Other   |            | 0.09043    |            |       |  9.97
-
-Nlocal:    32000 ave 32000 max 32000 min
-Histogram: 4 0 0 0 0 0 0 0 0 0
-Nghost:    5463 ave 5463 max 5463 min
-Histogram: 4 0 0 0 0 0 0 0 0 0
-Neighs:    115133 ave 115133 max 115133 min
-Histogram: 4 0 0 0 0 0 0 0 0 0
-
-Total # of neighbors = 460532
-Ave neighs/atom = 3.59791
-Neighbor list builds = 2
-Dangerous builds = 0
-Total wall time: 0:00:01

bench/log.15Feb16.eam.fixed.icc.1

@@ -1,83 +0,0 @@
-LAMMPS (15 Feb 2016)
-# bulk Cu lattice
-
-variable	x index 1
-variable	y index 1
-variable	z index 1
-
-variable	xx equal 20*$x
-variable	xx equal 20*1
-variable	yy equal 20*$y
-variable	yy equal 20*1
-variable	zz equal 20*$z
-variable	zz equal 20*1
-
-units		metal
-atom_style	atomic
-
-lattice		fcc 3.615
-Lattice spacing in x,y,z = 3.615 3.615 3.615
-region		box block 0 ${xx} 0 ${yy} 0 ${zz}
-region		box block 0 20 0 ${yy} 0 ${zz}
-region		box block 0 20 0 20 0 ${zz}
-region		box block 0 20 0 20 0 20
-create_box	1 box
-Created orthogonal box = (0 0 0) to (72.3 72.3 72.3)
-  1 by 1 by 1 MPI processor grid
-create_atoms	1 box
-Created 32000 atoms
-
-pair_style	eam
-pair_coeff	1 1 Cu_u3.eam
-Reading potential file Cu_u3.eam with DATE: 2007-06-11
-
-velocity	all create 1600.0 376847 loop geom
-
-neighbor	1.0 bin
-neigh_modify    every 1 delay 5 check yes
-
-fix		1 all nve
-
-timestep	0.005
-thermo		50
-
-run		100
-Neighbor list info ...
-  1 neighbor list requests
-  update every 1 steps, delay 5 steps, check yes
-  max neighbors/atom: 2000, page size: 100000
-  master list distance cutoff = 5.95
-  ghost atom cutoff = 5.95
-  binsize = 2.975 -> bins = 25 25 25
-Memory usage per processor = 10.2238 Mbytes
-Step Temp E_pair E_mol TotEng Press 
-       0         1600      -113280            0   -106662.09    18703.573 
-      50    781.69049   -109873.35            0   -106640.13    52273.088 
-     100      801.832    -109957.3            0   -106640.77    51322.821 
-Loop time of 5.90097 on 1 procs for 100 steps with 32000 atoms
-
-Performance: 7.321 ns/day, 3.278 hours/ns, 16.946 timesteps/s
-99.9% CPU use with 1 MPI tasks x no OpenMP threads
-
-MPI task timing breakdown:
-Section |  min time  |  avg time  |  max time  |%varavg| %total
----------------------------------------------------------------
-Pair    | 5.2121     | 5.2121     | 5.2121     |   0.0 | 88.33
-Neigh   | 0.58212    | 0.58212    | 0.58212    |   0.0 |  9.86
-Comm    | 0.030392   | 0.030392   | 0.030392   |   0.0 |  0.52
-Output  | 0.00023389 | 0.00023389 | 0.00023389 |   0.0 |  0.00
-Modify  | 0.060871   | 0.060871   | 0.060871   |   0.0 |  1.03
-Other   |            | 0.01527    |            |       |  0.26
-
-Nlocal:    32000 ave 32000 max 32000 min
-Histogram: 1 0 0 0 0 0 0 0 0 0
-Nghost:    19909 ave 19909 max 19909 min
-Histogram: 1 0 0 0 0 0 0 0 0 0
-Neighs:    1.20778e+06 ave 1.20778e+06 max 1.20778e+06 min
-Histogram: 1 0 0 0 0 0 0 0 0 0
-
-Total # of neighbors = 1207784
-Ave neighs/atom = 37.7433
-Neighbor list builds = 13
-Dangerous builds = 0
-Total wall time: 0:00:06

bench/log.15Feb16.eam.fixed.icc.4

@@ -1,83 +0,0 @@
-LAMMPS (15 Feb 2016)
-# bulk Cu lattice
-
-variable	x index 1
-variable	y index 1
-variable	z index 1
-
-variable	xx equal 20*$x
-variable	xx equal 20*1
-variable	yy equal 20*$y
-variable	yy equal 20*1
-variable	zz equal 20*$z
-variable	zz equal 20*1
-
-units		metal
-atom_style	atomic
-
-lattice		fcc 3.615
-Lattice spacing in x,y,z = 3.615 3.615 3.615
-region		box block 0 ${xx} 0 ${yy} 0 ${zz}
-region		box block 0 20 0 ${yy} 0 ${zz}
-region		box block 0 20 0 20 0 ${zz}
-region		box block 0 20 0 20 0 20
-create_box	1 box
-Created orthogonal box = (0 0 0) to (72.3 72.3 72.3)
-  1 by 2 by 2 MPI processor grid
-create_atoms	1 box
-Created 32000 atoms
-
-pair_style	eam
-pair_coeff	1 1 Cu_u3.eam
-Reading potential file Cu_u3.eam with DATE: 2007-06-11
-
-velocity	all create 1600.0 376847 loop geom
-
-neighbor	1.0 bin
-neigh_modify    every 1 delay 5 check yes
-
-fix		1 all nve
-
-timestep	0.005
-thermo		50
-
-run		100
-Neighbor list info ...
-  1 neighbor list requests
-  update every 1 steps, delay 5 steps, check yes
-  max neighbors/atom: 2000, page size: 100000
-  master list distance cutoff = 5.95
-  ghost atom cutoff = 5.95
-  binsize = 2.975 -> bins = 25 25 25
-Memory usage per processor = 5.09629 Mbytes
-Step Temp E_pair E_mol TotEng Press 
-       0         1600      -113280            0   -106662.09    18703.573 
-      50    781.69049   -109873.35            0   -106640.13    52273.088 
-     100      801.832    -109957.3            0   -106640.77    51322.821 
-Loop time of 1.58019 on 4 procs for 100 steps with 32000 atoms
-
-Performance: 27.338 ns/day, 0.878 hours/ns, 63.284 timesteps/s
-99.8% CPU use with 4 MPI tasks x no OpenMP threads
-
-MPI task timing breakdown:
-Section |  min time  |  avg time  |  max time  |%varavg| %total
----------------------------------------------------------------
-Pair    | 1.3617     | 1.366      | 1.3723     |   0.4 | 86.45
-Neigh   | 0.15123    | 0.15232    | 0.15374    |   0.2 |  9.64
-Comm    | 0.033429   | 0.041275   | 0.047066   |   2.7 |  2.61
-Output  | 0.00011301 | 0.0001573  | 0.000211   |   0.3 |  0.01
-Modify  | 0.014694   | 0.015085   | 0.015421   |   0.2 |  0.95
-Other   |            | 0.005342   |            |       |  0.34
-
-Nlocal:    8000 ave 8008 max 7993 min
-Histogram: 2 0 0 0 0 0 0 0 1 1
-Nghost:    9130.25 ave 9138 max 9122 min
-Histogram: 2 0 0 0 0 0 0 0 0 2
-Neighs:    301946 ave 302392 max 301360 min
-Histogram: 1 0 0 0 1 0 0 0 1 1
-
-Total # of neighbors = 1207784
-Ave neighs/atom = 37.7433
-Neighbor list builds = 13
-Dangerous builds = 0
-Total wall time: 0:00:01

bench/log.15Feb16.eam.scaled.icc.4

@@ -1,83 +0,0 @@
-LAMMPS (15 Feb 2016)
-# bulk Cu lattice
-
-variable	x index 1
-variable	y index 1
-variable	z index 1
-
-variable	xx equal 20*$x
-variable	xx equal 20*2
-variable	yy equal 20*$y
-variable	yy equal 20*2
-variable	zz equal 20*$z
-variable	zz equal 20*1
-
-units		metal
-atom_style	atomic
-
-lattice		fcc 3.615
-Lattice spacing in x,y,z = 3.615 3.615 3.615
-region		box block 0 ${xx} 0 ${yy} 0 ${zz}
-region		box block 0 40 0 ${yy} 0 ${zz}
-region		box block 0 40 0 40 0 ${zz}
-region		box block 0 40 0 40 0 20
-create_box	1 box
-Created orthogonal box = (0 0 0) to (144.6 144.6 72.3)
-  2 by 2 by 1 MPI processor grid
-create_atoms	1 box
-Created 128000 atoms
-
-pair_style	eam
-pair_coeff	1 1 Cu_u3.eam
-Reading potential file Cu_u3.eam with DATE: 2007-06-11
-
-velocity	all create 1600.0 376847 loop geom
-
-neighbor	1.0 bin
-neigh_modify    every 1 delay 5 check yes
-
-fix		1 all nve
-
-timestep	0.005
-thermo		50
-
-run		100
-Neighbor list info ...
-  1 neighbor list requests
-  update every 1 steps, delay 5 steps, check yes
-  max neighbors/atom: 2000, page size: 100000
-  master list distance cutoff = 5.95
-  ghost atom cutoff = 5.95
-  binsize = 2.975 -> bins = 49 49 25
-Memory usage per processor = 10.1402 Mbytes
-Step Temp E_pair E_mol TotEng Press 
-       0         1600      -453120            0   -426647.73    18704.012 
-      50    779.50001   -439457.02            0   -426560.06    52355.276 
-     100    797.97828   -439764.76            0   -426562.07     51474.74 
-Loop time of 6.46849 on 4 procs for 100 steps with 128000 atoms
-
-Performance: 6.679 ns/day, 3.594 hours/ns, 15.460 timesteps/s
-99.9% CPU use with 4 MPI tasks x no OpenMP threads
-
-MPI task timing breakdown:
-Section |  min time  |  avg time  |  max time  |%varavg| %total
----------------------------------------------------------------
-Pair    | 5.581      | 5.5997     | 5.6265     |   0.8 | 86.57
-Neigh   | 0.65287    | 0.658      | 0.66374    |   0.5 | 10.17
-Comm    | 0.075706   | 0.11015    | 0.13655    |   7.2 |  1.70
-Output  | 0.00026488 | 0.00028312 | 0.00029302 |   0.1 |  0.00
-Modify  | 0.069607   | 0.072407   | 0.074555   |   0.7 |  1.12
-Other   |            | 0.02794    |            |       |  0.43
-
-Nlocal:    32000 ave 32092 max 31914 min
-Histogram: 1 0 0 1 0 1 0 0 0 1
-Nghost:    19910 ave 19997 max 19818 min
-Histogram: 1 0 0 0 1 0 1 0 0 1
-Neighs:    1.20728e+06 ave 1.21142e+06 max 1.2036e+06 min
-Histogram: 1 0 0 1 1 0 0 0 0 1
-
-Total # of neighbors = 4829126
-Ave neighs/atom = 37.7275
-Neighbor list builds = 14
-Dangerous builds = 0
-Total wall time: 0:00:06

bench/log.15Feb16.lj.fixed.icc.1

@@ -1,79 +0,0 @@
-LAMMPS (15 Feb 2016)
-# 3d Lennard-Jones melt
-
-variable	x index 1
-variable	y index 1
-variable	z index 1
-
-variable	xx equal 20*$x
-variable	xx equal 20*1
-variable	yy equal 20*$y
-variable	yy equal 20*1
-variable	zz equal 20*$z
-variable	zz equal 20*1
-
-units		lj
-atom_style	atomic
-
-lattice		fcc 0.8442
-Lattice spacing in x,y,z = 1.6796 1.6796 1.6796
-region		box block 0 ${xx} 0 ${yy} 0 ${zz}
-region		box block 0 20 0 ${yy} 0 ${zz}
-region		box block 0 20 0 20 0 ${zz}
-region		box block 0 20 0 20 0 20
-create_box	1 box
-Created orthogonal box = (0 0 0) to (33.5919 33.5919 33.5919)
-  1 by 1 by 1 MPI processor grid
-create_atoms	1 box
-Created 32000 atoms
-mass		1 1.0
-
-velocity	all create 1.44 87287 loop geom
-
-pair_style	lj/cut 2.5
-pair_coeff	1 1 1.0 1.0 2.5
-
-neighbor	0.3 bin
-neigh_modify	delay 0 every 20 check no
-
-fix		1 all nve
-
-run		100
-Neighbor list info ...
-  1 neighbor list requests
-  update every 20 steps, delay 0 steps, check no
-  max neighbors/atom: 2000, page size: 100000
-  master list distance cutoff = 2.8
-  ghost atom cutoff = 2.8
-  binsize = 1.4 -> bins = 24 24 24
-Memory usage per processor = 8.21387 Mbytes
-Step Temp E_pair E_mol TotEng Press 
-       0         1.44   -6.7733681            0   -4.6134356   -5.0197073 
-     100    0.7574531   -5.7585055            0   -4.6223613   0.20726105 
-Loop time of 2.26309 on 1 procs for 100 steps with 32000 atoms
-
-Performance: 19088.920 tau/day, 44.187 timesteps/s
-99.9% CPU use with 1 MPI tasks x no OpenMP threads
-
-MPI task timing breakdown:
-Section |  min time  |  avg time  |  max time  |%varavg| %total
----------------------------------------------------------------
-Pair    | 1.9341     | 1.9341     | 1.9341     |   0.0 | 85.46
-Neigh   | 0.2442     | 0.2442     | 0.2442     |   0.0 | 10.79
-Comm    | 0.024158   | 0.024158   | 0.024158   |   0.0 |  1.07
-Output  | 0.00011611 | 0.00011611 | 0.00011611 |   0.0 |  0.01
-Modify  | 0.053222   | 0.053222   | 0.053222   |   0.0 |  2.35
-Other   |            | 0.007258   |            |       |  0.32
-
-Nlocal:    32000 ave 32000 max 32000 min
-Histogram: 1 0 0 0 0 0 0 0 0 0
-Nghost:    19657 ave 19657 max 19657 min
-Histogram: 1 0 0 0 0 0 0 0 0 0
-Neighs:    1.20283e+06 ave 1.20283e+06 max 1.20283e+06 min
-Histogram: 1 0 0 0 0 0 0 0 0 0
-
-Total # of neighbors = 1202833
-Ave neighs/atom = 37.5885
-Neighbor list builds = 5
-Dangerous builds not checked
-Total wall time: 0:00:02

bench/log.15Feb16.lj.fixed.icc.4

@@ -1,79 +0,0 @@
-LAMMPS (15 Feb 2016)
-# 3d Lennard-Jones melt
-
-variable	x index 1
-variable	y index 1
-variable	z index 1
-
-variable	xx equal 20*$x
-variable	xx equal 20*1
-variable	yy equal 20*$y
-variable	yy equal 20*1
-variable	zz equal 20*$z
-variable	zz equal 20*1
-
-units		lj
-atom_style	atomic
-
-lattice		fcc 0.8442
-Lattice spacing in x,y,z = 1.6796 1.6796 1.6796
-region		box block 0 ${xx} 0 ${yy} 0 ${zz}
-region		box block 0 20 0 ${yy} 0 ${zz}
-region		box block 0 20 0 20 0 ${zz}
-region		box block 0 20 0 20 0 20
-create_box	1 box
-Created orthogonal box = (0 0 0) to (33.5919 33.5919 33.5919)
-  1 by 2 by 2 MPI processor grid
-create_atoms	1 box
-Created 32000 atoms
-mass		1 1.0
-
-velocity	all create 1.44 87287 loop geom
-
-pair_style	lj/cut 2.5
-pair_coeff	1 1 1.0 1.0 2.5
-
-neighbor	0.3 bin
-neigh_modify	delay 0 every 20 check no
-
-fix		1 all nve
-
-run		100
-Neighbor list info ...
-  1 neighbor list requests
-  update every 20 steps, delay 0 steps, check no
-  max neighbors/atom: 2000, page size: 100000
-  master list distance cutoff = 2.8
-  ghost atom cutoff = 2.8
-  binsize = 1.4 -> bins = 24 24 24
-Memory usage per processor = 4.09506 Mbytes
-Step Temp E_pair E_mol TotEng Press 
-       0         1.44   -6.7733681            0   -4.6134356   -5.0197073 
-     100    0.7574531   -5.7585055            0   -4.6223613   0.20726105 
-Loop time of 0.640733 on 4 procs for 100 steps with 32000 atoms
-
-Performance: 67422.779 tau/day, 156.071 timesteps/s
-99.7% CPU use with 4 MPI tasks x no OpenMP threads
-
-MPI task timing breakdown:
-Section |  min time  |  avg time  |  max time  |%varavg| %total
----------------------------------------------------------------
-Pair    | 0.49487    | 0.51733    | 0.5322     |   1.9 | 80.74
-Neigh   | 0.061131   | 0.063685   | 0.065433   |   0.6 |  9.94
-Comm    | 0.02457    | 0.042349   | 0.069598   |   8.1 |  6.61
-Output  | 5.9843e-05 | 6.3181e-05 | 6.6996e-05 |   0.0 |  0.01
-Modify  | 0.012961   | 0.013863   | 0.014491   |   0.5 |  2.16
-Other   |            | 0.003448   |            |       |  0.54
-
-Nlocal:    8000 ave 8037 max 7964 min
-Histogram: 2 0 0 0 0 0 0 0 1 1
-Nghost:    9007.5 ave 9050 max 8968 min
-Histogram: 1 1 0 0 0 0 0 1 0 1
-Neighs:    300708 ave 305113 max 297203 min
-Histogram: 1 0 0 1 1 0 0 0 0 1
-
-Total # of neighbors = 1202833
-Ave neighs/atom = 37.5885
-Neighbor list builds = 5
-Dangerous builds not checked
-Total wall time: 0:00:00

bench/log.15Feb16.lj.scaled.icc.4

@@ -1,79 +0,0 @@
-LAMMPS (15 Feb 2016)
-# 3d Lennard-Jones melt
-
-variable	x index 1
-variable	y index 1
-variable	z index 1
-
-variable	xx equal 20*$x
-variable	xx equal 20*2
-variable	yy equal 20*$y
-variable	yy equal 20*2
-variable	zz equal 20*$z
-variable	zz equal 20*1
-
-units		lj
-atom_style	atomic
-
-lattice		fcc 0.8442
-Lattice spacing in x,y,z = 1.6796 1.6796 1.6796
-region		box block 0 ${xx} 0 ${yy} 0 ${zz}
-region		box block 0 40 0 ${yy} 0 ${zz}
-region		box block 0 40 0 40 0 ${zz}
-region		box block 0 40 0 40 0 20
-create_box	1 box
-Created orthogonal box = (0 0 0) to (67.1838 67.1838 33.5919)
-  2 by 2 by 1 MPI processor grid
-create_atoms	1 box
-Created 128000 atoms
-mass		1 1.0
-
-velocity	all create 1.44 87287 loop geom
-
-pair_style	lj/cut 2.5
-pair_coeff	1 1 1.0 1.0 2.5
-
-neighbor	0.3 bin
-neigh_modify	delay 0 every 20 check no
-
-fix		1 all nve
-
-run		100
-Neighbor list info ...
-  1 neighbor list requests
-  update every 20 steps, delay 0 steps, check no
-  max neighbors/atom: 2000, page size: 100000
-  master list distance cutoff = 2.8
-  ghost atom cutoff = 2.8
-  binsize = 1.4 -> bins = 48 48 24
-Memory usage per processor = 8.13678 Mbytes
-Step Temp E_pair E_mol TotEng Press 
-       0         1.44   -6.7733681            0   -4.6133849   -5.0196788 
-     100   0.75841891    -5.759957            0   -4.6223375   0.20008866 
-Loop time of 2.57914 on 4 procs for 100 steps with 128000 atoms
-
-Performance: 16749.768 tau/day, 38.773 timesteps/s
-99.8% CPU use with 4 MPI tasks x no OpenMP threads
-
-MPI task timing breakdown:
-Section |  min time  |  avg time  |  max time  |%varavg| %total
----------------------------------------------------------------
-Pair    | 2.042      | 2.1092     | 2.1668     |   3.1 | 81.78
-Neigh   | 0.23982    | 0.24551    | 0.25233    |   1.0 |  9.52
-Comm    | 0.067088   | 0.13887    | 0.22681    |  15.7 |  5.38
-Output  | 0.00013185 | 0.00021666 | 0.00027108 |   0.4 |  0.01
-Modify  | 0.060348   | 0.071269   | 0.077063   |   2.5 |  2.76
-Other   |            | 0.01403    |            |       |  0.54
-
-Nlocal:    32000 ave 32060 max 31939 min
-Histogram: 1 0 1 0 0 0 0 1 0 1
-Nghost:    19630.8 ave 19681 max 19562 min
-Histogram: 1 0 0 0 1 0 0 0 1 1
-Neighs:    1.20195e+06 ave 1.20354e+06 max 1.19931e+06 min
-Histogram: 1 0 0 0 0 0 0 2 0 1
-
-Total # of neighbors = 4807797
-Ave neighs/atom = 37.5609
-Neighbor list builds = 5
-Dangerous builds not checked
-Total wall time: 0:00:02

bench/log.15Feb16.rhodo.fixed.icc.1

@@ -1,121 +0,0 @@
-LAMMPS (15 Feb 2016)
-# Rhodopsin model
-
-units           real
-neigh_modify    delay 5 every 1
-
-atom_style      full
-bond_style      harmonic
-angle_style     charmm
-dihedral_style  charmm
-improper_style  harmonic
-pair_style      lj/charmm/coul/long 8.0 10.0
-pair_modify     mix arithmetic
-kspace_style    pppm 1e-4
-
-read_data       data.rhodo
-  orthogonal box = (-27.5 -38.5 -36.3646) to (27.5 38.5 36.3615)
-  1 by 1 by 1 MPI processor grid
-  reading atoms ...
-  32000 atoms
-  reading velocities ...
-  32000 velocities
-  scanning bonds ...
-  4 = max bonds/atom
-  scanning angles ...
-  8 = max angles/atom
-  scanning dihedrals ...
-  18 = max dihedrals/atom
-  scanning impropers ...
-  2 = max impropers/atom
-  reading bonds ...
-  27723 bonds
-  reading angles ...
-  40467 angles
-  reading dihedrals ...
-  56829 dihedrals
-  reading impropers ...
-  1034 impropers
-  4 = max # of 1-2 neighbors
-  12 = max # of 1-3 neighbors
-  24 = max # of 1-4 neighbors
-  26 = max # of special neighbors
-
-fix             1 all shake 0.0001 5 0 m 1.0 a 232
-  1617 = # of size 2 clusters
-  3633 = # of size 3 clusters
-  747 = # of size 4 clusters
-  4233 = # of frozen angles
-fix             2 all npt temp 300.0 300.0 100.0 		z 0.0 0.0 1000.0 mtk no pchain 0 tchain 1
-
-special_bonds   charmm
-
-thermo          50
-thermo_style    multi
-timestep        2.0
-
-run		100
-PPPM initialization ...
-  G vector (1/distance) = 0.248835
-  grid = 25 32 32
-  stencil order = 5
-  estimated absolute RMS force accuracy = 0.0355478
-  estimated relative force accuracy = 0.000107051
-  using double precision FFTs
-  3d grid and FFT values/proc = 41070 25600
-Neighbor list info ...
-  1 neighbor list requests
-  update every 1 steps, delay 5 steps, check yes
-  max neighbors/atom: 2000, page size: 100000
-  master list distance cutoff = 12
-  ghost atom cutoff = 12
-  binsize = 6 -> bins = 10 13 13
-Memory usage per processor = 91.7487 Mbytes
----------------- Step        0 ----- CPU =      0.0000 (sec) ----------------
-TotEng   =    -25356.2064 KinEng   =     21444.8313 Temp     =       299.0397 
-PotEng   =    -46801.0377 E_bond   =      2537.9940 E_angle  =     10921.3742 
-E_dihed  =      5211.7865 E_impro  =       213.5116 E_vdwl   =     -2307.8634 
-E_coul   =    207025.8927 E_long   =   -270403.7333 Press    =      -142.6035 
-Volume   =    307995.0335 
----------------- Step       50 ----- CPU =     17.6362 (sec) ----------------
-TotEng   =    -25330.0828 KinEng   =     21501.0029 Temp     =       299.8230 
-PotEng   =    -46831.0857 E_bond   =      2471.7004 E_angle  =     10836.4975 
-E_dihed  =      5239.6299 E_impro  =       227.1218 E_vdwl   =     -1993.2754 
-E_coul   =    206797.6331 E_long   =   -270410.3930 Press    =       237.6701 
-Volume   =    308031.5639 
----------------- Step      100 ----- CPU =     35.9089 (sec) ----------------
-TotEng   =    -25290.7593 KinEng   =     21592.0117 Temp     =       301.0920 
-PotEng   =    -46882.7709 E_bond   =      2567.9807 E_angle  =     10781.9408 
-E_dihed  =      5198.7432 E_impro  =       216.7834 E_vdwl   =     -1902.4783 
-E_coul   =    206659.2326 E_long   =   -270404.9733 Press    =         6.9960 
-Volume   =    308133.9888 
-Loop time of 35.9089 on 1 procs for 100 steps with 32000 atoms
-
-Performance: 0.481 ns/day, 49.874 hours/ns, 2.785 timesteps/s
-99.9% CPU use with 1 MPI tasks x no OpenMP threads
-
-MPI task timing breakdown:
-Section |  min time  |  avg time  |  max time  |%varavg| %total
----------------------------------------------------------------
-Pair    | 25.731     | 25.731     | 25.731     |   0.0 | 71.66
-Bond    | 1.2771     | 1.2771     | 1.2771     |   0.0 |  3.56
-Kspace  | 3.2094     | 3.2094     | 3.2094     |   0.0 |  8.94
-Neigh   | 4.4538     | 4.4538     | 4.4538     |   0.0 | 12.40
-Comm    | 0.068507   | 0.068507   | 0.068507   |   0.0 |  0.19
-Output  | 0.00025916 | 0.00025916 | 0.00025916 |   0.0 |  0.00
-Modify  | 1.1417     | 1.1417     | 1.1417     |   0.0 |  3.18
-Other   |            | 0.027      |            |       |  0.08
-
-Nlocal:    32000 ave 32000 max 32000 min
-Histogram: 1 0 0 0 0 0 0 0 0 0
-Nghost:    47958 ave 47958 max 47958 min
-Histogram: 1 0 0 0 0 0 0 0 0 0
-Neighs:    1.20281e+07 ave 1.20281e+07 max 1.20281e+07 min
-Histogram: 1 0 0 0 0 0 0 0 0 0
-
-Total # of neighbors = 12028107
-Ave neighs/atom = 375.878
-Ave special neighs/atom = 7.43187
-Neighbor list builds = 11
-Dangerous builds = 0
-Total wall time: 0:00:37

bench/log.15Feb16.rhodo.fixed.icc.4

@@ -1,121 +0,0 @@
-LAMMPS (15 Feb 2016)
-# Rhodopsin model
-
-units           real
-neigh_modify    delay 5 every 1
-
-atom_style      full
-bond_style      harmonic
-angle_style     charmm
-dihedral_style  charmm
-improper_style  harmonic
-pair_style      lj/charmm/coul/long 8.0 10.0
-pair_modify     mix arithmetic
-kspace_style    pppm 1e-4
-
-read_data       data.rhodo
-  orthogonal box = (-27.5 -38.5 -36.3646) to (27.5 38.5 36.3615)
-  1 by 2 by 2 MPI processor grid
-  reading atoms ...
-  32000 atoms
-  reading velocities ...
-  32000 velocities
-  scanning bonds ...
-  4 = max bonds/atom
-  scanning angles ...
-  8 = max angles/atom
-  scanning dihedrals ...
-  18 = max dihedrals/atom
-  scanning impropers ...
-  2 = max impropers/atom
-  reading bonds ...
-  27723 bonds
-  reading angles ...
-  40467 angles
-  reading dihedrals ...
-  56829 dihedrals
-  reading impropers ...
-  1034 impropers
-  4 = max # of 1-2 neighbors
-  12 = max # of 1-3 neighbors
-  24 = max # of 1-4 neighbors
-  26 = max # of special neighbors
-
-fix             1 all shake 0.0001 5 0 m 1.0 a 232
-  1617 = # of size 2 clusters
-  3633 = # of size 3 clusters
-  747 = # of size 4 clusters
-  4233 = # of frozen angles
-fix             2 all npt temp 300.0 300.0 100.0 		z 0.0 0.0 1000.0 mtk no pchain 0 tchain 1
-
-special_bonds   charmm
-
-thermo          50
-thermo_style    multi
-timestep        2.0
-
-run		100
-PPPM initialization ...
-  G vector (1/distance) = 0.248835
-  grid = 25 32 32
-  stencil order = 5
-  estimated absolute RMS force accuracy = 0.0355478
-  estimated relative force accuracy = 0.000107051
-  using double precision FFTs
-  3d grid and FFT values/proc = 13230 6400
-Neighbor list info ...
-  1 neighbor list requests
-  update every 1 steps, delay 5 steps, check yes
-  max neighbors/atom: 2000, page size: 100000
-  master list distance cutoff = 12
-  ghost atom cutoff = 12
-  binsize = 6 -> bins = 10 13 13
-Memory usage per processor = 36.629 Mbytes
----------------- Step        0 ----- CPU =      0.0000 (sec) ----------------
-TotEng   =    -25356.2064 KinEng   =     21444.8313 Temp     =       299.0397 
-PotEng   =    -46801.0377 E_bond   =      2537.9940 E_angle  =     10921.3742 
-E_dihed  =      5211.7865 E_impro  =       213.5116 E_vdwl   =     -2307.8634 
-E_coul   =    207025.8927 E_long   =   -270403.7333 Press    =      -142.6035 
-Volume   =    307995.0335 
----------------- Step       50 ----- CPU =      4.7461 (sec) ----------------
-TotEng   =    -25330.0828 KinEng   =     21501.0029 Temp     =       299.8230 
-PotEng   =    -46831.0857 E_bond   =      2471.7004 E_angle  =     10836.4975 
-E_dihed  =      5239.6299 E_impro  =       227.1218 E_vdwl   =     -1993.2754 
-E_coul   =    206797.6331 E_long   =   -270410.3930 Press    =       237.6701 
-Volume   =    308031.5639 
----------------- Step      100 ----- CPU =      9.6332 (sec) ----------------
-TotEng   =    -25290.7591 KinEng   =     21592.0117 Temp     =       301.0920 
-PotEng   =    -46882.7708 E_bond   =      2567.9807 E_angle  =     10781.9408 
-E_dihed  =      5198.7432 E_impro  =       216.7834 E_vdwl   =     -1902.4783 
-E_coul   =    206659.2327 E_long   =   -270404.9733 Press    =         6.9960 
-Volume   =    308133.9888 
-Loop time of 9.63322 on 4 procs for 100 steps with 32000 atoms
-
-Performance: 1.794 ns/day, 13.379 hours/ns, 10.381 timesteps/s
-99.9% CPU use with 4 MPI tasks x no OpenMP threads
-
-MPI task timing breakdown:
-Section |  min time  |  avg time  |  max time  |%varavg| %total
----------------------------------------------------------------
-Pair    | 6.4364     | 6.5993     | 6.7208     |   4.7 | 68.51
-Bond    | 0.30755    | 0.32435    | 0.35704    |   3.4 |  3.37
-Kspace  | 0.92248    | 1.0782     | 1.2597     |  13.0 | 11.19
-Neigh   | 1.1669     | 1.1672     | 1.1675     |   0.0 | 12.12
-Comm    | 0.094674   | 0.098065   | 0.10543    |   1.4 |  1.02
-Output  | 0.00015521 | 0.00016224 | 0.00018215 |   0.1 |  0.00
-Modify  | 0.32982    | 0.34654    | 0.35365    |   1.6 |  3.60
-Other   |            | 0.01943    |            |       |  0.20
-
-Nlocal:    8000 ave 8143 max 7933 min
-Histogram: 1 2 0 0 0 0 0 0 0 1
-Nghost:    22733.5 ave 22769 max 22693 min
-Histogram: 1 0 0 0 0 2 0 0 0 1
-Neighs:    3.00703e+06 ave 3.0975e+06 max 2.96493e+06 min
-Histogram: 1 2 0 0 0 0 0 0 0 1
-
-Total # of neighbors = 12028107
-Ave neighs/atom = 375.878
-Ave special neighs/atom = 7.43187
-Neighbor list builds = 11
-Dangerous builds = 0
-Total wall time: 0:00:10

bench/log.15Feb16.rhodo.scaled.icc.4

@@ -1,142 +0,0 @@
-LAMMPS (15 Feb 2016)
-# Rhodopsin model
-
-variable	x index 1
-variable	y index 1
-variable	z index 1
-
-units           real
-neigh_modify    delay 5 every 1
-
-atom_style      full
-atom_modify	map hash
-bond_style      harmonic
-angle_style     charmm
-dihedral_style  charmm
-improper_style  harmonic
-pair_style      lj/charmm/coul/long 8.0 10.0
-pair_modify     mix arithmetic
-kspace_style    pppm 1e-4
-
-read_data       data.rhodo
-  orthogonal box = (-27.5 -38.5 -36.3646) to (27.5 38.5 36.3615)
-  1 by 2 by 2 MPI processor grid
-  reading atoms ...
-  32000 atoms
-  reading velocities ...
-  32000 velocities
-  scanning bonds ...
-  4 = max bonds/atom
-  scanning angles ...
-  8 = max angles/atom
-  scanning dihedrals ...
-  18 = max dihedrals/atom
-  scanning impropers ...
-  2 = max impropers/atom
-  reading bonds ...
-  27723 bonds
-  reading angles ...
-  40467 angles
-  reading dihedrals ...
-  56829 dihedrals
-  reading impropers ...
-  1034 impropers
-  4 = max # of 1-2 neighbors
-  12 = max # of 1-3 neighbors
-  24 = max # of 1-4 neighbors
-  26 = max # of special neighbors
-
-replicate	$x $y $z
-replicate	2 $y $z
-replicate	2 2 $z
-replicate	2 2 1
-  orthogonal box = (-27.5 -38.5 -36.3646) to (82.5 115.5 36.3615)
-  2 by 2 by 1 MPI processor grid
-  128000 atoms
-  110892 bonds
-  161868 angles
-  227316 dihedrals
-  4136 impropers
-  4 = max # of 1-2 neighbors
-  12 = max # of 1-3 neighbors
-  24 = max # of 1-4 neighbors
-  26 = max # of special neighbors
-
-fix             1 all shake 0.0001 5 0 m 1.0 a 232
-  6468 = # of size 2 clusters
-  14532 = # of size 3 clusters
-  2988 = # of size 4 clusters
-  16932 = # of frozen angles
-fix             2 all npt temp 300.0 300.0 100.0 		z 0.0 0.0 1000.0 mtk no pchain 0 tchain 1
-
-special_bonds   charmm
-
-thermo          50
-thermo_style    multi
-timestep        2.0
-
-run		100
-PPPM initialization ...
-  G vector (1/distance) = 0.248593
-  grid = 48 60 36
-  stencil order = 5
-  estimated absolute RMS force accuracy = 0.0359793
-  estimated relative force accuracy = 0.00010835
-  using double precision FFTs
-  3d grid and FFT values/proc = 41615 25920
-Neighbor list info ...
-  1 neighbor list requests
-  update every 1 steps, delay 5 steps, check yes
-  max neighbors/atom: 2000, page size: 100000
-  master list distance cutoff = 12
-  ghost atom cutoff = 12
-  binsize = 6 -> bins = 19 26 13
-Memory usage per processor = 95.5339 Mbytes
----------------- Step        0 ----- CPU =      0.0000 (sec) ----------------
-TotEng   =   -101425.4887 KinEng   =     85779.3251 Temp     =       299.0304 
-PotEng   =   -187204.8138 E_bond   =     10151.9760 E_angle  =     43685.4968 
-E_dihed  =     20847.1460 E_impro  =       854.0463 E_vdwl   =     -9231.4537 
-E_coul   =    827053.5824 E_long   =  -1080565.6077 Press    =      -142.3092 
-Volume   =   1231980.1340 
----------------- Step       50 ----- CPU =     18.7806 (sec) ----------------
-TotEng   =   -101320.2677 KinEng   =     86003.4837 Temp     =       299.8118 
-PotEng   =   -187323.7514 E_bond   =      9887.1072 E_angle  =     43346.7922 
-E_dihed  =     20958.7032 E_impro  =       908.4715 E_vdwl   =     -7973.4457 
-E_coul   =    826141.3831 E_long   =  -1080592.7629 Press    =       238.0161 
-Volume   =   1232126.1855 
----------------- Step      100 ----- CPU =     38.3684 (sec) ----------------
-TotEng   =   -101158.1849 KinEng   =     86355.6149 Temp     =       301.0393 
-PotEng   =   -187513.7998 E_bond   =     10272.0693 E_angle  =     43128.6454 
-E_dihed  =     20793.9759 E_impro  =       867.0826 E_vdwl   =     -7586.7186 
-E_coul   =    825583.7122 E_long   =  -1080572.5667 Press    =        15.2151 
-Volume   =   1232535.8423 
-Loop time of 38.3684 on 4 procs for 100 steps with 128000 atoms
-
-Performance: 0.450 ns/day, 53.289 hours/ns, 2.606 timesteps/s
-99.9% CPU use with 4 MPI tasks x no OpenMP threads
-
-MPI task timing breakdown:
-Section |  min time  |  avg time  |  max time  |%varavg| %total
----------------------------------------------------------------
-Pair    | 26.205     | 26.538     | 26.911     |   5.0 | 69.17
-Bond    | 1.298      | 1.3125     | 1.3277     |   1.0 |  3.42
-Kspace  | 3.7099     | 4.0992     | 4.4422     |  13.3 | 10.68
-Neigh   | 4.6137     | 4.6144     | 4.615      |   0.0 | 12.03
-Comm    | 0.21398    | 0.21992    | 0.22886    |   1.2 |  0.57
-Output  | 0.00030518 | 0.00031543 | 0.00033307 |   0.1 |  0.00
-Modify  | 1.5066     | 1.5232     | 1.5388     |   1.0 |  3.97
-Other   |            | 0.06051    |            |       |  0.16
-
-Nlocal:    32000 ave 32000 max 32000 min
-Histogram: 4 0 0 0 0 0 0 0 0 0
-Nghost:    47957 ave 47957 max 47957 min
-Histogram: 4 0 0 0 0 0 0 0 0 0
-Neighs:    1.20281e+07 ave 1.20572e+07 max 1.1999e+07 min
-Histogram: 2 0 0 0 0 0 0 0 0 2
-
-Total # of neighbors = 48112472
-Ave neighs/atom = 375.879
-Ave special neighs/atom = 7.43187
-Neighbor list builds = 11
-Dangerous builds = 0
-Total wall time: 0:00:39

bench/log.6Oct16.chain.fixed.icc.1

@@ -0,0 +1,78 @@
+LAMMPS (6 Oct 2016)
+# FENE beadspring benchmark
+
+units		lj
+atom_style	bond
+special_bonds   fene
+
+read_data	data.chain
+  orthogonal box = (-16.796 -16.796 -16.796) to (16.796 16.796 16.796)
+  1 by 1 by 1 MPI processor grid
+  reading atoms ...
+  32000 atoms
+  reading velocities ...
+  32000 velocities
+  scanning bonds ...
+  1 = max bonds/atom
+  reading bonds ...
+  31680 bonds
+  2 = max # of 1-2 neighbors
+  2 = max # of special neighbors
+
+neighbor	0.4 bin
+neigh_modify	every 1 delay 1
+
+bond_style      fene
+bond_coeff	1 30.0 1.5 1.0 1.0
+
+pair_style	lj/cut 1.12
+pair_modify	shift yes
+pair_coeff	1 1 1.0 1.0 1.12
+
+fix		1 all nve
+fix		2 all langevin 1.0 1.0 10.0 904297
+
+thermo          100
+timestep	0.012
+
+run		100
+Neighbor list info ...
+  1 neighbor list requests
+  update every 1 steps, delay 1 steps, check yes
+  max neighbors/atom: 2000, page size: 100000
+  master list distance cutoff = 1.52
+  ghost atom cutoff = 1.52
+  binsize = 0.76 -> bins = 45 45 45
+Memory usage per processor = 12.0423 Mbytes
+Step Temp E_pair E_mol TotEng Press 
+       0   0.97029772   0.44484087    20.494523    22.394765    4.6721833 
+     100    0.9729966    0.4361122    20.507698     22.40326    4.6548819 
+Loop time of 0.977647 on 1 procs for 100 steps with 32000 atoms
+
+Performance: 106050.541 tau/day, 102.286 timesteps/s
+99.9% CPU use with 1 MPI tasks x no OpenMP threads
+
+MPI task timing breakdown:
+Section |  min time  |  avg time  |  max time  |%varavg| %total
+---------------------------------------------------------------
+Pair    | 0.19421    | 0.19421    | 0.19421    |   0.0 | 19.86
+Bond    | 0.08741    | 0.08741    | 0.08741    |   0.0 |  8.94
+Neigh   | 0.45791    | 0.45791    | 0.45791    |   0.0 | 46.84
+Comm    | 0.032649   | 0.032649   | 0.032649   |   0.0 |  3.34
+Output  | 0.00012207 | 0.00012207 | 0.00012207 |   0.0 |  0.01
+Modify  | 0.18071    | 0.18071    | 0.18071    |   0.0 | 18.48
+Other   |            | 0.02464    |            |       |  2.52
+
+Nlocal:    32000 ave 32000 max 32000 min
+Histogram: 1 0 0 0 0 0 0 0 0 0
+Nghost:    9493 ave 9493 max 9493 min
+Histogram: 1 0 0 0 0 0 0 0 0 0
+Neighs:    155873 ave 155873 max 155873 min
+Histogram: 1 0 0 0 0 0 0 0 0 0
+
+Total # of neighbors = 155873
+Ave neighs/atom = 4.87103
+Ave special neighs/atom = 1.98
+Neighbor list builds = 25
+Dangerous builds = 0
+Total wall time: 0:00:01

bench/log.6Oct16.chain.fixed.icc.4

@@ -0,0 +1,78 @@
+LAMMPS (6 Oct 2016)
+# FENE beadspring benchmark
+
+units		lj
+atom_style	bond
+special_bonds   fene
+
+read_data	data.chain
+  orthogonal box = (-16.796 -16.796 -16.796) to (16.796 16.796 16.796)
+  1 by 2 by 2 MPI processor grid
+  reading atoms ...
+  32000 atoms
+  reading velocities ...
+  32000 velocities
+  scanning bonds ...
+  1 = max bonds/atom
+  reading bonds ...
+  31680 bonds
+  2 = max # of 1-2 neighbors
+  2 = max # of special neighbors
+
+neighbor	0.4 bin
+neigh_modify	every 1 delay 1
+
+bond_style      fene
+bond_coeff	1 30.0 1.5 1.0 1.0
+
+pair_style	lj/cut 1.12
+pair_modify	shift yes
+pair_coeff	1 1 1.0 1.0 1.12
+
+fix		1 all nve
+fix		2 all langevin 1.0 1.0 10.0 904297
+
+thermo          100
+timestep	0.012
+
+run		100
+Neighbor list info ...
+  1 neighbor list requests
+  update every 1 steps, delay 1 steps, check yes
+  max neighbors/atom: 2000, page size: 100000
+  master list distance cutoff = 1.52
+  ghost atom cutoff = 1.52
+  binsize = 0.76 -> bins = 45 45 45
+Memory usage per processor = 4.14663 Mbytes
+Step Temp E_pair E_mol TotEng Press 
+       0   0.97029772   0.44484087    20.494523    22.394765    4.6721833 
+     100   0.97145835   0.43803883    20.502691    22.397872     4.626988 
+Loop time of 0.269205 on 4 procs for 100 steps with 32000 atoms
+
+Performance: 385133.446 tau/day, 371.464 timesteps/s
+99.8% CPU use with 4 MPI tasks x no OpenMP threads
+
+MPI task timing breakdown:
+Section |  min time  |  avg time  |  max time  |%varavg| %total
+---------------------------------------------------------------
+Pair    | 0.049383   | 0.049756   | 0.049988   |   0.1 | 18.48
+Bond    | 0.022701   | 0.022813   | 0.022872   |   0.0 |  8.47
+Neigh   | 0.11982    | 0.12002    | 0.12018    |   0.0 | 44.58
+Comm    | 0.020274   | 0.021077   | 0.022348   |   0.5 |  7.83
+Output  | 5.3167e-05 | 5.6148e-05 | 6.3181e-05 |   0.1 |  0.02
+Modify  | 0.046276   | 0.046809   | 0.047016   |   0.1 | 17.39
+Other   |            | 0.008669   |            |       |  3.22
+
+Nlocal:    8000 ave 8030 max 7974 min
+Histogram: 1 0 0 1 0 1 0 0 0 1
+Nghost:    4177 ave 4191 max 4160 min
+Histogram: 1 0 0 0 1 0 0 1 0 1
+Neighs:    38995.8 ave 39169 max 38852 min
+Histogram: 1 0 0 1 1 0 0 0 0 1
+
+Total # of neighbors = 155983
+Ave neighs/atom = 4.87447
+Ave special neighs/atom = 1.98
+Neighbor list builds = 25
+Dangerous builds = 0
+Total wall time: 0:00:00

bench/log.6Oct16.chain.scaled.icc.4

@@ -0,0 +1,94 @@
+LAMMPS (6 Oct 2016)
+# FENE beadspring benchmark
+
+variable	x index 1
+variable	y index 1
+variable	z index 1
+
+units		lj
+atom_style	bond
+atom_modify	map hash
+special_bonds   fene
+
+read_data	data.chain
+  orthogonal box = (-16.796 -16.796 -16.796) to (16.796 16.796 16.796)
+  1 by 2 by 2 MPI processor grid
+  reading atoms ...
+  32000 atoms
+  reading velocities ...
+  32000 velocities
+  scanning bonds ...
+  1 = max bonds/atom
+  reading bonds ...
+  31680 bonds
+  2 = max # of 1-2 neighbors
+  2 = max # of special neighbors
+
+replicate	$x $y $z
+replicate	2 $y $z
+replicate	2 2 $z
+replicate	2 2 1
+  orthogonal box = (-16.796 -16.796 -16.796) to (50.388 50.388 16.796)
+  2 by 2 by 1 MPI processor grid
+  128000 atoms
+  126720 bonds
+  2 = max # of 1-2 neighbors
+  2 = max # of special neighbors
+
+neighbor	0.4 bin
+neigh_modify	every 1 delay 1
+
+bond_style      fene
+bond_coeff	1 30.0 1.5 1.0 1.0
+
+pair_style	lj/cut 1.12
+pair_modify	shift yes
+pair_coeff	1 1 1.0 1.0 1.12
+
+fix		1 all nve
+fix		2 all langevin 1.0 1.0 10.0 904297
+
+thermo          100
+timestep	0.012
+
+run		100
+Neighbor list info ...
+  1 neighbor list requests
+  update every 1 steps, delay 1 steps, check yes
+  max neighbors/atom: 2000, page size: 100000
+  master list distance cutoff = 1.52
+  ghost atom cutoff = 1.52
+  binsize = 0.76 -> bins = 89 89 45
+Memory usage per processor = 13.2993 Mbytes
+Step Temp E_pair E_mol TotEng Press 
+       0   0.97027498   0.44484087    20.494523    22.394765    4.6721833 
+     100   0.97682955   0.44239968    20.500229    22.407862    4.6527025 
+Loop time of 1.14845 on 4 procs for 100 steps with 128000 atoms
+
+Performance: 90277.919 tau/day, 87.074 timesteps/s
+99.9% CPU use with 4 MPI tasks x no OpenMP threads
+
+MPI task timing breakdown:
+Section |  min time  |  avg time  |  max time  |%varavg| %total
+---------------------------------------------------------------
+Pair    | 0.2203     | 0.22207    | 0.22386    |   0.3 | 19.34
+Bond    | 0.094861   | 0.095302   | 0.095988   |   0.1 |  8.30
+Neigh   | 0.52127    | 0.5216     | 0.52189    |   0.0 | 45.42
+Comm    | 0.079585   | 0.082159   | 0.084366   |   0.7 |  7.15
+Output  | 0.00013304 | 0.00015306 | 0.00018501 |   0.2 |  0.01
+Modify  | 0.18351    | 0.18419    | 0.1856     |   0.2 | 16.04
+Other   |            | 0.04298    |            |       |  3.74
+
+Nlocal:    32000 ave 32015 max 31983 min
+Histogram: 1 0 1 0 0 0 0 0 1 1
+Nghost:    9492 ave 9522 max 9432 min
+Histogram: 1 0 0 0 0 0 1 0 0 2
+Neighs:    155837 ave 156079 max 155506 min
+Histogram: 1 0 0 0 0 1 0 0 1 1
+
+Total # of neighbors = 623349
+Ave neighs/atom = 4.86991
+Ave special neighs/atom = 1.98
+Neighbor list builds = 25
+Dangerous builds = 0
+Total wall time: 0:00:01

bench/log.6Oct16.chute.fixed.icc.1

@@ -0,0 +1,80 @@
+LAMMPS (6 Oct 2016)
+# LAMMPS benchmark of granular flow
+# chute flow of 32000 atoms with frozen base at 26 degrees
+
+units		lj
+atom_style	sphere
+boundary	p p fs
+newton		off
+comm_modify	vel yes
+
+read_data	data.chute
+  orthogonal box = (0 0 0) to (40 20 37.2886)
+  1 by 1 by 1 MPI processor grid
+  reading atoms ...
+  32000 atoms
+  reading velocities ...
+  32000 velocities
+
+pair_style	gran/hooke/history 200000.0 NULL 50.0 NULL 0.5 0
+pair_coeff	* *
+
+neighbor	0.1 bin
+neigh_modify	every 1 delay 0
+
+timestep	0.0001
+
+group		bottom type 2
+912 atoms in group bottom
+group		active subtract all bottom
+31088 atoms in group active
+neigh_modify	exclude group bottom bottom
+
+fix		1 all gravity 1.0 chute 26.0
+fix		2 bottom freeze
+fix		3 active nve/sphere
+
+compute		1 all erotate/sphere
+thermo_style	custom step atoms ke c_1 vol
+thermo_modify	norm no
+thermo		100
+
+run		100
+Neighbor list info ...
+  2 neighbor list requests
+  update every 1 steps, delay 0 steps, check yes
+  max neighbors/atom: 2000, page size: 100000
+  master list distance cutoff = 1.1
+  ghost atom cutoff = 1.1
+  binsize = 0.55 -> bins = 73 37 68
+Memory usage per processor = 16.0904 Mbytes
+Step Atoms KinEng c_1 Volume 
+       0    32000    784139.13    1601.1263    29833.783 
+     100    32000    784292.08    1571.0968    29834.707 
+Loop time of 0.534174 on 1 procs for 100 steps with 32000 atoms
+
+Performance: 1617.451 tau/day, 187.205 timesteps/s
+99.8% CPU use with 1 MPI tasks x no OpenMP threads
+
+MPI task timing breakdown:
+Section |  min time  |  avg time  |  max time  |%varavg| %total
+---------------------------------------------------------------
+Pair    | 0.33346    | 0.33346    | 0.33346    |   0.0 | 62.43
+Neigh   | 0.043902   | 0.043902   | 0.043902   |   0.0 |  8.22
+Comm    | 0.018391   | 0.018391   | 0.018391   |   0.0 |  3.44
+Output  | 0.00022411 | 0.00022411 | 0.00022411 |   0.0 |  0.04
+Modify  | 0.11666    | 0.11666    | 0.11666    |   0.0 | 21.84
+Other   |            | 0.02153    |            |       |  4.03
+
+Nlocal:    32000 ave 32000 max 32000 min
+Histogram: 1 0 0 0 0 0 0 0 0 0
+Nghost:    5463 ave 5463 max 5463 min
+Histogram: 1 0 0 0 0 0 0 0 0 0
+Neighs:    115133 ave 115133 max 115133 min
+Histogram: 1 0 0 0 0 0 0 0 0 0
+
+Total # of neighbors = 115133
+Ave neighs/atom = 3.59791
+Neighbor list builds = 2
+Dangerous builds = 0
+Total wall time: 0:00:00

bench/log.6Oct16.chute.fixed.icc.4

@@ -0,0 +1,80 @@
+LAMMPS (6 Oct 2016)
+# LAMMPS benchmark of granular flow
+# chute flow of 32000 atoms with frozen base at 26 degrees
+
+units		lj
+atom_style	sphere
+boundary	p p fs
+newton		off
+comm_modify	vel yes
+
+read_data	data.chute
+  orthogonal box = (0 0 0) to (40 20 37.2886)
+  2 by 1 by 2 MPI processor grid
+  reading atoms ...
+  32000 atoms
+  reading velocities ...
+  32000 velocities
+
+pair_style	gran/hooke/history 200000.0 NULL 50.0 NULL 0.5 0
+pair_coeff	* *
+
+neighbor	0.1 bin
+neigh_modify	every 1 delay 0
+
+timestep	0.0001
+
+group		bottom type 2
+912 atoms in group bottom
+group		active subtract all bottom
+31088 atoms in group active
+neigh_modify	exclude group bottom bottom
+
+fix		1 all gravity 1.0 chute 26.0
+fix		2 bottom freeze
+fix		3 active nve/sphere
+
+compute		1 all erotate/sphere
+thermo_style	custom step atoms ke c_1 vol
+thermo_modify	norm no
+thermo		100
+
+run		100
+Neighbor list info ...
+  2 neighbor list requests
+  update every 1 steps, delay 0 steps, check yes
+  max neighbors/atom: 2000, page size: 100000
+  master list distance cutoff = 1.1
+  ghost atom cutoff = 1.1
+  binsize = 0.55 -> bins = 73 37 68
+Memory usage per processor = 7.04927 Mbytes
+Step Atoms KinEng c_1 Volume 
+       0    32000    784139.13    1601.1263    29833.783 
+     100    32000    784292.08    1571.0968    29834.707 
+Loop time of 0.171815 on 4 procs for 100 steps with 32000 atoms
+
+Performance: 5028.653 tau/day, 582.020 timesteps/s
+99.7% CPU use with 4 MPI tasks x no OpenMP threads
+
+MPI task timing breakdown:
+Section |  min time  |  avg time  |  max time  |%varavg| %total
+---------------------------------------------------------------
+Pair    | 0.093691   | 0.096898   | 0.10005    |   0.8 | 56.40
+Neigh   | 0.011976   | 0.012059   | 0.012146   |   0.1 |  7.02
+Comm    | 0.016384   | 0.017418   | 0.018465   |   0.8 | 10.14
+Output  | 7.7963e-05 | 0.00010747 | 0.00013304 |   0.2 |  0.06
+Modify  | 0.031744   | 0.031943   | 0.032167   |   0.1 | 18.59
+Other   |            | 0.01339    |            |       |  7.79
+
+Nlocal:    8000 ave 8008 max 7992 min
+Histogram: 2 0 0 0 0 0 0 0 0 2
+Nghost:    2439 ave 2450 max 2428 min
+Histogram: 2 0 0 0 0 0 0 0 0 2
+Neighs:    29500.5 ave 30488 max 28513 min
+Histogram: 2 0 0 0 0 0 0 0 0 2
+
+Total # of neighbors = 118002
+Ave neighs/atom = 3.68756
+Neighbor list builds = 2
+Dangerous builds = 0
+Total wall time: 0:00:00

bench/log.6Oct16.chute.scaled.icc.4

@@ -0,0 +1,90 @@
+LAMMPS (6 Oct 2016)
+# LAMMPS benchmark of granular flow
+# chute flow of 32000 atoms with frozen base at 26 degrees
+
+variable	x index 1
+variable	y index 1
+
+units		lj
+atom_style	sphere
+boundary	p p fs
+newton		off
+comm_modify	vel yes
+
+read_data	data.chute
+  orthogonal box = (0 0 0) to (40 20 37.2886)
+  2 by 1 by 2 MPI processor grid
+  reading atoms ...
+  32000 atoms
+  reading velocities ...
+  32000 velocities
+
+replicate	$x $y 1
+replicate	2 $y 1
+replicate	2 2 1
+  orthogonal box = (0 0 0) to (80 40 37.2922)
+  2 by 2 by 1 MPI processor grid
+  128000 atoms
+
+pair_style	gran/hooke/history 200000.0 NULL 50.0 NULL 0.5 0
+pair_coeff	* *
+
+neighbor	0.1 bin
+neigh_modify	every 1 delay 0
+
+timestep	0.0001
+
+group		bottom type 2
+3648 atoms in group bottom
+group		active subtract all bottom
+124352 atoms in group active
+neigh_modify	exclude group bottom bottom
+
+fix		1 all gravity 1.0 chute 26.0
+fix		2 bottom freeze
+fix		3 active nve/sphere
+
+compute		1 all erotate/sphere
+thermo_style	custom step atoms ke c_1 vol
+thermo_modify	norm no
+thermo		100
+
+run		100
+Neighbor list info ...
+  2 neighbor list requests
+  update every 1 steps, delay 0 steps, check yes
+  max neighbors/atom: 2000, page size: 100000
+  master list distance cutoff = 1.1
+  ghost atom cutoff = 1.1
+  binsize = 0.55 -> bins = 146 73 68
+Memory usage per processor = 16.1265 Mbytes
+Step Atoms KinEng c_1 Volume 
+       0   128000    3136556.5    6404.5051    119335.13 
+     100   128000    3137168.3    6284.3873    119338.83 
+Loop time of 0.832365 on 4 procs for 100 steps with 128000 atoms
+
+Performance: 1038.006 tau/day, 120.140 timesteps/s
+99.8% CPU use with 4 MPI tasks x no OpenMP threads
+
+MPI task timing breakdown:
+Section |  min time  |  avg time  |  max time  |%varavg| %total
+---------------------------------------------------------------
+Pair    | 0.5178     | 0.52208    | 0.52793    |   0.5 | 62.72
+Neigh   | 0.047003   | 0.047113   | 0.047224   |   0.0 |  5.66
+Comm    | 0.05233    | 0.052988   | 0.053722   |   0.2 |  6.37
+Output  | 0.00024986 | 0.00032717 | 0.00036693 |   0.3 |  0.04
+Modify  | 0.15517    | 0.15627    | 0.15808    |   0.3 | 18.77
+Other   |            | 0.0536     |            |       |  6.44
+
+Nlocal:    32000 ave 32000 max 32000 min
+Histogram: 4 0 0 0 0 0 0 0 0 0
+Nghost:    5463 ave 5463 max 5463 min
+Histogram: 4 0 0 0 0 0 0 0 0 0
+Neighs:    115133 ave 115133 max 115133 min
+Histogram: 4 0 0 0 0 0 0 0 0 0
+
+Total # of neighbors = 460532
+Ave neighs/atom = 3.59791
+Neighbor list builds = 2
+Dangerous builds = 0
+Total wall time: 0:00:00

bench/log.6Oct16.eam.fixed.icc.1

@@ -0,0 +1,83 @@
+LAMMPS (6 Oct 2016)
+# bulk Cu lattice
+
+variable	x index 1
+variable	y index 1
+variable	z index 1
+
+variable	xx equal 20*$x
+variable	xx equal 20*1
+variable	yy equal 20*$y
+variable	yy equal 20*1
+variable	zz equal 20*$z
+variable	zz equal 20*1
+
+units		metal
+atom_style	atomic
+
+lattice		fcc 3.615
+Lattice spacing in x,y,z = 3.615 3.615 3.615
+region		box block 0 ${xx} 0 ${yy} 0 ${zz}
+region		box block 0 20 0 ${yy} 0 ${zz}
+region		box block 0 20 0 20 0 ${zz}
+region		box block 0 20 0 20 0 20
+create_box	1 box
+Created orthogonal box = (0 0 0) to (72.3 72.3 72.3)
+  1 by 1 by 1 MPI processor grid
+create_atoms	1 box
+Created 32000 atoms
+
+pair_style	eam
+pair_coeff	1 1 Cu_u3.eam
+Reading potential file Cu_u3.eam with DATE: 2007-06-11
+
+velocity	all create 1600.0 376847 loop geom
+
+neighbor	1.0 bin
+neigh_modify    every 1 delay 5 check yes
+
+fix		1 all nve
+
+timestep	0.005
+thermo		50
+
+run		100
+Neighbor list info ...
+  1 neighbor list requests
+  update every 1 steps, delay 5 steps, check yes
+  max neighbors/atom: 2000, page size: 100000
+  master list distance cutoff = 5.95
+  ghost atom cutoff = 5.95
+  binsize = 2.975 -> bins = 25 25 25
+Memory usage per processor = 11.2238 Mbytes
+Step Temp E_pair E_mol TotEng Press 
+       0         1600      -113280            0   -106662.09    18703.573 
+      50    781.69049   -109873.35            0   -106640.13    52273.088 
+     100      801.832    -109957.3            0   -106640.77    51322.821 
+Loop time of 5.96529 on 1 procs for 100 steps with 32000 atoms
+
+Performance: 7.242 ns/day, 3.314 hours/ns, 16.764 timesteps/s
+99.9% CPU use with 1 MPI tasks x no OpenMP threads
+
+MPI task timing breakdown:
+Section |  min time  |  avg time  |  max time  |%varavg| %total
+---------------------------------------------------------------
+Pair    | 5.2743     | 5.2743     | 5.2743     |   0.0 | 88.42
+Neigh   | 0.59212    | 0.59212    | 0.59212    |   0.0 |  9.93
+Comm    | 0.030399   | 0.030399   | 0.030399   |   0.0 |  0.51
+Output  | 0.00026202 | 0.00026202 | 0.00026202 |   0.0 |  0.00
+Modify  | 0.050487   | 0.050487   | 0.050487   |   0.0 |  0.85
+Other   |            | 0.01776    |            |       |  0.30
+
+Nlocal:    32000 ave 32000 max 32000 min
+Histogram: 1 0 0 0 0 0 0 0 0 0
+Nghost:    19909 ave 19909 max 19909 min
+Histogram: 1 0 0 0 0 0 0 0 0 0
+Neighs:    1.20778e+06 ave 1.20778e+06 max 1.20778e+06 min
+Histogram: 1 0 0 0 0 0 0 0 0 0
+
+Total # of neighbors = 1207784
+Ave neighs/atom = 37.7433
+Neighbor list builds = 13
+Dangerous builds = 0
+Total wall time: 0:00:06

bench/log.6Oct16.eam.fixed.icc.4

@@ -0,0 +1,83 @@
+LAMMPS (6 Oct 2016)
+# bulk Cu lattice
+
+variable	x index 1
+variable	y index 1
+variable	z index 1
+
+variable	xx equal 20*$x
+variable	xx equal 20*1
+variable	yy equal 20*$y
+variable	yy equal 20*1
+variable	zz equal 20*$z
+variable	zz equal 20*1
+
+units		metal
+atom_style	atomic
+
+lattice		fcc 3.615
+Lattice spacing in x,y,z = 3.615 3.615 3.615
+region		box block 0 ${xx} 0 ${yy} 0 ${zz}
+region		box block 0 20 0 ${yy} 0 ${zz}
+region		box block 0 20 0 20 0 ${zz}
+region		box block 0 20 0 20 0 20
+create_box	1 box
+Created orthogonal box = (0 0 0) to (72.3 72.3 72.3)
+  1 by 2 by 2 MPI processor grid
+create_atoms	1 box
+Created 32000 atoms
+
+pair_style	eam
+pair_coeff	1 1 Cu_u3.eam
+Reading potential file Cu_u3.eam with DATE: 2007-06-11
+
+velocity	all create 1600.0 376847 loop geom
+
+neighbor	1.0 bin
+neigh_modify    every 1 delay 5 check yes
+
+fix		1 all nve
+
+timestep	0.005
+thermo		50
+
+run		100
+Neighbor list info ...
+  1 neighbor list requests
+  update every 1 steps, delay 5 steps, check yes
+  max neighbors/atom: 2000, page size: 100000
+  master list distance cutoff = 5.95
+  ghost atom cutoff = 5.95
+  binsize = 2.975 -> bins = 25 25 25
+Memory usage per processor = 5.59629 Mbytes
+Step Temp E_pair E_mol TotEng Press 
+       0         1600      -113280            0   -106662.09    18703.573 
+      50    781.69049   -109873.35            0   -106640.13    52273.088 
+     100      801.832    -109957.3            0   -106640.77    51322.821 
+Loop time of 1.64562 on 4 procs for 100 steps with 32000 atoms
+
+Performance: 26.252 ns/day, 0.914 hours/ns, 60.767 timesteps/s
+99.8% CPU use with 4 MPI tasks x no OpenMP threads
+
+MPI task timing breakdown:
+Section |  min time  |  avg time  |  max time  |%varavg| %total
+---------------------------------------------------------------
+Pair    | 1.408      | 1.4175     | 1.4341     |   0.9 | 86.14
+Neigh   | 0.15512    | 0.15722    | 0.16112    |   0.6 |  9.55
+Comm    | 0.029105   | 0.049986   | 0.061822   |   5.8 |  3.04
+Output  | 0.00010991 | 0.00011539 | 0.00012302 |   0.0 |  0.01
+Modify  | 0.013383   | 0.013573   | 0.013883   |   0.2 |  0.82
+Other   |            | 0.007264   |            |       |  0.44
+
+Nlocal:    8000 ave 8008 max 7993 min
+Histogram: 2 0 0 0 0 0 0 0 1 1
+Nghost:    9130.25 ave 9138 max 9122 min
+Histogram: 2 0 0 0 0 0 0 0 0 2
+Neighs:    301946 ave 302392 max 301360 min
+Histogram: 1 0 0 0 1 0 0 0 1 1
+
+Total # of neighbors = 1207784
+Ave neighs/atom = 37.7433
+Neighbor list builds = 13
+Dangerous builds = 0
+Total wall time: 0:00:01

bench/log.6Oct16.eam.scaled.icc.4

@@ -0,0 +1,83 @@
+LAMMPS (6 Oct 2016)
+# bulk Cu lattice
+
+variable	x index 1
+variable	y index 1
+variable	z index 1
+
+variable	xx equal 20*$x
+variable	xx equal 20*2
+variable	yy equal 20*$y
+variable	yy equal 20*2
+variable	zz equal 20*$z
+variable	zz equal 20*1
+
+units		metal
+atom_style	atomic
+
+lattice		fcc 3.615
+Lattice spacing in x,y,z = 3.615 3.615 3.615
+region		box block 0 ${xx} 0 ${yy} 0 ${zz}
+region		box block 0 40 0 ${yy} 0 ${zz}
+region		box block 0 40 0 40 0 ${zz}
+region		box block 0 40 0 40 0 20
+create_box	1 box
+Created orthogonal box = (0 0 0) to (144.6 144.6 72.3)
+  2 by 2 by 1 MPI processor grid
+create_atoms	1 box
+Created 128000 atoms
+
+pair_style	eam
+pair_coeff	1 1 Cu_u3.eam
+Reading potential file Cu_u3.eam with DATE: 2007-06-11
+
+velocity	all create 1600.0 376847 loop geom
+
+neighbor	1.0 bin
+neigh_modify    every 1 delay 5 check yes
+
+fix		1 all nve
+
+timestep	0.005
+thermo		50
+
+run		100
+Neighbor list info ...
+  1 neighbor list requests
+  update every 1 steps, delay 5 steps, check yes
+  max neighbors/atom: 2000, page size: 100000
+  master list distance cutoff = 5.95
+  ghost atom cutoff = 5.95
+  binsize = 2.975 -> bins = 49 49 25
+Memory usage per processor = 11.1402 Mbytes
+Step Temp E_pair E_mol TotEng Press 
+       0         1600      -453120            0   -426647.73    18704.012 
+      50    779.50001   -439457.02            0   -426560.06    52355.276 
+     100    797.97828   -439764.76            0   -426562.07     51474.74 
+Loop time of 6.60121 on 4 procs for 100 steps with 128000 atoms
+
+Performance: 6.544 ns/day, 3.667 hours/ns, 15.149 timesteps/s
+99.9% CPU use with 4 MPI tasks x no OpenMP threads
+
+MPI task timing breakdown:
+Section |  min time  |  avg time  |  max time  |%varavg| %total
+---------------------------------------------------------------
+Pair    | 5.6676     | 5.7011     | 5.7469     |   1.3 | 86.36
+Neigh   | 0.66423    | 0.67119    | 0.68082    |   0.7 | 10.17
+Comm    | 0.079367   | 0.13668    | 0.1791     |  10.5 |  2.07
+Output  | 0.00026989 | 0.00028622 | 0.00031209 |   0.1 |  0.00
+Modify  | 0.060046   | 0.062203   | 0.065009   |   0.9 |  0.94
+Other   |            | 0.02974    |            |       |  0.45
+
+Nlocal:    32000 ave 32092 max 31914 min
+Histogram: 1 0 0 1 0 1 0 0 0 1
+Nghost:    19910 ave 19997 max 19818 min
+Histogram: 1 0 0 0 1 0 1 0 0 1
+Neighs:    1.20728e+06 ave 1.21142e+06 max 1.2036e+06 min
+Histogram: 1 0 0 1 1 0 0 0 0 1
+
+Total # of neighbors = 4829126
+Ave neighs/atom = 37.7275
+Neighbor list builds = 14
+Dangerous builds = 0
+Total wall time: 0:00:06

bench/log.6Oct16.lj.fixed.icc.1

@@ -0,0 +1,79 @@
+LAMMPS (6 Oct 2016)
+# 3d Lennard-Jones melt
+
+variable	x index 1
+variable	y index 1
+variable	z index 1
+
+variable	xx equal 20*$x
+variable	xx equal 20*1
+variable	yy equal 20*$y
+variable	yy equal 20*1
+variable	zz equal 20*$z
+variable	zz equal 20*1
+
+units		lj
+atom_style	atomic
+
+lattice		fcc 0.8442
+Lattice spacing in x,y,z = 1.6796 1.6796 1.6796
+region		box block 0 ${xx} 0 ${yy} 0 ${zz}
+region		box block 0 20 0 ${yy} 0 ${zz}
+region		box block 0 20 0 20 0 ${zz}
+region		box block 0 20 0 20 0 20
+create_box	1 box
+Created orthogonal box = (0 0 0) to (33.5919 33.5919 33.5919)
+  1 by 1 by 1 MPI processor grid
+create_atoms	1 box
+Created 32000 atoms
+mass		1 1.0
+
+velocity	all create 1.44 87287 loop geom
+
+pair_style	lj/cut 2.5
+pair_coeff	1 1 1.0 1.0 2.5
+
+neighbor	0.3 bin
+neigh_modify	delay 0 every 20 check no
+
+fix		1 all nve
+
+run		100
+Neighbor list info ...
+  1 neighbor list requests
+  update every 20 steps, delay 0 steps, check no
+  max neighbors/atom: 2000, page size: 100000
+  master list distance cutoff = 2.8
+  ghost atom cutoff = 2.8
+  binsize = 1.4 -> bins = 24 24 24
+Memory usage per processor = 8.21387 Mbytes
+Step Temp E_pair E_mol TotEng Press 
+       0         1.44   -6.7733681            0   -4.6134356   -5.0197073 
+     100    0.7574531   -5.7585055            0   -4.6223613   0.20726105 
+Loop time of 2.26185 on 1 procs for 100 steps with 32000 atoms
+
+Performance: 19099.377 tau/day, 44.212 timesteps/s
+99.9% CPU use with 1 MPI tasks x no OpenMP threads
+
+MPI task timing breakdown:
+Section |  min time  |  avg time  |  max time  |%varavg| %total
+---------------------------------------------------------------
+Pair    | 1.9328     | 1.9328     | 1.9328     |   0.0 | 85.45
+Neigh   | 0.2558     | 0.2558     | 0.2558     |   0.0 | 11.31
+Comm    | 0.024061   | 0.024061   | 0.024061   |   0.0 |  1.06
+Output  | 0.00012612 | 0.00012612 | 0.00012612 |   0.0 |  0.01
+Modify  | 0.040887   | 0.040887   | 0.040887   |   0.0 |  1.81
+Other   |            | 0.008214   |            |       |  0.36
+
+Nlocal:    32000 ave 32000 max 32000 min
+Histogram: 1 0 0 0 0 0 0 0 0 0
+Nghost:    19657 ave 19657 max 19657 min
+Histogram: 1 0 0 0 0 0 0 0 0 0
+Neighs:    1.20283e+06 ave 1.20283e+06 max 1.20283e+06 min
+Histogram: 1 0 0 0 0 0 0 0 0 0
+
+Total # of neighbors = 1202833
+Ave neighs/atom = 37.5885
+Neighbor list builds = 5
+Dangerous builds not checked
+Total wall time: 0:00:02

bench/log.6Oct16.lj.fixed.icc.4

@@ -0,0 +1,79 @@
+LAMMPS (6 Oct 2016)
+# 3d Lennard-Jones melt
+
+variable	x index 1
+variable	y index 1
+variable	z index 1
+
+variable	xx equal 20*$x
+variable	xx equal 20*1
+variable	yy equal 20*$y
+variable	yy equal 20*1
+variable	zz equal 20*$z
+variable	zz equal 20*1
+
+units		lj
+atom_style	atomic
+
+lattice		fcc 0.8442
+Lattice spacing in x,y,z = 1.6796 1.6796 1.6796
+region		box block 0 ${xx} 0 ${yy} 0 ${zz}
+region		box block 0 20 0 ${yy} 0 ${zz}
+region		box block 0 20 0 20 0 ${zz}
+region		box block 0 20 0 20 0 20
+create_box	1 box
+Created orthogonal box = (0 0 0) to (33.5919 33.5919 33.5919)
+  1 by 2 by 2 MPI processor grid
+create_atoms	1 box
+Created 32000 atoms
+mass		1 1.0
+
+velocity	all create 1.44 87287 loop geom
+
+pair_style	lj/cut 2.5
+pair_coeff	1 1 1.0 1.0 2.5
+
+neighbor	0.3 bin
+neigh_modify	delay 0 every 20 check no
+
+fix		1 all nve
+
+run		100
+Neighbor list info ...
+  1 neighbor list requests
+  update every 20 steps, delay 0 steps, check no
+  max neighbors/atom: 2000, page size: 100000
+  master list distance cutoff = 2.8
+  ghost atom cutoff = 2.8
+  binsize = 1.4 -> bins = 24 24 24
+Memory usage per processor = 4.09506 Mbytes
+Step Temp E_pair E_mol TotEng Press 
+       0         1.44   -6.7733681            0   -4.6134356   -5.0197073 
+     100    0.7574531   -5.7585055            0   -4.6223613   0.20726105 
+Loop time of 0.635957 on 4 procs for 100 steps with 32000 atoms
+
+Performance: 67929.172 tau/day, 157.243 timesteps/s
+99.9% CPU use with 4 MPI tasks x no OpenMP threads
+
+MPI task timing breakdown:
+Section |  min time  |  avg time  |  max time  |%varavg| %total
+---------------------------------------------------------------
+Pair    | 0.51335    | 0.51822    | 0.52569    |   0.7 | 81.49
+Neigh   | 0.063695   | 0.064309   | 0.065397   |   0.3 | 10.11
+Comm    | 0.027525   | 0.03629    | 0.041959   |   3.1 |  5.71
+Output  | 6.3896e-05 | 6.6698e-05 | 7.081e-05  |   0.0 |  0.01
+Modify  | 0.012472   | 0.01254    | 0.012618   |   0.1 |  1.97
+Other   |            | 0.004529   |            |       |  0.71
+
+Nlocal:    8000 ave 8037 max 7964 min
+Histogram: 2 0 0 0 0 0 0 0 1 1
+Nghost:    9007.5 ave 9050 max 8968 min
+Histogram: 1 1 0 0 0 0 0 1 0 1
+Neighs:    300708 ave 305113 max 297203 min
+Histogram: 1 0 0 1 1 0 0 0 0 1
+
+Total # of neighbors = 1202833
+Ave neighs/atom = 37.5885
+Neighbor list builds = 5
+Dangerous builds not checked
+Total wall time: 0:00:00

bench/log.6Oct16.lj.scaled.icc.4

@@ -0,0 +1,79 @@
+LAMMPS (6 Oct 2016)
+# 3d Lennard-Jones melt
+
+variable	x index 1
+variable	y index 1
+variable	z index 1
+
+variable	xx equal 20*$x
+variable	xx equal 20*2
+variable	yy equal 20*$y
+variable	yy equal 20*2
+variable	zz equal 20*$z
+variable	zz equal 20*1
+
+units		lj
+atom_style	atomic
+
+lattice		fcc 0.8442
+Lattice spacing in x,y,z = 1.6796 1.6796 1.6796
+region		box block 0 ${xx} 0 ${yy} 0 ${zz}
+region		box block 0 40 0 ${yy} 0 ${zz}
+region		box block 0 40 0 40 0 ${zz}
+region		box block 0 40 0 40 0 20
+create_box	1 box
+Created orthogonal box = (0 0 0) to (67.1838 67.1838 33.5919)
+  2 by 2 by 1 MPI processor grid
+create_atoms	1 box
+Created 128000 atoms
+mass		1 1.0
+
+velocity	all create 1.44 87287 loop geom
+
+pair_style	lj/cut 2.5
+pair_coeff	1 1 1.0 1.0 2.5
+
+neighbor	0.3 bin
+neigh_modify	delay 0 every 20 check no
+
+fix		1 all nve
+
+run		100
+Neighbor list info ...
+  1 neighbor list requests
+  update every 20 steps, delay 0 steps, check no
+  max neighbors/atom: 2000, page size: 100000
+  master list distance cutoff = 2.8
+  ghost atom cutoff = 2.8
+  binsize = 1.4 -> bins = 48 48 24
+Memory usage per processor = 8.13678 Mbytes
+Step Temp E_pair E_mol TotEng Press 
+       0         1.44   -6.7733681            0   -4.6133849   -5.0196788 
+     100   0.75841891    -5.759957            0   -4.6223375   0.20008866 
+Loop time of 2.55762 on 4 procs for 100 steps with 128000 atoms
+
+Performance: 16890.677 tau/day, 39.099 timesteps/s
+99.8% CPU use with 4 MPI tasks x no OpenMP threads
+
+MPI task timing breakdown:
+Section |  min time  |  avg time  |  max time  |%varavg| %total
+---------------------------------------------------------------
+Pair    | 2.0583     | 2.0988     | 2.1594     |   2.6 | 82.06
+Neigh   | 0.24411    | 0.24838    | 0.25585    |   0.9 |  9.71
+Comm    | 0.066397   | 0.13872    | 0.1863     |  11.9 |  5.42
+Output  | 0.00012994 | 0.00021023 | 0.00025702 |   0.3 |  0.01
+Modify  | 0.055533   | 0.058343   | 0.061791   |   1.2 |  2.28
+Other   |            | 0.0132     |            |       |  0.52
+
+Nlocal:    32000 ave 32060 max 31939 min
+Histogram: 1 0 1 0 0 0 0 1 0 1
+Nghost:    19630.8 ave 19681 max 19562 min
+Histogram: 1 0 0 0 1 0 0 0 1 1
+Neighs:    1.20195e+06 ave 1.20354e+06 max 1.19931e+06 min
+Histogram: 1 0 0 0 0 0 0 2 0 1
+
+Total # of neighbors = 4807797
+Ave neighs/atom = 37.5609
+Neighbor list builds = 5
+Dangerous builds not checked
+Total wall time: 0:00:02

bench/log.6Oct16.rhodo.fixed.icc.1

@@ -0,0 +1,122 @@
+LAMMPS (6 Oct 2016)
+# Rhodopsin model
+
+units           real
+neigh_modify    delay 5 every 1
+
+atom_style      full
+bond_style      harmonic
+angle_style     charmm
+dihedral_style  charmm
+improper_style  harmonic
+pair_style      lj/charmm/coul/long 8.0 10.0
+pair_modify     mix arithmetic
+kspace_style    pppm 1e-4
+
+read_data       data.rhodo
+  orthogonal box = (-27.5 -38.5 -36.3646) to (27.5 38.5 36.3615)
+  1 by 1 by 1 MPI processor grid
+  reading atoms ...
+  32000 atoms
+  reading velocities ...
+  32000 velocities
+  scanning bonds ...
+  4 = max bonds/atom
+  scanning angles ...
+  8 = max angles/atom
+  scanning dihedrals ...
+  18 = max dihedrals/atom
+  scanning impropers ...
+  2 = max impropers/atom
+  reading bonds ...
+  27723 bonds
+  reading angles ...
+  40467 angles
+  reading dihedrals ...
+  56829 dihedrals
+  reading impropers ...
+  1034 impropers
+  4 = max # of 1-2 neighbors
+  12 = max # of 1-3 neighbors
+  24 = max # of 1-4 neighbors
+  26 = max # of special neighbors
+
+fix             1 all shake 0.0001 5 0 m 1.0 a 232
+  1617 = # of size 2 clusters
+  3633 = # of size 3 clusters
+  747 = # of size 4 clusters
+  4233 = # of frozen angles
+fix             2 all npt temp 300.0 300.0 100.0 		z 0.0 0.0 1000.0 mtk no pchain 0 tchain 1
+
+special_bonds   charmm
+
+thermo          50
+thermo_style    multi
+timestep        2.0
+
+run		100
+PPPM initialization ...
+WARNING: Using 12-bit tables for long-range coulomb (../kspace.cpp:316)
+  G vector (1/distance) = 0.248835
+  grid = 25 32 32
+  stencil order = 5
+  estimated absolute RMS force accuracy = 0.0355478
+  estimated relative force accuracy = 0.000107051
+  using double precision FFTs
+  3d grid and FFT values/proc = 41070 25600
+Neighbor list info ...
+  1 neighbor list requests
+  update every 1 steps, delay 5 steps, check yes
+  max neighbors/atom: 2000, page size: 100000
+  master list distance cutoff = 12
+  ghost atom cutoff = 12
+  binsize = 6 -> bins = 10 13 13
+Memory usage per processor = 93.2721 Mbytes
+---------------- Step        0 ----- CPU =      0.0000 (sec) ----------------
+TotEng   =    -25356.2064 KinEng   =     21444.8313 Temp     =       299.0397 
+PotEng   =    -46801.0377 E_bond   =      2537.9940 E_angle  =     10921.3742 
+E_dihed  =      5211.7865 E_impro  =       213.5116 E_vdwl   =     -2307.8634 
+E_coul   =    207025.8927 E_long   =   -270403.7333 Press    =      -149.3301 
+Volume   =    307995.0335 
+---------------- Step       50 ----- CPU =     17.2007 (sec) ----------------
+TotEng   =    -25330.0321 KinEng   =     21501.0036 Temp     =       299.8230 
+PotEng   =    -46831.0357 E_bond   =      2471.7033 E_angle  =     10836.5108 
+E_dihed  =      5239.6316 E_impro  =       227.1219 E_vdwl   =     -1993.2763 
+E_coul   =    206797.6655 E_long   =   -270410.3927 Press    =       237.6866 
+Volume   =    308031.5640 
+---------------- Step      100 ----- CPU =     35.0315 (sec) ----------------
+TotEng   =    -25290.7387 KinEng   =     21591.9096 Temp     =       301.0906 
+PotEng   =    -46882.6484 E_bond   =      2567.9789 E_angle  =     10781.9556 
+E_dihed  =      5198.7493 E_impro  =       216.7863 E_vdwl   =     -1902.6458 
+E_coul   =    206659.5006 E_long   =   -270404.9733 Press    =         6.7898 
+Volume   =    308133.9933 
+Loop time of 35.0316 on 1 procs for 100 steps with 32000 atoms
+
+Performance: 0.493 ns/day, 48.655 hours/ns, 2.855 timesteps/s
+99.9% CPU use with 1 MPI tasks x no OpenMP threads
+
+MPI task timing breakdown:
+Section |  min time  |  avg time  |  max time  |%varavg| %total
+---------------------------------------------------------------
+Pair    | 25.021     | 25.021     | 25.021     |   0.0 | 71.42
+Bond    | 1.2834     | 1.2834     | 1.2834     |   0.0 |  3.66
+Kspace  | 3.2116     | 3.2116     | 3.2116     |   0.0 |  9.17
+Neigh   | 4.2767     | 4.2767     | 4.2767     |   0.0 | 12.21
+Comm    | 0.069283   | 0.069283   | 0.069283   |   0.0 |  0.20
+Output  | 0.00028205 | 0.00028205 | 0.00028205 |   0.0 |  0.00
+Modify  | 1.14       | 1.14       | 1.14       |   0.0 |  3.25
+Other   |            | 0.02938    |            |       |  0.08
+
+Nlocal:    32000 ave 32000 max 32000 min
+Histogram: 1 0 0 0 0 0 0 0 0 0
+Nghost:    47958 ave 47958 max 47958 min
+Histogram: 1 0 0 0 0 0 0 0 0 0
+Neighs:    1.20281e+07 ave 1.20281e+07 max 1.20281e+07 min
+Histogram: 1 0 0 0 0 0 0 0 0 0
+
+Total # of neighbors = 12028098
+Ave neighs/atom = 375.878
+Ave special neighs/atom = 7.43187
+Neighbor list builds = 11
+Dangerous builds = 0
+Total wall time: 0:00:36

bench/log.6Oct16.rhodo.fixed.icc.4

@@ -0,0 +1,122 @@
+LAMMPS (6 Oct 2016)
+# Rhodopsin model
+
+units           real
+neigh_modify    delay 5 every 1
+
+atom_style      full
+bond_style      harmonic
+angle_style     charmm
+dihedral_style  charmm
+improper_style  harmonic
+pair_style      lj/charmm/coul/long 8.0 10.0
+pair_modify     mix arithmetic
+kspace_style    pppm 1e-4
+
+read_data       data.rhodo
+  orthogonal box = (-27.5 -38.5 -36.3646) to (27.5 38.5 36.3615)
+  1 by 2 by 2 MPI processor grid
+  reading atoms ...
+  32000 atoms
+  reading velocities ...
+  32000 velocities
+  scanning bonds ...
+  4 = max bonds/atom
+  scanning angles ...
+  8 = max angles/atom
+  scanning dihedrals ...
+  18 = max dihedrals/atom
+  scanning impropers ...
+  2 = max impropers/atom
+  reading bonds ...
+  27723 bonds
+  reading angles ...
+  40467 angles
+  reading dihedrals ...
+  56829 dihedrals
+  reading impropers ...
+  1034 impropers
+  4 = max # of 1-2 neighbors
+  12 = max # of 1-3 neighbors
+  24 = max # of 1-4 neighbors
+  26 = max # of special neighbors
+
+fix             1 all shake 0.0001 5 0 m 1.0 a 232
+  1617 = # of size 2 clusters
+  3633 = # of size 3 clusters
+  747 = # of size 4 clusters
+  4233 = # of frozen angles
+fix             2 all npt temp 300.0 300.0 100.0 		z 0.0 0.0 1000.0 mtk no pchain 0 tchain 1
+
+special_bonds   charmm
+
+thermo          50
+thermo_style    multi
+timestep        2.0
+
+run		100
+PPPM initialization ...
+WARNING: Using 12-bit tables for long-range coulomb (../kspace.cpp:316)
+  G vector (1/distance) = 0.248835
+  grid = 25 32 32
+  stencil order = 5
+  estimated absolute RMS force accuracy = 0.0355478
+  estimated relative force accuracy = 0.000107051
+  using double precision FFTs
+  3d grid and FFT values/proc = 13230 6400
+Neighbor list info ...
+  1 neighbor list requests
+  update every 1 steps, delay 5 steps, check yes
+  max neighbors/atom: 2000, page size: 100000
+  master list distance cutoff = 12
+  ghost atom cutoff = 12
+  binsize = 6 -> bins = 10 13 13
+Memory usage per processor = 37.3604 Mbytes
+---------------- Step        0 ----- CPU =      0.0000 (sec) ----------------
+TotEng   =    -25356.2064 KinEng   =     21444.8313 Temp     =       299.0397 
+PotEng   =    -46801.0377 E_bond   =      2537.9940 E_angle  =     10921.3742 
+E_dihed  =      5211.7865 E_impro  =       213.5116 E_vdwl   =     -2307.8634 
+E_coul   =    207025.8927 E_long   =   -270403.7333 Press    =      -149.3301 
+Volume   =    307995.0335 
+---------------- Step       50 ----- CPU =      4.6056 (sec) ----------------
+TotEng   =    -25330.0321 KinEng   =     21501.0036 Temp     =       299.8230 
+PotEng   =    -46831.0357 E_bond   =      2471.7033 E_angle  =     10836.5108 
+E_dihed  =      5239.6316 E_impro  =       227.1219 E_vdwl   =     -1993.2763 
+E_coul   =    206797.6655 E_long   =   -270410.3927 Press    =       237.6866 
+Volume   =    308031.5640 
+---------------- Step      100 ----- CPU =      9.3910 (sec) ----------------
+TotEng   =    -25290.7386 KinEng   =     21591.9096 Temp     =       301.0906 
+PotEng   =    -46882.6482 E_bond   =      2567.9789 E_angle  =     10781.9556 
+E_dihed  =      5198.7493 E_impro  =       216.7863 E_vdwl   =     -1902.6458 
+E_coul   =    206659.5007 E_long   =   -270404.9733 Press    =         6.7898 
+Volume   =    308133.9933 
+Loop time of 9.39107 on 4 procs for 100 steps with 32000 atoms
+
+Performance: 1.840 ns/day, 13.043 hours/ns, 10.648 timesteps/s
+99.8% CPU use with 4 MPI tasks x no OpenMP threads
+
+MPI task timing breakdown:
+Section |  min time  |  avg time  |  max time  |%varavg| %total
+---------------------------------------------------------------
+Pair    | 6.2189     | 6.3266     | 6.6072     |   6.5 | 67.37
+Bond    | 0.30793    | 0.32122    | 0.3414     |   2.4 |  3.42
+Kspace  | 0.87994    | 1.1644     | 1.2855     |  15.3 | 12.40
+Neigh   | 1.1358     | 1.136      | 1.1362     |   0.0 | 12.10
+Comm    | 0.08292    | 0.084935   | 0.087077   |   0.5 |  0.90
+Output  | 0.00015712 | 0.00016558 | 0.00018501 |   0.1 |  0.00
+Modify  | 0.33717    | 0.34246    | 0.34794    |   0.7 |  3.65
+Other   |            | 0.01526    |            |       |  0.16
+
+Nlocal:    8000 ave 8143 max 7933 min
+Histogram: 1 2 0 0 0 0 0 0 0 1
+Nghost:    22733.5 ave 22769 max 22693 min
+Histogram: 1 0 0 0 0 2 0 0 0 1
+Neighs:    3.00702e+06 ave 3.0975e+06 max 2.96492e+06 min
+Histogram: 1 2 0 0 0 0 0 0 0 1
+
+Total # of neighbors = 12028098
+Ave neighs/atom = 375.878
+Ave special neighs/atom = 7.43187
+Neighbor list builds = 11
+Dangerous builds = 0
+Total wall time: 0:00:09

bench/log.6Oct16.rhodo.scaled.icc.4

@@ -0,0 +1,143 @@
+LAMMPS (6 Oct 2016)
+# Rhodopsin model
+
+variable	x index 1
+variable	y index 1
+variable	z index 1
+
+units           real
+neigh_modify    delay 5 every 1
+
+atom_style      full
+atom_modify	map hash
+bond_style      harmonic
+angle_style     charmm
+dihedral_style  charmm
+improper_style  harmonic
+pair_style      lj/charmm/coul/long 8.0 10.0
+pair_modify     mix arithmetic
+kspace_style    pppm 1e-4
+
+read_data       data.rhodo
+  orthogonal box = (-27.5 -38.5 -36.3646) to (27.5 38.5 36.3615)
+  1 by 2 by 2 MPI processor grid
+  reading atoms ...
+  32000 atoms
+  reading velocities ...
+  32000 velocities
+  scanning bonds ...
+  4 = max bonds/atom
+  scanning angles ...
+  8 = max angles/atom
+  scanning dihedrals ...
+  18 = max dihedrals/atom
+  scanning impropers ...
+  2 = max impropers/atom
+  reading bonds ...
+  27723 bonds
+  reading angles ...
+  40467 angles
+  reading dihedrals ...
+  56829 dihedrals
+  reading impropers ...
+  1034 impropers
+  4 = max # of 1-2 neighbors
+  12 = max # of 1-3 neighbors
+  24 = max # of 1-4 neighbors
+  26 = max # of special neighbors
+
+replicate	$x $y $z
+replicate	2 $y $z
+replicate	2 2 $z
+replicate	2 2 1
+  orthogonal box = (-27.5 -38.5 -36.3646) to (82.5 115.5 36.3615)
+  2 by 2 by 1 MPI processor grid
+  128000 atoms
+  110892 bonds
+  161868 angles
+  227316 dihedrals
+  4136 impropers
+  4 = max # of 1-2 neighbors
+  12 = max # of 1-3 neighbors
+  24 = max # of 1-4 neighbors
+  26 = max # of special neighbors
+
+fix             1 all shake 0.0001 5 0 m 1.0 a 232
+  6468 = # of size 2 clusters
+  14532 = # of size 3 clusters
+  2988 = # of size 4 clusters
+  16932 = # of frozen angles
+fix             2 all npt temp 300.0 300.0 100.0 		z 0.0 0.0 1000.0 mtk no pchain 0 tchain 1
+
+special_bonds   charmm
+
+thermo          50
+thermo_style    multi
+timestep        2.0
+
+run		100
+PPPM initialization ...
+WARNING: Using 12-bit tables for long-range coulomb (../kspace.cpp:316)
+  G vector (1/distance) = 0.248593
+  grid = 48 60 36
+  stencil order = 5
+  estimated absolute RMS force accuracy = 0.0359793
+  estimated relative force accuracy = 0.00010835
+  using double precision FFTs
+  3d grid and FFT values/proc = 41615 25920
+Neighbor list info ...
+  1 neighbor list requests
+  update every 1 steps, delay 5 steps, check yes
+  max neighbors/atom: 2000, page size: 100000
+  master list distance cutoff = 12
+  ghost atom cutoff = 12
+  binsize = 6 -> bins = 19 26 13
+Memory usage per processor = 96.9597 Mbytes
+---------------- Step        0 ----- CPU =      0.0000 (sec) ----------------
+TotEng   =   -101425.4887 KinEng   =     85779.3251 Temp     =       299.0304 
+PotEng   =   -187204.8138 E_bond   =     10151.9760 E_angle  =     43685.4968 
+E_dihed  =     20847.1460 E_impro  =       854.0463 E_vdwl   =     -9231.4537 
+E_coul   =    827053.5824 E_long   =  -1080565.6077 Press    =      -149.0358 
+Volume   =   1231980.1340 
+---------------- Step       50 ----- CPU =     18.1689 (sec) ----------------
+TotEng   =   -101320.0211 KinEng   =     86003.4933 Temp     =       299.8118 
+PotEng   =   -187323.5144 E_bond   =      9887.1189 E_angle  =     43346.8448 
+E_dihed  =     20958.7108 E_impro  =       908.4721 E_vdwl   =     -7973.4486 
+E_coul   =    826141.5493 E_long   =  -1080592.7617 Press    =       238.0404 
+Volume   =   1232126.1814 
+---------------- Step      100 ----- CPU =     37.2027 (sec) ----------------
+TotEng   =   -101157.9546 KinEng   =     86355.7413 Temp     =       301.0398 
+PotEng   =   -187513.6959 E_bond   =     10272.0456 E_angle  =     43128.7018 
+E_dihed  =     20794.0107 E_impro  =       867.0928 E_vdwl   =     -7587.2409 
+E_coul   =    825584.2416 E_long   =  -1080572.5474 Press    =        15.1729 
+Volume   =   1232535.8440 
+Loop time of 37.2028 on 4 procs for 100 steps with 128000 atoms
+
+Performance: 0.464 ns/day, 51.671 hours/ns, 2.688 timesteps/s
+99.9% CPU use with 4 MPI tasks x no OpenMP threads
+
+MPI task timing breakdown:
+Section |  min time  |  avg time  |  max time  |%varavg| %total
+---------------------------------------------------------------
+Pair    | 25.431     | 25.738     | 25.984     |   4.0 | 69.18
+Bond    | 1.2966     | 1.3131     | 1.3226     |   0.9 |  3.53
+Kspace  | 3.7563     | 4.0123     | 4.3127     |  10.0 | 10.79
+Neigh   | 4.3778     | 4.378      | 4.3782     |   0.0 | 11.77
+Comm    | 0.1903     | 0.19549    | 0.20485    |   1.3 |  0.53
+Output  | 0.00031805 | 0.00037521 | 0.00039601 |   0.2 |  0.00
+Modify  | 1.4861     | 1.5051     | 1.5122     |   0.9 |  4.05
+Other   |            | 0.05992    |            |       |  0.16
+
+Nlocal:    32000 ave 32000 max 32000 min
+Histogram: 4 0 0 0 0 0 0 0 0 0
+Nghost:    47957 ave 47957 max 47957 min
+Histogram: 4 0 0 0 0 0 0 0 0 0
+Neighs:    1.20281e+07 ave 1.20572e+07 max 1.19991e+07 min
+Histogram: 2 0 0 0 0 0 0 0 0 2
+
+Total # of neighbors = 48112540
+Ave neighs/atom = 375.879
+Ave special neighs/atom = 7.43187
+Neighbor list builds = 11
+Dangerous builds = 0
+Total wall time: 0:00:38

doc/.gitignore

@@ -0,0 +1,6 @@
+/html
+/spelling
+/LAMMPS.epub
+/LAMMPS.mobi
+/Manual.pdf
+/Developer.pdf

doc/Eqs/compute_dpd.tex

@@ -1,12 +0,0 @@
-\documentstyle[12pt]{article}
-\pagestyle{empty}
-\begin{document}
-
-\begin{eqnarray*}
-   U^{cond} = \displaystyle\sum_{i=1}^{N} u_{i}^{cond} \\ 
-   U^{mech} = \displaystyle\sum_{i=1}^{N} u_{i}^{mech} \\
-   U = \displaystyle\sum_{i=1}^{N} (u_{i}^{cond} + u_{i}^{mech}) \\
-   \theta_{avg} = (\frac{1}{N}\displaystyle\sum_{i=1}^{N} \frac{1}{\theta_{i}})^{-1} \\
-\end{eqnarray*}                           
-
-\end{document}

doc/Eqs/fix_ti_rs_force.tex

@@ -1,11 +0,0 @@
-\documentclass[12pt]{article}
-
-\usepackage{amsmath}
-
-\begin{document}
-
-$$
-  F_{\text{total}} = \lambda F_{\text{int}}
-$$
-
-\end{document}

doc/Eqs/fix_ti_rs_function_1.tex

@@ -1,9 +0,0 @@
-\documentclass[12pt]{article}
-
-\begin{document}
-
-$$
-  \lambda(\tau) = \lambda_i + \tau \left( \lambda_f - \lambda_i \right)
-$$
-
-\end{document}

doc/Eqs/fix_ti_rs_function_2.tex

@@ -1,9 +0,0 @@
-\documentclass[12pt]{article}
-
-\begin{document}
-
-$$
-  \lambda(\tau) = \frac{\lambda_i}{1 + \tau \left( \frac{\lambda_i}{\lambda_f} - 1 \right)}
-$$
-
-\end{document}

doc/Eqs/fix_ti_rs_function_3.tex

@@ -1,9 +0,0 @@
-\documentclass[12pt]{article}
-
-\begin{document}
-
-$$
-  \lambda(\tau) = \frac{\lambda_i}{ 1 + \log_2(1+\tau) \left( \frac{\lambda_i}{\lambda_f} - 1 \right)}
-$$
-
-\end{document}

doc/Eqs/fix_ti_spring_force.tex

@@ -1,11 +0,0 @@
-\documentclass[12pt]{article}
-
-\usepackage{amsmath}
-
-\begin{document}
-
-$$
-  F_{\text{total}} = \left( 1-\lambda \right) F_{\text{solid}} + \lambda F_{\text{harm}}
-$$
-
-\end{document}

doc/Eqs/improper_umbrella.tex

@@ -1,13 +0,0 @@
-\documentstyle[12pt]{article}
-
-\begin{document}
-
-$$
-E=\frac{1}{2}K\left( \frac{1+cos\omega_0}{sin\omega_0}\right) ^2 \left( cos\omega - cos\omega_0\right) \qquad \omega_0 \neq 0^o
-$$
-
-$$
-E=K\left( 1-cos\omega\right)  \qquad \omega_0 = 0^o
-$$
-
-\end{document}

doc/Eqs/pair_dpd_conservative.tex

@@ -1,9 +0,0 @@
-\documentclass[12pt]{article}
-\pagestyle{empty}
-\begin{document}
-
-$$
-F^C = A \omega_{ij} \qquad \qquad r_{ij} < r_c
-$$
-
-\end{document}

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

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

doc/Eqs/pressure.tex

@@ -1,9 +0,0 @@
-\documentclass[12pt]{article}
-
-\begin{document}
-
-$$
-   P = \frac{N k_B T}{V} + \frac{\sum_{i}^{N} r_i \bullet f_i}{dV}
-$$
-
-\end{document}

doc/Makefile

@@ -0,0 +1,173 @@
+# Makefile for LAMMPS documentation
+
+SHELL 	      = /bin/bash
+SHA1          = $(shell echo $USER-$PWD | python utils/sha1sum.py)
+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
+HAS_VIRTUALENV = NO
+
+ifeq ($(shell which python3 >/dev/null 2>&1; echo $$?), 0)
+HAS_PYTHON3 = YES
+endif
+
+ifeq ($(shell which virtualenv >/dev/null 2>&1; echo $$?), 0)
+HAS_VIRTUALENV = YES
+endif
+
+SOURCES=$(wildcard src/*.txt)
+OBJECTS=$(SOURCES:src/%.txt=$(RSTDIR)/%.rst)
+
+.PHONY: help clean-all clean epub html pdf old venv spelling anchor_check
+
+# ------------------------------------------
+
+help:
+	@echo "Please use \`make <target>' where <target> is one of"
+	@echo "  html       create HTML doc pages in html dir"
+	@echo "  pdf        create Manual.pdf and Developer.pdf in this dir"
+	@echo "  old        create old-style HTML doc pages in old dir"
+	@echo "  fetch      fetch HTML and PDF files from LAMMPS web site"
+	@echo "  epub       create ePUB format manual for e-book readers"
+	@echo "  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"
+
+# ------------------------------------------
+
+clean-all:
+	rm -rf $(BUILDDIR)/* utils/txt2html/txt2html.exe
+
+clean:
+	rm -rf $(RSTDIR) html
+	rm -rf spelling
+
+clean-spelling:
+	rm -rf spelling
+
+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
+	@rm -rf html/_sources
+	@rm -rf html/PDF
+	@rm -rf html/USER
+	@cp -r src/PDF html/PDF
+	@cp -r src/USER html/USER
+	@rm -rf html/PDF/.[sg]*
+	@rm -rf html/USER/.[sg]*
+	@rm -rf html/USER/*/.[sg]*
+	@rm -rf html/USER/*/*.[sg]*
+	@echo "Build finished. The HTML pages are in doc/html."
+
+spelling: $(OBJECTS) utils/sphinx-config/false_positives.txt
+	@(\
+		. $(VENV)/bin/activate ;\
+		pip install sphinxcontrib-spelling ;\
+		cp -r src/* $(RSTDIR)/ ;\
+        cp utils/sphinx-config/false_positives.txt $(RSTDIR)/ ;\
+		sphinx-build -b spelling -c utils/sphinx-config -d $(BUILDDIR)/doctrees $(RSTDIR) spelling ;\
+		deactivate ;\
+	)
+	@echo "Spell check finished."
+
+epub: $(OBJECTS)
+	@mkdir -p epub
+	@rm -f LAMMPS.epub
+	@cp src/JPG/lammps-logo.png epub/
+	@(\
+		. $(VENV)/bin/activate ;\
+		cp -r src/* $(RSTDIR)/ ;\
+		sphinx-build -j 8 -b epub -c utils/sphinx-config -d $(BUILDDIR)/doctrees $(RSTDIR) epub ;\
+		deactivate ;\
+	)
+	@mv  epub/LAMMPS.epub .
+	@rm -rf epub
+	@echo "Build finished. The ePUB manual file is created."
+
+pdf: utils/txt2html/txt2html.exe
+	@(\
+		set -e; \
+		cd src; \
+		../utils/txt2html/txt2html.exe -b *.txt; \
+		htmldoc --batch lammps.book;          \
+		for s in `echo *.txt | sed -e 's,\.txt,\.html,g'` ; \
+			do grep -q $$s lammps.book || \
+			echo doc file $$s missing in src/lammps.book; done; \
+		rm *.html; \
+		cd Developer; \
+		pdflatex developer; \
+		pdflatex developer; \
+		mv developer.pdf ../../Developer.pdf; \
+	)
+
+old: utils/txt2html/txt2html.exe
+	@rm -rf old
+	@mkdir old; mkdir old/Eqs; mkdir old/JPG; mkdir old/PDF
+	@cd src; ../utils/txt2html/txt2html.exe -b *.txt; \
+	  mv *.html ../old; \
+	  cp Eqs/*.jpg ../old/Eqs; \
+	  cp JPG/* ../old/JPG; \
+	  cp PDF/* ../old/PDF;
+
+fetch:
+	@rm -rf html_www Manual_www.pdf Developer_www.pdf
+	@curl -s -o Manual_www.pdf http://lammps.sandia.gov/doc/Manual.pdf
+	@curl -s -o Developer_www.pdf http://lammps.sandia.gov/doc/Developer.pdf
+	@curl -s -o lammps-doc.tar.gz http://lammps.sandia.gov/tars/lammps-doc.tar.gz
+	@tar xzf lammps-doc.tar.gz
+	@rm -f lammps-doc.tar.gz
+
+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
+	g++ -O -Wall -o $@ $<
+
+$(RSTDIR)/%.rst : src/%.txt $(TXT2RST)
+	@(\
+		mkdir -p $(RSTDIR) ; \
+		. $(VENV)/bin/activate ;\
+		txt2rst $< > $@ ;\
+		deactivate ;\
+	)
+
+$(VENV):
+	@if [ "$(HAS_PYTHON3)" == "NO" ] ; then echo "Python3 was not found! Please check README.md for further instructions" 1>&2; exit 1; fi
+	@if [ "$(HAS_VIRTUALENV)" == "NO" ] ; then echo "virtualenv was not found! Please check README.md for further instructions" 1>&2; exit 1; fi
+	@( \
+		virtualenv -p $(PYTHON) $(VENV); \
+		. $(VENV)/bin/activate; \
+		pip install Sphinx==1.5.6; \
+		pip install sphinxcontrib-images; \
+		deactivate;\
+	)
+
+$(TXT2RST) $(ANCHORCHECK): $(VENV)
+	@( \
+		. $(VENV)/bin/activate; \
+		(cd utils/converters;\
+		python setup.py develop);\
+		deactivate;\
+	)

doc/Manual.html

@@ -1,457 +0,0 @@
-
-
-<!DOCTYPE html>
-<!--[if IE 8]><html class="no-js lt-ie9" lang="en" > <![endif]-->
-<!--[if gt IE 8]><!--> <html class="no-js" lang="en" > <!--<![endif]-->
-<head>
-  <meta charset="utf-8">
-  
-  <meta name="viewport" content="width=device-width, initial-scale=1.0">
-  
-  <title>LAMMPS Documentation &mdash; LAMMPS documentation</title>
-  
-
-  
-  
-
-  
-
-  
-  
-    
-
-  
-
-  
-  
-    <link rel="stylesheet" href="_static/css/theme.css" type="text/css" />
-  
-
-  
-    <link rel="stylesheet" href="_static/sphinxcontrib-images/LightBox2/lightbox2/css/lightbox.css" type="text/css" />
-  
-
-  
-    <link rel="top" title="LAMMPS documentation" href="index.html"/>
-        <link rel="next" title="1. Introduction" href="Section_intro.html"/> 
-
-  
-  <script src="_static/js/modernizr.min.js"></script>
-
-</head>
-
-<body class="wy-body-for-nav" role="document">
-
-  <div class="wy-grid-for-nav">
-
-    
-    <nav data-toggle="wy-nav-shift" class="wy-nav-side">
-      <div class="wy-side-nav-search">
-        
-
-        
-          <a href="#" class="icon icon-home"> LAMMPS
-        
-
-        
-        </a>
-
-        
-<div role="search">
-  <form id="rtd-search-form" class="wy-form" action="search.html" method="get">
-    <input type="text" name="q" placeholder="Search docs" />
-    <input type="hidden" name="check_keywords" value="yes" />
-    <input type="hidden" name="area" value="default" />
-  </form>
-</div>
-
-        
-      </div>
-
-      <div class="wy-menu wy-menu-vertical" data-spy="affix" role="navigation" aria-label="main navigation">
-        
-          
-          
-              <ul>
-<li class="toctree-l1"><a class="reference internal" href="Section_intro.html">1. Introduction</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_start.html">2. Getting Started</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_commands.html">3. Commands</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_packages.html">4. Packages</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_accelerate.html">5. Accelerating LAMMPS performance</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_howto.html">6. How-to discussions</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_example.html">7. Example problems</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_perf.html">8. Performance &amp; scalability</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_tools.html">9. Additional tools</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_modify.html">10. Modifying &amp; extending LAMMPS</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_python.html">11. Python interface to LAMMPS</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_errors.html">12. Errors</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_history.html">13. Future and history</a></li>
-</ul>
-
-          
-        
-      </div>
-      &nbsp;
-    </nav>
-
-    <section data-toggle="wy-nav-shift" class="wy-nav-content-wrap">
-
-      
-      <nav class="wy-nav-top" role="navigation" aria-label="top navigation">
-        <i data-toggle="wy-nav-top" class="fa fa-bars"></i>
-        <a href="#">LAMMPS</a>
-      </nav>
-
-
-      
-      <div class="wy-nav-content">
-        <div class="rst-content">
-          <div role="navigation" aria-label="breadcrumbs navigation">
-  <ul class="wy-breadcrumbs">
-    <li><a href="#">Docs</a> &raquo;</li>
-      
-    <li>LAMMPS Documentation</li>
-      <li class="wy-breadcrumbs-aside">
-        
-          
-            <a href="http://lammps.sandia.gov">Website</a>
-            <a href="Section_commands.html#comm">Commands</a>
-        
-      </li>
-  </ul>
-  <hr/>
-  
-    <div class="rst-footer-buttons" style="margin-bottom: 1em" role="navigation" aria-label="footer navigation">
-      
-        <a href="Section_intro.html" class="btn btn-neutral float-right" title="1. Introduction" accesskey="n">Next <span class="fa fa-arrow-circle-right"></span></a>
-      
-      
-    </div>
-  
-</div>
-          <div role="main" class="document" itemscope="itemscope" itemtype="http://schema.org/Article">
-           <div itemprop="articleBody">
-            
-  <H1></H1><div class="section" id="lammps-documentation">
-<h1>LAMMPS Documentation<a class="headerlink" href="#lammps-documentation" title="Permalink to this headline">¶</a></h1>
-<div class="section" id="feb-2016-version">
-<h2>16 Feb 2016 version<a class="headerlink" href="#feb-2016-version" title="Permalink to this headline">¶</a></h2>
-</div>
-<div class="section" id="version-info">
-<h2>Version info:<a class="headerlink" href="#version-info" title="Permalink to this headline">¶</a></h2>
-<p>The LAMMPS &#8220;version&#8221; is the date when it was released, such as 1 May
-2010. LAMMPS is updated continuously.  Whenever we fix a bug or add a
-feature, we release it immediately, and post a notice on <a class="reference external" href="http://lammps.sandia.gov/bug.html">this page of the WWW site</a>.  Each dated copy of LAMMPS contains all the
-features and bug-fixes up to and including that version date. The
-version date is printed to the screen and logfile every time you run
-LAMMPS. It is also in the file src/version.h and in the LAMMPS
-directory name created when you unpack a tarball, and at the top of
-the first page of the manual (this page).</p>
-<ul class="simple">
-<li>If you browse the HTML doc pages on the LAMMPS WWW site, they always
-describe the most current version of LAMMPS.</li>
-<li>If you browse the HTML doc pages included in your tarball, they
-describe the version you have.</li>
-<li>The <a class="reference external" href="Manual.pdf">PDF file</a> on the WWW site or in the tarball is updated
-about once per month.  This is because it is large, and we don&#8217;t want
-it to be part of every patch.</li>
-<li>There is also a <a class="reference external" href="Developer.pdf">Developer.pdf</a> file in the doc
-directory, which describes the internal structure and algorithms of
-LAMMPS.</li>
-</ul>
-<p>LAMMPS stands for Large-scale Atomic/Molecular Massively Parallel
-Simulator.</p>
-<p>LAMMPS is a classical molecular dynamics simulation code designed to
-run efficiently on parallel computers.  It was developed at Sandia
-National Laboratories, a US Department of Energy facility, with
-funding from the DOE.  It is an open-source code, distributed freely
-under the terms of the GNU Public License (GPL).</p>
-<p>The primary developers of LAMMPS are <a class="reference external" href="http://www.sandia.gov/~sjplimp">Steve Plimpton</a>, Aidan
-Thompson, and Paul Crozier who can be contacted at
-sjplimp,athomps,pscrozi at sandia.gov.  The <a class="reference external" href="http://lammps.sandia.gov">LAMMPS WWW Site</a> at
-<a class="reference external" href="http://lammps.sandia.gov">http://lammps.sandia.gov</a> has more information about the code and its
-uses.</p>
-<hr class="docutils" />
-<p>The LAMMPS documentation is organized into the following sections.  If
-you find errors or omissions in this manual or have suggestions for
-useful information to add, please send an email to the developers so
-we can improve the LAMMPS documentation.</p>
-<p>Once you are familiar with LAMMPS, you may want to bookmark <a class="reference internal" href="Section_commands.html#comm"><span>this page</span></a> at Section_commands.html#comm since
-it gives quick access to documentation for all LAMMPS commands.</p>
-<p><a class="reference external" href="Manual.pdf">PDF file</a> of the entire manual, generated by
-<a class="reference external" href="http://freecode.com/projects/htmldoc">htmldoc</a></p>
-<div class="toctree-wrapper compound">
-<ul>
-<li class="toctree-l1"><a class="reference internal" href="Section_intro.html">1. Introduction</a><ul>
-<li class="toctree-l2"><a class="reference internal" href="Section_intro.html#what-is-lammps">1.1. What is LAMMPS</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_intro.html#lammps-features">1.2. LAMMPS features</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_intro.html#lammps-non-features">1.3. LAMMPS non-features</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_intro.html#open-source-distribution">1.4. Open source distribution</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_intro.html#acknowledgments-and-citations">1.5. Acknowledgments and citations</a></li>
-</ul>
-</li>
-<li class="toctree-l1"><a class="reference internal" href="Section_start.html">2. Getting Started</a><ul>
-<li class="toctree-l2"><a class="reference internal" href="Section_start.html#what-s-in-the-lammps-distribution">2.1. What&#8217;s in the LAMMPS distribution</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_start.html#making-lammps">2.2. Making LAMMPS</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_start.html#making-lammps-with-optional-packages">2.3. Making LAMMPS with optional packages</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_start.html#building-lammps-via-the-make-py-tool">2.4. Building LAMMPS via the Make.py tool</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_start.html#building-lammps-as-a-library">2.5. Building LAMMPS as a library</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_start.html#running-lammps">2.6. Running LAMMPS</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_start.html#command-line-options">2.7. Command-line options</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_start.html#lammps-screen-output">2.8. LAMMPS screen output</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_start.html#tips-for-users-of-previous-lammps-versions">2.9. Tips for users of previous LAMMPS versions</a></li>
-</ul>
-</li>
-<li class="toctree-l1"><a class="reference internal" href="Section_commands.html">3. Commands</a><ul>
-<li class="toctree-l2"><a class="reference internal" href="Section_commands.html#lammps-input-script">3.1. LAMMPS input script</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_commands.html#parsing-rules">3.2. Parsing rules</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_commands.html#input-script-structure">3.3. Input script structure</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_commands.html#commands-listed-by-category">3.4. Commands listed by category</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_commands.html#individual-commands">3.5. Individual commands</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_commands.html#fix-styles">3.6. Fix styles</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_commands.html#compute-styles">3.7. Compute styles</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_commands.html#pair-style-potentials">3.8. Pair_style potentials</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_commands.html#bond-style-potentials">3.9. Bond_style potentials</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_commands.html#angle-style-potentials">3.10. Angle_style potentials</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_commands.html#dihedral-style-potentials">3.11. Dihedral_style potentials</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_commands.html#improper-style-potentials">3.12. Improper_style potentials</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_commands.html#kspace-solvers">3.13. Kspace solvers</a></li>
-</ul>
-</li>
-<li class="toctree-l1"><a class="reference internal" href="Section_packages.html">4. Packages</a><ul>
-<li class="toctree-l2"><a class="reference internal" href="Section_packages.html#standard-packages">4.1. Standard packages</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_packages.html#build-instructions-for-compress-package">4.2. Build instructions for COMPRESS package</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_packages.html#build-instructions-for-gpu-package">4.3. Build instructions for GPU package</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_packages.html#build-instructions-for-kim-package">4.4. Build instructions for KIM package</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_packages.html#build-instructions-for-kokkos-package">4.5. Build instructions for KOKKOS package</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_packages.html#build-instructions-for-kspace-package">4.6. Build instructions for KSPACE package</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_packages.html#build-instructions-for-meam-package">4.7. Build instructions for MEAM package</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_packages.html#build-instructions-for-poems-package">4.8. Build instructions for POEMS package</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_packages.html#build-instructions-for-python-package">4.9. Build instructions for PYTHON package</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_packages.html#build-instructions-for-reax-package">4.10. Build instructions for REAX package</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_packages.html#build-instructions-for-voronoi-package">4.11. Build instructions for VORONOI package</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_packages.html#build-instructions-for-xtc-package">4.12. Build instructions for XTC package</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_packages.html#user-packages">4.13. User packages</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_packages.html#user-atc-package">4.14. USER-ATC package</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_packages.html#user-awpmd-package">4.15. USER-AWPMD package</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_packages.html#user-cg-cmm-package">4.16. USER-CG-CMM package</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_packages.html#user-colvars-package">4.17. USER-COLVARS package</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_packages.html#user-cuda-package">4.18. USER-CUDA package</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_packages.html#user-diffraction-package">4.19. USER-DIFFRACTION package</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_packages.html#user-dpd-package">4.20. USER-DPD package</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_packages.html#user-drude-package">4.21. USER-DRUDE package</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_packages.html#user-eff-package">4.22. USER-EFF package</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_packages.html#user-fep-package">4.23. USER-FEP package</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_packages.html#user-h5md-package">4.24. USER-H5MD package</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_packages.html#user-intel-package">4.25. USER-INTEL package</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_packages.html#user-lb-package">4.26. USER-LB package</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_packages.html#user-mgpt-package">4.27. USER-MGPT package</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_packages.html#user-misc-package">4.28. USER-MISC package</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_packages.html#user-molfile-package">4.29. USER-MOLFILE package</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_packages.html#user-omp-package">4.30. USER-OMP package</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_packages.html#user-phonon-package">4.31. USER-PHONON package</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_packages.html#user-qmmm-package">4.32. USER-QMMM package</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_packages.html#user-qtb-package">4.33. USER-QTB package</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_packages.html#user-reaxc-package">4.34. USER-REAXC package</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_packages.html#user-smd-package">4.35. USER-SMD package</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_packages.html#user-smtbq-package">4.36. USER-SMTBQ package</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_packages.html#user-sph-package">4.37. USER-SPH package</a></li>
-</ul>
-</li>
-<li class="toctree-l1"><a class="reference internal" href="Section_accelerate.html">5. Accelerating LAMMPS performance</a><ul>
-<li class="toctree-l2"><a class="reference internal" href="Section_accelerate.html#measuring-performance">5.1. Measuring performance</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_accelerate.html#general-strategies">5.2. General strategies</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_accelerate.html#packages-with-optimized-styles">5.3. Packages with optimized styles</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_accelerate.html#comparison-of-various-accelerator-packages">5.4. Comparison of various accelerator packages</a></li>
-</ul>
-</li>
-<li class="toctree-l1"><a class="reference internal" href="Section_howto.html">6. How-to discussions</a><ul>
-<li class="toctree-l2"><a class="reference internal" href="Section_howto.html#restarting-a-simulation">6.1. Restarting a simulation</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_howto.html#d-simulations">6.2. 2d simulations</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_howto.html#charmm-amber-and-dreiding-force-fields">6.3. CHARMM, AMBER, and DREIDING force fields</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_howto.html#running-multiple-simulations-from-one-input-script">6.4. Running multiple simulations from one input script</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_howto.html#multi-replica-simulations">6.5. Multi-replica simulations</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_howto.html#granular-models">6.6. Granular models</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_howto.html#tip3p-water-model">6.7. TIP3P water model</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_howto.html#tip4p-water-model">6.8. TIP4P water model</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_howto.html#spc-water-model">6.9. SPC water model</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_howto.html#coupling-lammps-to-other-codes">6.10. Coupling LAMMPS to other codes</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_howto.html#visualizing-lammps-snapshots">6.11. Visualizing LAMMPS snapshots</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_howto.html#triclinic-non-orthogonal-simulation-boxes">6.12. Triclinic (non-orthogonal) simulation boxes</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_howto.html#nemd-simulations">6.13. NEMD simulations</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_howto.html#finite-size-spherical-and-aspherical-particles">6.14. Finite-size spherical and aspherical particles</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_howto.html#output-from-lammps-thermo-dumps-computes-fixes-variables">6.15. Output from LAMMPS (thermo, dumps, computes, fixes, variables)</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_howto.html#thermostatting-barostatting-and-computing-temperature">6.16. Thermostatting, barostatting, and computing temperature</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_howto.html#walls">6.17. Walls</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_howto.html#elastic-constants">6.18. Elastic constants</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_howto.html#library-interface-to-lammps">6.19. Library interface to LAMMPS</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_howto.html#calculating-thermal-conductivity">6.20. Calculating thermal conductivity</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_howto.html#calculating-viscosity">6.21. Calculating viscosity</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_howto.html#calculating-a-diffusion-coefficient">6.22. Calculating a diffusion coefficient</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_howto.html#using-chunks-to-calculate-system-properties">6.23. Using chunks to calculate system properties</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_howto.html#setting-parameters-for-the-kspace-style-pppm-disp-command">6.24. Setting parameters for the <code class="docutils literal"><span class="pre">kspace_style</span> <span class="pre">pppm/disp</span></code> command</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_howto.html#polarizable-models">6.25. Polarizable models</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_howto.html#adiabatic-core-shell-model">6.26. Adiabatic core/shell model</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_howto.html#drude-induced-dipoles">6.27. Drude induced dipoles</a></li>
-</ul>
-</li>
-<li class="toctree-l1"><a class="reference internal" href="Section_example.html">7. Example problems</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_perf.html">8. Performance &amp; scalability</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_tools.html">9. Additional tools</a><ul>
-<li class="toctree-l2"><a class="reference internal" href="Section_tools.html#amber2lmp-tool">9.1. amber2lmp tool</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_tools.html#binary2txt-tool">9.2. binary2txt tool</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_tools.html#ch2lmp-tool">9.3. ch2lmp tool</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_tools.html#chain-tool">9.4. chain tool</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_tools.html#colvars-tools">9.5. colvars tools</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_tools.html#createatoms-tool">9.6. createatoms tool</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_tools.html#data2xmovie-tool">9.7. data2xmovie tool</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_tools.html#eam-database-tool">9.8. eam database tool</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_tools.html#eam-generate-tool">9.9. eam generate tool</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_tools.html#eff-tool">9.10. eff tool</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_tools.html#emacs-tool">9.11. emacs tool</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_tools.html#fep-tool">9.12. fep tool</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_tools.html#i-pi-tool">9.13. i-pi tool</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_tools.html#ipp-tool">9.14. ipp tool</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_tools.html#kate-tool">9.15. kate tool</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_tools.html#lmp2arc-tool">9.16. lmp2arc tool</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_tools.html#lmp2cfg-tool">9.17. lmp2cfg tool</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_tools.html#lmp2vmd-tool">9.18. lmp2vmd tool</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_tools.html#matlab-tool">9.19. matlab tool</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_tools.html#micelle2d-tool">9.20. micelle2d tool</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_tools.html#moltemplate-tool">9.21. moltemplate tool</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_tools.html#msi2lmp-tool">9.22. msi2lmp tool</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_tools.html#phonon-tool">9.23. phonon tool</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_tools.html#polymer-bonding-tool">9.24. polymer bonding tool</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_tools.html#pymol-asphere-tool">9.25. pymol_asphere tool</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_tools.html#python-tool">9.26. python tool</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_tools.html#reax-tool">9.27. reax tool</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_tools.html#restart2data-tool">9.28. restart2data tool</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_tools.html#vim-tool">9.29. vim tool</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_tools.html#xmgrace-tool">9.30. xmgrace tool</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_tools.html#xmovie-tool">9.31. xmovie tool</a></li>
-</ul>
-</li>
-<li class="toctree-l1"><a class="reference internal" href="Section_modify.html">10. Modifying &amp; extending LAMMPS</a><ul>
-<li class="toctree-l2"><a class="reference internal" href="Section_modify.html#atom-styles">10.1. Atom styles</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_modify.html#bond-angle-dihedral-improper-potentials">10.2. Bond, angle, dihedral, improper potentials</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_modify.html#compute-styles">10.3. Compute styles</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_modify.html#dump-styles">10.4. Dump styles</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_modify.html#dump-custom-output-options">10.5. Dump custom output options</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_modify.html#fix-styles">10.6. Fix styles</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_modify.html#input-script-commands">10.7. Input script commands</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_modify.html#kspace-computations">10.8. Kspace computations</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_modify.html#minimization-styles">10.9. Minimization styles</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_modify.html#pairwise-potentials">10.10. Pairwise potentials</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_modify.html#region-styles">10.11. Region styles</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_modify.html#body-styles">10.12. Body styles</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_modify.html#thermodynamic-output-options">10.13. Thermodynamic output options</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_modify.html#variable-options">10.14. Variable options</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_modify.html#submitting-new-features-for-inclusion-in-lammps">10.15. Submitting new features for inclusion in LAMMPS</a></li>
-</ul>
-</li>
-<li class="toctree-l1"><a class="reference internal" href="Section_python.html">11. Python interface to LAMMPS</a><ul>
-<li class="toctree-l2"><a class="reference internal" href="Section_python.html#overview-of-running-lammps-from-python">11.1. Overview of running LAMMPS from Python</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_python.html#overview-of-using-python-from-a-lammps-script">11.2. Overview of using Python from a LAMMPS script</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_python.html#building-lammps-as-a-shared-library">11.3. Building LAMMPS as a shared library</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_python.html#installing-the-python-wrapper-into-python">11.4. Installing the Python wrapper into Python</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_python.html#extending-python-with-mpi-to-run-in-parallel">11.5. Extending Python with MPI to run in parallel</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_python.html#testing-the-python-lammps-interface">11.6. Testing the Python-LAMMPS interface</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_python.html#using-lammps-from-python">11.7. Using LAMMPS from Python</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_python.html#example-python-scripts-that-use-lammps">11.8. Example Python scripts that use LAMMPS</a></li>
-</ul>
-</li>
-<li class="toctree-l1"><a class="reference internal" href="Section_errors.html">12. Errors</a><ul>
-<li class="toctree-l2"><a class="reference internal" href="Section_errors.html#common-problems">12.1. Common problems</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_errors.html#reporting-bugs">12.2. Reporting bugs</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_errors.html#error-warning-messages">12.3. Error &amp; warning messages</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_errors.html#error">12.4. Errors:</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_errors.html#warnings">12.5. Warnings:</a></li>
-</ul>
-</li>
-<li class="toctree-l1"><a class="reference internal" href="Section_history.html">13. Future and history</a><ul>
-<li class="toctree-l2"><a class="reference internal" href="Section_history.html#coming-attractions">13.1. Coming attractions</a></li>
-<li class="toctree-l2"><a class="reference internal" href="Section_history.html#past-versions">13.2. Past versions</a></li>
-</ul>
-</li>
-</ul>
-</div>
-</div>
-</div>
-<div class="section" id="indices-and-tables">
-<h1>Indices and tables<a class="headerlink" href="#indices-and-tables" title="Permalink to this headline">¶</a></h1>
-<ul class="simple">
-<li><a class="reference internal" href="genindex.html"><span>Index</span></a></li>
-<li><a class="reference internal" href="search.html"><span>Search Page</span></a></li>
-</ul>
-</BODY></div>
-
-
-           </div>
-          </div>
-          <footer>
-  
-    <div class="rst-footer-buttons" role="navigation" aria-label="footer navigation">
-      
-        <a href="Section_intro.html" class="btn btn-neutral float-right" title="1. Introduction" accesskey="n">Next <span class="fa fa-arrow-circle-right"></span></a>
-      
-      
-    </div>
-  
-
-  <hr/>
-
-  <div role="contentinfo">
-    <p>
-        &copy; Copyright 2013 Sandia Corporation.
-    </p>
-  </div>
-  Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
-
-</footer>
-
-        </div>
-      </div>
-
-    </section>
-
-  </div>
-  
-
-
-  
-
-    <script type="text/javascript">
-        var DOCUMENTATION_OPTIONS = {
-            URL_ROOT:'./',
-            VERSION:'',
-            COLLAPSE_INDEX:false,
-            FILE_SUFFIX:'.html',
-            HAS_SOURCE:  true
-        };
-    </script>
-      <script type="text/javascript" src="_static/jquery.js"></script>
-      <script type="text/javascript" src="_static/underscore.js"></script>
-      <script type="text/javascript" src="_static/doctools.js"></script>
-      <script type="text/javascript" src="https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>
-      <script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/jquery-1.11.0.min.js"></script>
-      <script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/lightbox.min.js"></script>
-      <script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2-customize/jquery-noconflict.js"></script>
-
-  
-
-  
-  
-    <script type="text/javascript" src="_static/js/theme.js"></script>
-  
-
-  
-  
-  <script type="text/javascript">
-      jQuery(function () {
-          SphinxRtdTheme.StickyNav.enable();
-      });
-  </script>
-   
-
-</body>
-</html>

doc/Manual.txt

@@ -1,304 +0,0 @@
-<!-- HTML_ONLY -->
-<HEAD>
-<TITLE>LAMMPS Users Manual</TITLE>
-<META NAME="docnumber" CONTENT="16 Feb 2016 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>
-
-<BODY>
-
-<!-- END_HTML_ONLY -->
-
-"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
-
-<H1></H1>
-
-LAMMPS Documentation :c,h3
-16 Feb 2016 version :c,h4
-
-Version info: :h4
-
-The LAMMPS "version" is the date when it was released, such as 1 May
-2010. LAMMPS is updated continuously.  Whenever we fix a bug or add a
-feature, we release it immediately, and post a notice on "this page of
-the WWW site"_bug.  Each dated copy of LAMMPS contains all the
-features and bug-fixes up to and including that version date. The
-version date is printed to the screen and logfile every time you run
-LAMMPS. It is also in the file src/version.h and in the LAMMPS
-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
-
-If you browse the HTML doc pages included in your tarball, they
-describe the version you have. :l
-
-The "PDF file"_Manual.pdf on the WWW site or in the tarball is updated
-about once per month.  This is because it is large, and we don't want
-it to be part of every patch. :l
-
-There is also a "Developer.pdf"_Developer.pdf file in the doc
-directory, which describes the internal structure and algorithms of
-LAMMPS.  :ule,l
-
-LAMMPS stands for Large-scale Atomic/Molecular Massively Parallel
-Simulator.
-
-LAMMPS is a classical molecular dynamics simulation code designed to
-run efficiently on parallel computers.  It was developed at Sandia
-National Laboratories, a US Department of Energy facility, with
-funding from the DOE.  It is an open-source code, distributed freely
-under the terms of the GNU Public License (GPL).
-
-The primary developers of LAMMPS are "Steve Plimpton"_sjp, Aidan
-Thompson, and Paul Crozier who can be contacted at
-sjplimp,athomps,pscrozi at sandia.gov.  The "LAMMPS WWW Site"_lws at
-http://lammps.sandia.gov has more information about the code and its
-uses.
-
-:link(bug,http://lammps.sandia.gov/bug.html)
-:link(sjp,http://www.sandia.gov/~sjplimp)
-
-:line
-
-The LAMMPS documentation is organized into the following sections.  If
-you find errors or omissions in this manual or have suggestions for
-useful information to add, please send an email to the developers so
-we can improve the LAMMPS documentation.
-
-Once you are familiar with LAMMPS, you may want to bookmark "this
-page"_Section_commands.html#comm at Section_commands.html#comm since
-it gives quick access to documentation for all LAMMPS commands.
-
-"PDF file"_Manual.pdf of the entire manual, generated by
-"htmldoc"_http://freecode.com/projects/htmldoc
-
-<!-- RST
-
-.. toctree::
-   :maxdepth: 2
-   :numbered:
-   
-   Section_intro
-   Section_start
-   Section_commands
-   Section_packages
-   Section_accelerate
-   Section_howto
-   Section_example
-   Section_perf
-   Section_tools
-   Section_modify
-   Section_python
-   Section_errors
-   Section_history
-
-
-Indices and tables
-==================
-
-* :ref:`genindex`
-* :ref:`search`
-   
-END_RST -->
-
-<!-- HTML_ONLY -->
-"Introduction"_Section_intro.html :olb,l
-  1.1 "What is LAMMPS"_intro_1 :ulb,b
-  1.2 "LAMMPS features"_intro_2 :b
-  1.3 "LAMMPS non-features"_intro_3 :b
-  1.4 "Open source distribution"_intro_4 :b
-  1.5 "Acknowledgments and citations"_intro_5 :ule,b
-"Getting started"_Section_start.html :l
-  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
-"Commands"_Section_commands.html :l
-  3.1 "LAMMPS input script"_cmd_1 :ulb,b
-  3.2 "Parsing rules"_cmd_2 :b
-  3.3 "Input script structure"_cmd_3 :b
-  3.4 "Commands listed by category"_cmd_4 :b
-  3.5 "Commands listed alphabetically"_cmd_5 :ule,b
-"Packages"_Section_packages.html :l
-  4.1 "Standard packages"_pkg_1 :ulb,b
-  4.2 "User packages"_pkg_2 :ule,b
-"Accelerating LAMMPS performance"_Section_accelerate.html :l
-  5.1 "Measuring performance"_acc_1 :ulb,b
-  5.2 "Algorithms and code options to boost performace"_acc_2 :b
-  5.3 "Accelerator packages with optimized styles"_acc_3 :b
-    5.3.1 "USER-CUDA package"_accelerate_cuda.html :ulb,b
-    5.3.2 "GPU package"_accelerate_gpu.html :b
-    5.3.3 "USER-INTEL package"_accelerate_intel.html :b
-    5.3.4 "KOKKOS package"_accelerate_kokkos.html :b
-    5.3.5 "USER-OMP package"_accelerate_omp.html :b
-    5.3.6 "OPT package"_accelerate_opt.html :ule,b
-  5.4 "Comparison of various accelerator packages"_acc_4 :ule,b
-"How-to discussions"_Section_howto.html :l
-  6.1 "Restarting a simulation"_howto_1 :ulb,b
-  6.2 "2d simulations"_howto_2 :b
-  6.3 "CHARMM and AMBER force fields"_howto_3 :b
-  6.4 "Running multiple simulations from one input script"_howto_4 :b
-  6.5 "Multi-replica simulations"_howto_5 :b
-  6.6 "Granular models"_howto_6 :b
-  6.7 "TIP3P water model"_howto_7 :b
-  6.8 "TIP4P water model"_howto_8 :b
-  6.9 "SPC water model"_howto_9 :b
-  6.10 "Coupling LAMMPS to other codes"_howto_10 :b
-  6.11 "Visualizing LAMMPS snapshots"_howto_11 :b
-  6.12 "Triclinic (non-orthogonal) simulation boxes"_howto_12 :b
-  6.13 "NEMD simulations"_howto_13 :b
-  6.14 "Finite-size spherical and aspherical particles"_howto_14 :b
-  6.15 "Output from LAMMPS (thermo, dumps, computes, fixes, variables)"_howto_15 :b
-  6.16 "Thermostatting, barostatting, and compute temperature"_howto_16 :b
-  6.17 "Walls"_howto_17 :b
-  6.18 "Elastic constants"_howto_18 :b
-  6.19 "Library interface to LAMMPS"_howto_19 :b
-  6.20 "Calculating thermal conductivity"_howto_20 :b
-  6.21 "Calculating viscosity"_howto_21 :b
-  6.22 "Calculating a diffusion coefficient"_howto_22 :b
-  6.23 "Using chunks to calculate system properties"_howto_23 :b
-  6.24 "Setting parameters for pppm/disp"_howto_24 :b
-  6.25 "Polarizable models"_howto_25 :b
-  6.26 "Adiabatic core/shell model"_howto_26 :b
-  6.27 "Drude induced dipoles"_howto_27 :ule,b
-"Example problems"_Section_example.html :l
-"Performance & scalability"_Section_perf.html :l
-"Additional tools"_Section_tools.html :l
-"Modifying & extending LAMMPS"_Section_modify.html :l
-  10.1 "Atom styles"_mod_1 :ulb,b
-  10.2 "Bond, angle, dihedral, improper potentials"_mod_2 :b
-  10.3 "Compute styles"_mod_3 :b
-  10.4 "Dump styles"_mod_4 :b
-  10.5 "Dump custom output options"_mod_5 :b
-  10.6 "Fix styles"_mod_6 :b
-  10.7 "Input script commands"_mod_7 :b
-  10.8 "Kspace computations"_mod_8 :b
-  10.9 "Minimization styles"_mod_9 :b
-  10.10 "Pairwise potentials"_mod_10 :b
-  10.11 "Region styles"_mod_11 :b
-  10.12 "Body styles"_mod_12 :b
-  10.13 "Thermodynamic output options"_mod_13 :b
-  10.14 "Variable options"_mod_14 :b
-  10.15 "Submitting new features for inclusion in LAMMPS"_mod_15 :ule,b
-"Python interface"_Section_python.html :l
-  11.1 "Overview of running LAMMPS from Python"_py_1 :ulb,b
-  11.2 "Overview of using Python from a LAMMPS script"_py_2 :b
-  11.3 "Building LAMMPS as a shared library"_py_3 :b
-  11.4 "Installing the Python wrapper into Python"_py_4 :b
-  11.5 "Extending Python with MPI to run in parallel"_py_5 :b
-  11.6 "Testing the Python-LAMMPS interface"_py_6 :b
-  11.7 "Using LAMMPS from Python"_py_7 :b
-  11.8 "Example Python scripts that use LAMMPS"_py_8 :ule,b
-"Errors"_Section_errors.html :l
-  12.1 "Common problems"_err_1 :ulb,b
-  12.2 "Reporting bugs"_err_2 :b
-  12.3 "Error & warning messages"_err_3 :ule,b
-"Future and history"_Section_history.html :l
-  13.1 "Coming attractions"_hist_1 :ulb,b
-  13.2 "Past versions"_hist_2 :ule,b
-:ole
-
-:link(intro_1,Section_intro.html#intro_1)
-:link(intro_2,Section_intro.html#intro_2)
-:link(intro_3,Section_intro.html#intro_3)
-:link(intro_4,Section_intro.html#intro_4)
-:link(intro_5,Section_intro.html#intro_5)
-
-:link(start_1,Section_start.html#start_1)
-:link(start_2,Section_start.html#start_2)
-:link(start_3,Section_start.html#start_3)
-:link(start_4,Section_start.html#start_4)
-:link(start_5,Section_start.html#start_5)
-:link(start_6,Section_start.html#start_6)
-:link(start_7,Section_start.html#start_7)
-:link(start_8,Section_start.html#start_8)
-:link(start_9,Section_start.html#start_9)
-
-:link(cmd_1,Section_commands.html#cmd_1)
-:link(cmd_2,Section_commands.html#cmd_2)
-:link(cmd_3,Section_commands.html#cmd_3)
-:link(cmd_4,Section_commands.html#cmd_4)
-:link(cmd_5,Section_commands.html#cmd_5)
-
-:link(pkg_1,Section_packages.html#pkg_1)
-:link(pkg_2,Section_packages.html#pkg_2)
-
-:link(acc_1,Section_accelerate.html#acc_1)
-:link(acc_2,Section_accelerate.html#acc_2)
-:link(acc_3,Section_accelerate.html#acc_3)
-:link(acc_4,Section_accelerate.html#acc_4)
-
-:link(howto_1,Section_howto.html#howto_1)
-:link(howto_2,Section_howto.html#howto_2)
-:link(howto_3,Section_howto.html#howto_3)
-:link(howto_4,Section_howto.html#howto_4)
-:link(howto_5,Section_howto.html#howto_5)
-:link(howto_6,Section_howto.html#howto_6)
-:link(howto_7,Section_howto.html#howto_7)
-:link(howto_8,Section_howto.html#howto_8)
-:link(howto_9,Section_howto.html#howto_9)
-:link(howto_10,Section_howto.html#howto_10)
-:link(howto_11,Section_howto.html#howto_11)
-:link(howto_12,Section_howto.html#howto_12)
-:link(howto_13,Section_howto.html#howto_13)
-:link(howto_14,Section_howto.html#howto_14)
-:link(howto_15,Section_howto.html#howto_15)
-:link(howto_16,Section_howto.html#howto_16)
-:link(howto_17,Section_howto.html#howto_17)
-:link(howto_18,Section_howto.html#howto_18)
-:link(howto_19,Section_howto.html#howto_19)
-:link(howto_20,Section_howto.html#howto_20)
-:link(howto_21,Section_howto.html#howto_21)
-:link(howto_22,Section_howto.html#howto_22)
-:link(howto_23,Section_howto.html#howto_23)
-:link(howto_24,Section_howto.html#howto_24)
-:link(howto_25,Section_howto.html#howto_25)
-:link(howto_26,Section_howto.html#howto_26)
-:link(howto_27,Section_howto.html#howto_27)
-
-:link(mod_1,Section_modify.html#mod_1)
-:link(mod_2,Section_modify.html#mod_2)
-:link(mod_3,Section_modify.html#mod_3)
-:link(mod_4,Section_modify.html#mod_4)
-:link(mod_5,Section_modify.html#mod_5)
-:link(mod_6,Section_modify.html#mod_6)
-:link(mod_7,Section_modify.html#mod_7)
-:link(mod_8,Section_modify.html#mod_8)
-:link(mod_9,Section_modify.html#mod_9)
-:link(mod_10,Section_modify.html#mod_10)
-:link(mod_11,Section_modify.html#mod_11)
-:link(mod_12,Section_modify.html#mod_12)
-:link(mod_13,Section_modify.html#mod_13)
-:link(mod_14,Section_modify.html#mod_14)
-:link(mod_15,Section_modify.html#mod_15)
-
-:link(py_1,Section_python.html#py_1)
-:link(py_2,Section_python.html#py_2)
-:link(py_3,Section_python.html#py_3)
-:link(py_4,Section_python.html#py_4)
-:link(py_5,Section_python.html#py_5)
-:link(py_6,Section_python.html#py_6)
-
-:link(err_1,Section_errors.html#err_1)
-:link(err_2,Section_errors.html#err_2)
-:link(err_3,Section_errors.html#err_3)
-
-:link(hist_1,Section_history.html#hist_1)
-:link(hist_2,Section_history.html#hist_2)
-<!-- END_HTML_ONLY -->
-
-</BODY>

doc/README

@@ -0,0 +1,115 @@
+LAMMPS Documentation
+
+Depending on how you obtained LAMMPS, this directory has 2 or 3
+sub-directories and optionally 2 PDF files and an ePUB file:
+
+src             content files for LAMMPS documentation
+html            HTML version of the LAMMPS manual (see html/Manual.html)
+tools           tools and settings for building the documentation
+Manual.pdf      large PDF version of entire manual
+Developer.pdf   small PDF with info about how LAMMPS is structured
+LAMMPS.epub     Manual in ePUB format
+
+If you downloaded LAMMPS as a tarball from the web site, all these
+directories and files should be included.
+
+If you downloaded LAMMPS from the public SVN or Git repositories, then
+the HTML and PDF files are not included.  Instead you need to create
+them, in one of three ways:
+
+(a) You can "fetch" the current HTML and PDF files from the LAMMPS web
+site.  Just type "make fetch".  This should create a html_www dir and
+Manual_www.pdf/Developer_www.pdf files.  Note that if new LAMMPS
+features have been added more recently than the date of your version,
+the fetched documentation will include those changes (but your source
+code will not, unless you update your local repository).
+
+(b) You can build the HTML and PDF files yourself, by typing "make
+html" followed by "make pdf".  Note that the PDF make requires the
+HTML files already exist.  This requires various tools including
+Sphinx, which the build process will attempt to download and install
+on your system, if not already available.  See more details below.
+
+(c) You can genererate an older, simpler, less-fancy style of HTML
+documentation by typing "make old".  This will create an "old"
+directory.  This can be useful if (b) does not work on your box for
+some reason, or you want to quickly view the HTML version of a doc
+page you have created or edited yourself within the src directory.
+E.g. if you are planning to submit a new feature to LAMMPS.
+
+----------------
+
+The generation of all documentation is managed by the Makefile in this
+dir.
+
+Options:
+
+make html         # generate HTML in html dir using Sphinx
+make pdf          # generate 2 PDF files (Manual.pdf,Developer.pdf)
+                  #   in this dir via htmldoc and pdflatex
+make old          # generate old-style HTML pages in old dir via txt2html
+make fetch        # fetch HTML doc pages and 2 PDF files from web site
+                  #   as a tarball and unpack into html dir and 2 PDFs
+make epub         # generate LAMMPS.epub in ePUB format using Sphinx 
+make clean        # remove intermediate RST files created by HTML build
+make clean-all    # remove entire build folder and any cached data
+
+----------------
+
+Installing prerequisites for HTML build
+
+To run the HTML documention build toolchain, Python 3 and virtualenv
+have to be installed.  Here are instructions for common setups:
+
+# Ubuntu
+
+sudo apt-get install python-virtualenv
+
+# Fedora (up to version 21)
+# Red Hat Enterprise Linux or CentOS (up to version 7.x)
+
+sudo yum install python3-virtualenv
+
+# Fedora (since version 22)
+
+sudo dnf install python3-virtualenv
+
+# MacOS X
+
+## Python 3
+
+Download the latest Python 3 MacOS X package from
+https://www.python.org and install it.  This will install both Python
+3 and pip3.
+
+## virtualenv
+
+Once Python 3 is installed, open a Terminal and type
+
+pip3 install virtualenv
+
+This will install virtualenv from the Python Package Index.
+
+----------------
+
+Installing prerequisites for PDF build
+
+[TBA]
+
+----------------
+
+Installing prerequisites for epub build
+
+## ePUB
+
+Same as for HTML. This uses the same tools and configuration
+files as the HTML tree.
+
+For converting the generated ePUB file to a mobi format file
+(for e-book readers like Kindle, that cannot read ePUB), you
+also need to have the 'ebook-convert' tool from the "calibre"
+software installed. http://calibre-ebook.com/
+You first create the ePUB file with 'make epub' and then do:
+
+ebook-convert LAMMPS.epub LAMMPS.mobi
+

doc/Scripts/correlate.py

@@ -1,89 +0,0 @@
-#!/usr/bin/env python
-"""
-  function: 
-    parse the block of thermo data in a lammps logfile and perform auto- and 
-    cross correlation of the specified column data.  The total sum of the 
-    correlation is also computed which can be converted to an integral by 
-    multiplying by the timestep. 
-  output:
-    standard output contains column data for the auto- & cross correlations 
-    plus the total sum of each. Note, only the upper triangle of the 
-    correlation matrix is computed.
-  usage: 
-    correlate.py [-c col] <-c col2> <-s max_correlation_time>  [logfile] 
-"""
-import sys
-import re
-import array
-
-# parse command line
-
-maxCorrelationTime = 0
-cols = array.array("I")
-nCols = 0
-args = sys.argv[1:]
-index = 0
-while index < len(args):
-  arg = args[index]
-  index += 1
-  if   (arg == "-c"):
-    cols.append(int(args[index])-1)
-    nCols += 1
-    index += 1
-  elif (arg == "-s"):
-    maxCorrelationTime = int(args[index])
-    index += 1
-  else :
-    filename = arg
-if (nCols < 1): raise RuntimeError, 'no data columns requested'
-data = [array.array("d")]
-for s in range(1,nCols)  : data.append( array.array("d") )
-
-# read data block from log file
-
-start = False
-input = open(filename)
-nSamples = 0
-pattern = re.compile('\d')
-line = input.readline()
-while line :
-  columns = line.split()
-  if (columns and pattern.match(columns[0])) :
-    for i in range(nCols): 
-      data[i].append( float(columns[cols[i]]) )
-    nSamples += 1
-    start = True
-  else :
-     if (start) : break
-  line = input.readline()
-print "# read :",nSamples," samples of ", nCols," data"
-if( maxCorrelationTime < 1): maxCorrelationTime = int(nSamples/2);
- 
-# correlate and integrate
-
-correlationPairs = []
-for i in range(0,nCols):
-  for j in range(i,nCols): # note only upper triangle of the correlation matrix
-    correlationPairs.append([i,j])
-header = "# "
-for k in range(len(correlationPairs)):
-  i = str(correlationPairs[k][0]+1)
-  j = str(correlationPairs[k][1]+1)
-  header += " C"+i+j+" sum_C"+i+j
-print header
-nCorrelationPairs = len(correlationPairs)
-sum = [0.0] * nCorrelationPairs
-for s in range(maxCorrelationTime)  :
-  correlation = [0.0] * nCorrelationPairs
-  nt = nSamples-s
-  for t in range(0,nt)  :
-    for p in range(nCorrelationPairs):
-      i = correlationPairs[p][0]
-      j = correlationPairs[p][1]
-      correlation[p] += data[i][t]*data[j][s+t]
-  output = ""
-  for p in range(0,nCorrelationPairs):
-    correlation[p] /= nt
-    sum[p] += correlation[p]
-    output += str(correlation[p]) + " " + str(sum[p]) + " "
-  print output

doc/Section_accelerate.html

@@ -1,642 +0,0 @@
-
-
-<!DOCTYPE html>
-<!--[if IE 8]><html class="no-js lt-ie9" lang="en" > <![endif]-->
-<!--[if gt IE 8]><!--> <html class="no-js" lang="en" > <!--<![endif]-->
-<head>
-  <meta charset="utf-8">
-  
-  <meta name="viewport" content="width=device-width, initial-scale=1.0">
-  
-  <title>5. Accelerating LAMMPS performance &mdash; LAMMPS documentation</title>
-  
-
-  
-  
-
-  
-
-  
-  
-    
-
-  
-
-  
-  
-    <link rel="stylesheet" href="_static/css/theme.css" type="text/css" />
-  
-
-  
-    <link rel="stylesheet" href="_static/sphinxcontrib-images/LightBox2/lightbox2/css/lightbox.css" type="text/css" />
-  
-
-  
-    <link rel="top" title="LAMMPS documentation" href="index.html"/>
-        <link rel="next" title="6. How-to discussions" href="Section_howto.html"/>
-        <link rel="prev" title="4. Packages" href="Section_packages.html"/> 
-
-  
-  <script src="_static/js/modernizr.min.js"></script>
-
-</head>
-
-<body class="wy-body-for-nav" role="document">
-
-  <div class="wy-grid-for-nav">
-
-    
-    <nav data-toggle="wy-nav-shift" class="wy-nav-side">
-      <div class="wy-side-nav-search">
-        
-
-        
-          <a href="Manual.html" class="icon icon-home"> LAMMPS
-        
-
-        
-        </a>
-
-        
-<div role="search">
-  <form id="rtd-search-form" class="wy-form" action="search.html" method="get">
-    <input type="text" name="q" placeholder="Search docs" />
-    <input type="hidden" name="check_keywords" value="yes" />
-    <input type="hidden" name="area" value="default" />
-  </form>
-</div>
-
-        
-      </div>
-
-      <div class="wy-menu wy-menu-vertical" data-spy="affix" role="navigation" aria-label="main navigation">
-        
-          
-          
-              <ul class="current">
-<li class="toctree-l1"><a class="reference internal" href="Section_intro.html">1. Introduction</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_start.html">2. Getting Started</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_commands.html">3. Commands</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_packages.html">4. Packages</a></li>
-<li class="toctree-l1 current"><a class="current reference internal" href="">5. Accelerating LAMMPS performance</a><ul>
-<li class="toctree-l2"><a class="reference internal" href="#measuring-performance">5.1. Measuring performance</a></li>
-<li class="toctree-l2"><a class="reference internal" href="#general-strategies">5.2. General strategies</a></li>
-<li class="toctree-l2"><a class="reference internal" href="#packages-with-optimized-styles">5.3. Packages with optimized styles</a></li>
-<li class="toctree-l2"><a class="reference internal" href="#comparison-of-various-accelerator-packages">5.4. Comparison of various accelerator packages</a><ul>
-<li class="toctree-l3"><a class="reference internal" href="#examples">5.4.1. Examples</a></li>
-</ul>
-</li>
-</ul>
-</li>
-<li class="toctree-l1"><a class="reference internal" href="Section_howto.html">6. How-to discussions</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_example.html">7. Example problems</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_perf.html">8. Performance &amp; scalability</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_tools.html">9. Additional tools</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_modify.html">10. Modifying &amp; extending LAMMPS</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_python.html">11. Python interface to LAMMPS</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_errors.html">12. Errors</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_history.html">13. Future and history</a></li>
-</ul>
-
-          
-        
-      </div>
-      &nbsp;
-    </nav>
-
-    <section data-toggle="wy-nav-shift" class="wy-nav-content-wrap">
-
-      
-      <nav class="wy-nav-top" role="navigation" aria-label="top navigation">
-        <i data-toggle="wy-nav-top" class="fa fa-bars"></i>
-        <a href="Manual.html">LAMMPS</a>
-      </nav>
-
-
-      
-      <div class="wy-nav-content">
-        <div class="rst-content">
-          <div role="navigation" aria-label="breadcrumbs navigation">
-  <ul class="wy-breadcrumbs">
-    <li><a href="Manual.html">Docs</a> &raquo;</li>
-      
-    <li>5. Accelerating LAMMPS performance</li>
-      <li class="wy-breadcrumbs-aside">
-        
-          
-            <a href="http://lammps.sandia.gov">Website</a>
-            <a href="Section_commands.html#comm">Commands</a>
-        
-      </li>
-  </ul>
-  <hr/>
-  
-    <div class="rst-footer-buttons" style="margin-bottom: 1em" role="navigation" aria-label="footer navigation">
-      
-        <a href="Section_howto.html" class="btn btn-neutral float-right" title="6. How-to discussions" accesskey="n">Next <span class="fa fa-arrow-circle-right"></span></a>
-      
-      
-        <a href="Section_packages.html" class="btn btn-neutral" title="4. Packages" accesskey="p"><span class="fa fa-arrow-circle-left"></span> Previous</a>
-      
-    </div>
-  
-</div>
-          <div role="main" class="document" itemscope="itemscope" itemtype="http://schema.org/Article">
-           <div itemprop="articleBody">
-            
-  <div class="section" id="accelerating-lammps-performance">
-<h1>5. Accelerating LAMMPS performance<a class="headerlink" href="#accelerating-lammps-performance" title="Permalink to this headline">¶</a></h1>
-<p>This section describes various methods for improving LAMMPS
-performance for different classes of problems running on different
-kinds of machines.</p>
-<p>There are two thrusts to the discussion that follows.  The
-first is using code options that implement alternate algorithms
-that can speed-up a simulation.  The second is to use one
-of the several accelerator packages provided with LAMMPS that
-contain code optimized for certain kinds of hardware, including
-multi-core CPUs, GPUs, and Intel Xeon Phi coprocessors.</p>
-<ul class="simple">
-<li>5.1 <a class="reference internal" href="#acc-1"><span>Measuring performance</span></a></li>
-<li>5.2 <a class="reference internal" href="#acc-2"><span>Algorithms and code options to boost performace</span></a></li>
-<li>5.3 <a class="reference internal" href="#acc-3"><span>Accelerator packages with optimized styles</span></a></li>
-<li>5.3.1 <a class="reference internal" href="accelerate_cuda.html"><em>USER-CUDA package</em></a></li>
-<li>5.3.2 <a class="reference internal" href="accelerate_gpu.html"><em>GPU package</em></a></li>
-<li>5.3.3 <a class="reference internal" href="accelerate_intel.html"><em>USER-INTEL package</em></a></li>
-<li>5.3.4 <a class="reference internal" href="accelerate_kokkos.html"><em>KOKKOS package</em></a></li>
-<li>5.3.5 <a class="reference internal" href="accelerate_omp.html"><em>USER-OMP package</em></a></li>
-<li>5.3.6 <a class="reference internal" href="accelerate_opt.html"><em>OPT package</em></a></li>
-<li>5.4 <a class="reference internal" href="#acc-4"><span>Comparison of various accelerator packages</span></a></li>
-</ul>
-<p>The <a class="reference external" href="http://lammps.sandia.gov/bench.html">Benchmark page</a> of the LAMMPS
-web site gives performance results for the various accelerator
-packages discussed in Section 5.2, for several of the standard LAMMPS
-benchmark problems, as a function of problem size and number of
-compute nodes, on different hardware platforms.</p>
-<div class="section" id="measuring-performance">
-<span id="acc-1"></span><h2>5.1. Measuring performance<a class="headerlink" href="#measuring-performance" title="Permalink to this headline">¶</a></h2>
-<p>Before trying to make your simulation run faster, you should
-understand how it currently performs and where the bottlenecks are.</p>
-<p>The best way to do this is run the your system (actual number of
-atoms) for a modest number of timesteps (say 100 steps) on several
-different processor counts, including a single processor if possible.
-Do this for an equilibrium version of your system, so that the
-100-step timings are representative of a much longer run.  There is
-typically no need to run for 1000s of timesteps to get accurate
-timings; you can simply extrapolate from short runs.</p>
-<p>For the set of runs, look at the timing data printed to the screen and
-log file at the end of each LAMMPS run.  <a class="reference internal" href="Section_start.html#start-8"><span>This section</span></a> of the manual has an overview.</p>
-<p>Running on one (or a few processors) should give a good estimate of
-the serial performance and what portions of the timestep are taking
-the most time.  Running the same problem on a few different processor
-counts should give an estimate of parallel scalability.  I.e. if the
-simulation runs 16x faster on 16 processors, its 100% parallel
-efficient; if it runs 8x faster on 16 processors, it&#8217;s 50% efficient.</p>
-<p>The most important data to look at in the timing info is the timing
-breakdown and relative percentages.  For example, trying different
-options for speeding up the long-range solvers will have little impact
-if they only consume 10% of the run time.  If the pairwise time is
-dominating, you may want to look at GPU or OMP versions of the pair
-style, as discussed below.  Comparing how the percentages change as
-you increase the processor count gives you a sense of how different
-operations within the timestep are scaling.  Note that if you are
-running with a Kspace solver, there is additional output on the
-breakdown of the Kspace time.  For PPPM, this includes the fraction
-spent on FFTs, which can be communication intensive.</p>
-<p>Another important detail in the timing info are the histograms of
-atoms counts and neighbor counts.  If these vary widely across
-processors, you have a load-imbalance issue.  This often results in
-inaccurate relative timing data, because processors have to wait when
-communication occurs for other processors to catch up.  Thus the
-reported times for &#8220;Communication&#8221; or &#8220;Other&#8221; may be higher than they
-really are, due to load-imbalance.  If this is an issue, you can
-uncomment the MPI_Barrier() lines in src/timer.cpp, and recompile
-LAMMPS, to obtain synchronized timings.</p>
-<hr class="docutils" />
-</div>
-<div class="section" id="general-strategies">
-<span id="acc-2"></span><h2>5.2. General strategies<a class="headerlink" href="#general-strategies" title="Permalink to this headline">¶</a></h2>
-<div class="admonition note">
-<p class="first admonition-title">Note</p>
-<p class="last">this section 5.2 is still a work in progress</p>
-</div>
-<p>Here is a list of general ideas for improving simulation performance.
-Most of them are only applicable to certain models and certain
-bottlenecks in the current performance, so let the timing data you
-generate be your guide.  It is hard, if not impossible, to predict how
-much difference these options will make, since it is a function of
-problem size, number of processors used, and your machine.  There is
-no substitute for identifying performance bottlenecks, and trying out
-various options.</p>
-<ul class="simple">
-<li>rRESPA</li>
-<li>2-FFT PPPM</li>
-<li>Staggered PPPM</li>
-<li>single vs double PPPM</li>
-<li>partial charge PPPM</li>
-<li>verlet/split run style</li>
-<li>processor command for proc layout and numa layout</li>
-<li>load-balancing: balance and fix balance</li>
-</ul>
-<p>2-FFT PPPM, also called <em>analytic differentiation</em> or <em>ad</em> PPPM, uses
-2 FFTs instead of the 4 FFTs used by the default <em>ik differentiation</em>
-PPPM. However, 2-FFT PPPM also requires a slightly larger mesh size to
-achieve the same accuracy as 4-FFT PPPM. For problems where the FFT
-cost is the performance bottleneck (typically large problems running
-on many processors), 2-FFT PPPM may be faster than 4-FFT PPPM.</p>
-<p>Staggered PPPM performs calculations using two different meshes, one
-shifted slightly with respect to the other.  This can reduce force
-aliasing errors and increase the accuracy of the method, but also
-doubles the amount of work required. For high relative accuracy, using
-staggered PPPM allows one to half the mesh size in each dimension as
-compared to regular PPPM, which can give around a 4x speedup in the
-kspace time. However, for low relative accuracy, using staggered PPPM
-gives little benefit and can be up to 2x slower in the kspace
-time. For example, the rhodopsin benchmark was run on a single
-processor, and results for kspace time vs. relative accuracy for the
-different methods are shown in the figure below.  For this system,
-staggered PPPM (using ik differentiation) becomes useful when using a
-relative accuracy of slightly greater than 1e-5 and above.</p>
-<img alt="_images/rhodo_staggered.jpg" class="align-center" src="_images/rhodo_staggered.jpg" />
-<div class="admonition note">
-<p class="first admonition-title">Note</p>
-<p class="last">Using staggered PPPM may not give the same increase in accuracy
-of energy and pressure as it does in forces, so some caution must be
-used if energy and/or pressure are quantities of interest, such as
-when using a barostat.</p>
-</div>
-<hr class="docutils" />
-</div>
-<div class="section" id="packages-with-optimized-styles">
-<span id="acc-3"></span><h2>5.3. Packages with optimized styles<a class="headerlink" href="#packages-with-optimized-styles" title="Permalink to this headline">¶</a></h2>
-<p>Accelerated versions of various <a class="reference internal" href="pair_style.html"><em>pair_style</em></a>,
-<a class="reference internal" href="fix.html"><em>fixes</em></a>, <a class="reference internal" href="compute.html"><em>computes</em></a>, and other commands have
-been added to LAMMPS, which will typically run faster than the
-standard non-accelerated versions.  Some require appropriate hardware
-to be present on your system, e.g. GPUs or Intel Xeon Phi
-coprocessors.</p>
-<p>All of these commands are in packages provided with LAMMPS.  An
-overview of packages is give in <a class="reference internal" href="Section_packages.html"><em>Section packages</em></a>.</p>
-<p>These are the accelerator packages
-currently in LAMMPS, either as standard or user packages:</p>
-<table border="1" class="docutils">
-<colgroup>
-<col width="44%" />
-<col width="56%" />
-</colgroup>
-<tbody valign="top">
-<tr class="row-odd"><td><a class="reference internal" href="accelerate_cuda.html"><em>USER-CUDA</em></a></td>
-<td>for NVIDIA GPUs</td>
-</tr>
-<tr class="row-even"><td><a class="reference internal" href="accelerate_gpu.html"><em>GPU</em></a></td>
-<td>for NVIDIA GPUs as well as OpenCL support</td>
-</tr>
-<tr class="row-odd"><td><a class="reference internal" href="accelerate_intel.html"><em>USER-INTEL</em></a></td>
-<td>for Intel CPUs and Intel Xeon Phi</td>
-</tr>
-<tr class="row-even"><td><a class="reference internal" href="accelerate_kokkos.html"><em>KOKKOS</em></a></td>
-<td>for GPUs, Intel Xeon Phi, and OpenMP threading</td>
-</tr>
-<tr class="row-odd"><td><a class="reference internal" href="accelerate_omp.html"><em>USER-OMP</em></a></td>
-<td>for OpenMP threading</td>
-</tr>
-<tr class="row-even"><td><a class="reference internal" href="accelerate_opt.html"><em>OPT</em></a></td>
-<td>generic CPU optimizations</td>
-</tr>
-</tbody>
-</table>
-<p>Inverting this list, LAMMPS currently has acceleration support for
-three kinds of hardware, via the listed packages:</p>
-<table border="1" class="docutils">
-<colgroup>
-<col width="10%" />
-<col width="90%" />
-</colgroup>
-<tbody valign="top">
-<tr class="row-odd"><td>Many-core CPUs</td>
-<td><a class="reference internal" href="accelerate_intel.html"><em>USER-INTEL</em></a>, <a class="reference internal" href="accelerate_kokkos.html"><em>KOKKOS</em></a>, <a class="reference internal" href="accelerate_omp.html"><em>USER-OMP</em></a>, <a class="reference internal" href="accelerate_opt.html"><em>OPT</em></a> packages</td>
-</tr>
-<tr class="row-even"><td>NVIDIA GPUs</td>
-<td><a class="reference internal" href="accelerate_cuda.html"><em>USER-CUDA</em></a>, <a class="reference internal" href="accelerate_gpu.html"><em>GPU</em></a>, <a class="reference internal" href="accelerate_kokkos.html"><em>KOKKOS</em></a> packages</td>
-</tr>
-<tr class="row-odd"><td>Intel Phi</td>
-<td><a class="reference internal" href="accelerate_intel.html"><em>USER-INTEL</em></a>, <a class="reference internal" href="accelerate_kokkos.html"><em>KOKKOS</em></a> packages</td>
-</tr>
-</tbody>
-</table>
-<p>Which package is fastest for your hardware may depend on the size
-problem you are running and what commands (accelerated and
-non-accelerated) are invoked by your input script.  While these doc
-pages include performance guidelines, there is no substitute for
-trying out the different packages appropriate to your hardware.</p>
-<p>Any accelerated style has the same name as the corresponding standard
-style, except that a suffix is appended.  Otherwise, the syntax for
-the command that uses the style is identical, their functionality is
-the same, and the numerical results it produces should also be the
-same, except for precision and round-off effects.</p>
-<p>For example, all of these styles are accelerated variants of the
-Lennard-Jones <a class="reference internal" href="pair_lj.html"><em>pair_style lj/cut</em></a>:</p>
-<ul class="simple">
-<li><a class="reference internal" href="pair_lj.html"><em>pair_style lj/cut/cuda</em></a></li>
-<li><a class="reference internal" href="pair_lj.html"><em>pair_style lj/cut/gpu</em></a></li>
-<li><a class="reference internal" href="pair_lj.html"><em>pair_style lj/cut/intel</em></a></li>
-<li><a class="reference internal" href="pair_lj.html"><em>pair_style lj/cut/kk</em></a></li>
-<li><a class="reference internal" href="pair_lj.html"><em>pair_style lj/cut/omp</em></a></li>
-<li><a class="reference internal" href="pair_lj.html"><em>pair_style lj/cut/opt</em></a></li>
-</ul>
-<p>To see what accelerate styles are currently available, see
-<a class="reference internal" href="Section_commands.html#cmd-5"><span>Section_commands 5</span></a> of the manual.  The
-doc pages for individual commands (e.g. <a class="reference internal" href="pair_lj.html"><em>pair lj/cut</em></a> or
-<a class="reference internal" href="fix_nve.html"><em>fix nve</em></a>) also list any accelerated variants available
-for that style.</p>
-<p>To use an accelerator package in LAMMPS, and one or more of the styles
-it provides, follow these general steps.  Details vary from package to
-package and are explained in the individual accelerator doc pages,
-listed above:</p>
-<table border="1" class="docutils">
-<colgroup>
-<col width="26%" />
-<col width="74%" />
-</colgroup>
-<tbody valign="top">
-<tr class="row-odd"><td>build the accelerator library</td>
-<td>only for USER-CUDA and GPU packages</td>
-</tr>
-<tr class="row-even"><td>install the accelerator package</td>
-<td>make yes-opt, make yes-user-intel, etc</td>
-</tr>
-</tbody>
-</table>
-<div class="line-block">
-<div class="line">install the accelerator package             | make yes-opt, make yes-user-intel, etc                                                                                           |</div>
-</div>
-<blockquote>
-<div>only for USER-INTEL, KOKKOS, USER-OMP, OPT packages                                                          |</div></blockquote>
-<table border="1" class="docutils">
-<colgroup>
-<col width="26%" />
-<col width="74%" />
-</colgroup>
-<tbody valign="top">
-<tr class="row-odd"><td>re-build LAMMPS</td>
-<td>make machine</td>
-</tr>
-</tbody>
-</table>
-<div class="line-block">
-<div class="line">re-build LAMMPS                             | make machine                                                                                                                     |</div>
-</div>
-<blockquote>
-<div>mpirun -np 32 lmp_machine -in in.script                                                          |</div></blockquote>
-<blockquote>
-<div>only for USER-CUDA and KOKKOS packages                    |</div></blockquote>
-<blockquote>
-<div><a class="reference internal" href="package.html"><em>package</em></a> command, &lt;br&gt;
-only if defaults need to be changed |</div></blockquote>
-<blockquote>
-<div><a class="reference internal" href="suffix.html"><em>suffix</em></a> command                                               |</div></blockquote>
-<table border="1" class="docutils">
-<colgroup>
-</colgroup>
-<tbody valign="top">
-</tbody>
-</table>
-<p>Note that the first 4 steps can be done as a single command, using the
-src/Make.py tool.  This tool is discussed in <a class="reference internal" href="Section_start.html#start-4"><span>Section 2.4</span></a> of the manual, and its use is
-illustrated in the individual accelerator sections.  Typically these
-steps only need to be done once, to create an executable that uses one
-or more accelerator packages.</p>
-<p>The last 4 steps can all be done from the command-line when LAMMPS is
-launched, without changing your input script, as illustrated in the
-individual accelerator sections.  Or you can add
-<a class="reference internal" href="package.html"><em>package</em></a> and <a class="reference internal" href="suffix.html"><em>suffix</em></a> commands to your input
-script.</p>
-<div class="admonition note">
-<p class="first admonition-title">Note</p>
-<p class="last">With a few exceptions, you can build a single LAMMPS executable
-with all its accelerator packages installed.  Note however that the
-USER-INTEL and KOKKOS packages require you to choose one of their
-hardware options when building for a specific platform.  I.e. CPU or
-Phi option for the USER-INTEL package.  Or the OpenMP, Cuda, or Phi
-option for the KOKKOS package.</p>
-</div>
-<p>These are the exceptions.  You cannot build a single executable with:</p>
-<ul class="simple">
-<li>both the USER-INTEL Phi and KOKKOS Phi options</li>
-<li>the USER-INTEL Phi or Kokkos Phi option, and either the USER-CUDA or GPU packages</li>
-</ul>
-<p>See the examples/accelerate/README and make.list files for sample
-Make.py commands that build LAMMPS with any or all of the accelerator
-packages.  As an example, here is a command that builds with all the
-GPU related packages installed (USER-CUDA, GPU, KOKKOS with Cuda),
-including settings to build the needed auxiliary USER-CUDA and GPU
-libraries for Kepler GPUs:</p>
-<pre class="literal-block">
-Make.py -j 16 -p omp gpu cuda kokkos -cc nvcc wrap=mpi   -cuda mode=double arch=35 -gpu mode=double arch=35  -kokkos cuda arch=35 lib-all file mpi
-</pre>
-<p>The examples/accelerate directory also has input scripts that can be
-used with all of the accelerator packages.  See its README file for
-details.</p>
-<p>Likewise, the bench directory has FERMI and KEPLER and PHI
-sub-directories with Make.py commands and input scripts for using all
-the accelerator packages on various machines.  See the README files in
-those dirs.</p>
-<p>As mentioned above, the <a class="reference external" href="http://lammps.sandia.gov/bench.html">Benchmark page</a> of the LAMMPS web site gives
-performance results for the various accelerator packages for several
-of the standard LAMMPS benchmark problems, as a function of problem
-size and number of compute nodes, on different hardware platforms.</p>
-<p>Here is a brief summary of what the various packages provide.  Details
-are in the individual accelerator sections.</p>
-<ul class="simple">
-<li>Styles with a &#8220;cuda&#8221; or &#8220;gpu&#8221; suffix are part of the USER-CUDA or GPU
-packages, and can be run on NVIDIA GPUs.  The speed-up on a GPU
-depends on a variety of factors, discussed in the accelerator
-sections.</li>
-<li>Styles with an &#8220;intel&#8221; suffix are part of the USER-INTEL
-package. These styles support vectorized single and mixed precision
-calculations, in addition to full double precision.  In extreme cases,
-this can provide speedups over 3.5x on CPUs.  The package also
-supports acceleration in &#8220;offload&#8221; mode to Intel(R) Xeon Phi(TM)
-coprocessors.  This can result in additional speedup over 2x depending
-on the hardware configuration.</li>
-<li>Styles with a &#8220;kk&#8221; suffix are part of the KOKKOS package, and can be
-run using OpenMP on multicore CPUs, on an NVIDIA GPU, or on an Intel
-Xeon Phi in &#8220;native&#8221; mode.  The speed-up depends on a variety of
-factors, as discussed on the KOKKOS accelerator page.</li>
-<li>Styles with an &#8220;omp&#8221; suffix are part of the USER-OMP package and allow
-a pair-style to be run in multi-threaded mode using OpenMP.  This can
-be useful on nodes with high-core counts when using less MPI processes
-than cores is advantageous, e.g. when running with PPPM so that FFTs
-are run on fewer MPI processors or when the many MPI tasks would
-overload the available bandwidth for communication.</li>
-<li>Styles with an &#8220;opt&#8221; suffix are part of the OPT package and typically
-speed-up the pairwise calculations of your simulation by 5-25% on a
-CPU.</li>
-</ul>
-<p>The individual accelerator package doc pages explain:</p>
-<ul class="simple">
-<li>what hardware and software the accelerated package requires</li>
-<li>how to build LAMMPS with the accelerated package</li>
-<li>how to run with the accelerated package either via command-line switches or modifying the input script</li>
-<li>speed-ups to expect</li>
-<li>guidelines for best performance</li>
-<li>restrictions</li>
-</ul>
-<hr class="docutils" />
-</div>
-<div class="section" id="comparison-of-various-accelerator-packages">
-<span id="acc-4"></span><h2>5.4. Comparison of various accelerator packages<a class="headerlink" href="#comparison-of-various-accelerator-packages" title="Permalink to this headline">¶</a></h2>
-<div class="admonition note">
-<p class="first admonition-title">Note</p>
-<p class="last">this section still needs to be re-worked with additional KOKKOS
-and USER-INTEL information.</p>
-</div>
-<p>The next section compares and contrasts the various accelerator
-options, since there are multiple ways to perform OpenMP threading,
-run on GPUs, and run on Intel Xeon Phi coprocessors.</p>
-<p>All 3 of these packages accelerate a LAMMPS calculation using NVIDIA
-hardware, but they do it in different ways.</p>
-<p>As a consequence, for a particular simulation on specific hardware,
-one package may be faster than the other.  We give guidelines below,
-but the best way to determine which package is faster for your input
-script is to try both of them on your machine.  See the benchmarking
-section below for examples where this has been done.</p>
-<p><strong>Guidelines for using each package optimally:</strong></p>
-<ul class="simple">
-<li>The GPU package allows you to assign multiple CPUs (cores) to a single
-GPU (a common configuration for &#8220;hybrid&#8221; nodes that contain multicore
-CPU(s) and GPU(s)) and works effectively in this mode.  The USER-CUDA
-package does not allow this; you can only use one CPU per GPU.</li>
-<li>The GPU package moves per-atom data (coordinates, forces)
-back-and-forth between the CPU and GPU every timestep.  The USER-CUDA
-package only does this on timesteps when a CPU calculation is required
-(e.g. to invoke a fix or compute that is non-GPU-ized).  Hence, if you
-can formulate your input script to only use GPU-ized fixes and
-computes, and avoid doing I/O too often (thermo output, dump file
-snapshots, restart files), then the data transfer cost of the
-USER-CUDA package can be very low, causing it to run faster than the
-GPU package.</li>
-<li>The GPU package is often faster than the USER-CUDA package, if the
-number of atoms per GPU is smaller.  The crossover point, in terms of
-atoms/GPU at which the USER-CUDA package becomes faster depends
-strongly on the pair style.  For example, for a simple Lennard Jones
-system the crossover (in single precision) is often about 50K-100K
-atoms per GPU.  When performing double precision calculations the
-crossover point can be significantly smaller.</li>
-<li>Both packages compute bonded interactions (bonds, angles, etc) on the
-CPU.  This means a model with bonds will force the USER-CUDA package
-to transfer per-atom data back-and-forth between the CPU and GPU every
-timestep.  If the GPU package is running with several MPI processes
-assigned to one GPU, the cost of computing the bonded interactions is
-spread across more CPUs and hence the GPU package can run faster.</li>
-<li>When using the GPU package with multiple CPUs assigned to one GPU, its
-performance depends to some extent on high bandwidth between the CPUs
-and the GPU.  Hence its performance is affected if full 16 PCIe lanes
-are not available for each GPU.  In HPC environments this can be the
-case if S2050/70 servers are used, where two devices generally share
-one PCIe 2.0 16x slot.  Also many multi-GPU mainboards do not provide
-full 16 lanes to each of the PCIe 2.0 16x slots.</li>
-</ul>
-<p><strong>Differences between the two packages:</strong></p>
-<ul class="simple">
-<li>The GPU package accelerates only pair force, neighbor list, and PPPM
-calculations.  The USER-CUDA package currently supports a wider range
-of pair styles and can also accelerate many fix styles and some
-compute styles, as well as neighbor list and PPPM calculations.</li>
-<li>The USER-CUDA package does not support acceleration for minimization.</li>
-<li>The USER-CUDA package does not support hybrid pair styles.</li>
-<li>The USER-CUDA package can order atoms in the neighbor list differently
-from run to run resulting in a different order for force accumulation.</li>
-<li>The USER-CUDA package has a limit on the number of atom types that can be
-used in a simulation.</li>
-<li>The GPU package requires neighbor lists to be built on the CPU when using
-exclusion lists or a triclinic simulation box.</li>
-<li>The GPU package uses more GPU memory than the USER-CUDA package.  This
-is generally not a problem since typical runs are computation-limited
-rather than memory-limited.</li>
-</ul>
-<div class="section" id="examples">
-<h3>5.4.1. Examples<a class="headerlink" href="#examples" title="Permalink to this headline">¶</a></h3>
-<p>The LAMMPS distribution has two directories with sample input scripts
-for the GPU and USER-CUDA packages.</p>
-<ul class="simple">
-<li>lammps/examples/gpu = GPU package files</li>
-<li>lammps/examples/USER/cuda = USER-CUDA package files</li>
-</ul>
-<p>These contain input scripts for identical systems, so they can be used
-to benchmark the performance of both packages on your system.</p>
-</div>
-</div>
-</div>
-
-
-           </div>
-          </div>
-          <footer>
-  
-    <div class="rst-footer-buttons" role="navigation" aria-label="footer navigation">
-      
-        <a href="Section_howto.html" class="btn btn-neutral float-right" title="6. How-to discussions" accesskey="n">Next <span class="fa fa-arrow-circle-right"></span></a>
-      
-      
-        <a href="Section_packages.html" class="btn btn-neutral" title="4. Packages" accesskey="p"><span class="fa fa-arrow-circle-left"></span> Previous</a>
-      
-    </div>
-  
-
-  <hr/>
-
-  <div role="contentinfo">
-    <p>
-        &copy; Copyright 2013 Sandia Corporation.
-    </p>
-  </div>
-  Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
-
-</footer>
-
-        </div>
-      </div>
-
-    </section>
-
-  </div>
-  
-
-
-  
-
-    <script type="text/javascript">
-        var DOCUMENTATION_OPTIONS = {
-            URL_ROOT:'./',
-            VERSION:'',
-            COLLAPSE_INDEX:false,
-            FILE_SUFFIX:'.html',
-            HAS_SOURCE:  true
-        };
-    </script>
-      <script type="text/javascript" src="_static/jquery.js"></script>
-      <script type="text/javascript" src="_static/underscore.js"></script>
-      <script type="text/javascript" src="_static/doctools.js"></script>
-      <script type="text/javascript" src="https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>
-      <script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/jquery-1.11.0.min.js"></script>
-      <script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/lightbox.min.js"></script>
-      <script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2-customize/jquery-noconflict.js"></script>
-
-  
-
-  
-  
-    <script type="text/javascript" src="_static/js/theme.js"></script>
-  
-
-  
-  
-  <script type="text/javascript">
-      jQuery(function () {
-          SphinxRtdTheme.StickyNav.enable();
-      });
-  </script>
-   
-
-</body>
-</html>

doc/Section_accelerate.txt

@@ -1,415 +0,0 @@
-"Previous Section"_Section_packages.html - "LAMMPS WWW Site"_lws -
-"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
-Section"_Section_howto.html :c
-
-:link(lws,http://lammps.sandia.gov)
-:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
-
-:line
-
-5. Accelerating LAMMPS performance :h3
-
-This section describes various methods for improving LAMMPS
-performance for different classes of problems running on different
-kinds of machines.
-
-There are two thrusts to the discussion that follows.  The
-first is using code options that implement alternate algorithms
-that can speed-up a simulation.  The second is to use one
-of the several accelerator packages provided with LAMMPS that
-contain code optimized for certain kinds of hardware, including
-multi-core CPUs, GPUs, and Intel Xeon Phi coprocessors.
-
-5.1 "Measuring performance"_#acc_1 :ulb,l
-5.2 "Algorithms and code options to boost performace"_#acc_2 :l
-5.3 "Accelerator packages with optimized styles"_#acc_3 :l
-    5.3.1 "USER-CUDA package"_accelerate_cuda.html :ulb,l
-    5.3.2 "GPU package"_accelerate_gpu.html :l
-    5.3.3 "USER-INTEL package"_accelerate_intel.html :l
-    5.3.4 "KOKKOS package"_accelerate_kokkos.html :l
-    5.3.5 "USER-OMP package"_accelerate_omp.html :l
-    5.3.6 "OPT package"_accelerate_opt.html :l,ule
-5.4 "Comparison of various accelerator packages"_#acc_4 :l,ule
-
-The "Benchmark page"_http://lammps.sandia.gov/bench.html of the LAMMPS
-web site gives performance results for the various accelerator
-packages discussed in Section 5.2, for several of the standard LAMMPS
-benchmark problems, as a function of problem size and number of
-compute nodes, on different hardware platforms.
-
-:line
-:line
-
-5.1 Measuring performance :h4,link(acc_1)
-
-Before trying to make your simulation run faster, you should
-understand how it currently performs and where the bottlenecks are.
-
-The best way to do this is run the your system (actual number of
-atoms) for a modest number of timesteps (say 100 steps) on several
-different processor counts, including a single processor if possible.
-Do this for an equilibrium version of your system, so that the
-100-step timings are representative of a much longer run.  There is
-typically no need to run for 1000s of timesteps to get accurate
-timings; you can simply extrapolate from short runs.
-
-For the set of runs, look at the timing data printed to the screen and
-log file at the end of each LAMMPS run.  "This
-section"_Section_start.html#start_8 of the manual has an overview.
-
-Running on one (or a few processors) should give a good estimate of
-the serial performance and what portions of the timestep are taking
-the most time.  Running the same problem on a few different processor
-counts should give an estimate of parallel scalability.  I.e. if the
-simulation runs 16x faster on 16 processors, its 100% parallel
-efficient; if it runs 8x faster on 16 processors, it's 50% efficient.
-
-The most important data to look at in the timing info is the timing
-breakdown and relative percentages.  For example, trying different
-options for speeding up the long-range solvers will have little impact
-if they only consume 10% of the run time.  If the pairwise time is
-dominating, you may want to look at GPU or OMP versions of the pair
-style, as discussed below.  Comparing how the percentages change as
-you increase the processor count gives you a sense of how different
-operations within the timestep are scaling.  Note that if you are
-running with a Kspace solver, there is additional output on the
-breakdown of the Kspace time.  For PPPM, this includes the fraction
-spent on FFTs, which can be communication intensive.
-
-Another important detail in the timing info are the histograms of
-atoms counts and neighbor counts.  If these vary widely across
-processors, you have a load-imbalance issue.  This often results in
-inaccurate relative timing data, because processors have to wait when
-communication occurs for other processors to catch up.  Thus the
-reported times for "Communication" or "Other" may be higher than they
-really are, due to load-imbalance.  If this is an issue, you can
-uncomment the MPI_Barrier() lines in src/timer.cpp, and recompile
-LAMMPS, to obtain synchronized timings.
-
-:line
-
-5.2 General strategies :h4,link(acc_2)
-
-NOTE: this section 5.2 is still a work in progress
-
-Here is a list of general ideas for improving simulation performance.
-Most of them are only applicable to certain models and certain
-bottlenecks in the current performance, so let the timing data you
-generate be your guide.  It is hard, if not impossible, to predict how
-much difference these options will make, since it is a function of
-problem size, number of processors used, and your machine.  There is
-no substitute for identifying performance bottlenecks, and trying out
-various options.
-
-rRESPA
-2-FFT PPPM
-Staggered PPPM
-single vs double PPPM
-partial charge PPPM
-verlet/split run style
-processor command for proc layout and numa layout
-load-balancing: balance and fix balance :ul
-
-2-FFT PPPM, also called {analytic differentiation} or {ad} PPPM, uses
-2 FFTs instead of the 4 FFTs used by the default {ik differentiation}
-PPPM. However, 2-FFT PPPM also requires a slightly larger mesh size to
-achieve the same accuracy as 4-FFT PPPM. For problems where the FFT
-cost is the performance bottleneck (typically large problems running
-on many processors), 2-FFT PPPM may be faster than 4-FFT PPPM.
-  
-Staggered PPPM performs calculations using two different meshes, one
-shifted slightly with respect to the other.  This can reduce force
-aliasing errors and increase the accuracy of the method, but also
-doubles the amount of work required. For high relative accuracy, using
-staggered PPPM allows one to half the mesh size in each dimension as
-compared to regular PPPM, which can give around a 4x speedup in the
-kspace time. However, for low relative accuracy, using staggered PPPM
-gives little benefit and can be up to 2x slower in the kspace
-time. For example, the rhodopsin benchmark was run on a single
-processor, and results for kspace time vs. relative accuracy for the
-different methods are shown in the figure below.  For this system,
-staggered PPPM (using ik differentiation) becomes useful when using a
-relative accuracy of slightly greater than 1e-5 and above.
-
-:c,image(JPG/rhodo_staggered.jpg)
-
-NOTE: Using staggered PPPM may not give the same increase in accuracy
-of energy and pressure as it does in forces, so some caution must be
-used if energy and/or pressure are quantities of interest, such as
-when using a barostat.
-
-:line
-
-5.3 Packages with optimized styles :h4,link(acc_3)
-
-Accelerated versions of various "pair_style"_pair_style.html,
-"fixes"_fix.html, "computes"_compute.html, and other commands have
-been added to LAMMPS, which will typically run faster than the
-standard non-accelerated versions.  Some require appropriate hardware
-to be present on your system, e.g. GPUs or Intel Xeon Phi
-coprocessors.
-
-All of these commands are in packages provided with LAMMPS.  An
-overview of packages is give in "Section
-packages"_Section_packages.html.
-
-These are the accelerator packages
-currently in LAMMPS, either as standard or user packages:
-
-"USER-CUDA"_accelerate_cuda.html : for NVIDIA GPUs
-"GPU"_accelerate_gpu.html : for NVIDIA GPUs as well as OpenCL support
-"USER-INTEL"_accelerate_intel.html : for Intel CPUs and Intel Xeon Phi
-"KOKKOS"_accelerate_kokkos.html : for GPUs, Intel Xeon Phi, and OpenMP threading
-"USER-OMP"_accelerate_omp.html : for OpenMP threading
-"OPT"_accelerate_opt.html : generic CPU optimizations :tb(s=:)
-
-Inverting this list, LAMMPS currently has acceleration support for
-three kinds of hardware, via the listed packages:
-
-Many-core CPUs : "USER-INTEL"_accelerate_intel.html, "KOKKOS"_accelerate_kokkos.html, "USER-OMP"_accelerate_omp.html, "OPT"_accelerate_opt.html packages
-NVIDIA GPUs : "USER-CUDA"_accelerate_cuda.html, "GPU"_accelerate_gpu.html, "KOKKOS"_accelerate_kokkos.html packages
-Intel Phi : "USER-INTEL"_accelerate_intel.html, "KOKKOS"_accelerate_kokkos.html packages :tb(s=:)
-
-Which package is fastest for your hardware may depend on the size
-problem you are running and what commands (accelerated and
-non-accelerated) are invoked by your input script.  While these doc
-pages include performance guidelines, there is no substitute for
-trying out the different packages appropriate to your hardware.
-
-Any accelerated style has the same name as the corresponding standard
-style, except that a suffix is appended.  Otherwise, the syntax for
-the command that uses the style is identical, their functionality is
-the same, and the numerical results it produces should also be the
-same, except for precision and round-off effects.
-
-For example, all of these styles are accelerated variants of the
-Lennard-Jones "pair_style lj/cut"_pair_lj.html:
-
-"pair_style lj/cut/cuda"_pair_lj.html
-"pair_style lj/cut/gpu"_pair_lj.html
-"pair_style lj/cut/intel"_pair_lj.html
-"pair_style lj/cut/kk"_pair_lj.html
-"pair_style lj/cut/omp"_pair_lj.html
-"pair_style lj/cut/opt"_pair_lj.html :ul
-
-To see what accelerate styles are currently available, see
-"Section_commands 5"_Section_commands.html#cmd_5 of the manual.  The
-doc pages for individual commands (e.g. "pair lj/cut"_pair_lj.html or
-"fix nve"_fix_nve.html) also list any accelerated variants available
-for that style.
-
-To use an accelerator package in LAMMPS, and one or more of the styles
-it provides, follow these general steps.  Details vary from package to
-package and are explained in the individual accelerator doc pages,
-listed above:
-
-build the accelerator library |
-  only for USER-CUDA and GPU packages |
-install the accelerator package |
-  make yes-opt, make yes-user-intel, etc |
-add compile/link flags to Makefile.machine |
-  in src/MAKE, <br>
-  only for USER-INTEL, KOKKOS, USER-OMP, OPT packages |
-re-build LAMMPS |
-  make machine |
-run a LAMMPS simulation |
-  lmp_machine < in.script <br> 
-  mpirun -np 32 lmp_machine -in in.script |
-enable the accelerator package |
-  via "-c on" and "-k on" "command-line switches"_Section_start.html#start_7, <br>
-  only for USER-CUDA and KOKKOS packages |
-set any needed options for the package |
-  via "-pk" "command-line switch"_Section_start.html#start_7 or
-  "package"_package.html command, <br>
-  only if defaults need to be changed |
-use accelerated styles in your input script |
-  via "-sf" "command-line switch"_Section_start.html#start_7 or
-  "suffix"_suffix.html command :tb(c=2,s=|)
-
-Note that the first 4 steps can be done as a single command, using the
-src/Make.py tool.  This tool is discussed in "Section
-2.4"_Section_start.html#start_4 of the manual, and its use is
-illustrated in the individual accelerator sections.  Typically these
-steps only need to be done once, to create an executable that uses one
-or more accelerator packages.
-
-The last 4 steps can all be done from the command-line when LAMMPS is
-launched, without changing your input script, as illustrated in the
-individual accelerator sections.  Or you can add
-"package"_package.html and "suffix"_suffix.html commands to your input
-script.
-
-NOTE: With a few exceptions, you can build a single LAMMPS executable
-with all its accelerator packages installed.  Note however that the
-USER-INTEL and KOKKOS packages require you to choose one of their
-hardware options when building for a specific platform.  I.e. CPU or
-Phi option for the USER-INTEL package.  Or the OpenMP, Cuda, or Phi
-option for the KOKKOS package.
-
-These are the exceptions.  You cannot build a single executable with:
-
-both the USER-INTEL Phi and KOKKOS Phi options
-the USER-INTEL Phi or Kokkos Phi option, and either the USER-CUDA or GPU packages :ul
-
-See the examples/accelerate/README and make.list files for sample
-Make.py commands that build LAMMPS with any or all of the accelerator
-packages.  As an example, here is a command that builds with all the
-GPU related packages installed (USER-CUDA, GPU, KOKKOS with Cuda),
-including settings to build the needed auxiliary USER-CUDA and GPU
-libraries for Kepler GPUs:
-
-Make.py -j 16 -p omp gpu cuda kokkos -cc nvcc wrap=mpi \
-  -cuda mode=double arch=35 -gpu mode=double arch=35 \\
-  -kokkos cuda arch=35 lib-all file mpi :pre
-
-The examples/accelerate directory also has input scripts that can be
-used with all of the accelerator packages.  See its README file for
-details.
-
-Likewise, the bench directory has FERMI and KEPLER and PHI
-sub-directories with Make.py commands and input scripts for using all
-the accelerator packages on various machines.  See the README files in
-those dirs.
-
-As mentioned above, the "Benchmark
-page"_http://lammps.sandia.gov/bench.html of the LAMMPS web site gives
-performance results for the various accelerator packages for several
-of the standard LAMMPS benchmark problems, as a function of problem
-size and number of compute nodes, on different hardware platforms.
-
-Here is a brief summary of what the various packages provide.  Details
-are in the individual accelerator sections.
-
-Styles with a "cuda" or "gpu" suffix are part of the USER-CUDA or GPU
-packages, and can be run on NVIDIA GPUs.  The speed-up on a GPU
-depends on a variety of factors, discussed in the accelerator
-sections. :ulb,l
-
-Styles with an "intel" suffix are part of the USER-INTEL
-package. These styles support vectorized single and mixed precision
-calculations, in addition to full double precision.  In extreme cases,
-this can provide speedups over 3.5x on CPUs.  The package also
-supports acceleration in "offload" mode to Intel(R) Xeon Phi(TM)
-coprocessors.  This can result in additional speedup over 2x depending
-on the hardware configuration. :l
-
-Styles with a "kk" suffix are part of the KOKKOS package, and can be
-run using OpenMP on multicore CPUs, on an NVIDIA GPU, or on an Intel
-Xeon Phi in "native" mode.  The speed-up depends on a variety of
-factors, as discussed on the KOKKOS accelerator page. :l
-
-Styles with an "omp" suffix are part of the USER-OMP package and allow
-a pair-style to be run in multi-threaded mode using OpenMP.  This can
-be useful on nodes with high-core counts when using less MPI processes
-than cores is advantageous, e.g. when running with PPPM so that FFTs
-are run on fewer MPI processors or when the many MPI tasks would
-overload the available bandwidth for communication. :l
-
-Styles with an "opt" suffix are part of the OPT package and typically
-speed-up the pairwise calculations of your simulation by 5-25% on a
-CPU. :l,ule
-
-The individual accelerator package doc pages explain:
-
-what hardware and software the accelerated package requires
-how to build LAMMPS with the accelerated package
-how to run with the accelerated package either via command-line switches or modifying the input script
-speed-ups to expect
-guidelines for best performance
-restrictions :ul
-
-:line
-
-5.4 Comparison of various accelerator packages :h4,link(acc_4)
-
-NOTE: this section still needs to be re-worked with additional KOKKOS
-and USER-INTEL information.
-
-The next section compares and contrasts the various accelerator
-options, since there are multiple ways to perform OpenMP threading,
-run on GPUs, and run on Intel Xeon Phi coprocessors.
-
-All 3 of these packages accelerate a LAMMPS calculation using NVIDIA
-hardware, but they do it in different ways.
-
-As a consequence, for a particular simulation on specific hardware,
-one package may be faster than the other.  We give guidelines below,
-but the best way to determine which package is faster for your input
-script is to try both of them on your machine.  See the benchmarking
-section below for examples where this has been done.
-
-[Guidelines for using each package optimally:]
-
-The GPU package allows you to assign multiple CPUs (cores) to a single
-GPU (a common configuration for "hybrid" nodes that contain multicore
-CPU(s) and GPU(s)) and works effectively in this mode.  The USER-CUDA
-package does not allow this; you can only use one CPU per GPU. :ulb,l
-
-The GPU package moves per-atom data (coordinates, forces)
-back-and-forth between the CPU and GPU every timestep.  The USER-CUDA
-package only does this on timesteps when a CPU calculation is required
-(e.g. to invoke a fix or compute that is non-GPU-ized).  Hence, if you
-can formulate your input script to only use GPU-ized fixes and
-computes, and avoid doing I/O too often (thermo output, dump file
-snapshots, restart files), then the data transfer cost of the
-USER-CUDA package can be very low, causing it to run faster than the
-GPU package. :l
-
-The GPU package is often faster than the USER-CUDA package, if the
-number of atoms per GPU is smaller.  The crossover point, in terms of
-atoms/GPU at which the USER-CUDA package becomes faster depends
-strongly on the pair style.  For example, for a simple Lennard Jones
-system the crossover (in single precision) is often about 50K-100K
-atoms per GPU.  When performing double precision calculations the
-crossover point can be significantly smaller. :l
-
-Both packages compute bonded interactions (bonds, angles, etc) on the
-CPU.  This means a model with bonds will force the USER-CUDA package
-to transfer per-atom data back-and-forth between the CPU and GPU every
-timestep.  If the GPU package is running with several MPI processes
-assigned to one GPU, the cost of computing the bonded interactions is
-spread across more CPUs and hence the GPU package can run faster. :l
-
-When using the GPU package with multiple CPUs assigned to one GPU, its
-performance depends to some extent on high bandwidth between the CPUs
-and the GPU.  Hence its performance is affected if full 16 PCIe lanes
-are not available for each GPU.  In HPC environments this can be the
-case if S2050/70 servers are used, where two devices generally share
-one PCIe 2.0 16x slot.  Also many multi-GPU mainboards do not provide
-full 16 lanes to each of the PCIe 2.0 16x slots. :l,ule
-
-[Differences between the two packages:]
-
-The GPU package accelerates only pair force, neighbor list, and PPPM
-calculations.  The USER-CUDA package currently supports a wider range
-of pair styles and can also accelerate many fix styles and some
-compute styles, as well as neighbor list and PPPM calculations. :ulb,l
-
-The USER-CUDA package does not support acceleration for minimization. :l
-
-The USER-CUDA package does not support hybrid pair styles. :l
-
-The USER-CUDA package can order atoms in the neighbor list differently
-from run to run resulting in a different order for force accumulation. :l
-
-The USER-CUDA package has a limit on the number of atom types that can be
-used in a simulation. :l
-
-The GPU package requires neighbor lists to be built on the CPU when using
-exclusion lists or a triclinic simulation box. :l
-
-The GPU package uses more GPU memory than the USER-CUDA package.  This
-is generally not a problem since typical runs are computation-limited
-rather than memory-limited. :l,ule
-
-[Examples:]
-
-The LAMMPS distribution has two directories with sample input scripts
-for the GPU and USER-CUDA packages.
-
-lammps/examples/gpu = GPU package files
-lammps/examples/USER/cuda = USER-CUDA package files :ul
-
-These contain input scripts for identical systems, so they can be used
-to benchmark the performance of both packages on your system.

doc/Section_example.html

@@ -1,401 +0,0 @@
-
-
-<!DOCTYPE html>
-<!--[if IE 8]><html class="no-js lt-ie9" lang="en" > <![endif]-->
-<!--[if gt IE 8]><!--> <html class="no-js" lang="en" > <!--<![endif]-->
-<head>
-  <meta charset="utf-8">
-  
-  <meta name="viewport" content="width=device-width, initial-scale=1.0">
-  
-  <title>7. Example problems &mdash; LAMMPS documentation</title>
-  
-
-  
-  
-
-  
-
-  
-  
-    
-
-  
-
-  
-  
-    <link rel="stylesheet" href="_static/css/theme.css" type="text/css" />
-  
-
-  
-    <link rel="stylesheet" href="_static/sphinxcontrib-images/LightBox2/lightbox2/css/lightbox.css" type="text/css" />
-  
-
-  
-    <link rel="top" title="LAMMPS documentation" href="index.html"/>
-        <link rel="next" title="8. Performance &amp; scalability" href="Section_perf.html"/>
-        <link rel="prev" title="6. How-to discussions" href="Section_howto.html"/> 
-
-  
-  <script src="_static/js/modernizr.min.js"></script>
-
-</head>
-
-<body class="wy-body-for-nav" role="document">
-
-  <div class="wy-grid-for-nav">
-
-    
-    <nav data-toggle="wy-nav-shift" class="wy-nav-side">
-      <div class="wy-side-nav-search">
-        
-
-        
-          <a href="Manual.html" class="icon icon-home"> LAMMPS
-        
-
-        
-        </a>
-
-        
-<div role="search">
-  <form id="rtd-search-form" class="wy-form" action="search.html" method="get">
-    <input type="text" name="q" placeholder="Search docs" />
-    <input type="hidden" name="check_keywords" value="yes" />
-    <input type="hidden" name="area" value="default" />
-  </form>
-</div>
-
-        
-      </div>
-
-      <div class="wy-menu wy-menu-vertical" data-spy="affix" role="navigation" aria-label="main navigation">
-        
-          
-          
-              <ul class="current">
-<li class="toctree-l1"><a class="reference internal" href="Section_intro.html">1. Introduction</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_start.html">2. Getting Started</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_commands.html">3. Commands</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_packages.html">4. Packages</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_accelerate.html">5. Accelerating LAMMPS performance</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_howto.html">6. How-to discussions</a></li>
-<li class="toctree-l1 current"><a class="current reference internal" href="">7. Example problems</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_perf.html">8. Performance &amp; scalability</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_tools.html">9. Additional tools</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_modify.html">10. Modifying &amp; extending LAMMPS</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_python.html">11. Python interface to LAMMPS</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_errors.html">12. Errors</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_history.html">13. Future and history</a></li>
-</ul>
-
-          
-        
-      </div>
-      &nbsp;
-    </nav>
-
-    <section data-toggle="wy-nav-shift" class="wy-nav-content-wrap">
-
-      
-      <nav class="wy-nav-top" role="navigation" aria-label="top navigation">
-        <i data-toggle="wy-nav-top" class="fa fa-bars"></i>
-        <a href="Manual.html">LAMMPS</a>
-      </nav>
-
-
-      
-      <div class="wy-nav-content">
-        <div class="rst-content">
-          <div role="navigation" aria-label="breadcrumbs navigation">
-  <ul class="wy-breadcrumbs">
-    <li><a href="Manual.html">Docs</a> &raquo;</li>
-      
-    <li>7. Example problems</li>
-      <li class="wy-breadcrumbs-aside">
-        
-          
-            <a href="http://lammps.sandia.gov">Website</a>
-            <a href="Section_commands.html#comm">Commands</a>
-        
-      </li>
-  </ul>
-  <hr/>
-  
-    <div class="rst-footer-buttons" style="margin-bottom: 1em" role="navigation" aria-label="footer navigation">
-      
-        <a href="Section_perf.html" class="btn btn-neutral float-right" title="8. Performance &amp; scalability" accesskey="n">Next <span class="fa fa-arrow-circle-right"></span></a>
-      
-      
-        <a href="Section_howto.html" class="btn btn-neutral" title="6. How-to discussions" accesskey="p"><span class="fa fa-arrow-circle-left"></span> Previous</a>
-      
-    </div>
-  
-</div>
-          <div role="main" class="document" itemscope="itemscope" itemtype="http://schema.org/Article">
-           <div itemprop="articleBody">
-            
-  <div class="section" id="example-problems">
-<h1>7. Example problems<a class="headerlink" href="#example-problems" title="Permalink to this headline">¶</a></h1>
-<p>The LAMMPS distribution includes an examples sub-directory with
-several sample problems.  Each problem is in a sub-directory of its
-own.  Most are 2d models so that they run quickly, requiring at most a
-couple of minutes to run on a desktop machine.  Each problem has an
-input script (in.*) and produces a log file (log.*) and dump file
-(dump.*) when it runs.  Some use a data file (data.*) of initial
-coordinates as additional input.  A few sample log file outputs on
-different machines and different numbers of processors are included in
-the directories to compare your answers to.  E.g. a log file like
-log.crack.foo.P means it ran on P processors of machine &#8220;foo&#8221;.</p>
-<p>For examples that use input data files, many of them were produced by
-<a class="reference external" href="http://pizza.sandia.gov">Pizza.py</a> or setup tools described in the
-<a class="reference internal" href="Section_tools.html"><em>Additional Tools</em></a> section of the LAMMPS
-documentation and provided with the LAMMPS distribution.</p>
-<p>If you uncomment the <a class="reference internal" href="dump.html"><em>dump</em></a> command in the input script, a
-text dump file will be produced, which can be animated by various
-<a class="reference external" href="http://lammps.sandia.gov/viz.html">visualization programs</a>.  It can
-also be animated using the xmovie tool described in the <a class="reference internal" href="Section_tools.html"><em>Additional Tools</em></a> section of the LAMMPS documentation.</p>
-<p>If you uncomment the <a class="reference internal" href="dump.html"><em>dump image</em></a> command in the input
-script, and assuming you have built LAMMPS with a JPG library, JPG
-snapshot images will be produced when the simulation runs.  They can
-be quickly post-processed into a movie using commands described on the
-<a class="reference internal" href="dump_image.html"><em>dump image</em></a> doc page.</p>
-<p>Animations of many of these examples can be viewed on the Movies
-section of the <a class="reference external" href="http://lammps.sandia.gov">LAMMPS WWW Site</a>.</p>
-<p>These are the sample problems in the examples sub-directories:</p>
-<table border="1" class="docutils">
-<colgroup>
-<col width="15%" />
-<col width="85%" />
-</colgroup>
-<tbody valign="top">
-<tr class="row-odd"><td>balance</td>
-<td>dynamic load balancing, 2d system</td>
-</tr>
-<tr class="row-even"><td>body</td>
-<td>body particles, 2d system</td>
-</tr>
-<tr class="row-odd"><td>colloid</td>
-<td>big colloid particles in a small particle solvent, 2d system</td>
-</tr>
-<tr class="row-even"><td>comb</td>
-<td>models using the COMB potential</td>
-</tr>
-<tr class="row-odd"><td>crack</td>
-<td>crack propagation in a 2d solid</td>
-</tr>
-<tr class="row-even"><td>cuda</td>
-<td>use of the USER-CUDA package for GPU acceleration</td>
-</tr>
-<tr class="row-odd"><td>dipole</td>
-<td>point dipolar particles, 2d system</td>
-</tr>
-<tr class="row-even"><td>dreiding</td>
-<td>methanol via Dreiding FF</td>
-</tr>
-<tr class="row-odd"><td>eim</td>
-<td>NaCl using the EIM potential</td>
-</tr>
-<tr class="row-even"><td>ellipse</td>
-<td>ellipsoidal particles in spherical solvent, 2d system</td>
-</tr>
-<tr class="row-odd"><td>flow</td>
-<td>Couette and Poiseuille flow in a 2d channel</td>
-</tr>
-<tr class="row-even"><td>friction</td>
-<td>frictional contact of spherical asperities between 2d surfaces</td>
-</tr>
-<tr class="row-odd"><td>gpu</td>
-<td>use of the GPU package for GPU acceleration</td>
-</tr>
-<tr class="row-even"><td>hugoniostat</td>
-<td>Hugoniostat shock dynamics</td>
-</tr>
-<tr class="row-odd"><td>indent</td>
-<td>spherical indenter into a 2d solid</td>
-</tr>
-<tr class="row-even"><td>intel</td>
-<td>use of the USER-INTEL package for CPU or Intel(R) Xeon Phi(TM) coprocessor</td>
-</tr>
-<tr class="row-odd"><td>kim</td>
-<td>use of potentials in Knowledge Base for Interatomic Models (KIM)</td>
-</tr>
-<tr class="row-even"><td>line</td>
-<td>line segment particles in 2d rigid bodies</td>
-</tr>
-<tr class="row-odd"><td>meam</td>
-<td>MEAM test for SiC and shear (same as shear examples)</td>
-</tr>
-<tr class="row-even"><td>melt</td>
-<td>rapid melt of 3d LJ system</td>
-</tr>
-<tr class="row-odd"><td>micelle</td>
-<td>self-assembly of small lipid-like molecules into 2d bilayers</td>
-</tr>
-<tr class="row-even"><td>min</td>
-<td>energy minimization of 2d LJ melt</td>
-</tr>
-<tr class="row-odd"><td>msst</td>
-<td>MSST shock dynamics</td>
-</tr>
-<tr class="row-even"><td>nb3b</td>
-<td>use of nonbonded 3-body harmonic pair style</td>
-</tr>
-<tr class="row-odd"><td>neb</td>
-<td>nudged elastic band (NEB) calculation for barrier finding</td>
-</tr>
-<tr class="row-even"><td>nemd</td>
-<td>non-equilibrium MD of 2d sheared system</td>
-</tr>
-<tr class="row-odd"><td>obstacle</td>
-<td>flow around two voids in a 2d channel</td>
-</tr>
-<tr class="row-even"><td>peptide</td>
-<td>dynamics of a small solvated peptide chain (5-mer)</td>
-</tr>
-<tr class="row-odd"><td>peri</td>
-<td>Peridynamic model of cylinder impacted by indenter</td>
-</tr>
-<tr class="row-even"><td>pour</td>
-<td>pouring of granular particles into a 3d box, then chute flow</td>
-</tr>
-<tr class="row-odd"><td>prd</td>
-<td>parallel replica dynamics of vacancy diffusion in bulk Si</td>
-</tr>
-<tr class="row-even"><td>qeq</td>
-<td>use of the QEQ pacakge for charge equilibration</td>
-</tr>
-<tr class="row-odd"><td>reax</td>
-<td>RDX and TATB models using the ReaxFF</td>
-</tr>
-<tr class="row-even"><td>rigid</td>
-<td>rigid bodies modeled as independent or coupled</td>
-</tr>
-<tr class="row-odd"><td>shear</td>
-<td>sideways shear applied to 2d solid, with and without a void</td>
-</tr>
-<tr class="row-even"><td>snap</td>
-<td>NVE dynamics for BCC tantalum crystal using SNAP potential</td>
-</tr>
-<tr class="row-odd"><td>srd</td>
-<td>stochastic rotation dynamics (SRD) particles as solvent</td>
-</tr>
-<tr class="row-even"><td>tad</td>
-<td>temperature-accelerated dynamics of vacancy diffusion in bulk Si</td>
-</tr>
-<tr class="row-odd"><td>tri</td>
-<td>triangular particles in rigid bodies</td>
-</tr>
-</tbody>
-</table>
-<p>vashishta: models using the Vashishta potential</p>
-<p>Here is how you might run and visualize one of the sample problems:</p>
-<div class="highlight-python"><div class="highlight"><pre>cd indent
-cp ../../src/lmp_linux .           # copy LAMMPS executable to this dir
-lmp_linux -in in.indent            # run the problem
-</pre></div>
-</div>
-<p>Running the simulation produces the files <em>dump.indent</em> and
-<em>log.lammps</em>.  You can visualize the dump file as follows:</p>
-<div class="highlight-python"><div class="highlight"><pre>../../tools/xmovie/xmovie -scale dump.indent
-</pre></div>
-</div>
-<p>If you uncomment the <a class="reference internal" href="dump_image.html"><em>dump image</em></a> line(s) in the input
-script a series of JPG images will be produced by the run.  These can
-be viewed individually or turned into a movie or animated by tools
-like ImageMagick or QuickTime or various Windows-based tools.  See the
-<a class="reference internal" href="dump_image.html"><em>dump image</em></a> doc page for more details.  E.g. this
-Imagemagick command would create a GIF file suitable for viewing in a
-browser.</p>
-<div class="highlight-python"><div class="highlight"><pre>% convert -loop 1 *.jpg foo.gif
-</pre></div>
-</div>
-<hr class="docutils" />
-<p>There is also a COUPLE directory with examples of how to use LAMMPS as
-a library, either by itself or in tandem with another code or library.
-See the COUPLE/README file to get started.</p>
-<p>There is also an ELASTIC directory with an example script for
-computing elastic constants at zero temperature, using an Si example.  See
-the ELASTIC/in.elastic file for more info.</p>
-<p>There is also an ELASTIC_T directory with an example script for
-computing elastic constants at finite temperature, using an Si example.  See
-the ELASTIC_T/in.elastic file for more info.</p>
-<p>There is also a USER directory which contains subdirectories of
-user-provided examples for user packages.  See the README files in
-those directories for more info.  See the
-<a class="reference internal" href="Section_start.html"><em>Section_start.html</em></a> file for more info about user
-packages.</p>
-</div>
-
-
-           </div>
-          </div>
-          <footer>
-  
-    <div class="rst-footer-buttons" role="navigation" aria-label="footer navigation">
-      
-        <a href="Section_perf.html" class="btn btn-neutral float-right" title="8. Performance &amp; scalability" accesskey="n">Next <span class="fa fa-arrow-circle-right"></span></a>
-      
-      
-        <a href="Section_howto.html" class="btn btn-neutral" title="6. How-to discussions" accesskey="p"><span class="fa fa-arrow-circle-left"></span> Previous</a>
-      
-    </div>
-  
-
-  <hr/>
-
-  <div role="contentinfo">
-    <p>
-        &copy; Copyright 2013 Sandia Corporation.
-    </p>
-  </div>
-  Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
-
-</footer>
-
-        </div>
-      </div>
-
-    </section>
-
-  </div>
-  
-
-
-  
-
-    <script type="text/javascript">
-        var DOCUMENTATION_OPTIONS = {
-            URL_ROOT:'./',
-            VERSION:'',
-            COLLAPSE_INDEX:false,
-            FILE_SUFFIX:'.html',
-            HAS_SOURCE:  true
-        };
-    </script>
-      <script type="text/javascript" src="_static/jquery.js"></script>
-      <script type="text/javascript" src="_static/underscore.js"></script>
-      <script type="text/javascript" src="_static/doctools.js"></script>
-      <script type="text/javascript" src="https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>
-      <script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/jquery-1.11.0.min.js"></script>
-      <script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/lightbox.min.js"></script>
-      <script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2-customize/jquery-noconflict.js"></script>
-
-  
-
-  
-  
-    <script type="text/javascript" src="_static/js/theme.js"></script>
-  
-
-  
-  
-  <script type="text/javascript">
-      jQuery(function () {
-          SphinxRtdTheme.StickyNav.enable();
-      });
-  </script>
-   
-
-</body>
-</html>

doc/Section_example.txt

@@ -1,124 +0,0 @@
-"Previous Section"_Section_howto.html - "LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next Section"_Section_perf.html :c
-
-:link(lws,http://lammps.sandia.gov)
-:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
-
-:line
-
-7. Example problems :h3
-
-The LAMMPS distribution includes an examples sub-directory with
-several sample problems.  Each problem is in a sub-directory of its
-own.  Most are 2d models so that they run quickly, requiring at most a
-couple of minutes to run on a desktop machine.  Each problem has an
-input script (in.*) and produces a log file (log.*) and dump file
-(dump.*) when it runs.  Some use a data file (data.*) of initial
-coordinates as additional input.  A few sample log file outputs on
-different machines and different numbers of processors are included in
-the directories to compare your answers to.  E.g. a log file like
-log.crack.foo.P means it ran on P processors of machine "foo".
-
-For examples that use input data files, many of them were produced by
-"Pizza.py"_http://pizza.sandia.gov or setup tools described in the
-"Additional Tools"_Section_tools.html section of the LAMMPS
-documentation and provided with the LAMMPS distribution.
-
-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.
-
-If you uncomment the "dump image"_dump.html command in the input
-script, and assuming you have built LAMMPS with a JPG library, JPG
-snapshot images will be produced when the simulation runs.  They can
-be quickly post-processed into a movie using commands described on the
-"dump image"_dump_image.html doc page.
-
-Animations of many of these examples can be viewed on the Movies
-section of the "LAMMPS WWW Site"_lws.
-
-These are the sample problems in the examples sub-directories:
-
-balance:  dynamic load balancing, 2d system
-body:     body particles, 2d system
-colloid:  big colloid particles in a small particle solvent, 2d system
-comb:	  models using the COMB potential
-crack:	  crack propagation in a 2d solid
-cuda:     use of the USER-CUDA package for GPU acceleration
-dipole:   point dipolar particles, 2d system
-dreiding: methanol via Dreiding FF
-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
-gpu:      use of the GPU package for GPU acceleration
-hugoniostat: Hugoniostat shock dynamics
-indent:	  spherical indenter into a 2d solid
-intel:    use of the USER-INTEL package for CPU or Intel(R) Xeon Phi(TM) coprocessor
-kim:      use of potentials in Knowledge Base for Interatomic Models (KIM)
-line:     line segment particles in 2d rigid bodies
-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
-msst:	  MSST shock dynamics
-nb3b:     use of nonbonded 3-body harmonic pair style
-neb:	  nudged elastic band (NEB) calculation for barrier finding
-nemd:	  non-equilibrium MD of 2d sheared system
-obstacle: flow around two voids in a 2d channel
-peptide:  dynamics of a small solvated peptide chain (5-mer)
-peri:	  Peridynamic model of cylinder impacted by indenter
-pour:     pouring of granular particles into a 3d box, then chute flow
-prd:      parallel replica dynamics of vacancy diffusion in bulk Si
-qeq:      use of the QEQ pacakge for charge equilibration
-reax:     RDX and TATB models using the ReaxFF
-rigid:    rigid bodies modeled as independent or coupled
-shear:    sideways shear applied to 2d solid, with and without a void
-snap:     NVE dynamics for BCC tantalum crystal using SNAP potential
-srd:      stochastic rotation dynamics (SRD) particles as solvent
-tad:      temperature-accelerated dynamics of vacancy diffusion in bulk Si
-tri:      triangular particles in rigid bodies :tb(s=:)
-vashishta: models using the Vashishta potential
-
-Here is how you might run and visualize one of the sample problems:
-
-cd indent
-cp ../../src/lmp_linux .           # copy LAMMPS executable to this dir
-lmp_linux -in in.indent            # run the problem :pre
-
-Running the simulation produces the files {dump.indent} and
-{log.lammps}.  You can visualize the dump file as follows:
-
-../../tools/xmovie/xmovie -scale dump.indent :pre
-
-If you uncomment the "dump image"_dump_image.html line(s) in the input
-script a series of JPG images will be produced by the run.  These can
-be viewed individually or turned into a movie or animated by tools
-like ImageMagick or QuickTime or various Windows-based tools.  See the
-"dump image"_dump_image.html doc page for more details.  E.g. this
-Imagemagick command would create a GIF file suitable for viewing in a
-browser.
-
-% convert -loop 1 *.jpg foo.gif :pre
-
-:line
-
-There is also a COUPLE directory with examples of how to use LAMMPS as
-a library, either by itself or in tandem with another code or library.
-See the COUPLE/README file to get started.
-
-There is also an ELASTIC directory with an example script for
-computing elastic constants at zero temperature, using an Si example.  See
-the ELASTIC/in.elastic file for more info.
-
-There is also an ELASTIC_T directory with an example script for
-computing elastic constants at finite temperature, using an Si example.  See
-the ELASTIC_T/in.elastic file for more info.
-
-There is also a USER directory which contains subdirectories of
-user-provided examples for user packages.  See the README files in
-those directories for more info.  See the
-"Section_start.html"_Section_start.html file for more info about user
-packages.

doc/Section_history.html

@@ -1,313 +0,0 @@
-
-
-<!DOCTYPE html>
-<!--[if IE 8]><html class="no-js lt-ie9" lang="en" > <![endif]-->
-<!--[if gt IE 8]><!--> <html class="no-js" lang="en" > <!--<![endif]-->
-<head>
-  <meta charset="utf-8">
-  
-  <meta name="viewport" content="width=device-width, initial-scale=1.0">
-  
-  <title>13. Future and history &mdash; LAMMPS documentation</title>
-  
-
-  
-  
-
-  
-
-  
-  
-    
-
-  
-
-  
-  
-    <link rel="stylesheet" href="_static/css/theme.css" type="text/css" />
-  
-
-  
-    <link rel="stylesheet" href="_static/sphinxcontrib-images/LightBox2/lightbox2/css/lightbox.css" type="text/css" />
-  
-
-  
-    <link rel="top" title="LAMMPS documentation" href="index.html"/>
-        <link rel="prev" title="12. Errors" href="Section_errors.html"/> 
-
-  
-  <script src="_static/js/modernizr.min.js"></script>
-
-</head>
-
-<body class="wy-body-for-nav" role="document">
-
-  <div class="wy-grid-for-nav">
-
-    
-    <nav data-toggle="wy-nav-shift" class="wy-nav-side">
-      <div class="wy-side-nav-search">
-        
-
-        
-          <a href="Manual.html" class="icon icon-home"> LAMMPS
-        
-
-        
-        </a>
-
-        
-<div role="search">
-  <form id="rtd-search-form" class="wy-form" action="search.html" method="get">
-    <input type="text" name="q" placeholder="Search docs" />
-    <input type="hidden" name="check_keywords" value="yes" />
-    <input type="hidden" name="area" value="default" />
-  </form>
-</div>
-
-        
-      </div>
-
-      <div class="wy-menu wy-menu-vertical" data-spy="affix" role="navigation" aria-label="main navigation">
-        
-          
-          
-              <ul class="current">
-<li class="toctree-l1"><a class="reference internal" href="Section_intro.html">1. Introduction</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_start.html">2. Getting Started</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_commands.html">3. Commands</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_packages.html">4. Packages</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_accelerate.html">5. Accelerating LAMMPS performance</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_howto.html">6. How-to discussions</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_example.html">7. Example problems</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_perf.html">8. Performance &amp; scalability</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_tools.html">9. Additional tools</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_modify.html">10. Modifying &amp; extending LAMMPS</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_python.html">11. Python interface to LAMMPS</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_errors.html">12. Errors</a></li>
-<li class="toctree-l1 current"><a class="current reference internal" href="">13. Future and history</a><ul>
-<li class="toctree-l2"><a class="reference internal" href="#coming-attractions">13.1. Coming attractions</a></li>
-<li class="toctree-l2"><a class="reference internal" href="#past-versions">13.2. Past versions</a></li>
-</ul>
-</li>
-</ul>
-
-          
-        
-      </div>
-      &nbsp;
-    </nav>
-
-    <section data-toggle="wy-nav-shift" class="wy-nav-content-wrap">
-
-      
-      <nav class="wy-nav-top" role="navigation" aria-label="top navigation">
-        <i data-toggle="wy-nav-top" class="fa fa-bars"></i>
-        <a href="Manual.html">LAMMPS</a>
-      </nav>
-
-
-      
-      <div class="wy-nav-content">
-        <div class="rst-content">
-          <div role="navigation" aria-label="breadcrumbs navigation">
-  <ul class="wy-breadcrumbs">
-    <li><a href="Manual.html">Docs</a> &raquo;</li>
-      
-    <li>13. Future and history</li>
-      <li class="wy-breadcrumbs-aside">
-        
-          
-            <a href="http://lammps.sandia.gov">Website</a>
-            <a href="Section_commands.html#comm">Commands</a>
-        
-      </li>
-  </ul>
-  <hr/>
-  
-    <div class="rst-footer-buttons" style="margin-bottom: 1em" role="navigation" aria-label="footer navigation">
-      
-      
-        <a href="Section_errors.html" class="btn btn-neutral" title="12. Errors" accesskey="p"><span class="fa fa-arrow-circle-left"></span> Previous</a>
-      
-    </div>
-  
-</div>
-          <div role="main" class="document" itemscope="itemscope" itemtype="http://schema.org/Article">
-           <div itemprop="articleBody">
-            
-  <div class="section" id="future-and-history">
-<h1>13. Future and history<a class="headerlink" href="#future-and-history" title="Permalink to this headline">¶</a></h1>
-<p>This section lists features we plan to add to LAMMPS, features of
-previous versions of LAMMPS, and features of other parallel molecular
-dynamics codes our group has distributed.</p>
-<div class="line-block">
-<div class="line">13.1 <a class="reference internal" href="#hist-1"><span>Coming attractions</span></a></div>
-<div class="line">13.2 <a class="reference internal" href="#hist-2"><span>Past versions</span></a></div>
-<div class="line"><br /></div>
-</div>
-<div class="section" id="coming-attractions">
-<span id="hist-1"></span><h2>13.1. Coming attractions<a class="headerlink" href="#coming-attractions" title="Permalink to this headline">¶</a></h2>
-<p>The <a class="reference external" href="http://lammps.sandia.gov/future.html">Wish list link</a> on the
-LAMMPS WWW page gives a list of features we are hoping to add to
-LAMMPS in the future, including contact names of individuals you can
-email if you are interested in contributing to the developement or
-would be a future user of that feature.</p>
-<p>You can also send <a class="reference external" href="http://lammps.sandia.gov/authors.html">email to the developers</a> if you want to add
-your wish to the list.</p>
-<hr class="docutils" />
-</div>
-<div class="section" id="past-versions">
-<span id="hist-2"></span><h2>13.2. Past versions<a class="headerlink" href="#past-versions" title="Permalink to this headline">¶</a></h2>
-<p>LAMMPS development began in the mid 1990s under a cooperative research
-&amp; development agreement (CRADA) between two DOE labs (Sandia and LLNL)
-and 3 companies (Cray, Bristol Myers Squibb, and Dupont). The goal was
-to develop a large-scale parallel classical MD code; the coding effort
-was led by Steve Plimpton at Sandia.</p>
-<p>After the CRADA ended, a final F77 version, LAMMPS 99, was
-released. As development of LAMMPS continued at Sandia, its memory
-management was converted to F90; a final F90 version was released as
-LAMMPS 2001.</p>
-<p>The current LAMMPS is a rewrite in C++ and was first publicly released
-as an open source code in 2004. It includes many new features beyond
-those in LAMMPS 99 or 2001. It also includes features from older
-parallel MD codes written at Sandia, namely ParaDyn, Warp, and
-GranFlow (see below).</p>
-<p>In late 2006 we began merging new capabilities into LAMMPS that were
-developed by Aidan Thompson at Sandia for his MD code GRASP, which has
-a parallel framework similar to LAMMPS. Most notably, these have
-included many-body potentials - Stillinger-Weber, Tersoff, ReaxFF -
-and the associated charge-equilibration routines needed for ReaxFF.</p>
-<p>The <a class="reference external" href="http://lammps.sandia.gov/history.html">History link</a> on the
-LAMMPS WWW page gives a timeline of features added to the
-C++ open-source version of LAMMPS over the last several years.</p>
-<p>These older codes are available for download from the <a class="reference external" href="http://lammps.sandia.gov">LAMMPS WWW site</a>, except for Warp &amp; GranFlow which were primarily used
-internally.  A brief listing of their features is given here.</p>
-<p>LAMMPS 2001</p>
-<ul class="simple">
-<li>F90 + MPI</li>
-<li>dynamic memory</li>
-<li>spatial-decomposition parallelism</li>
-<li>NVE, NVT, NPT, NPH, rRESPA integrators</li>
-<li>LJ and Coulombic pairwise force fields</li>
-<li>all-atom, united-atom, bead-spring polymer force fields</li>
-<li>CHARMM-compatible force fields</li>
-<li>class 2 force fields</li>
-<li>3d/2d Ewald &amp; PPPM</li>
-<li>various force and temperature constraints</li>
-<li>SHAKE</li>
-<li>Hessian-free truncated-Newton minimizer</li>
-<li>user-defined diagnostics</li>
-</ul>
-<p>LAMMPS 99</p>
-<ul class="simple">
-<li>F77 + MPI</li>
-<li>static memory allocation</li>
-<li>spatial-decomposition parallelism</li>
-<li>most of the LAMMPS 2001 features with a few exceptions</li>
-<li>no 2d Ewald &amp; PPPM</li>
-<li>molecular force fields are missing a few CHARMM terms</li>
-<li>no SHAKE</li>
-</ul>
-<p>Warp</p>
-<ul class="simple">
-<li>F90 + MPI</li>
-<li>spatial-decomposition parallelism</li>
-<li>embedded atom method (EAM) metal potentials + LJ</li>
-<li>lattice and grain-boundary atom creation</li>
-<li>NVE, NVT integrators</li>
-<li>boundary conditions for applying shear stresses</li>
-<li>temperature controls for actively sheared systems</li>
-<li>per-atom energy and centro-symmetry computation and output</li>
-</ul>
-<p>ParaDyn</p>
-<ul class="simple">
-<li>F77 + MPI</li>
-<li>atom- and force-decomposition parallelism</li>
-<li>embedded atom method (EAM) metal potentials</li>
-<li>lattice atom creation</li>
-<li>NVE, NVT, NPT integrators</li>
-<li>all serial DYNAMO features for controls and constraints</li>
-</ul>
-<p>GranFlow</p>
-<ul class="simple">
-<li>F90 + MPI</li>
-<li>spatial-decomposition parallelism</li>
-<li>frictional granular potentials</li>
-<li>NVE integrator</li>
-<li>boundary conditions for granular flow and packing and walls</li>
-<li>particle insertion</li>
-</ul>
-</div>
-</div>
-
-
-           </div>
-          </div>
-          <footer>
-  
-    <div class="rst-footer-buttons" role="navigation" aria-label="footer navigation">
-      
-      
-        <a href="Section_errors.html" class="btn btn-neutral" title="12. Errors" accesskey="p"><span class="fa fa-arrow-circle-left"></span> Previous</a>
-      
-    </div>
-  
-
-  <hr/>
-
-  <div role="contentinfo">
-    <p>
-        &copy; Copyright 2013 Sandia Corporation.
-    </p>
-  </div>
-  Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
-
-</footer>
-
-        </div>
-      </div>
-
-    </section>
-
-  </div>
-  
-
-
-  
-
-    <script type="text/javascript">
-        var DOCUMENTATION_OPTIONS = {
-            URL_ROOT:'./',
-            VERSION:'',
-            COLLAPSE_INDEX:false,
-            FILE_SUFFIX:'.html',
-            HAS_SOURCE:  true
-        };
-    </script>
-      <script type="text/javascript" src="_static/jquery.js"></script>
-      <script type="text/javascript" src="_static/underscore.js"></script>
-      <script type="text/javascript" src="_static/doctools.js"></script>
-      <script type="text/javascript" src="https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>
-      <script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/jquery-1.11.0.min.js"></script>
-      <script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/lightbox.min.js"></script>
-      <script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2-customize/jquery-noconflict.js"></script>
-
-  
-
-  
-  
-    <script type="text/javascript" src="_static/js/theme.js"></script>
-  
-
-  
-  
-  <script type="text/javascript">
-      jQuery(function () {
-          SphinxRtdTheme.StickyNav.enable();
-      });
-  </script>
-   
-
-</body>
-</html>

doc/Section_history.txt

@@ -1,123 +0,0 @@
-"Previous Section"_Section_errors.html - "LAMMPS WWW Site"_lws -
-"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
-Section"_Manual.html :c
-
-:link(lws,http://lammps.sandia.gov)
-:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
-
-:line
-
-13. Future and history :h3
-
-This section lists features we plan to add to LAMMPS, features of
-previous versions of LAMMPS, and features of other parallel molecular
-dynamics codes our group has distributed.
-
-13.1 "Coming attractions"_#hist_1
-13.2 "Past versions"_#hist_2 :all(b)
-
-:line
-:line
-
-13.1 Coming attractions :h4,link(hist_1)
-
-The "Wish list link"_http://lammps.sandia.gov/future.html on the
-LAMMPS WWW page gives a list of features we are hoping to add to
-LAMMPS in the future, including contact names of individuals you can
-email if you are interested in contributing to the developement or
-would be a future user of that feature.
-
-You can also send "email to the
-developers"_http://lammps.sandia.gov/authors.html if you want to add
-your wish to the list.
-
-:line
-
-13.2 Past versions :h4,link(hist_2)
-
-LAMMPS development began in the mid 1990s under a cooperative research
-& development agreement (CRADA) between two DOE labs (Sandia and LLNL)
-and 3 companies (Cray, Bristol Myers Squibb, and Dupont). The goal was
-to develop a large-scale parallel classical MD code; the coding effort
-was led by Steve Plimpton at Sandia.
-
-After the CRADA ended, a final F77 version, LAMMPS 99, was
-released. As development of LAMMPS continued at Sandia, its memory
-management was converted to F90; a final F90 version was released as
-LAMMPS 2001.
-
-The current LAMMPS is a rewrite in C++ and was first publicly released
-as an open source code in 2004. It includes many new features beyond
-those in LAMMPS 99 or 2001. It also includes features from older
-parallel MD codes written at Sandia, namely ParaDyn, Warp, and
-GranFlow (see below).
-
-In late 2006 we began merging new capabilities into LAMMPS that were
-developed by Aidan Thompson at Sandia for his MD code GRASP, which has
-a parallel framework similar to LAMMPS. Most notably, these have
-included many-body potentials - Stillinger-Weber, Tersoff, ReaxFF -
-and the associated charge-equilibration routines needed for ReaxFF.
-
-The "History link"_http://lammps.sandia.gov/history.html on the 
-LAMMPS WWW page gives a timeline of features added to the
-C++ open-source version of LAMMPS over the last several years.
-
-These older codes are available for download from the "LAMMPS WWW
-site"_lws, except for Warp & GranFlow which were primarily used
-internally.  A brief listing of their features is given here.
-
-LAMMPS 2001
-    
-    F90 + MPI
-    dynamic memory
-    spatial-decomposition parallelism
-    NVE, NVT, NPT, NPH, rRESPA integrators
-    LJ and Coulombic pairwise force fields
-    all-atom, united-atom, bead-spring polymer force fields
-    CHARMM-compatible force fields
-    class 2 force fields
-    3d/2d Ewald & PPPM
-    various force and temperature constraints
-    SHAKE
-    Hessian-free truncated-Newton minimizer
-    user-defined diagnostics :ul
-
-LAMMPS 99
-    
-    F77 + MPI
-    static memory allocation
-    spatial-decomposition parallelism
-    most of the LAMMPS 2001 features with a few exceptions
-    no 2d Ewald & PPPM
-    molecular force fields are missing a few CHARMM terms
-    no SHAKE :ul
-
-Warp
-
-    F90 + MPI
-    spatial-decomposition parallelism
-    embedded atom method (EAM) metal potentials + LJ
-    lattice and grain-boundary atom creation
-    NVE, NVT integrators
-    boundary conditions for applying shear stresses
-    temperature controls for actively sheared systems
-    per-atom energy and centro-symmetry computation and output :ul
-
-ParaDyn
-
-    F77 + MPI
-    atom- and force-decomposition parallelism
-    embedded atom method (EAM) metal potentials
-    lattice atom creation
-    NVE, NVT, NPT integrators
-    all serial DYNAMO features for controls and constraints :ul
-
-GranFlow
-
-    F90 + MPI
-    spatial-decomposition parallelism
-    frictional granular potentials
-    NVE integrator
-    boundary conditions for granular flow and packing and walls
-    particle insertion :ul

doc/Section_intro.html

@@ -1,695 +0,0 @@
-
-
-<!DOCTYPE html>
-<!--[if IE 8]><html class="no-js lt-ie9" lang="en" > <![endif]-->
-<!--[if gt IE 8]><!--> <html class="no-js" lang="en" > <!--<![endif]-->
-<head>
-  <meta charset="utf-8">
-  
-  <meta name="viewport" content="width=device-width, initial-scale=1.0">
-  
-  <title>1. Introduction &mdash; LAMMPS documentation</title>
-  
-
-  
-  
-
-  
-
-  
-  
-    
-
-  
-
-  
-  
-    <link rel="stylesheet" href="_static/css/theme.css" type="text/css" />
-  
-
-  
-    <link rel="stylesheet" href="_static/sphinxcontrib-images/LightBox2/lightbox2/css/lightbox.css" type="text/css" />
-  
-
-  
-    <link rel="top" title="LAMMPS documentation" href="index.html"/>
-        <link rel="next" title="2. Getting Started" href="Section_start.html"/>
-        <link rel="prev" title="LAMMPS Documentation" href="Manual.html"/> 
-
-  
-  <script src="_static/js/modernizr.min.js"></script>
-
-</head>
-
-<body class="wy-body-for-nav" role="document">
-
-  <div class="wy-grid-for-nav">
-
-    
-    <nav data-toggle="wy-nav-shift" class="wy-nav-side">
-      <div class="wy-side-nav-search">
-        
-
-        
-          <a href="Manual.html" class="icon icon-home"> LAMMPS
-        
-
-        
-        </a>
-
-        
-<div role="search">
-  <form id="rtd-search-form" class="wy-form" action="search.html" method="get">
-    <input type="text" name="q" placeholder="Search docs" />
-    <input type="hidden" name="check_keywords" value="yes" />
-    <input type="hidden" name="area" value="default" />
-  </form>
-</div>
-
-        
-      </div>
-
-      <div class="wy-menu wy-menu-vertical" data-spy="affix" role="navigation" aria-label="main navigation">
-        
-          
-          
-              <ul class="current">
-<li class="toctree-l1 current"><a class="current reference internal" href="">1. Introduction</a><ul>
-<li class="toctree-l2"><a class="reference internal" href="#what-is-lammps">1.1. What is LAMMPS</a></li>
-<li class="toctree-l2"><a class="reference internal" href="#lammps-features">1.2. LAMMPS features</a><ul>
-<li class="toctree-l3"><a class="reference internal" href="#general-features">1.2.1. General features</a></li>
-<li class="toctree-l3"><a class="reference internal" href="#particle-and-model-types">1.2.2. Particle and model types</a></li>
-<li class="toctree-l3"><a class="reference internal" href="#force-fields">1.2.3. Force fields</a></li>
-<li class="toctree-l3"><a class="reference internal" href="#atom-creation">1.2.4. Atom creation</a></li>
-<li class="toctree-l3"><a class="reference internal" href="#ensembles-constraints-and-boundary-conditions">1.2.5. Ensembles, constraints, and boundary conditions</a></li>
-<li class="toctree-l3"><a class="reference internal" href="#integrators">1.2.6. Integrators</a></li>
-<li class="toctree-l3"><a class="reference internal" href="#diagnostics">1.2.7. Diagnostics</a></li>
-<li class="toctree-l3"><a class="reference internal" href="#output">1.2.8. Output</a></li>
-<li class="toctree-l3"><a class="reference internal" href="#multi-replica-models">1.2.9. Multi-replica models</a></li>
-<li class="toctree-l3"><a class="reference internal" href="#pre-and-post-processing">1.2.10. Pre- and post-processing</a></li>
-<li class="toctree-l3"><a class="reference internal" href="#specialized-features">1.2.11. Specialized features</a></li>
-</ul>
-</li>
-<li class="toctree-l2"><a class="reference internal" href="#lammps-non-features">1.3. LAMMPS non-features</a></li>
-<li class="toctree-l2"><a class="reference internal" href="#open-source-distribution">1.4. Open source distribution</a></li>
-<li class="toctree-l2"><a class="reference internal" href="#acknowledgments-and-citations">1.5. Acknowledgments and citations</a></li>
-</ul>
-</li>
-<li class="toctree-l1"><a class="reference internal" href="Section_start.html">2. Getting Started</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_commands.html">3. Commands</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_packages.html">4. Packages</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_accelerate.html">5. Accelerating LAMMPS performance</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_howto.html">6. How-to discussions</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_example.html">7. Example problems</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_perf.html">8. Performance &amp; scalability</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_tools.html">9. Additional tools</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_modify.html">10. Modifying &amp; extending LAMMPS</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_python.html">11. Python interface to LAMMPS</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_errors.html">12. Errors</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_history.html">13. Future and history</a></li>
-</ul>
-
-          
-        
-      </div>
-      &nbsp;
-    </nav>
-
-    <section data-toggle="wy-nav-shift" class="wy-nav-content-wrap">
-
-      
-      <nav class="wy-nav-top" role="navigation" aria-label="top navigation">
-        <i data-toggle="wy-nav-top" class="fa fa-bars"></i>
-        <a href="Manual.html">LAMMPS</a>
-      </nav>
-
-
-      
-      <div class="wy-nav-content">
-        <div class="rst-content">
-          <div role="navigation" aria-label="breadcrumbs navigation">
-  <ul class="wy-breadcrumbs">
-    <li><a href="Manual.html">Docs</a> &raquo;</li>
-      
-    <li>1. Introduction</li>
-      <li class="wy-breadcrumbs-aside">
-        
-          
-            <a href="http://lammps.sandia.gov">Website</a>
-            <a href="Section_commands.html#comm">Commands</a>
-        
-      </li>
-  </ul>
-  <hr/>
-  
-    <div class="rst-footer-buttons" style="margin-bottom: 1em" role="navigation" aria-label="footer navigation">
-      
-        <a href="Section_start.html" class="btn btn-neutral float-right" title="2. Getting Started" accesskey="n">Next <span class="fa fa-arrow-circle-right"></span></a>
-      
-      
-        <a href="Manual.html" class="btn btn-neutral" title="LAMMPS Documentation" accesskey="p"><span class="fa fa-arrow-circle-left"></span> Previous</a>
-      
-    </div>
-  
-</div>
-          <div role="main" class="document" itemscope="itemscope" itemtype="http://schema.org/Article">
-           <div itemprop="articleBody">
-            
-  <div class="section" id="introduction">
-<h1>1. Introduction<a class="headerlink" href="#introduction" title="Permalink to this headline">¶</a></h1>
-<p>This section provides an overview of what LAMMPS can and can&#8217;t do,
-describes what it means for LAMMPS to be an open-source code, and
-acknowledges the funding and people who have contributed to LAMMPS
-over the years.</p>
-<div class="line-block">
-<div class="line">1.1 <a class="reference internal" href="#intro-1"><span>What is LAMMPS</span></a></div>
-<div class="line">1.2 <a class="reference internal" href="#intro-2"><span>LAMMPS features</span></a></div>
-<div class="line">1.3 <a class="reference internal" href="#intro-3"><span>LAMMPS non-features</span></a></div>
-<div class="line">1.4 <a class="reference internal" href="#intro-4"><span>Open source distribution</span></a></div>
-<div class="line">1.5 <a class="reference internal" href="#intro-5"><span>Acknowledgments and citations</span></a></div>
-<div class="line"><br /></div>
-</div>
-<div class="section" id="what-is-lammps">
-<span id="intro-1"></span><h2>1.1. What is LAMMPS<a class="headerlink" href="#what-is-lammps" title="Permalink to this headline">¶</a></h2>
-<p>LAMMPS is a classical molecular dynamics code that models an ensemble
-of particles in a liquid, solid, or gaseous state.  It can model
-atomic, polymeric, biological, metallic, granular, and coarse-grained
-systems using a variety of force fields and boundary conditions.</p>
-<p>For examples of LAMMPS simulations, see the Publications page of the
-<a class="reference external" href="http://lammps.sandia.gov">LAMMPS WWW Site</a>.</p>
-<p>LAMMPS runs efficiently on single-processor desktop or laptop
-machines, but is designed for parallel computers.  It will run on any
-parallel machine that compiles C++ and supports the <a class="reference external" href="http://www-unix.mcs.anl.gov/mpi">MPI</a>
-message-passing library.  This includes distributed- or shared-memory
-parallel machines and Beowulf-style clusters.</p>
-<p>LAMMPS can model systems with only a few particles up to millions or
-billions.  See <a class="reference internal" href="Section_perf.html"><em>Section_perf</em></a> for information on
-LAMMPS performance and scalability, or the Benchmarks section of the
-<a class="reference external" href="http://lammps.sandia.gov">LAMMPS WWW Site</a>.</p>
-<p>LAMMPS is a freely-available open-source code, distributed under the
-terms of the <a class="reference external" href="http://www.gnu.org/copyleft/gpl.html">GNU Public License</a>, which means you can use or
-modify the code however you wish.  See <a class="reference internal" href="#intro-4"><span>this section</span></a> for a
-brief discussion of the open-source philosophy.</p>
-<p>LAMMPS is designed to be easy to modify or extend with new
-capabilities, such as new force fields, atom types, boundary
-conditions, or diagnostics.  See <a class="reference internal" href="Section_modify.html"><em>Section_modify</em></a>
-for more details.</p>
-<p>The current version of LAMMPS is written in C++.  Earlier versions
-were written in F77 and F90.  See
-<a class="reference internal" href="Section_history.html"><em>Section_history</em></a> for more information on
-different versions.  All versions can be downloaded from the <a class="reference external" href="http://lammps.sandia.gov">LAMMPS WWW Site</a>.</p>
-<p>LAMMPS was originally developed under a US Department of Energy CRADA
-(Cooperative Research and Development Agreement) between two DOE labs
-and 3 companies.  It is distributed by <a class="reference external" href="http://www.sandia.gov">Sandia National Labs</a>.
-See <a class="reference internal" href="#intro-5"><span>this section</span></a> for more information on LAMMPS funding and
-individuals who have contributed to LAMMPS.</p>
-<p>In the most general sense, LAMMPS integrates Newton&#8217;s equations of
-motion for collections of atoms, molecules, or macroscopic particles
-that interact via short- or long-range forces with a variety of
-initial and/or boundary conditions.  For computational efficiency
-LAMMPS uses neighbor lists to keep track of nearby particles.  The
-lists are optimized for systems with particles that are repulsive at
-short distances, so that the local density of particles never becomes
-too large.  On parallel machines, LAMMPS uses spatial-decomposition
-techniques to partition the simulation domain into small 3d
-sub-domains, one of which is assigned to each processor.  Processors
-communicate and store &#8220;ghost&#8221; atom information for atoms that border
-their sub-domain.  LAMMPS is most efficient (in a parallel sense) for
-systems whose particles fill a 3d rectangular box with roughly uniform
-density.  Papers with technical details of the algorithms used in
-LAMMPS are listed in <a class="reference internal" href="#intro-5"><span>this section</span></a>.</p>
-<hr class="docutils" />
-</div>
-<div class="section" id="lammps-features">
-<span id="intro-2"></span><h2>1.2. LAMMPS features<a class="headerlink" href="#lammps-features" title="Permalink to this headline">¶</a></h2>
-<p>This section highlights LAMMPS features, with pointers to specific
-commands which give more details.  If LAMMPS doesn&#8217;t have your
-favorite interatomic potential, boundary condition, or atom type, see
-<a class="reference internal" href="Section_modify.html"><em>Section_modify</em></a>, which describes how you can add
-it to LAMMPS.</p>
-<div class="section" id="general-features">
-<h3>1.2.1. General features<a class="headerlink" href="#general-features" title="Permalink to this headline">¶</a></h3>
-<ul class="simple">
-<li>runs on a single processor or in parallel</li>
-<li>distributed-memory message-passing parallelism (MPI)</li>
-<li>spatial-decomposition of simulation domain for parallelism</li>
-<li>open-source distribution</li>
-<li>highly portable C++</li>
-<li>optional libraries used: MPI and single-processor FFT</li>
-<li>GPU (CUDA and OpenCL), Intel(R) Xeon Phi(TM) coprocessors, and OpenMP support for many code features</li>
-<li>easy to extend with new features and functionality</li>
-<li>runs from an input script</li>
-<li>syntax for defining and using variables and formulas</li>
-<li>syntax for looping over runs and breaking out of loops</li>
-<li>run one or multiple simulations simultaneously (in parallel) from one script</li>
-<li>build as library, invoke LAMMPS thru library interface or provided Python wrapper</li>
-<li>couple with other codes: LAMMPS calls other code, other code calls LAMMPS, umbrella code calls both</li>
-</ul>
-</div>
-<div class="section" id="particle-and-model-types">
-<h3>1.2.2. Particle and model types<a class="headerlink" href="#particle-and-model-types" title="Permalink to this headline">¶</a></h3>
-<p>(<a class="reference internal" href="atom_style.html"><em>atom style</em></a> command)</p>
-<ul class="simple">
-<li>atoms</li>
-<li>coarse-grained particles (e.g. bead-spring polymers)</li>
-<li>united-atom polymers or organic molecules</li>
-<li>all-atom polymers, organic molecules, proteins, DNA</li>
-<li>metals</li>
-<li>granular materials</li>
-<li>coarse-grained mesoscale models</li>
-<li>finite-size spherical and ellipsoidal particles</li>
-<li>finite-size  line segment (2d) and triangle (3d) particles</li>
-<li>point dipole particles</li>
-<li>rigid collections of particles</li>
-<li>hybrid combinations of these</li>
-</ul>
-</div>
-<div class="section" id="force-fields">
-<h3>1.2.3. Force fields<a class="headerlink" href="#force-fields" title="Permalink to this headline">¶</a></h3>
-<p>(<a class="reference internal" href="pair_style.html"><em>pair style</em></a>, <a class="reference internal" href="bond_style.html"><em>bond style</em></a>,
-<a class="reference internal" href="angle_style.html"><em>angle style</em></a>, <a class="reference internal" href="dihedral_style.html"><em>dihedral style</em></a>,
-<a class="reference internal" href="improper_style.html"><em>improper style</em></a>, <a class="reference internal" href="kspace_style.html"><em>kspace style</em></a>
-commands)</p>
-<ul class="simple">
-<li>pairwise potentials: Lennard-Jones, Buckingham, Morse, Born-Mayer-Huggins,     Yukawa, soft, class 2 (COMPASS), hydrogen bond, tabulated</li>
-<li>charged pairwise potentials: Coulombic, point-dipole</li>
-<li>manybody potentials: EAM, Finnis/Sinclair EAM, modified EAM (MEAM),     embedded ion method (EIM), EDIP, ADP, Stillinger-Weber, Tersoff,     REBO, AIREBO, ReaxFF, COMB, SNAP, Streitz-Mintmire, 3-body polymorphic</li>
-<li>long-range interactions for charge, point-dipoles, and LJ dispersion:     Ewald, Wolf, PPPM (similar to particle-mesh Ewald)</li>
-<li>polarization models: <a class="reference internal" href="fix_qeq.html"><em>QEq</em></a>,     <a class="reference internal" href="Section_howto.html#howto-26"><span>core/shell model</span></a>,     <a class="reference internal" href="Section_howto.html#howto-27"><span>Drude dipole model</span></a></li>
-<li>charge equilibration (QEq via dynamic, point, shielded, Slater methods)</li>
-<li>coarse-grained potentials: DPD, GayBerne, REsquared, colloidal, DLVO</li>
-<li>mesoscopic potentials: granular, Peridynamics, SPH</li>
-<li>electron force field (eFF, AWPMD)</li>
-<li>bond potentials: harmonic, FENE, Morse, nonlinear, class 2,     quartic (breakable)</li>
-<li>angle potentials: harmonic, CHARMM, cosine, cosine/squared, cosine/periodic,     class 2 (COMPASS)</li>
-<li>dihedral potentials: harmonic, CHARMM, multi-harmonic, helix,     class 2 (COMPASS), OPLS</li>
-<li>improper potentials: harmonic, cvff, umbrella, class 2 (COMPASS)</li>
-<li>polymer potentials: all-atom, united-atom, bead-spring, breakable</li>
-<li>water potentials: TIP3P, TIP4P, SPC</li>
-<li>implicit solvent potentials: hydrodynamic lubrication, Debye</li>
-<li>force-field compatibility with common CHARMM, AMBER, DREIDING,     OPLS, GROMACS, COMPASS options</li>
-<li>access to <a class="reference external" href="http://openkim.org">KIM archive</a> of potentials via     <a class="reference internal" href="pair_kim.html"><em>pair kim</em></a></li>
-<li>hybrid potentials: multiple pair, bond, angle, dihedral, improper     potentials can be used in one simulation</li>
-<li>overlaid potentials: superposition of multiple pair potentials</li>
-</ul>
-</div>
-<div class="section" id="atom-creation">
-<h3>1.2.4. Atom creation<a class="headerlink" href="#atom-creation" title="Permalink to this headline">¶</a></h3>
-<p>(<a class="reference internal" href="read_data.html"><em>read_data</em></a>, <a class="reference internal" href="lattice.html"><em>lattice</em></a>,
-<a class="reference internal" href="create_atoms.html"><em>create_atoms</em></a>, <a class="reference internal" href="delete_atoms.html"><em>delete_atoms</em></a>,
-<a class="reference internal" href="displace_atoms.html"><em>displace_atoms</em></a>, <a class="reference internal" href="replicate.html"><em>replicate</em></a> commands)</p>
-<ul class="simple">
-<li>read in atom coords from files</li>
-<li>create atoms on one or more lattices (e.g. grain boundaries)</li>
-<li>delete geometric or logical groups of atoms (e.g. voids)</li>
-<li>replicate existing atoms multiple times</li>
-<li>displace atoms</li>
-</ul>
-</div>
-<div class="section" id="ensembles-constraints-and-boundary-conditions">
-<h3>1.2.5. Ensembles, constraints, and boundary conditions<a class="headerlink" href="#ensembles-constraints-and-boundary-conditions" title="Permalink to this headline">¶</a></h3>
-<p>(<a class="reference internal" href="fix.html"><em>fix</em></a> command)</p>
-<ul class="simple">
-<li>2d or 3d systems</li>
-<li>orthogonal or non-orthogonal (triclinic symmetry) simulation domains</li>
-<li>constant NVE, NVT, NPT, NPH, Parinello/Rahman integrators</li>
-<li>thermostatting options for groups and geometric regions of atoms</li>
-<li>pressure control via Nose/Hoover or Berendsen barostatting in 1 to 3 dimensions</li>
-<li>simulation box deformation (tensile and shear)</li>
-<li>harmonic (umbrella) constraint forces</li>
-<li>rigid body constraints</li>
-<li>SHAKE bond and angle constraints</li>
-<li>Monte Carlo bond breaking, formation, swapping</li>
-<li>atom/molecule insertion and deletion</li>
-<li>walls of various kinds</li>
-<li>non-equilibrium molecular dynamics (NEMD)</li>
-<li>variety of additional boundary conditions and constraints</li>
-</ul>
-</div>
-<div class="section" id="integrators">
-<h3>1.2.6. Integrators<a class="headerlink" href="#integrators" title="Permalink to this headline">¶</a></h3>
-<p>(<a class="reference internal" href="run.html"><em>run</em></a>, <a class="reference internal" href="run_style.html"><em>run_style</em></a>, <a class="reference internal" href="minimize.html"><em>minimize</em></a> commands)</p>
-<ul class="simple">
-<li>velocity-Verlet integrator</li>
-<li>Brownian dynamics</li>
-<li>rigid body integration</li>
-<li>energy minimization via conjugate gradient or steepest descent relaxation</li>
-<li>rRESPA hierarchical timestepping</li>
-<li>rerun command for post-processing of dump files</li>
-</ul>
-</div>
-<div class="section" id="diagnostics">
-<h3>1.2.7. Diagnostics<a class="headerlink" href="#diagnostics" title="Permalink to this headline">¶</a></h3>
-<ul class="simple">
-<li>see the various flavors of the <a class="reference internal" href="fix.html"><em>fix</em></a> and <a class="reference internal" href="compute.html"><em>compute</em></a> commands</li>
-</ul>
-</div>
-<div class="section" id="output">
-<h3>1.2.8. Output<a class="headerlink" href="#output" title="Permalink to this headline">¶</a></h3>
-<p>(<a class="reference internal" href="dump.html"><em>dump</em></a>, <a class="reference internal" href="restart.html"><em>restart</em></a> commands)</p>
-<ul class="simple">
-<li>log file of thermodynamic info</li>
-<li>text dump files of atom coords, velocities, other per-atom quantities</li>
-<li>binary restart files</li>
-<li>parallel I/O of dump and restart files</li>
-<li>per-atom quantities (energy, stress, centro-symmetry parameter, CNA, etc)</li>
-<li>user-defined system-wide (log file) or per-atom (dump file) calculations</li>
-<li>spatial and time averaging of per-atom quantities</li>
-<li>time averaging of system-wide quantities</li>
-<li>atom snapshots in native, XYZ, XTC, DCD, CFG formats</li>
-</ul>
-</div>
-<div class="section" id="multi-replica-models">
-<h3>1.2.9. Multi-replica models<a class="headerlink" href="#multi-replica-models" title="Permalink to this headline">¶</a></h3>
-<p><a class="reference internal" href="neb.html"><em>nudged elastic band</em></a>
-<a class="reference internal" href="prd.html"><em>parallel replica dynamics</em></a>
-<a class="reference internal" href="tad.html"><em>temperature accelerated dynamics</em></a>
-<a class="reference internal" href="temper.html"><em>parallel tempering</em></a></p>
-</div>
-<div class="section" id="pre-and-post-processing">
-<h3>1.2.10. Pre- and post-processing<a class="headerlink" href="#pre-and-post-processing" title="Permalink to this headline">¶</a></h3>
-<ul class="simple">
-<li>Various pre- and post-processing serial tools are packaged
-with LAMMPS; see these <a class="reference internal" href="Section_tools.html"><em>doc pages</em></a>.</li>
-<li>Our group has also written and released a separate toolkit called
-<a class="reference external" href="http://www.sandia.gov/~sjplimp/pizza.html">Pizza.py</a> which provides tools for doing setup, analysis,
-plotting, and visualization for LAMMPS simulations.  Pizza.py is
-written in <a class="reference external" href="http://www.python.org">Python</a> and is available for download from <a class="reference external" href="http://www.sandia.gov/~sjplimp/pizza.html">the Pizza.py WWW site</a>.</li>
-</ul>
-</div>
-<div class="section" id="specialized-features">
-<h3>1.2.11. Specialized features<a class="headerlink" href="#specialized-features" title="Permalink to this headline">¶</a></h3>
-<p>These are LAMMPS capabilities which you may not think of as typical
-molecular dynamics options:</p>
-<ul class="simple">
-<li><a class="reference internal" href="balance.html"><em>static</em></a> and <a class="reference internal" href="fix_balance.html"><em>dynamic load-balancing</em></a></li>
-<li><a class="reference internal" href="body.html"><em>generalized aspherical particles</em></a></li>
-<li><a class="reference internal" href="fix_srd.html"><em>stochastic rotation dynamics (SRD)</em></a></li>
-<li><a class="reference internal" href="fix_imd.html"><em>real-time visualization and interactive MD</em></a></li>
-<li>calculate <a class="reference internal" href="compute_xrd.html"><em>virtual diffraction patterns</em></a></li>
-<li><a class="reference internal" href="fix_atc.html"><em>atom-to-continuum coupling</em></a> with finite elements</li>
-<li>coupled rigid body integration via the <a class="reference internal" href="fix_poems.html"><em>POEMS</em></a> library</li>
-<li><a class="reference internal" href="fix_qmmm.html"><em>QM/MM coupling</em></a></li>
-<li><a class="reference internal" href="fix_ipi.html"><em>path-integral molecular dynamics (PIMD)</em></a> and <a class="reference internal" href="fix_pimd.html"><em>this as well</em></a></li>
-<li>Monte Carlo via <a class="reference internal" href="fix_gcmc.html"><em>GCMC</em></a> and <a class="reference internal" href="fix_tfmc.html"><em>tfMC</em></a> and <code class="xref doc docutils literal"><span class="pre">atom</span> <span class="pre">swapping</span></code></li>
-<li><a class="reference internal" href="pair_dsmc.html"><em>Direct Simulation Monte Carlo</em></a> for low-density fluids</li>
-<li><a class="reference internal" href="pair_peri.html"><em>Peridynamics mesoscale modeling</em></a></li>
-<li><a class="reference internal" href="fix_lb_fluid.html"><em>Lattice Boltzmann fluid</em></a></li>
-<li><a class="reference internal" href="fix_tmd.html"><em>targeted</em></a> and <a class="reference internal" href="fix_smd.html"><em>steered</em></a> molecular dynamics</li>
-<li><a class="reference internal" href="fix_ttm.html"><em>two-temperature electron model</em></a></li>
-</ul>
-<hr class="docutils" />
-</div>
-</div>
-<div class="section" id="lammps-non-features">
-<span id="intro-3"></span><h2>1.3. LAMMPS non-features<a class="headerlink" href="#lammps-non-features" title="Permalink to this headline">¶</a></h2>
-<p>LAMMPS is designed to efficiently compute Newton&#8217;s equations of motion
-for a system of interacting particles.  Many of the tools needed to
-pre- and post-process the data for such simulations are not included
-in the LAMMPS kernel for several reasons:</p>
-<ul class="simple">
-<li>the desire to keep LAMMPS simple</li>
-<li>they are not parallel operations</li>
-<li>other codes already do them</li>
-<li>limited development resources</li>
-</ul>
-<p>Specifically, LAMMPS itself does not:</p>
-<ul class="simple">
-<li>run thru a GUI</li>
-<li>build molecular systems</li>
-<li>assign force-field coefficients automagically</li>
-<li>perform sophisticated analyses of your MD simulation</li>
-<li>visualize your MD simulation</li>
-<li>plot your output data</li>
-</ul>
-<p>A few tools for pre- and post-processing tasks are provided as part of
-the LAMMPS package; they are described in <a class="reference internal" href="Section_tools.html"><em>this section</em></a>.  However, many people use other codes or
-write their own tools for these tasks.</p>
-<p>As noted above, our group has also written and released a separate
-toolkit called <a class="reference external" href="http://www.sandia.gov/~sjplimp/pizza.html">Pizza.py</a> which addresses some of the listed
-bullets.  It provides tools for doing setup, analysis, plotting, and
-visualization for LAMMPS simulations.  Pizza.py is written in
-<a class="reference external" href="http://www.python.org">Python</a> and is available for download from <a class="reference external" href="http://www.sandia.gov/~sjplimp/pizza.html">the Pizza.py WWW site</a>.</p>
-<p>LAMMPS requires as input a list of initial atom coordinates and types,
-molecular topology information, and force-field coefficients assigned
-to all atoms and bonds.  LAMMPS will not build molecular systems and
-assign force-field parameters for you.</p>
-<p>For atomic systems LAMMPS provides a <a class="reference internal" href="create_atoms.html"><em>create_atoms</em></a>
-command which places atoms on solid-state lattices (fcc, bcc,
-user-defined, etc).  Assigning small numbers of force field
-coefficients can be done via the <a class="reference internal" href="pair_coeff.html"><em>pair coeff</em></a>, <a class="reference internal" href="bond_coeff.html"><em>bond coeff</em></a>, <a class="reference internal" href="angle_coeff.html"><em>angle coeff</em></a>, etc commands.
-For molecular systems or more complicated simulation geometries, users
-typically use another code as a builder and convert its output to
-LAMMPS input format, or write their own code to generate atom
-coordinate and molecular topology for LAMMPS to read in.</p>
-<p>For complicated molecular systems (e.g. a protein), a multitude of
-topology information and hundreds of force-field coefficients must
-typically be specified.  We suggest you use a program like
-<a class="reference external" href="http://www.scripps.edu/brooks">CHARMM</a> or <a class="reference external" href="http://amber.scripps.edu">AMBER</a> or other molecular builders to setup
-such problems and dump its information to a file.  You can then
-reformat the file as LAMMPS input.  Some of the tools in <a class="reference internal" href="Section_tools.html"><em>this section</em></a> can assist in this process.</p>
-<p>Similarly, LAMMPS creates output files in a simple format.  Most users
-post-process these files with their own analysis tools or re-format
-them for input into other programs, including visualization packages.
-If you are convinced you need to compute something on-the-fly as
-LAMMPS runs, see <a class="reference internal" href="Section_modify.html"><em>Section_modify</em></a> for a discussion
-of how you can use the <a class="reference internal" href="dump.html"><em>dump</em></a> and <a class="reference internal" href="compute.html"><em>compute</em></a> and
-<a class="reference internal" href="fix.html"><em>fix</em></a> commands to print out data of your choosing.  Keep in
-mind that complicated computations can slow down the molecular
-dynamics timestepping, particularly if the computations are not
-parallel, so it is often better to leave such analysis to
-post-processing codes.</p>
-<p>A very simple (yet fast) visualizer is provided with the LAMMPS
-package - see the <a class="reference internal" href="Section_tools.html#xmovie"><span>xmovie</span></a> tool in <a class="reference internal" href="Section_tools.html"><em>this section</em></a>.  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
-following packages:</p>
-<ul class="simple">
-<li><a class="reference external" href="http://www.ks.uiuc.edu/Research/vmd">VMD</a></li>
-<li><a class="reference external" href="http://mt.seas.upenn.edu/Archive/Graphics/A">AtomEye</a></li>
-<li><a class="reference external" href="http://pymol.sourceforge.net">PyMol</a></li>
-<li><a class="reference external" href="http://www.bmsc.washington.edu/raster3d/raster3d.html">Raster3d</a></li>
-<li><a class="reference external" href="http://www.openrasmol.org">RasMol</a></li>
-</ul>
-<p>Other features that LAMMPS does not yet (and may never) support are
-discussed in <a class="reference internal" href="Section_history.html"><em>Section_history</em></a>.</p>
-<p>Finally, these are freely-available molecular dynamics codes, most of
-them parallel, which may be well-suited to the problems you want to
-model.  They can also be used in conjunction with LAMMPS to perform
-complementary modeling tasks.</p>
-<ul class="simple">
-<li><a class="reference external" href="http://www.scripps.edu/brooks">CHARMM</a></li>
-<li><a class="reference external" href="http://amber.scripps.edu">AMBER</a></li>
-<li><a class="reference external" href="http://www.ks.uiuc.edu/Research/namd/">NAMD</a></li>
-<li><a class="reference external" href="http://www.emsl.pnl.gov/docs/nwchem/nwchem.html">NWCHEM</a></li>
-<li><a class="reference external" href="http://www.cse.clrc.ac.uk/msi/software/DL_POLY">DL_POLY</a></li>
-<li><a class="reference external" href="http://dasher.wustl.edu/tinker">Tinker</a></li>
-</ul>
-<p>CHARMM, AMBER, NAMD, NWCHEM, and Tinker are designed primarily for
-modeling biological molecules.  CHARMM and AMBER use
-atom-decomposition (replicated-data) strategies for parallelism; NAMD
-and NWCHEM use spatial-decomposition approaches, similar to LAMMPS.
-Tinker is a serial code.  DL_POLY includes potentials for a variety of
-biological and non-biological materials; both a replicated-data and
-spatial-decomposition version exist.</p>
-<hr class="docutils" />
-</div>
-<div class="section" id="open-source-distribution">
-<span id="intro-4"></span><h2>1.4. Open source distribution<a class="headerlink" href="#open-source-distribution" title="Permalink to this headline">¶</a></h2>
-<p>LAMMPS comes with no warranty of any kind.  As each source file states
-in its header, it is a copyrighted code that is distributed free-of-
-charge, under the terms of the <a class="reference external" href="http://www.gnu.org/copyleft/gpl.html">GNU Public License</a> (GPL).  This
-is often referred to as open-source distribution - see
-<a class="reference external" href="http://www.gnu.org">www.gnu.org</a> or <a class="reference external" href="http://www.opensource.org">www.opensource.org</a> for more
-details.  The legal text of the GPL is in the LICENSE file that is
-included in the LAMMPS distribution.</p>
-<p>Here is a summary of what the GPL means for LAMMPS users:</p>
-<p>(1) Anyone is free to use, modify, or extend LAMMPS in any way they
-choose, including for commercial purposes.</p>
-<p>(2) If you distribute a modified version of LAMMPS, it must remain
-open-source, meaning you distribute it under the terms of the GPL.
-You should clearly annotate such a code as a derivative version of
-LAMMPS.</p>
-<p>(3) If you release any code that includes LAMMPS source code, then it
-must also be open-sourced, meaning you distribute it under the terms
-of the GPL.</p>
-<p>(4) If you give LAMMPS files to someone else, the GPL LICENSE file and
-source file headers (including the copyright and GPL notices) should
-remain part of the code.</p>
-<p>In the spirit of an open-source code, these are various ways you can
-contribute to making LAMMPS better.  You can send email to the
-<a class="reference external" href="http://lammps.sandia.gov/authors.html">developers</a> on any of these
-items.</p>
-<ul class="simple">
-<li>Point prospective users to the <a class="reference external" href="http://lammps.sandia.gov">LAMMPS WWW Site</a>.  Mention it in
-talks or link to it from your WWW site.</li>
-<li>If you find an error or omission in this manual or on the <a class="reference external" href="http://lammps.sandia.gov">LAMMPS WWW Site</a>, or have a suggestion for something to clarify or include,
-send an email to the
-<a class="reference external" href="http://lammps.sandia.gov/authors.html">developers</a>.</li>
-<li>If you find a bug, <a class="reference internal" href="Section_errors.html#err-2"><span>Section_errors 2</span></a>
-describes how to report it.</li>
-<li>If you publish a paper using LAMMPS results, send the citation (and
-any cool pictures or movies if you like) to add to the Publications,
-Pictures, and Movies pages of the <a class="reference external" href="http://lammps.sandia.gov">LAMMPS WWW Site</a>, with links
-and attributions back to you.</li>
-<li>Create a new Makefile.machine that can be added to the src/MAKE
-directory.</li>
-<li>The tools sub-directory of the LAMMPS distribution has various
-stand-alone codes for pre- and post-processing of LAMMPS data.  More
-details are given in <a class="reference internal" href="Section_tools.html"><em>Section_tools</em></a>.  If you write
-a new tool that users will find useful, it can be added to the LAMMPS
-distribution.</li>
-<li>LAMMPS is designed to be easy to extend with new code for features
-like potentials, boundary conditions, diagnostic computations, etc.
-<a class="reference internal" href="Section_modify.html"><em>This section</em></a> gives details.  If you add a
-feature of general interest, it can be added to the LAMMPS
-distribution.</li>
-<li>The Benchmark page of the <a class="reference external" href="http://lammps.sandia.gov">LAMMPS WWW Site</a> lists LAMMPS
-performance on various platforms.  The files needed to run the
-benchmarks are part of the LAMMPS distribution.  If your machine is
-sufficiently different from those listed, your timing data can be
-added to the page.</li>
-<li>You can send feedback for the User Comments page of the <a class="reference external" href="http://lammps.sandia.gov">LAMMPS WWW Site</a>.  It might be added to the page.  No promises.</li>
-<li>Cash.  Small denominations, unmarked bills preferred.  Paper sack OK.
-Leave on desk.  VISA also accepted.  Chocolate chip cookies
-encouraged.</li>
-</ul>
-<hr class="docutils" />
-</div>
-<div class="section" id="acknowledgments-and-citations">
-<span id="intro-5"></span><h2>1.5. Acknowledgments and citations<a class="headerlink" href="#acknowledgments-and-citations" title="Permalink to this headline">¶</a></h2>
-<p>LAMMPS development has been funded by the <a class="reference external" href="http://www.doe.gov">US Department of Energy</a> (DOE), through its CRADA, LDRD, ASCI, and Genomes-to-Life
-programs and its <a class="reference external" href="http://www.sc.doe.gov/ascr/home.html">OASCR</a> and <a class="reference external" href="http://www.er.doe.gov/production/ober/ober_top.html">OBER</a> offices.</p>
-<p>Specifically, work on the latest version was funded in part by the US
-Department of Energy&#8217;s Genomics:GTL program
-(<a class="reference external" href="http://www.doegenomestolife.org">www.doegenomestolife.org</a>) under the <a class="reference external" href="http://www.genomes2life.org">project</a>, &#8220;Carbon
-Sequestration in Synechococcus Sp.: From Molecular Machines to
-Hierarchical Modeling&#8221;.</p>
-<p>The following paper describe the basic parallel algorithms used in
-LAMMPS.  If you use LAMMPS results in your published work, please cite
-this paper and include a pointer to the <a class="reference external" href="http://lammps.sandia.gov">LAMMPS WWW Site</a>
-(<a class="reference external" href="http://lammps.sandia.gov">http://lammps.sandia.gov</a>):</p>
-<p>S. J. Plimpton, <strong>Fast Parallel Algorithms for Short-Range Molecular
-Dynamics</strong>, J Comp Phys, 117, 1-19 (1995).</p>
-<p>Other papers describing specific algorithms used in LAMMPS are listed
-under the <a class="reference external" href="http://lammps.sandia.gov/cite.html">Citing LAMMPS link</a> of
-the LAMMPS WWW page.</p>
-<p>The <a class="reference external" href="http://lammps.sandia.gov/papers.html">Publications link</a> on the
-LAMMPS WWW page lists papers that have cited LAMMPS.  If your paper is
-not listed there for some reason, feel free to send us the info.  If
-the simulations in your paper produced cool pictures or animations,
-we&#8217;ll be pleased to add them to the
-<a class="reference external" href="http://lammps.sandia.gov/pictures.html">Pictures</a> or
-<a class="reference external" href="http://lammps.sandia.gov/movies.html">Movies</a> pages of the LAMMPS WWW
-site.</p>
-<p>The core group of LAMMPS developers is at Sandia National Labs:</p>
-<ul class="simple">
-<li>Steve Plimpton, sjplimp at sandia.gov</li>
-<li>Aidan Thompson, athomps at sandia.gov</li>
-<li>Paul Crozier, pscrozi at sandia.gov</li>
-</ul>
-<p>The following folks are responsible for significant contributions to
-the code, or other aspects of the LAMMPS development effort.  Many of
-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.</p>
-<ul class="simple">
-<li>Axel Kohlmeyer (Temple U), akohlmey at gmail.com, SVN and Git repositories, indefatigable mail list responder, USER-CG-CMM and USER-OMP packages</li>
-<li>Roy Pollock (LLNL), Ewald and PPPM solvers</li>
-<li>Mike Brown (ORNL), brownw at ornl.gov, GPU package</li>
-<li>Greg Wagner (Sandia), gjwagne at sandia.gov, MEAM package for MEAM potential</li>
-<li>Mike Parks (Sandia), mlparks at sandia.gov, PERI package for Peridynamics</li>
-<li>Rudra Mukherjee (JPL), Rudranarayan.M.Mukherjee at jpl.nasa.gov, POEMS package for articulated rigid body motion</li>
-<li>Reese Jones (Sandia) and collaborators, rjones at sandia.gov, USER-ATC package for atom/continuum coupling</li>
-<li>Ilya Valuev (JIHT), valuev at physik.hu-berlin.de, USER-AWPMD package for wave-packet MD</li>
-<li>Christian Trott (U Tech Ilmenau), christian.trott at tu-ilmenau.de, USER-CUDA package</li>
-<li>Andres Jaramillo-Botero (Caltech), ajaramil at wag.caltech.edu, USER-EFF package for electron force field</li>
-<li>Christoph Kloss (JKU), Christoph.Kloss at jku.at, USER-LIGGGHTS package for granular models and granular/fluid coupling</li>
-<li>Metin Aktulga (LBL), hmaktulga at lbl.gov, USER-REAXC package for C version of ReaxFF</li>
-<li>Georg Gunzenmuller (EMI), georg.ganzenmueller at emi.fhg.de, USER-SPH package</li>
-</ul>
-<p>As discussed in <a class="reference internal" href="Section_history.html"><em>Section_history</em></a>, LAMMPS
-originated as a cooperative project between DOE labs and industrial
-partners. Folks involved in the design and testing of the original
-version of LAMMPS were the following:</p>
-<ul class="simple">
-<li>John Carpenter (Mayo Clinic, formerly at Cray Research)</li>
-<li>Terry Stouch (Lexicon Pharmaceuticals, formerly at Bristol Myers Squibb)</li>
-<li>Steve Lustig (Dupont)</li>
-<li>Jim Belak (LLNL)</li>
-</ul>
-</div>
-</div>
-
-
-           </div>
-          </div>
-          <footer>
-  
-    <div class="rst-footer-buttons" role="navigation" aria-label="footer navigation">
-      
-        <a href="Section_start.html" class="btn btn-neutral float-right" title="2. Getting Started" accesskey="n">Next <span class="fa fa-arrow-circle-right"></span></a>
-      
-      
-        <a href="Manual.html" class="btn btn-neutral" title="LAMMPS Documentation" accesskey="p"><span class="fa fa-arrow-circle-left"></span> Previous</a>
-      
-    </div>
-  
-
-  <hr/>
-
-  <div role="contentinfo">
-    <p>
-        &copy; Copyright 2013 Sandia Corporation.
-    </p>
-  </div>
-  Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
-
-</footer>
-
-        </div>
-      </div>
-
-    </section>
-
-  </div>
-  
-
-
-  
-
-    <script type="text/javascript">
-        var DOCUMENTATION_OPTIONS = {
-            URL_ROOT:'./',
-            VERSION:'',
-            COLLAPSE_INDEX:false,
-            FILE_SUFFIX:'.html',
-            HAS_SOURCE:  true
-        };
-    </script>
-      <script type="text/javascript" src="_static/jquery.js"></script>
-      <script type="text/javascript" src="_static/underscore.js"></script>
-      <script type="text/javascript" src="_static/doctools.js"></script>
-      <script type="text/javascript" src="https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>
-      <script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/jquery-1.11.0.min.js"></script>
-      <script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/lightbox.min.js"></script>
-      <script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2-customize/jquery-noconflict.js"></script>
-
-  
-
-  
-  
-    <script type="text/javascript" src="_static/js/theme.js"></script>
-  
-
-  
-  
-  <script type="text/javascript">
-      jQuery(function () {
-          SphinxRtdTheme.StickyNav.enable();
-      });
-  </script>
-   
-
-</body>
-</html>

doc/Section_intro.txt

@@ -1,540 +0,0 @@
-"Previous Section"_Manual.html - "LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next Section"_Section_start.html :c
-
-:link(lws,http://lammps.sandia.gov)
-:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
-
-:line
-
-1. Introduction :h3
-
-This section provides an overview of what LAMMPS can and can't do,
-describes what it means for LAMMPS to be an open-source code, and
-acknowledges the funding and people who have contributed to LAMMPS
-over the years.
-
-1.1 "What is LAMMPS"_#intro_1
-1.2 "LAMMPS features"_#intro_2
-1.3 "LAMMPS non-features"_#intro_3
-1.4 "Open source distribution"_#intro_4
-1.5 "Acknowledgments and citations"_#intro_5 :all(b)
-
-:line
-:line
-
-1.1 What is LAMMPS :link(intro_1),h4
-
-LAMMPS is a classical molecular dynamics code that models an ensemble
-of particles in a liquid, solid, or gaseous state.  It can model
-atomic, polymeric, biological, metallic, granular, and coarse-grained
-systems using a variety of force fields and boundary conditions.
-
-For examples of LAMMPS simulations, see the Publications page of the
-"LAMMPS WWW Site"_lws.
-
-LAMMPS runs efficiently on single-processor desktop or laptop
-machines, but is designed for parallel computers.  It will run on any
-parallel machine that compiles C++ and supports the "MPI"_mpi
-message-passing library.  This includes distributed- or shared-memory
-parallel machines and Beowulf-style clusters.
-
-:link(mpi,http://www-unix.mcs.anl.gov/mpi)
-
-LAMMPS can model systems with only a few particles up to millions or
-billions.  See "Section_perf"_Section_perf.html for information on
-LAMMPS performance and scalability, or the Benchmarks section of the
-"LAMMPS WWW Site"_lws.
-
-LAMMPS is a freely-available open-source code, distributed under the
-terms of the "GNU Public License"_gnu, which means you can use or
-modify the code however you wish.  See "this section"_#intro_4 for a
-brief discussion of the open-source philosophy.
-
-:link(gnu,http://www.gnu.org/copyleft/gpl.html)
-
-LAMMPS is designed to be easy to modify or extend with new
-capabilities, such as new force fields, atom types, boundary
-conditions, or diagnostics.  See "Section_modify"_Section_modify.html
-for more details.
-
-The current version of LAMMPS is written in C++.  Earlier versions
-were written in F77 and F90.  See
-"Section_history"_Section_history.html for more information on
-different versions.  All versions can be downloaded from the "LAMMPS
-WWW Site"_lws.
-
-LAMMPS was originally developed under a US Department of Energy CRADA
-(Cooperative Research and Development Agreement) between two DOE labs
-and 3 companies.  It is distributed by "Sandia National Labs"_snl.
-See "this section"_#intro_5 for more information on LAMMPS funding and
-individuals who have contributed to LAMMPS.
-
-:link(snl,http://www.sandia.gov)
-
-In the most general sense, LAMMPS integrates Newton's equations of
-motion for collections of atoms, molecules, or macroscopic particles
-that interact via short- or long-range forces with a variety of
-initial and/or boundary conditions.  For computational efficiency
-LAMMPS uses neighbor lists to keep track of nearby particles.  The
-lists are optimized for systems with particles that are repulsive at
-short distances, so that the local density of particles never becomes
-too large.  On parallel machines, LAMMPS uses spatial-decomposition
-techniques to partition the simulation domain into small 3d
-sub-domains, one of which is assigned to each processor.  Processors
-communicate and store "ghost" atom information for atoms that border
-their sub-domain.  LAMMPS is most efficient (in a parallel sense) for
-systems whose particles fill a 3d rectangular box with roughly uniform
-density.  Papers with technical details of the algorithms used in
-LAMMPS are listed in "this section"_#intro_5.
-
-:line
-
-1.2 LAMMPS features :link(intro_2),h4
-
-This section highlights LAMMPS features, with pointers to specific
-commands which give more details.  If LAMMPS doesn't have your
-favorite interatomic potential, boundary condition, or atom type, see
-"Section_modify"_Section_modify.html, which describes how you can add
-it to LAMMPS.
-
-General features :h5
-
-  runs on a single processor or in parallel
-  distributed-memory message-passing parallelism (MPI)
-  spatial-decomposition of simulation domain for parallelism
-  open-source distribution
-  highly portable C++
-  optional libraries used: MPI and single-processor FFT
-  GPU (CUDA and OpenCL), Intel(R) Xeon Phi(TM) coprocessors, and OpenMP support for many code features
-  easy to extend with new features and functionality
-  runs from an input script
-  syntax for defining and using variables and formulas
-  syntax for looping over runs and breaking out of loops
-  run one or multiple simulations simultaneously (in parallel) from one script
-  build as library, invoke LAMMPS thru library interface or provided Python wrapper
-  couple with other codes: LAMMPS calls other code, other code calls LAMMPS, umbrella code calls both :ul
-
-Particle and model types :h5
-("atom style"_atom_style.html command)
-
-  atoms
-  coarse-grained particles (e.g. bead-spring polymers)
-  united-atom polymers or organic molecules
-  all-atom polymers, organic molecules, proteins, DNA
-  metals
-  granular materials
-  coarse-grained mesoscale models
-  finite-size spherical and ellipsoidal particles
-  finite-size  line segment (2d) and triangle (3d) particles
-  point dipole particles
-  rigid collections of particles
-  hybrid combinations of these :ul
-
-Force fields :h5
-("pair style"_pair_style.html, "bond style"_bond_style.html,
-"angle style"_angle_style.html, "dihedral style"_dihedral_style.html,
-"improper style"_improper_style.html, "kspace style"_kspace_style.html
-commands)
-
-  pairwise potentials: Lennard-Jones, Buckingham, Morse, Born-Mayer-Huggins, \
-    Yukawa, soft, class 2 (COMPASS), hydrogen bond, tabulated
-  charged pairwise potentials: Coulombic, point-dipole
-  manybody potentials: EAM, Finnis/Sinclair EAM, modified EAM (MEAM), \
-    embedded ion method (EIM), EDIP, ADP, Stillinger-Weber, Tersoff, \
-    REBO, AIREBO, ReaxFF, COMB, SNAP, Streitz-Mintmire, 3-body polymorphic
-  long-range interactions for charge, point-dipoles, and LJ dispersion: \
-    Ewald, Wolf, PPPM (similar to particle-mesh Ewald)
-  polarization models: "QEq"_fix_qeq.html, \
-    "core/shell model"_Section_howto.html#howto_26, \
-    "Drude dipole model"_Section_howto.html#howto_27
-  charge equilibration (QEq via dynamic, point, shielded, Slater methods)
-  coarse-grained potentials: DPD, GayBerne, REsquared, colloidal, DLVO
-  mesoscopic potentials: granular, Peridynamics, SPH
-  electron force field (eFF, AWPMD)
-  bond potentials: harmonic, FENE, Morse, nonlinear, class 2, \
-    quartic (breakable)
-  angle potentials: harmonic, CHARMM, cosine, cosine/squared, cosine/periodic, \
-    class 2 (COMPASS)
-  dihedral potentials: harmonic, CHARMM, multi-harmonic, helix, \
-    class 2 (COMPASS), OPLS
-  improper potentials: harmonic, cvff, umbrella, class 2 (COMPASS)
-  polymer potentials: all-atom, united-atom, bead-spring, breakable
-  water potentials: TIP3P, TIP4P, SPC
-  implicit solvent potentials: hydrodynamic lubrication, Debye
-  force-field compatibility with common CHARMM, AMBER, DREIDING, \
-    OPLS, GROMACS, COMPASS options
-  access to "KIM archive"_http://openkim.org of potentials via \
-    "pair kim"_pair_kim.html
-  hybrid potentials: multiple pair, bond, angle, dihedral, improper \
-    potentials can be used in one simulation
-  overlaid potentials: superposition of multiple pair potentials :ul
-
-Atom creation :h5
-("read_data"_read_data.html, "lattice"_lattice.html,
-"create_atoms"_create_atoms.html, "delete_atoms"_delete_atoms.html,
-"displace_atoms"_displace_atoms.html, "replicate"_replicate.html commands)
-
-  read in atom coords from files
-  create atoms on one or more lattices (e.g. grain boundaries)
-  delete geometric or logical groups of atoms (e.g. voids)
-  replicate existing atoms multiple times
-  displace atoms :ul
-
-Ensembles, constraints, and boundary conditions :h5
-("fix"_fix.html command) 
-
-  2d or 3d systems
-  orthogonal or non-orthogonal (triclinic symmetry) simulation domains
-  constant NVE, NVT, NPT, NPH, Parinello/Rahman integrators
-  thermostatting options for groups and geometric regions of atoms
-  pressure control via Nose/Hoover or Berendsen barostatting in 1 to 3 dimensions
-  simulation box deformation (tensile and shear)
-  harmonic (umbrella) constraint forces
-  rigid body constraints
-  SHAKE bond and angle constraints
-  Monte Carlo bond breaking, formation, swapping
-  atom/molecule insertion and deletion
-  walls of various kinds
-  non-equilibrium molecular dynamics (NEMD)
-  variety of additional boundary conditions and constraints :ul
-
-Integrators :h5
-("run"_run.html, "run_style"_run_style.html, "minimize"_minimize.html commands) 
-
-  velocity-Verlet integrator
-  Brownian dynamics
-  rigid body integration
-  energy minimization via conjugate gradient or steepest descent relaxation
-  rRESPA hierarchical timestepping
-  rerun command for post-processing of dump files :ul
-
-Diagnostics :h5
-
-  see the various flavors of the "fix"_fix.html and "compute"_compute.html commands :ul
-
-Output :h5
-("dump"_dump.html, "restart"_restart.html commands) 
-
-  log file of thermodynamic info
-  text dump files of atom coords, velocities, other per-atom quantities
-  binary restart files
-  parallel I/O of dump and restart files
-  per-atom quantities (energy, stress, centro-symmetry parameter, CNA, etc)
-  user-defined system-wide (log file) or per-atom (dump file) calculations
-  spatial and time averaging of per-atom quantities
-  time averaging of system-wide quantities
-  atom snapshots in native, XYZ, XTC, DCD, CFG formats :ul
-
-Multi-replica models :h5
-
-"nudged elastic band"_neb.html
-"parallel replica dynamics"_prd.html
-"temperature accelerated dynamics"_tad.html
-"parallel tempering"_temper.html
-
-Pre- and post-processing :h5
-
-Various pre- and post-processing serial tools are packaged
-with LAMMPS; see these "doc pages"_Section_tools.html. :ulb,l
-
-Our group has also written and released a separate toolkit called
-"Pizza.py"_pizza which provides tools for doing setup, analysis,
-plotting, and visualization for LAMMPS simulations.  Pizza.py is
-written in "Python"_python and is available for download from "the
-Pizza.py WWW site"_pizza. :l,ule
-
-:link(pizza,http://www.sandia.gov/~sjplimp/pizza.html)
-:link(python,http://www.python.org)
-
-Specialized features :h5
-
-These are LAMMPS capabilities which you may not think of as typical
-molecular dynamics options:
-
-"static"_balance.html and "dynamic load-balancing"_fix_balance.html
-"generalized aspherical particles"_body.html
-"stochastic rotation dynamics (SRD)"_fix_srd.html
-"real-time visualization and interactive MD"_fix_imd.html
-calculate "virtual diffraction patterns"_compute_xrd.html
-"atom-to-continuum coupling"_fix_atc.html with finite elements
-coupled rigid body integration via the "POEMS"_fix_poems.html library
-"QM/MM coupling"_fix_qmmm.html
-"path-integral molecular dynamics (PIMD)"_fix_ipi.html and "this as well"_fix_pimd.html
-Monte Carlo via "GCMC"_fix_gcmc.html and "tfMC"_fix_tfmc.html and "atom swapping"_fix_swap.html
-"Direct Simulation Monte Carlo"_pair_dsmc.html for low-density fluids
-"Peridynamics mesoscale modeling"_pair_peri.html
-"Lattice Boltzmann fluid"_fix_lb_fluid.html
-"targeted"_fix_tmd.html and "steered"_fix_smd.html molecular dynamics
-"two-temperature electron model"_fix_ttm.html :ul
-
-:line
-
-1.3 LAMMPS non-features :link(intro_3),h4
-
-LAMMPS is designed to efficiently compute Newton's equations of motion
-for a system of interacting particles.  Many of the tools needed to
-pre- and post-process the data for such simulations are not included
-in the LAMMPS kernel for several reasons:
-
-the desire to keep LAMMPS simple
-they are not parallel operations
-other codes already do them
-limited development resources :ul
-
-Specifically, LAMMPS itself does not:
-
-run thru a GUI
-build molecular systems
-assign force-field coefficients automagically
-perform sophisticated analyses of your MD simulation
-visualize your MD simulation
-plot your output data :ul
-
-A few tools for pre- and post-processing tasks are provided as part of
-the LAMMPS package; they are described in "this
-section"_Section_tools.html.  However, many people use other codes or
-write their own tools for these tasks.
-
-As noted above, our group has also written and released a separate
-toolkit called "Pizza.py"_pizza which addresses some of the listed
-bullets.  It provides tools for doing setup, analysis, plotting, and
-visualization for LAMMPS simulations.  Pizza.py is written in
-"Python"_python and is available for download from "the Pizza.py WWW
-site"_pizza.
-
-LAMMPS requires as input a list of initial atom coordinates and types,
-molecular topology information, and force-field coefficients assigned
-to all atoms and bonds.  LAMMPS will not build molecular systems and
-assign force-field parameters for you.
-
-For atomic systems LAMMPS provides a "create_atoms"_create_atoms.html
-command which places atoms on solid-state lattices (fcc, bcc,
-user-defined, etc).  Assigning small numbers of force field
-coefficients can be done via the "pair coeff"_pair_coeff.html, "bond
-coeff"_bond_coeff.html, "angle coeff"_angle_coeff.html, etc commands.
-For molecular systems or more complicated simulation geometries, users
-typically use another code as a builder and convert its output to
-LAMMPS input format, or write their own code to generate atom
-coordinate and molecular topology for LAMMPS to read in.
-
-For complicated molecular systems (e.g. a protein), a multitude of
-topology information and hundreds of force-field coefficients must
-typically be specified.  We suggest you use a program like
-"CHARMM"_charmm or "AMBER"_amber or other molecular builders to setup
-such problems and dump its information to a file.  You can then
-reformat the file as LAMMPS input.  Some of the tools in "this
-section"_Section_tools.html can assist in this process.
-
-Similarly, LAMMPS creates output files in a simple format.  Most users
-post-process these files with their own analysis tools or re-format
-them for input into other programs, including visualization packages.
-If you are convinced you need to compute something on-the-fly as
-LAMMPS runs, see "Section_modify"_Section_modify.html for a discussion
-of how you can use the "dump"_dump.html and "compute"_compute.html and
-"fix"_fix.html commands to print out data of your choosing.  Keep in
-mind that complicated computations can slow down the molecular
-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
-following packages:
-
-"VMD"_http://www.ks.uiuc.edu/Research/vmd
-"AtomEye"_http://mt.seas.upenn.edu/Archive/Graphics/A
-"PyMol"_http://pymol.sourceforge.net
-"Raster3d"_http://www.bmsc.washington.edu/raster3d/raster3d.html
-"RasMol"_http://www.openrasmol.org :ul
-
-Other features that LAMMPS does not yet (and may never) support are
-discussed in "Section_history"_Section_history.html.
-
-Finally, these are freely-available molecular dynamics codes, most of
-them parallel, which may be well-suited to the problems you want to
-model.  They can also be used in conjunction with LAMMPS to perform
-complementary modeling tasks.
-
-"CHARMM"_charmm
-"AMBER"_amber
-"NAMD"_namd
-"NWCHEM"_nwchem
-"DL_POLY"_dlpoly
-"Tinker"_tinker :ul
-
-:link(charmm,http://www.scripps.edu/brooks)
-:link(amber,http://amber.scripps.edu)
-:link(namd,http://www.ks.uiuc.edu/Research/namd/)
-:link(nwchem,http://www.emsl.pnl.gov/docs/nwchem/nwchem.html)
-:link(dlpoly,http://www.cse.clrc.ac.uk/msi/software/DL_POLY)
-:link(tinker,http://dasher.wustl.edu/tinker)
-
-CHARMM, AMBER, NAMD, NWCHEM, and Tinker are designed primarily for
-modeling biological molecules.  CHARMM and AMBER use
-atom-decomposition (replicated-data) strategies for parallelism; NAMD
-and NWCHEM use spatial-decomposition approaches, similar to LAMMPS.
-Tinker is a serial code.  DL_POLY includes potentials for a variety of
-biological and non-biological materials; both a replicated-data and
-spatial-decomposition version exist.
-
-:line
-
-1.4 Open source distribution :link(intro_4),h4
-
-LAMMPS comes with no warranty of any kind.  As each source file states
-in its header, it is a copyrighted code that is distributed free-of-
-charge, under the terms of the "GNU Public License"_gnu (GPL).  This
-is often referred to as open-source distribution - see
-"www.gnu.org"_gnuorg or "www.opensource.org"_opensource for more
-details.  The legal text of the GPL is in the LICENSE file that is
-included in the LAMMPS distribution.
-
-:link(gnuorg,http://www.gnu.org)
-:link(opensource,http://www.opensource.org)
-
-Here is a summary of what the GPL means for LAMMPS users:
-
-(1) Anyone is free to use, modify, or extend LAMMPS in any way they
-choose, including for commercial purposes.
-
-(2) If you distribute a modified version of LAMMPS, it must remain
-open-source, meaning you distribute it under the terms of the GPL.
-You should clearly annotate such a code as a derivative version of
-LAMMPS.
-
-(3) If you release any code that includes LAMMPS source code, then it
-must also be open-sourced, meaning you distribute it under the terms
-of the GPL.
-
-(4) If you give LAMMPS files to someone else, the GPL LICENSE file and
-source file headers (including the copyright and GPL notices) should
-remain part of the code.
-
-In the spirit of an open-source code, these are various ways you can
-contribute to making LAMMPS better.  You can send email to the
-"developers"_http://lammps.sandia.gov/authors.html on any of these
-items.
-
-Point prospective users to the "LAMMPS WWW Site"_lws.  Mention it in
-talks or link to it from your WWW site. :ulb,l
-
-If you find an error or omission in this manual or on the "LAMMPS WWW
-Site"_lws, or have a suggestion for something to clarify or include,
-send an email to the
-"developers"_http://lammps.sandia.gov/authors.html. :l
-
-If you find a bug, "Section_errors 2"_Section_errors.html#err_2
-describes how to report it. :l
-
-If you publish a paper using LAMMPS results, send the citation (and
-any cool pictures or movies if you like) to add to the Publications,
-Pictures, and Movies pages of the "LAMMPS WWW Site"_lws, with links
-and attributions back to you. :l
-
-Create a new Makefile.machine that can be added to the src/MAKE
-directory. :l
-
-The tools sub-directory of the LAMMPS distribution has various
-stand-alone codes for pre- and post-processing of LAMMPS data.  More
-details are given in "Section_tools"_Section_tools.html.  If you write
-a new tool that users will find useful, it can be added to the LAMMPS
-distribution. :l
-
-LAMMPS is designed to be easy to extend with new code for features
-like potentials, boundary conditions, diagnostic computations, etc.
-"This section"_Section_modify.html gives details.  If you add a
-feature of general interest, it can be added to the LAMMPS
-distribution. :l
-
-The Benchmark page of the "LAMMPS WWW Site"_lws lists LAMMPS
-performance on various platforms.  The files needed to run the
-benchmarks are part of the LAMMPS distribution.  If your machine is
-sufficiently different from those listed, your timing data can be
-added to the page. :l
-
-You can send feedback for the User Comments page of the "LAMMPS WWW
-Site"_lws.  It might be added to the page.  No promises. :l
-
-Cash.  Small denominations, unmarked bills preferred.  Paper sack OK.
-Leave on desk.  VISA also accepted.  Chocolate chip cookies
-encouraged. :ule,l
-
-:line
-
-1.5 Acknowledgments and citations :h4,link(intro_5)
-
-LAMMPS development has been funded by the "US Department of
-Energy"_doe (DOE), through its CRADA, LDRD, ASCI, and Genomes-to-Life
-programs and its "OASCR"_oascr and "OBER"_ober offices.
-
-Specifically, work on the latest version was funded in part by the US
-Department of Energy's Genomics:GTL program
-("www.doegenomestolife.org"_gtl) under the "project"_ourgtl, "Carbon
-Sequestration in Synechococcus Sp.: From Molecular Machines to
-Hierarchical Modeling".
-
-:link(doe,http://www.doe.gov)
-:link(gtl,http://www.doegenomestolife.org)
-:link(ourgtl,http://www.genomes2life.org)
-:link(oascr,http://www.sc.doe.gov/ascr/home.html)
-:link(ober,http://www.er.doe.gov/production/ober/ober_top.html)
-
-The following paper describe the basic parallel algorithms used in
-LAMMPS.  If you use LAMMPS results in your published work, please cite
-this paper and include a pointer to the "LAMMPS WWW Site"_lws
-(http://lammps.sandia.gov):
-
-S. J. Plimpton, [Fast Parallel Algorithms for Short-Range Molecular
-Dynamics], J Comp Phys, 117, 1-19 (1995).
-
-Other papers describing specific algorithms used in LAMMPS are listed
-under the "Citing LAMMPS link"_http://lammps.sandia.gov/cite.html of
-the LAMMPS WWW page.
-
-The "Publications link"_http://lammps.sandia.gov/papers.html on the
-LAMMPS WWW page lists papers that have cited LAMMPS.  If your paper is
-not listed there for some reason, feel free to send us the info.  If
-the simulations in your paper produced cool pictures or animations,
-we'll be pleased to add them to the
-"Pictures"_http://lammps.sandia.gov/pictures.html or
-"Movies"_http://lammps.sandia.gov/movies.html pages of the LAMMPS WWW
-site.
-
-The core group of LAMMPS developers is at Sandia National Labs:
-
-Steve Plimpton, sjplimp at sandia.gov
-Aidan Thompson, athomps at sandia.gov
-Paul Crozier, pscrozi at sandia.gov :ul
-
-The following folks are responsible for significant contributions to
-the code, or other aspects of the LAMMPS development effort.  Many of
-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
-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
-Mike Parks (Sandia), mlparks at sandia.gov, PERI package for Peridynamics
-Rudra Mukherjee (JPL), Rudranarayan.M.Mukherjee at jpl.nasa.gov, POEMS package for articulated rigid body motion
-Reese Jones (Sandia) and collaborators, rjones at sandia.gov, USER-ATC package for atom/continuum coupling
-Ilya Valuev (JIHT), valuev at physik.hu-berlin.de, USER-AWPMD package for wave-packet MD
-Christian Trott (U Tech Ilmenau), christian.trott at tu-ilmenau.de, USER-CUDA package
-Andres Jaramillo-Botero (Caltech), ajaramil at wag.caltech.edu, USER-EFF package for electron force field
-Christoph Kloss (JKU), Christoph.Kloss at jku.at, USER-LIGGGHTS package for granular models and granular/fluid coupling
-Metin Aktulga (LBL), hmaktulga at lbl.gov, USER-REAXC package for C version of ReaxFF
-Georg Gunzenmuller (EMI), georg.ganzenmueller at emi.fhg.de, USER-SPH package :ul
-
-As discussed in "Section_history"_Section_history.html, LAMMPS
-originated as a cooperative project between DOE labs and industrial
-partners. Folks involved in the design and testing of the original
-version of LAMMPS were the following:
-
-John Carpenter (Mayo Clinic, formerly at Cray Research)
-Terry Stouch (Lexicon Pharmaceuticals, formerly at Bristol Myers Squibb)
-Steve Lustig (Dupont)
-Jim Belak (LLNL) :ul

doc/Section_modify.txt

@@ -1,768 +0,0 @@
- "Previous Section"_Section_tools.html - "LAMMPS WWW Site"_lws -
-"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
-Section"_Section_python.html :c
-
-:link(lws,http://lammps.sandia.gov)
-:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
-
-:line
-
-10. Modifying & extending LAMMPS :h3
-
-This section describes how to customize LAMMPS by modifying
-and extending its source code.
-
-10.1 "Atom styles"_#mod_1
-10.2 "Bond, angle, dihedral, improper potentials"_#mod_2
-10.3 "Compute styles"_#mod_3
-10.4 "Dump styles"_#mod_4
-10.5 "Dump custom output options"_#mod_5
-10.6 "Fix styles"_#mod_6 which include integrators, \
-     temperature and pressure control, force constraints, \
-     boundary conditions, diagnostic output, etc
-10.7 "Input script commands"_mod_7
-10.8 "Kspace computations"_#mod_8
-10.9 "Minimization styles"_#mod_9
-10.10 "Pairwise potentials"_#mod_10
-10.11 "Region styles"_#mod_11
-10.12 "Body styles"_#mod_12
-10.13 "Thermodynamic output options"_#mod_13
-10.14 "Variable options"_#mod_14
-10.15 "Submitting new features for inclusion in LAMMPS"_#mod_15 :all(b)
-
-LAMMPS is designed in a modular fashion so as to be easy to modify and
-extend with new functionality.  In fact, about 75% of its source code
-is files added in this fashion.
-
-In this section, changes and additions users can make are listed along
-with minimal instructions.  If you add a new feature to LAMMPS and
-think it will be of interest to general users, we encourage you to
-submit it to the developers for inclusion in the released version of
-LAMMPS.  Information about how to do this is provided
-"below"_#mod_14.
-
-The best way to add a new feature is to find a similar feature in
-LAMMPS and look at the corresponding source and header files to figure
-out what it does.  You will need some knowledge of C++ to be able to
-understand the hi-level structure of LAMMPS and its class
-organization, but functions (class methods) that do actual
-computations are written in vanilla C-style code and operate on simple
-C-style data structures (vectors and arrays).
-
-Most of the new features described in this section require you to
-write a new C++ derived class (except for exceptions described below,
-where you can make small edits to existing files).  Creating a new
-class requires 2 files, a source code file (*.cpp) and a header file
-(*.h).  The derived class must provide certain methods to work as a
-new option.  Depending on how different your new feature is compared
-to existing features, you can either derive from the base class
-itself, or from a derived class that already exists.  Enabling LAMMPS
-to invoke the new class is as simple as putting the two source
-files in the src dir and re-building LAMMPS.
-
-The advantage of C++ and its object-orientation is that all the code
-and variables needed to define the new feature are in the 2 files you
-write, and thus shouldn't make the rest of LAMMPS more complex or
-cause side-effect bugs.
-
-Here is a concrete example.  Suppose you write 2 files pair_foo.cpp
-and pair_foo.h that define a new class PairFoo that computes pairwise
-potentials described in the classic 1997 "paper"_#Foo by Foo, et al.
-If you wish to invoke those potentials in a LAMMPS input script with a
-command like
-
-pair_style foo 0.1 3.5 :pre
-
-then your pair_foo.h file should be structured as follows:
-
-#ifdef PAIR_CLASS
-PairStyle(foo,PairFoo)
-#else
-...
-(class definition for PairFoo)
-...
-#endif :pre
-
-where "foo" is the style keyword in the pair_style command, and
-PairFoo is the class name defined in your pair_foo.cpp and pair_foo.h
-files.
-
-When you re-build LAMMPS, your new pairwise potential becomes part of
-the executable and can be invoked with a pair_style command like the
-example above.  Arguments like 0.1 and 3.5 can be defined and
-processed by your new class.
-
-As illustrated by this pairwise example, many kinds of options are
-referred to in the LAMMPS documentation as the "style" of a particular
-command.
-
-The instructions below give the header file for the base class that
-these styles are derived from.  Public variables in that file are ones
-used and set by the derived classes which are also used by the base
-class.  Sometimes they are also used by the rest of LAMMPS.  Virtual
-functions in the base class header file which are set = 0 are ones you
-must define in your new derived class to give it the functionality
-LAMMPS expects.  Virtual functions that are not set to 0 are functions
-you can optionally define.
-
-Additionally, new output options can be added directly to the
-thermo.cpp, dump_custom.cpp, and variable.cpp files as explained
-below.
-
-Here are additional guidelines for modifying LAMMPS and adding new
-functionality:
-
-Think about whether what you want to do would be better as a pre- or
-post-processing step.  Many computations are more easily and more
-quickly done that way. :ulb,l
-
-Don't do anything within the timestepping of a run that isn't
-parallel.  E.g. don't accumulate a bunch of data on a single processor
-and analyze it.  You run the risk of seriously degrading the parallel
-efficiency. :l
-
-If your new feature reads arguments or writes output, make sure you
-follow the unit conventions discussed by the "units"_units.html
-command. :l
-
-If you add something you think is truly useful and doesn't impact
-LAMMPS performance when it isn't used, send an email to the
-"developers"_http://lammps.sandia.gov/authors.html.  We might be
-interested in adding it to the LAMMPS distribution.  See further
-details on this at the bottom of this page. :l,ule
-
-:line
-:line
-
-10.1 Atom styles :link(mod_1),h4
-
-Classes that define an "atom style"_atom_style.html are derived from
-the AtomVec class and managed by the Atom class.  The atom style
-determines what attributes are associated with an atom.  A new atom
-style can be created if one of the existing atom styles does not
-define all the attributes you need to store and communicate with
-atoms.
-
-Atom_vec_atomic.cpp is a simple example of an atom style.
-
-Here is a brief description of methods you define in your new derived
-class.  See atom_vec.h for details.
-
-init: one time setup (optional)
-grow: re-allocate atom arrays to longer lengths (required)
-grow_reset: make array pointers in Atom and AtomVec classes consistent (required)
-copy: copy info for one atom to another atom's array locations (required)
-pack_comm: store an atom's info in a buffer communicated every timestep (required)
-pack_comm_vel: add velocity info to communication buffer (required)
-pack_comm_hybrid: store extra info unique to this atom style (optional)
-unpack_comm: retrieve an atom's info from the buffer (required)
-unpack_comm_vel: also retrieve velocity info (required)
-unpack_comm_hybrid: retreive extra info unique to this atom style (optional)
-pack_reverse: store an atom's info in a buffer communicating partial forces  (required)
-pack_reverse_hybrid: store extra info unique to this atom style (optional)
-unpack_reverse: retrieve an atom's info from the buffer (required)
-unpack_reverse_hybrid: retreive extra info unique to this atom style (optional)
-pack_border: store an atom's info in a buffer communicated on neighbor re-builds (required)
-pack_border_vel: add velocity info to buffer (required)
-pack_border_hybrid: store extra info unique to this atom style (optional)
-unpack_border: retrieve an atom's info from the buffer (required)
-unpack_border_vel: also retrieve velocity info (required)
-unpack_border_hybrid: retreive extra info unique to this atom style (optional)
-pack_exchange: store all an atom's info to migrate to another processor (required)
-unpack_exchange: retrieve an atom's info from the buffer (required)
-size_restart: number of restart quantities associated with proc's atoms (required)
-pack_restart: pack atom quantities into a buffer (required)
-unpack_restart: unpack atom quantities from a buffer (required)
-create_atom: create an individual atom of this style (required)
-data_atom: parse an atom line from the data file (required)
-data_atom_hybrid: parse additional atom info unique to this atom style (optional)
-data_vel: parse one line of velocity information from data file (optional)
-data_vel_hybrid: parse additional velocity data unique to this atom style (optional)
-memory_usage: tally memory allocated by atom arrays (required) :tb(s=:)
-
-The constructor of the derived class sets values for several variables
-that you must set when defining a new atom style, which are documented
-in atom_vec.h.  New atom arrays are defined in atom.cpp.  Search for
-the word "customize" and you will find locations you will need to
-modify.
-
-NOTE: It is possible to add some attributes, such as a molecule ID, to
-atom styles that do not have them via the "fix
-property/atom"_fix_property_atom.html command.  This command also
-allows new custom attributes consisting of extra integer or
-floating-point values to be added to atoms.  See the "fix
-property/atom"_fix_property_atom.html doc page for examples of cases
-where this is useful and details on how to initialize, access, and
-output the custom values.
-
-New "pair styles"_pair_style.html, "fixes"_fix.html, or
-"computes"_compute.html can be added to LAMMPS, as discussed below.
-The code for these classes can use the per-atom properties defined by
-fix property/atom.  The Atom class has a find_custom() method that is
-useful in this context:
-
-int index = atom->find_custom(char *name, int &flag); :pre
-
-The "name" of a custom attribute, as specified in the "fix
-property/atom"_fix_property_atom.html command, is checked to verify
-that it exists and its index is returned.  The method also sets flag =
-0/1 depending on whether it is an integer or floating-point attribute.
-The vector of values associated with the attribute can then be
-accessed using the returned index as
-
-int *ivector = atom->ivector\[index\];
-double *dvector = atom->dvector\[index\]; :pre
-
-Ivector or dvector are vectors of length Nlocal = # of owned atoms,
-which store the attributes of individual atoms.
-
-:line
-
-10.2 Bond, angle, dihedral, improper potentials :link(mod_2),h4
-
-Classes that compute molecular interactions are derived from the Bond,
-Angle, Dihedral, and Improper classes.  New styles can be created to
-add new potentials to LAMMPS.
-
-Bond_harmonic.cpp is the simplest example of a bond style.  Ditto for
-the harmonic forms of the angle, dihedral, and improper style
-commands.
-
-Here is a brief description of common methods you define in your
-new derived class.  See bond.h, angle.h, dihedral.h, and improper.h
-for details and specific additional methods.
-
-init: check if all coefficients are set, calls {init_style} (optional)
-init_style: check if style specific conditions are met (optional)
-compute: compute the molecular interactions (required)
-settings: apply global settings for all types (optional)
-coeff: set coefficients for one type (required)
-equilibrium_distance: length of bond, used by SHAKE (required, bond only)
-equilibrium_angle: opening of angle, used by SHAKE (required, angle only)
-write & read_restart: writes/reads coeffs to restart files (required)
-single: force and energy of a single bond or angle (required, bond or angle only)
-memory_usage: tally memory allocated by the style (optional) :tb(s=:)
-
-:line
-
-10.3 Compute styles :link(mod_3),h4
-
-Classes that compute scalar and vector quantities like temperature
-and the pressure tensor, as well as classes that compute per-atom
-quantities like kinetic energy and the centro-symmetry parameter
-are derived from the Compute class.  New styles can be created
-to add new calculations to LAMMPS.
-
-Compute_temp.cpp is a simple example of computing a scalar
-temperature.  Compute_ke_atom.cpp is a simple example of computing
-per-atom kinetic energy.
-
-Here is a brief description of methods you define in your new derived
-class.  See compute.h for details.
-
-init: perform one time setup (required)
-init_list: neighbor list setup, if needed (optional)
-compute_scalar: compute a scalar quantity (optional)
-compute_vector: compute a vector of quantities (optional)
-compute_peratom: compute one or more quantities per atom (optional)
-compute_local: compute one or more quantities per processor (optional)
-pack_comm: pack a buffer with items to communicate (optional)
-unpack_comm: unpack the buffer (optional)
-pack_reverse: pack a buffer with items to reverse communicate (optional)
-unpack_reverse: unpack the buffer (optional)
-remove_bias: remove velocity bias from one atom (optional)
-remove_bias_all: remove velocity bias from all atoms in group (optional)
-restore_bias: restore velocity bias for one atom after remove_bias (optional)
-restore_bias_all: same as before, but for all atoms in group (optional)
-pair_tally_callback: callback function for {tally}-style computes (optional).
-memory_usage: tally memory usage (optional) :tb(s=:)
-
-Tally-style computes are a special case, as their computation is done
-in two stages: the callback function is registered with the pair style
-and then called from the Pair::ev_tally() function, which is called for
-each pair after force and energy has been computed for this pair. Then
-the tallied values are retrieved with the standard compute_scalar or
-compute_vector or compute_peratom methods. The USER-TALLY package
-provides {examples}_compute_tally.html for utilizing this mechanism.
-
-:line
-
-10.4 Dump styles :link(mod_4),h4
-10.5 Dump custom output options :link(mod_5),h4
-
-Classes that dump per-atom info to files are derived from the Dump
-class.  To dump new quantities or in a new format, a new derived dump
-class can be added, but it is typically simpler to modify the
-DumpCustom class contained in the dump_custom.cpp file.
-
-Dump_atom.cpp is a simple example of a derived dump class.
-
-Here is a brief description of methods you define in your new derived
-class.  See dump.h for details.
-
-write_header: write the header section of a snapshot of atoms
-count: count the number of lines a processor will output
-pack: pack a proc's output data into a buffer
-write_data: write a proc's data to a file :tb(s=:)
-
-See the "dump"_dump.html command and its {custom} style for a list of
-keywords for atom information that can already be dumped by
-DumpCustom.  It includes options to dump per-atom info from Compute
-classes, so adding a new derived Compute class is one way to calculate
-new quantities to dump.
-
-Alternatively, you can add new keywords to the dump custom command.
-Search for the word "customize" in dump_custom.cpp to see the
-half-dozen or so locations where code will need to be added.
-
-:line
-
-10.6 Fix styles :link(mod_6),h4
-
-In LAMMPS, a "fix" is any operation that is computed during
-timestepping that alters some property of the system.  Essentially
-everything that happens during a simulation besides force computation,
-neighbor list construction, and output, is a "fix".  This includes
-time integration (update of coordinates and velocities), force
-constraints or boundary conditions (SHAKE or walls), and diagnostics
-(compute a diffusion coefficient).  New styles can be created to add
-new options to LAMMPS.
-
-Fix_setforce.cpp is a simple example of setting forces on atoms to
-prescribed values.  There are dozens of fix options already in LAMMPS;
-choose one as a template that is similar to what you want to
-implement.
-
-Here is a brief description of methods you can define in your new
-derived class.  See fix.h for details.
-
-setmask: determines when the fix is called during the timestep (required)
-init: initialization before a run (optional)
-setup_pre_exchange: called before atom exchange in setup (optional)
-setup_pre_force: called before force computation in setup (optional)
-setup: called immediately before the 1st timestep and after forces are computed (optional)
-min_setup_pre_force: like setup_pre_force, but for minimizations instead of MD runs (optional)
-min_setup: like setup, but for minimizations instead of MD runs (optional)
-initial_integrate: called at very beginning of each timestep (optional)
-pre_exchange: called before atom exchange on re-neighboring steps (optional)
-pre_neighbor: called before neighbor list build (optional)
-pre_force: called before pair & molecular forces are computed (optional)
-post_force: called after pair & molecular forces are computed and communicated (optional)
-final_integrate: called at end of each timestep (optional)
-end_of_step: called at very end of timestep (optional)
-write_restart: dumps fix info to restart file (optional)
-restart: uses info from restart file to re-initialize the fix (optional)
-grow_arrays: allocate memory for atom-based arrays used by fix (optional)
-copy_arrays: copy atom info when an atom migrates to a new processor (optional)
-pack_exchange: store atom's data in a buffer (optional)
-unpack_exchange: retrieve atom's data from a buffer (optional)
-pack_restart: store atom's data for writing to restart file (optional)
-unpack_restart: retrieve atom's data from a restart file buffer (optional)
-size_restart: size of atom's data (optional)
-maxsize_restart: max size of atom's data (optional)
-setup_pre_force_respa: same as setup_pre_force, but for rRESPA (optional)
-initial_integrate_respa: same as initial_integrate, but for rRESPA (optional)
-post_integrate_respa: called after the first half integration step is done in rRESPA (optional)
-pre_force_respa: same as pre_force, but for rRESPA (optional)
-post_force_respa: same as post_force, but for rRESPA (optional)
-final_integrate_respa: same as final_integrate, but for rRESPA (optional)
-min_pre_force: called after pair & molecular forces are computed in minimizer (optional)
-min_post_force: called after pair & molecular forces are computed and communicated in minmizer (optional)
-min_store: store extra data for linesearch based minimization on a LIFO stack (optional)
-min_pushstore: push the minimization LIFO stack one element down (optional)
-min_popstore: pop the minimization LIFO stack one element up (optional)
-min_clearstore: clear minimization LIFO stack (optional)
-min_step: reset or move forward on line search minimization (optional)
-min_dof: report number of degrees of freedom {added} by this fix in minimization (optional)
-max_alpha: report maximum allowed step size during linesearch minimization (optional)
-pack_comm: pack a buffer to communicate a per-atom quantity (optional)
-unpack_comm: unpack a buffer to communicate a per-atom quantity (optional)
-pack_reverse_comm: pack a buffer to reverse communicate a per-atom quantity (optional)
-unpack_reverse_comm: unpack a buffer to reverse communicate a per-atom quantity (optional)
-dof: report number of degrees of freedom {removed} by this fix during MD (optional)
-compute_scalar: return a global scalar property that the fix computes (optional)
-compute_vector: return a component of a vector property that the fix computes (optional)
-compute_array: return a component of an array property that the fix computes (optional)
-deform: called when the box size is changed (optional)
-reset_target: called when a change of the target temperature is requested during a run (optional)
-reset_dt: is called when a change of the time step is requested during a run (optional)
-modify_param: called when a fix_modify request is executed (optional)
-memory_usage: report memory used by fix (optional)
-thermo: compute quantities for thermodynamic output (optional) :tb(s=:)
-
-Typically, only a small fraction of these methods are defined for a
-particular fix.  Setmask is mandatory, as it determines when the fix
-will be invoked during the timestep.  Fixes that perform time
-integration ({nve}, {nvt}, {npt}) implement initial_integrate() and
-final_integrate() to perform velocity Verlet updates.  Fixes that
-constrain forces implement post_force().
-
-Fixes that perform diagnostics typically implement end_of_step().  For
-an end_of_step fix, one of your fix arguments must be the variable
-"nevery" which is used to determine when to call the fix and you must
-set this variable in the constructor of your fix.  By convention, this
-is the first argument the fix defines (after the ID, group-ID, style).
-
-If the fix needs to store information for each atom that persists from
-timestep to timestep, it can manage that memory and migrate the info
-with the atoms as they move from processors to processor by
-implementing the grow_arrays, copy_arrays, pack_exchange, and
-unpack_exchange methods.  Similarly, the pack_restart and
-unpack_restart methods can be implemented to store information about
-the fix in restart files.  If you wish an integrator or force
-constraint fix to work with rRESPA (see the "run_style"_run_style.html
-command), the initial_integrate, post_force_integrate, and
-final_integrate_respa methods can be implemented.  The thermo method
-enables a fix to contribute values to thermodynamic output, as printed
-quantities and/or to be summed to the potential energy of the system.
-
-:line
-
-10.7 Input script commands :link(mod_7),h4
-
-New commands can be added to LAMMPS input scripts by adding new
-classes that have a "command" method.  For example, the create_atoms,
-read_data, velocity, and run commands are all implemented in this
-fashion.  When such a command is encountered in the LAMMPS input
-script, LAMMPS simply creates a class with the corresponding name,
-invokes the "command" method of the class, and passes it the arguments
-from the input script.  The command method can perform whatever
-operations it wishes on LAMMPS data structures.
-
-The single method your new class must define is as follows:
-
-command: operations performed by the new command :tb(s=:)
-
-Of course, the new class can define other methods and variables as
-needed.
-
-:line
-
-10.8 Kspace computations :link(mod_8),h4
-
-Classes that compute long-range Coulombic interactions via K-space
-representations (Ewald, PPPM) are derived from the KSpace class.  New
-styles can be created to add new K-space options to LAMMPS.
-
-Ewald.cpp is an example of computing K-space interactions.
-
-Here is a brief description of methods you define in your new derived
-class.  See kspace.h for details.
-
-init: initialize the calculation before a run
-setup: computation before the 1st timestep of a run
-compute: every-timestep computation
-memory_usage: tally of memory usage :tb(s=:)
-
-:line
-
-10.9 Minimization styles :link(mod_9),h4
-
-Classes that perform energy minimization derived from the Min class.
-New styles can be created to add new minimization algorithms to
-LAMMPS.
-
-Min_cg.cpp is an example of conjugate gradient minimization.
-
-Here is a brief description of methods you define in your new derived
-class.  See min.h for details.
-
-init: initialize the minimization before a run
-run: perform the minimization
-memory_usage: tally of memory usage :tb(s=:)
-
-:line
-
-10.10 Pairwise potentials :link(mod_10),h4
-
-Classes that compute pairwise interactions are derived from the Pair
-class.  In LAMMPS, pairwise calculation include manybody potentials
-such as EAM or Tersoff where particles interact without a static bond
-topology.  New styles can be created to add new pair potentials to
-LAMMPS.
-
-Pair_lj_cut.cpp is a simple example of a Pair class, though it
-includes some optional methods to enable its use with rRESPA.
-
-Here is a brief description of the class methods in pair.h:
-
-compute: workhorse routine that computes pairwise interactions
-settings: reads the input script line with arguments you define
-coeff: set coefficients for one i,j type pair
-init_one: perform initialization for one i,j type pair
-init_style: initialization specific to this pair style
-write & read_restart: write/read i,j pair coeffs to restart files
-write & read_restart_settings: write/read global settings to restart files
-single: force and energy of a single pairwise interaction between 2 atoms
-compute_inner/middle/outer: versions of compute used by rRESPA :tb(s=:)
-
-The inner/middle/outer routines are optional.
-
-:line
-
-10.11 Region styles :link(mod_11),h4
-
-Classes that define geometric regions are derived from the Region
-class.  Regions are used elsewhere in LAMMPS to group atoms, delete
-atoms to create a void, insert atoms in a specified region, etc.  New
-styles can be created to add new region shapes to LAMMPS.
-
-Region_sphere.cpp is an example of a spherical region.
-
-Here is a brief description of methods you define in your new derived
-class.  See region.h for details.
-
-match: determine whether a point is in the region :tb(s=:)
-
-:line
-
-10.11 Body styles :link(mod_12),h4
-
-Classes that define body particles are derived from the Body class.
-Body particles can represent complex entities, such as surface meshes
-of discrete points, collections of sub-particles, deformable objects,
-etc.
-
-See "Section_howto 14"_Section_howto.html#howto_14 of the manual for
-an overview of using body particles and the "body"_body.html doc page
-for details on the various body styles LAMMPS supports.  New styles
-can be created to add new kinds of body particles to LAMMPS.
-
-Body_nparticle.cpp is an example of a body particle that is treated as
-a rigid body containing N sub-particles.
-
-Here is a brief description of methods you define in your new derived
-class.  See body.h for details.
-
-data_body: process a line from the Bodies section of a data file
-noutrow: number of sub-particles output is generated for
-noutcol: number of values per-sub-particle output is generated for
-output: output values for the Mth sub-particle
-pack_comm_body: body attributes to communicate every timestep
-unpack_comm_body: unpacking of those attributes
-pack_border_body: body attributes to communicate when reneighboring is done
-unpack_border_body: unpacking of those attributes :tb(s=:)
-
-:line
-
-10.13 Thermodynamic output options :link(mod_13),h4
-
-There is one class that computes and prints thermodynamic information
-to the screen and log file; see the file thermo.cpp.
-
-There are two styles defined in thermo.cpp: "one" and "multi".  There
-is also a flexible "custom" style which allows the user to explicitly
-list keywords for quantities to print when thermodynamic info is
-output.  See the "thermo_style"_thermo_style.html command for a list
-of defined quantities.
-
-The thermo styles (one, multi, etc) are simply lists of keywords.
-Adding a new style thus only requires defining a new list of keywords.
-Search for the word "customize" with references to "thermo style" in
-thermo.cpp to see the two locations where code will need to be added.
-
-New keywords can also be added to thermo.cpp to compute new quantities
-for output.  Search for the word "customize" with references to
-"keyword" in thermo.cpp to see the several locations where code will
-need to be added.
-
-Note that the "thermo_style custom"_thermo.html command already allows
-for thermo output of quantities calculated by "fixes"_fix.html,
-"computes"_compute.html, and "variables"_variable.html.  Thus, it may
-be simpler to compute what you wish via one of those constructs, than
-by adding a new keyword to the thermo command.
-
-:line
-
-10.14 Variable options :link(mod_14),h4
-
-There is one class that computes and stores "variable"_variable.html
-information in LAMMPS; see the file variable.cpp.  The value
-associated with a variable can be periodically printed to the screen
-via the "print"_print.html, "fix print"_fix_print.html, or
-"thermo_style custom"_thermo_style.html commands.  Variables of style
-"equal" can compute complex equations that involve the following types
-of arguments:
-
-thermo keywords = ke, vol, atoms, ...
-other variables = v_a, v_myvar, ...
-math functions = div(x,y), mult(x,y), add(x,y), ...
-group functions = mass(group), xcm(group,x), ...
-atom values = x\[123\], y\[3\], vx\[34\], ...
-compute values = c_mytemp\[0\], c_thermo_press\[3\], ... :pre
-
-Adding keywords for the "thermo_style custom"_thermo_style.html command
-(which can then be accessed by variables) was discussed
-"here"_Section_modify.html#thermo on this page.
-
-Adding a new math function of one or two arguments can be done by
-editing one section of the Variable::evaulate() method.  Search for
-the word "customize" to find the appropriate location.
-
-Adding a new group function can be done by editing one section of the
-Variable::evaulate() method.  Search for the word "customize" to find
-the appropriate location.  You may need to add a new method to the
-Group class as well (see the group.cpp file).
-
-Accessing a new atom-based vector can be done by editing one section
-of the Variable::evaulate() method.  Search for the word "customize"
-to find the appropriate location.
-
-Adding new "compute styles"_compute.html (whose calculated values can
-then be accessed by variables) was discussed
-"here"_Section_modify.html#compute on this page.
-
-:line
-:line
-
-10.15 Submitting new features for inclusion in LAMMPS :link(mod_15),h4
-
-We encourage users to submit new features to "the
-developers"_http://lammps.sandia.gov/authors.html that they add to
-LAMMPS, especially if you think they will be of interest to other
-users.  If they are broadly useful we may add them as core files to
-LAMMPS or as part of a "standard package"_Section_start.html#start_3.
-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 the 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"_Section_intro.html#intro_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"_http://lammps.sandia.gov/authors.html
-of the "LAMMPS WWW site"_lws), 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're 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).
-
-NOTE: If you prefer to actively develop and support your add-on
-feature yourself, then you may wish to make it available for download
-from your own website, as a user package that LAMMPS users can add to
-their copy of LAMMPS.  See the "Offsite LAMMPS packages and
-tools"_http://lammps.sandia.gov/offsite.html page of the LAMMPS web
-site for examples of groups that do this.  We are happy to advertise
-your package and web site from that page.  Simply email the
-"developers"_http://lammps.sandia.gov/authors.html with info about
-your package and we will post it there.
-
-The previous sections of this doc page describe how to add new "style"
-files of various kinds to LAMMPS.  Packages are simply collections of
-one or more new class files which are invoked as a new style within a
-LAMMPS input script.  If designed correctly, these additions typically
-do not require changes to the main core of LAMMPS; they are simply
-add-on files.  If you think your new feature requires non-trivial
-changes in core LAMMPS files, you'll need to "communicate with the
-developers"_http://lammps.sandia.gov/authors.html, since we may or may
-not want to make those changes.  An example of a trivial change is
-making a parent-class method "virtual" when you derive a new child
-class from it.
-
-Here are the 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 src dir for
-examples.
-
-All source files you provide must compile with the most current
-version of LAMMPS. :ulb,l
-
-If you want your file(s) to be added to main LAMMPS or one of its
-standard packages, then it needs to be written in a style compatible
-with other LAMMPS source files.  This is so the developers can
-understand it and hopefully maintain it.  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. :l
-
-If you want your contribution to be added as a user-contributed
-feature, and it's a single file (actually a *.cpp and *.h file) it can
-rapidly be added to the USER-MISC directory.  Send us the one-line
-entry to add to the USER-MISC/README file in that dir, along with the
-2 source files.  You can do this multiple times if you wish to
-contribute several individual features.  :l
-
-If you want your contribution to be added as a user-contribution and
-it is several related featues, 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. :l
-
-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. :l
-
-You must also create a documentation file for each new command or
-style you are adding to LAMMPS.  This will be one file for a
-single-file feature.  For a package, it might be several files.  These
-are simple text files which we auto-convert to HTML.  Thus they must
-be in the same format as other *.txt files in the lammps/doc directory
-for similar commands and styles; use one or more of them as a starting
-point.  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
-txt2html tool we use to convert to HTML can be downloaded from "this
-site"_http://www.sandia.gov/~sjplimp/download.html, so you can perform
-the HTML conversion yourself to proofread your doc page. :l
-
-For a new package (or even a single command) you can include one or
-more example scripts.  These should run in no more than 1 minute, 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. :l
-
-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. :l,ule
-
-Finally, as a general rule-of-thumb, the more clear and
-self-explanatory you make your doc 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.
-
-:line
-:line
-
-:link(Foo)
-[(Foo)] Foo, Morefoo, and Maxfoo, J of Classic Potentials, 75, 345 (1997).

doc/Section_packages.txt

@@ -1,889 +0,0 @@
-"Previous Section"_Section_commands.html - "LAMMPS WWW Site"_lws -
-"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
-Section"_Section_accelerate.html :c
-
-:link(lws,http://lammps.sandia.gov)
-:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
-
-:line
-
-4. Packages :h3
-
-This section gives a quick overview of the add-on packages that extend
-LAMMPS functionality.
-
-4.1 "Standard packages"_#pkg_1
-4.2 "User packages"_#pkg_2 :all(b)
-
-LAMMPS includes many optional packages, which are groups of files that
-enable a specific set of features.  For example, force fields for
-molecular systems or granular systems are in packages.  You can see
-the list of all packages by typing "make package" from within the src
-directory of the LAMMPS distribution.
-
-See "Section_start 3"_Section_start.html#start_3 of the manual for
-details on how to include/exclude specific packages as part of the
-LAMMPS build process, and for more details about the differences
-between standard packages and user packages.
-
-Unless otherwise noted below, every package is independent of all the
-others.  I.e. any package can be included or excluded in a LAMMPS
-build, independent of all other packages.  However, note that some
-packages include commands derived from commands in other packages.  If
-the other package is not installed, the derived command from the new
-package will also not be installed when you include the new one.
-E.g. the pair lj/cut/coul/long/omp command from the USER-OMP package
-will not be installed as part of the USER-OMP package if the KSPACE
-package is not also installed, since it contains the pair
-lj/cut/coul/long command.  If you later install the KSPACE pacakge and
-the USER-OMP package is already installed, both the pair
-lj/cut/coul/long and lj/cut/coul/long/omp commands will be installed.
-
-The two tables below list currently available packages in LAMMPS, with
-a one-line descriptions of each.  The sections below give a few more
-details, including instructions for building LAMMPS with the package,
-either via the make command or the Make.py tool described in "Section
-2.4"_Section_start.html#start_4.
-
-:line
-:line
-
-4.1 Standard packages :h4,link(pkg_1)
-
-The current list of standard packages is as follows. 
-
-Package, Description, Author(s), Doc page, Example, Library
-ASPHERE, aspherical particles, -, "Section_howto 6.14"_Section_howto.html#howto_14, ellipse, -
-BODY, body-style particles, -, "body"_body.html, body, -
-CLASS2, class 2 force fields, -, "pair_style lj/class2"_pair_class2.html, -, -
-COLLOID, colloidal particles, -, "atom_style colloid"_atom_style.html, colloid, -
-COMPRESS, I/O compression, Axel Kohlmeyer (Temple U), "dump */gz"_dump.html, -, -
-CORESHELL, adiabatic core/shell model, Hendrik Heenen (Technical U of Munich), "Section_howto 6.25"_Section_howto.html#howto_25, coreshell, -
-DIPOLE, point dipole particles, -, "pair_style dipole/cut"_pair_dipole.html, dipole, -
-FLD, Fast Lubrication Dynamics, Kumar & Bybee & Higdon (1), "pair_style lubricateU"_pair_lubricateU.html, -, -
-GPU, GPU-enabled styles, Mike Brown (ORNL), "Section accelerate"_accelerate_gpu.html, gpu, lib/gpu
-GRANULAR, granular systems, -, "Section_howto 6.6"_Section_howto.html#howto_6, pour, -
-KIM, openKIM potentials, Smirichinski & Elliot & Tadmor (3), "pair_style kim"_pair_kim.html, kim, KIM
-KOKKOS, Kokkos-enabled styles, Trott & Edwards (4), "Section_accelerate"_accelerate_kokkos.html, kokkos, lib/kokkos
-KSPACE, long-range Coulombic solvers, -, "kspace_style"_kspace_style.html, peptide, -
-MANYBODY, many-body potentials, -, "pair_style tersoff"_pair_tersoff.html, shear, -
-MEAM, modified EAM potential, Greg Wagner (Sandia), "pair_style meam"_pair_meam.html, meam, lib/meam
-MC, Monte Carlo options, -, "fix gcmc"_fix_gcmc.html, -, -
-MOLECULE, molecular system force fields, -, "Section_howto 6.3"_Section_howto.html#howto_3, peptide, -
-OPT, optimized pair styles, Fischer & Richie & Natoli (2), "Section accelerate"_accelerate_opt.html, -, -
-PERI, Peridynamics models, Mike Parks (Sandia), "pair_style peri"_pair_peri.html, peri, -
-POEMS, coupled rigid body motion, Rudra Mukherjee (JPL), "fix poems"_fix_poems.html, rigid, lib/poems
-PYTHON, embed Python code in an input script, -, "python"_python.html, python, lib/python
-REAX, ReaxFF potential, Aidan Thompson (Sandia), "pair_style reax"_pair_reax.html, reax,  lib/reax
-REPLICA, multi-replica methods, -, "Section_howto 6.5"_Section_howto.html#howto_5, tad, -
-RIGID, rigid bodies, -, "fix rigid"_fix_rigid.html, rigid, -
-SHOCK, shock loading methods, -, "fix msst"_fix_msst.html, -, -
-SNAP, quantum-fit potential, Aidan Thompson (Sandia), "pair snap"_pair_snap.html, snap, -
-SRD, stochastic rotation dynamics, -, "fix srd"_fix_srd.html, srd, -
-VORONOI, Voronoi tesselations, Daniel Schwen (LANL), "compute voronoi/atom"_compute_voronoi_atom.html, -, Voro++
-XTC, dumps in XTC format, -, "dump"_dump.html, -, -
-:tb(ea=c)
-
-The "Authors" column lists a name(s) if a specific person is
-responible for creating and maintaining the package.
-More details on
-multiple authors are give below.
-
-(1) The FLD package was created by Amit Kumar and Michael Bybee from
-Jonathan Higdon's group at UIUC.
-
-(2) The OPT package was created by James Fischer (High Performance
-Technologies), David Richie, and Vincent Natoli (Stone Ridge
-Technolgy).
-
-(3) The KIM package was created by Valeriu Smirichinski, Ryan Elliott,
-and Ellad Tadmor (U Minn).
-
-(4) The KOKKOS package was created primarily by Christian Trott
-(Sandia).  It uses the Kokkos library which was developed by Carter
-Edwards, Christian, and collaborators at Sandia.
-
-The "Doc page" column links to either a portion of the
-"Section_howto"_Section_howto.html of the manual, or an input script
-command implemented as part of the package.
-
-The "Example" column is a sub-directory in the examples directory of
-the distribution which has an input script that uses the package.
-E.g. "peptide" refers to the examples/peptide directory.
-
-The "Library" column lists an external library which must be built
-first and which LAMMPS links to when it is built.  If it is listed as
-lib/package, then the code for the library is under the lib directory
-of the LAMMPS distribution.  See the lib/package/README file for info
-on how to build the library.  If it is not listed as lib/package, then
-it is a third-party library not included in the LAMMPS distribution.
-See the src/package/README or src/package/Makefile.lammps file for
-info on where to download the library.  "Section
-start"_Section_start.html#start_3_3 of the manual also gives details
-on how to build LAMMPS with both kinds of auxiliary libraries.
-
-Except where explained below, all of these packages can be installed,
-and LAMMPS re-built, by issuing these commands from the src dir.
-
-make yes-package
-make machine
-or
-Make.py -p package -a machine :pre
-
-To un-install the package and re-build LAMMPS without it:
-
-make no-package
-make machine
-or
-Make.py -p ^package -a machine :pre
-
-"Package" is the name of the package in lower-case letters,
-e.g. asphere or rigid, and "machine" is the build target, e.g. mpi or
-serial.
-
-:line
-:line
-
-Build instructions for COMPRESS package :h4
-
-:line
-
-Build instructions for GPU package :h4
-
-:line
-
-Build instructions for KIM package :h4
-
-:line
-
-Build instructions for KOKKOS package :h4
-
-:line
-
-Build instructions for KSPACE package :h4
-
-:line
-
-Build instructions for MEAM package :h4
-
-:line
-
-Build instructions for POEMS package :h4
-
-:line
-
-Build instructions for PYTHON package :h4
-
-:line
-
-Build instructions for REAX package :h4
-
-:line
-
-Build instructions for VORONOI package :h4
-
-:line
-
-Build instructions for XTC package :h4
-
-:line
-:line
-
-4.2 User packages :h4,link(pkg_2)
-
-The current list of user-contributed packages is as follows:
-
-Package, Description, Author(s), Doc page, Example, Pic/movie, Library
-USER-ATC, atom-to-continuum coupling, Jones & Templeton & Zimmerman (1), "fix atc"_fix_atc.html, USER/atc, "atc"_atc, lib/atc
-USER-AWPMD, wave-packet MD, Ilya Valuev (JIHT), "pair_style awpmd/cut"_pair_awpmd.html, USER/awpmd, -, lib/awpmd
-USER-CG-CMM, coarse-graining model, Axel Kohlmeyer (Temple U), "pair_style lj/sdk"_pair_sdk.html, USER/cg-cmm, "cg"_cg, -
-USER-COLVARS, collective variables, Fiorin & Henin & Kohlmeyer (2), "fix colvars"_fix_colvars.html, USER/colvars, "colvars"_colvars, lib/colvars
-USER-CUDA, NVIDIA GPU styles, Christian Trott (U Tech Ilmenau), "Section accelerate"_accelerate_cuda.html, USER/cuda, -, lib/cuda
-USER-DIFFRACTION, virutal x-ray and electron diffraction, Shawn Coleman (ARL),"compute xrd"_compute_xrd.html, USER/diffraction, -, -
-USER-DPD, dissipative particle dynamics (DPD), Larentzos & Mattox & Brennan (5), src/USER-DPD/README, USER/dpd, -, -
-USER-DRUDE, Drude oscillators, Dequidt & Devemy & Padua (3), "tutorial"_tutorial_drude.html, USER/drude, -, -
-USER-EFF, electron force field, Andres Jaramillo-Botero (Caltech), "pair_style eff/cut"_pair_eff.html, USER/eff, "eff"_eff, -
-USER-FEP, free energy perturbation, Agilio Padua (U Blaise Pascal Clermont-Ferrand), "compute fep"_compute_fep.html, USER/fep, -, -
-USER-H5MD, dump output via HDF5, Pierre de Buyl (KU Leuven), "dump h5md"_dump_h5md.html, -, -, lib/h5md
-USER-INTEL, Vectorized CPU and Intel(R) coprocessor styles, W. Michael Brown (Intel), "Section accelerate"_accelerate_intel.html, examples/intel, -, -
-USER-LB, Lattice Boltzmann fluid, Colin Denniston (U Western Ontario), "fix lb/fluid"_fix_lb_fluid.html, USER/lb, -, -
-USER-MGPT, fast MGPT multi-ion potentials, Tomas Oppelstrup & John Moriarty (LLNL), "pair_style mgpt"_pair_mgpt.html, USER/mgpt, -, -
-USER-MISC, single-file contributions, USER-MISC/README, USER-MISC/README, -, -, -
-USER-MOLFILE, "VMD"_VMD molfile plug-ins, Axel Kohlmeyer (Temple U), "dump molfile"_dump_molfile.html, -, -, VMD-MOLFILE
-USER-OMP, OpenMP threaded styles, Axel Kohlmeyer (Temple U), "Section accelerate"_accelerate_omp.html, -, -, -
-USER-PHONON, phonon dynamical matrix, Ling-Ti Kong (Shanghai Jiao Tong U), "fix phonon"_fix_phonon.html, USER/phonon, -, -
-USER-QMMM, QM/MM coupling, Axel Kohlmeyer (Temple U), "fix qmmm"_fix_qmmm.html, USER/qmmm, -, lib/qmmm
-USER-QTB, quantum nuclear effects, Yuan Shen (Stanford), "fix qtb"_fix_qtb.html "fix_qbmsst"_fix_qbmsst.html, qtb, -, -
-USER-QUIP, QUIP/libatoms interface, Albert Bartok-Partay (U Cambridge), "pair_style quip"_pair_quip.html, USER/quip, -, lib/quip
-USER-REAXC, C version of ReaxFF, Metin Aktulga (LBNL), "pair_style reaxc"_pair_reax_c.html, reax, -, -
-USER-SMD, smoothed Mach dynamics, Georg Ganzenmuller (EMI), "userguide.pdf"_PDF/SMD_LAMMPS_userguide.pdf, USER/smd, -, -
-USER-SMTBQ, Second Moment Tight Binding - QEq potential, Salles & Maras & Politano & Tetot (4), "pair_style smtbq"_pair_smtbq.html, USER/smtbq, -, -
-USER-SPH, smoothed particle hydrodynamics, Georg Ganzenmuller (EMI), "userguide.pdf"_PDF/SPH_LAMMPS_userguide.pdf, USER/sph, "sph"_sph, -
-USER-TALLY, Pairwise tallied computes, Axel Kohlmeyer (Temple U), "compute <...>/tally"_compute_tally.html, USER/tally, -, -
-:tb(ea=c)
-
-:link(atc,http://lammps.sandia.gov/pictures.html#atc)
-:link(cg,http://lammps.sandia.gov/pictures.html#cg)
-:link(eff,http://lammps.sandia.gov/movies.html#eff)
-:link(sph,http://lammps.sandia.gov/movies.html#sph)
-:link(VMD,http://www.ks.uiuc.edu/Research/vmd)
-
-The "Authors" column lists a name(s) if a specific person is
-responible for creating and maintaining the package.
-
-(1) The ATC package was created by Reese Jones, Jeremy Templeton, and
-Jon Zimmerman (Sandia).
-
-(2) The COLVARS package was created by Axel Kohlmeyer (Temple U) using
-the colvars module library written by Giacomo Fiorin (Temple U) and
-Jerome Henin (LISM, Marseille, France).
-
-(3) The DRUDE package was created by Alain Dequidt (U Blaise Pascal
-Clermont-Ferrand) and co-authors Julien Devemy (CNRS) and Agilio Padua
-(U Blaise Pascal).
-
-(4) The SMTBQ package was created by Nicolas Salles, Emile Maras,
-Olivier Politano, and Robert Tetot (LAAS-CNRS, France).
-
-(4) The USER-DPD package was created by James Larentzos, Timothy
-Mattox, and John Brennan (Army Research Lab (ARL) and Engility Corp).
-
-If the Library is not listed as lib/package, then it is a third-party
-library not included in the LAMMPS distribution.  See the
-src/package/Makefile.lammps file for info on where to download the
-library from.
-
-The "Doc page" column links to either a portion of the
-"Section_howto"_Section_howto.html of the manual, or an input script
-command implemented as part of the package, or to additional
-documentation provided within the package.
-
-The "Example" column is a sub-directory in the examples directory of
-the distribution which has an input script that uses the package.
-E.g. "peptide" refers to the examples/peptide directory.  USER/cuda
-refers to the examples/USER/cuda directory.
-
-The "Library" column lists an external library which must be built
-first and which LAMMPS links to when it is built.  If it is listed as
-lib/package, then the code for the library is under the lib directory
-of the LAMMPS distribution.  See the lib/package/README file for info
-on how to build the library.  If it is not listed as lib/package, then
-it is a third-party library not included in the LAMMPS distribution.
-See the src/package/Makefile.lammps file for info on where to download
-the library.  "Section start"_Section_start.html#start_3_3 of the
-manual also gives details on how to build LAMMPS with both kinds of
-auxiliary libraries.
-
-Except where explained below, all of these packages can be installed,
-and LAMMPS re-built, by issuing these commands from the src dir.
-
-make yes-user-package
-make machine
-or
-Make.py -p package -a machine :pre
-
-To un-install the package and re-build LAMMPS without it:
-
-make no-user-package
-make machine
-or
-Make.py -p ^package -a machine :pre
-
-"Package" is the name of the package (in this case without the user
-prefix) in lower-case letters, e.g. drude or phonon, and "machine" is
-the build target, e.g. mpi or serial.
-
-:line
-:line
-
-USER-ATC package :h4
-
-This package implements a "fix atc" command which can be used in a
-LAMMPS input script.  This fix can be employed to either do concurrent
-coupling of MD with FE-based physics surrogates or on-the-fly
-post-processing of atomic information to continuum fields.
-
-See the doc page for the fix atc command to get started.  At the
-bottom of the doc page are many links to additional documentation
-contained in the doc/USER/atc directory.
-
-There are example scripts for using this package in examples/USER/atc.
-
-This package uses an external library in lib/atc which must be
-compiled before making LAMMPS.  See the lib/atc/README file and the
-LAMMPS manual for information on building LAMMPS with external
-libraries.
-
-The primary people who created this package are Reese Jones (rjones at
-sandia.gov), Jeremy Templeton (jatempl at sandia.gov) and Jon
-Zimmerman (jzimmer at sandia.gov) at Sandia.  Contact them directly if
-you have questions.
-
-:line
-
-USER-AWPMD package :h4
-
-This package contains a LAMMPS implementation of the Antisymmetrized
-Wave Packet Molecular Dynamics (AWPMD) method.
-
-See the doc page for the pair_style awpmd/cut command to get started.
-
-There are example scripts for using this package in examples/USER/awpmd.
-
-This package uses an external library in lib/awpmd which must be
-compiled before making LAMMPS.  See the lib/awpmd/README file and the
-LAMMPS manual for information on building LAMMPS with external
-libraries.
-
-The person who created this package is Ilya Valuev at the JIHT in
-Russia (valuev at physik.hu-berlin.de).  Contact him directly if you
-have questions.
-
-:line
-
-USER-CG-CMM package :h4
-
-This package implements 3 commands which can be used in a LAMMPS input
-script:
-
-pair_style lj/sdk
-pair_style lj/sdk/coul/long
-angle_style sdk :ul
-
-These styles allow coarse grained MD simulations with the
-parametrization of Shinoda, DeVane, Klein, Mol Sim, 33, 27 (2007)
-(SDK), with extensions to simulate ionic liquids, electrolytes, lipids
-and charged amino acids.
-
-See the doc pages for these commands for details.
-
-There are example scripts for using this package in
-examples/USER/cg-cmm.
-
-This is the second generation implementation reducing the the clutter
-of the previous version. For many systems with electrostatics, it will
-be faster to use pair_style hybrid/overlay with lj/sdk and coul/long
-instead of the combined lj/sdk/coul/long style.  since the number of
-charged atom types is usually small.  For any other coulomb
-interactions this is now required.  To exploit this property, the use
-of the kspace_style pppm/cg is recommended over regular pppm. For all
-new styles, input file backward compatibility is provided.  The old
-implementation is still available through appending the /old
-suffix. These will be discontinued and removed after the new
-implementation has been fully validated.
-
-The current version of this package should be considered beta
-quality. The CG potentials work correctly for "normal" situations, but
-have not been testing with all kinds of potential parameters and
-simulation systems.
-
-The person who created this package is Axel Kohlmeyer at Temple U
-(akohlmey at gmail.com).  Contact him directly if you have questions.
-
-:line
-
-USER-COLVARS package :h4
-
-This package implements the "fix colvars" command which can be
-used in a LAMMPS input script.
-
-This fix allows to use "collective variables" to implement
-Adaptive Biasing Force, Metadynamics, Steered MD, Umbrella
-Sampling and Restraints. This code consists of two parts:
-
-A portable collective variable module library written and maintained
-by Giacomo Fiorin (ICMS, Temple University, Philadelphia, PA, USA) and
-Jerome Henin (LISM, CNRS, Marseille, France). This code is located in
-the directory lib/colvars and needs to be compiled first.  The colvars
-fix and an interface layer, exchanges information between LAMMPS and
-the collective variable module. :ul
-
-See the doc page of "fix colvars"_fix_colvars.html for more details.
-
-There are example scripts for using this package in
-examples/USER/colvars
-
-This is a very new interface that does not yet support all
-features in the module and will see future optimizations
-and improvements. The colvars module library is also available
-in NAMD has been thoroughly used and tested there. Bugs and
-problems are likely due to the interface layers code.
-Thus the current version of this package should be considered
-beta quality.
-
-The person who created this package is Axel Kohlmeyer at Temple U
-(akohlmey at gmail.com).  Contact him directly if you have questions.
-
-:line
-
-USER-CUDA package :h4
-
-This package provides acceleration of various LAMMPS pair styles, fix
-styles, compute styles, and long-range Coulombics via PPPM for NVIDIA
-GPUs.
- 
-See this section of the manual to get started:
-
-"Section_accelerate"_Section_accelerate.html#acc_7
-
-There are example scripts for using this package in
-examples/USER/cuda.
-
-This package uses an external library in lib/cuda which must be
-compiled before making LAMMPS.  See the lib/cuda/README file and the
-LAMMPS manual for information on building LAMMPS with external
-libraries.
-
-The person who created this package is Christian Trott at the
-University of Technology Ilmenau, Germany (christian.trott at
-tu-ilmenau.de).  Contact him directly if you have questions.
-
-:line
-
-USER-DIFFRACTION package :h4
-
-This package contains the commands neeed to calculate x-ray and
-electron diffraction intensities based on kinematic diffraction 
-theory.
-
-See these doc pages and their related commands to get started:
-
-"compute xrd"_compute_xrd.html
-"compute saed"_compute_saed.html
-"fix saed/vtk"_fix_saed_vtk.html :ul
-
-The person who created this package is Shawn P. Coleman 
-(shawn.p.coleman8.ctr at mail.mil) while at the University of 
-Arkansas.  Contact him directly if you have questions.
-
-:line
-
-USER-DPD package :h4
-
-This package implements the dissipative particle dynamics (DPD) method
-under isothermal, isoenergetic, isobaric and isenthalpic conditions.
-The DPD equations of motion are integrated efficiently through the
-Shardlow splitting algorithm.
-
-See these doc pages and their related commands to get started:
-
-"compute dpd"_compute_dpd.html
-"compute dpd/atom"_compute_dpd_atom.html
-"fix_eos/cv"_fix_eos_table.html
-"fix_eos/table"_fix_eos_table.html
-"fix_shardlow"_fix_shardlow.html
-"pair_dpd/conservative"_pair_dpd_conservative.html
-"pair_dpd/fdt"_pair_dpd_fdt.html
-"pair_dpd/fdt/energy"_pair_dpd_fdt.html :ul
-
-There are example scripts for using this package in examples/USER/dpd.
-
-The people who created this package are James Larentzos
-(james.p.larentzos.civ at mail.mil), Timothy Mattox (Timothy.Mattox at
-engilitycorp.com) and John Brennan (john.k.brennan.civ at mail.mil).
-Contact them directly if you have questions.
-
-:line
-
-USER-DRUDE package :h4
-
-This package implements methods for simulating polarizable systems
-in LAMMPS using thermalized Drude oscillators.
-
-See these doc pages and their related commands to get started:
-
-"Drude tutorial"_tutorial_drude.html
-"fix drude"_fix_drude.html
-"compute temp/drude"_compute_temp_drude.html
-"fix langevin/drude"_fix_langevin_drude.html
-"fix drude/transform/..."_fix_drude_transform.html
-"pair thole"_pair_thole.html :ul
-
-There are auxiliary tools for using this package in tools/drude.
-
-The person who created this package is Alain Dequidt at Universite
-Blaise Pascal Clermont-Ferrand (alain.dequidt at univ-bpclermont.fr)
-Contact him directly if you have questions. Co-authors: Julien Devemy,
-Agilio Padua.
-
-:line
-
-USER-EFF package :h4
-
-This package contains a LAMMPS implementation of the electron Force
-Field (eFF) currently under development at Caltech, as described in
-A. Jaramillo-Botero, J. Su, Q. An, and W.A. Goddard III, JCC,
-2010. The eFF potential was first introduced by Su and Goddard, in
-2007.
-
-eFF can be viewed as an approximation to QM wave packet dynamics and
-Fermionic molecular dynamics, combining the ability of electronic
-structure methods to describe atomic structure, bonding, and chemistry
-in materials, and of plasma methods to describe nonequilibrium
-dynamics of large systems with a large number of highly excited
-electrons. We classify it as a mixed QM-classical approach rather than
-a conventional force field method, which introduces QM-based terms (a
-spin-dependent repulsion term to account for the Pauli exclusion
-principle and the electron wavefunction kinetic energy associated with
-the Heisenberg principle) that reduce, along with classical
-electrostatic terms between nuclei and electrons, to the sum of a set
-of effective pairwise potentials.  This makes eFF uniquely suited to
-simulate materials over a wide range of temperatures and pressures
-where electronically excited and ionized states of matter can occur
-and coexist.
-
-The necessary customizations to the LAMMPS core are in place to
-enable the correct handling of explicit electron properties during
-minimization and dynamics.
-
-See the doc page for the pair_style eff/cut command to get started.
-
-There are example scripts for using this package in
-examples/USER/eff.
-
-There are auxiliary tools for using this package in tools/eff.
-
-The person who created this package is Andres Jaramillo-Botero at
-CalTech (ajaramil at wag.caltech.edu).  Contact him directly if you
-have questions.
-
-:line
-
-USER-FEP package :h4
-
-This package provides methods for performing free energy perturbation
-simulations with soft-core pair potentials in LAMMPS.
-
-See these doc pages and their related commands to get started:
-
-"fix adapt/fep"_fix_adapt_fep.html
-"compute fep"_compute_fep.html
-"soft pair styles"_pair_lj_soft.html :ul
-
-The person who created this package is Agilio Padua at Universite
-Blaise Pascal Clermont-Ferrand (agilio.padua at univ-bpclermont.fr)
-Contact him directly if you have questions.
-
-:line
-
-USER-H5MD package :h4
-
-This package contains a "dump h5md"_dump_h5md.html command for
-performing a dump of atom properties in HDF5 format.  "HDF5
-files"_HDF5 are binary, portable and self-describing and can be
-examined and used by a variety of auxiliary tools.  The output HDF5
-files are structured in a format called H5MD, which was designed to
-store molecular data, and can be used and produced by various MD and
-MD-related codes.  The "dump h5md"_doc/dump_h5md.html command gives a
-citation to a paper describing the format.
-
-:link(HDF5,http://www.hdfgroup.org/HDF5/)
-
-The person who created this package and the underlying H5MD format is
-Pierre de Buyl at KU Leuven (see http://pdebuyl.be).  Contact him
-directly if you have questions.
-
-:line
-
-USER-INTEL package :h4
-
-This package provides options for performing neighbor list and
-non-bonded force calculations in single, mixed, or double precision
-and also a capability for accelerating calculations with an
-Intel(R) Xeon Phi(TM) coprocessor.
- 
-See this section of the manual to get started:
-
-"Section_accelerate"_Section_accelerate.html#acc_9
-
-The person who created this package is W. Michael Brown at Intel
-(michael.w.brown at intel.com).  Contact him directly if you have questions.
-
-:line
-
-USER-LB package :h4
-
-This package contains a LAMMPS implementation of a background
-Lattice-Boltzmann fluid, which can be used to model MD particles
-influenced by hydrodynamic forces.
-
-See this doc page and its related commands to get started:
-
-"fix lb/fluid"_fix_lb_fluid.html
-
-The people who created this package are Frances Mackay (fmackay at
-uwo.ca) and Colin (cdennist at uwo.ca) Denniston, University of
-Western Ontario.  Contact them directly if you have questions.
-
-:line
-
-USER-MGPT package :h4
-
-This package contains a fast implementation for LAMMPS of
-quantum-based MGPT multi-ion potentials.  The MGPT or model GPT method
-derives from first-principles DFT-based generalized pseudopotential
-theory (GPT) through a series of systematic approximations valid for
-mid-period transition metals with nearly half-filled d bands.  The
-MGPT method was originally developed by John Moriarty at Lawrence
-Livermore National Lab (LLNL).
-
-In the general matrix representation of MGPT, which can also be
-applied to f-band actinide metals, the multi-ion potentials are
-evaluated on the fly during a simulation through d- or f-state matrix
-multiplication, and the forces that move the ions are determined
-analytically.  The {mgpt} pair style in this package calculates forces
-and energies using an optimized matrix-MGPT algorithm due to Tomas
-Oppelstrup at LLNL.
-
-See this doc page to get started:
-
-"pair_style mgpt"_pair_mgpt.html
-
-The persons who created the USER-MGPT package are Tomas Oppelstrup
-(oppelstrup2@llnl.gov) and John Moriarty (moriarty2@llnl.gov)
-Contact them directly if you have any questions.
-
-:line
-
-USER-MISC package :h4
-
-The files in this package are a potpourri of (mostly) unrelated
-features contributed to LAMMPS by users.  Each feature is a single
-pair of files (*.cpp and *.h).
-
-More information about each feature can be found by reading its doc
-page in the LAMMPS doc directory.  The doc page which lists all LAMMPS
-input script commands is as follows:
-
-"Section_commands"_Section_commands.html#cmd_5
-
-User-contributed features are listed at the bottom of the fix,
-compute, pair, etc sections.
-
-The list of features and author of each is given in the
-src/USER-MISC/README file.
-
-You should contact the author directly if you have specific questions
-about the feature or its coding.
-
-:line
-
-USER-MOLFILE package :h4
-
-This package contains a dump molfile command which uses molfile
-plugins that are bundled with the
-"VMD"_http://www.ks.uiuc.edu/Research/vmd molecular visualization and
-analysis program, to enable LAMMPS to dump its information in formats
-compatible with various molecular simulation tools.
-
-The package only provides the interface code, not the plugins.  These
-can be obtained from a VMD installation which has to match the
-platform that you are using to compile LAMMPS for. By adding plugins
-to VMD, support for new file formats can be added to LAMMPS (or VMD or
-other programs that use them) without having to recompile the
-application itself.
-
-See this doc page to get started:
-
-"dump molfile"_dump_molfile.html#acc_5
-
-The person who created this package is Axel Kohlmeyer at Temple U
-(akohlmey at gmail.com).  Contact him directly if you have questions.
-
-:line
-
-USER-OMP package :h4
-
-This package provides OpenMP multi-threading support and
-other optimizations of various LAMMPS pair styles, dihedral
-styles, and fix styles.
- 
-See this section of the manual to get started:
-
-"Section_accelerate"_Section_accelerate.html#acc_5
-
-The person who created this package is Axel Kohlmeyer at Temple U
-(akohlmey at gmail.com).  Contact him directly if you have questions.
-
-:line
-
-USER-PHONON package :h4
-
-This package contains a fix phonon command that calculates dynamical
-matrices, which can then be used to compute phonon dispersion
-relations, directly from molecular dynamics simulations.
-
-See this doc page to get started:
-
-"fix phonon"_fix_phonon.html
-
-The person who created this package is Ling-Ti Kong (konglt at
-sjtu.edu.cn) at Shanghai Jiao Tong University.  Contact him directly
-if you have questions.
-
-:line
-
-USER-QMMM package :h4
-
-This package provides a fix qmmm command which allows LAMMPS to be
-used in a QM/MM simulation, currently only in combination with pw.x
-code from the "Quantum ESPRESSO"_espresso package.
-
-:link(espresso,http://www.quantum-espresso.org)
-
-The current implementation only supports an ONIOM style mechanical
-coupling to the Quantum ESPRESSO plane wave DFT package.
-Electrostatic coupling is in preparation and the interface has been
-written in a manner that coupling to other QM codes should be possible
-without changes to LAMMPS itself.
-
-See this doc page to get started:
-
-"fix qmmm"_fix_qmmm.html
-
-as well as the lib/qmmm/README file.
-
-The person who created this package is Axel Kohlmeyer at Temple U
-(akohlmey at gmail.com).  Contact him directly if you have questions.
-
-:line
-
-USER-QTB package :h4
-
-This package provides a self-consistent quantum treatment of the
-vibrational modes in a classical molecular dynamics simulation.  By
-coupling the MD simulation to a colored thermostat, it introduces zero
-point energy into the system, alter the energy power spectrum and the
-heat capacity towards their quantum nature. This package could be of
-interest if one wants to model systems at temperatures lower than
-their classical limits or when temperatures ramp up across the
-classical limits in the simulation.
-
-See these two doc pages to get started:
-
-"fix qtb"_fix_qtb.html provides quantum nulcear correction through a
-colored thermostat and can be used with other time integration schemes
-like "fix nve"_fix_nve.html or "fix nph"_fix_nh.html.
-
-"fix qbmsst"_fix_qbmsst.html enables quantum nuclear correction of a
-multi-scale shock technique simulation by coupling the quantum thermal
-bath with the shocked system.
-
-The person who created this package is Yuan Shen (sy0302 at
-stanford.edu) at Stanford University.  Contact him directly if you
-have questions.
-
-:line
-
-USER-REAXC package :h4
-
-This package contains a implementation for LAMMPS of the ReaxFF force
-field.  ReaxFF uses distance-dependent bond-order functions to
-represent the contributions of chemical bonding to the potential
-energy.  It was originally developed by Adri van Duin and the Goddard
-group at CalTech.
-
-The USER-REAXC version of ReaxFF (pair_style reax/c), implemented in
-C, should give identical or very similar results to pair_style reax,
-which is a ReaxFF implementation on top of a Fortran library, a
-version of which library was originally authored by Adri van Duin.
-
-The reax/c version should be somewhat faster and more scalable,
-particularly with respect to the charge equilibration calculation.  It
-should also be easier to build and use since there are no complicating
-issues with Fortran memory allocation or linking to a Fortran library.
-
-For technical details about this implemention of ReaxFF, see
-this paper:
-
-Parallel and Scalable Reactive Molecular Dynamics: Numerical Methods
-and Algorithmic Techniques, H. M. Aktulga, J. C. Fogarty,
-S. A. Pandit, A. Y. Grama, Parallel Computing, in press (2011).
-
-See the doc page for the pair_style reax/c command for details
-of how to use it in LAMMPS.
-
-The person who created this package is Hasan Metin Aktulga (hmaktulga
-at lbl.gov), while at Purdue University.  Contact him directly, or
-Aidan Thompson at Sandia (athomps at sandia.gov), if you have
-questions.
-
-:line
-
-USER-SMD package :h4
-
-This package implements smoothed Mach dynamics (SMD) in
-LAMMPS.  Currently, the package has the following features:
-
-* Does liquids via traditional Smooth Particle Hydrodynamics (SPH)
-
-* Also solves solids mechanics problems via a state of the art 
-  stabilized meshless method with hourglass control.
-
-* Can specify hydrostatic interactions independently from material 
-  strength models, i.e. pressure and deviatoric stresses are separated.
-
-* Many material models available (Johnson-Cook, plasticity with 
-  hardening, Mie-Grueneisen, Polynomial EOS).  Easy to add new 
-  material models.
-
-* Rigid boundary conditions (walls) can be loaded as surface geometries 
-  from *.STL files.
-
-See the file doc/PDF/SMD_LAMMPS_userguide.pdf to get started.
-
-There are example scripts for using this package in examples/USER/smd.
-
-The person who created this package is Georg Ganzenmuller at the
-Fraunhofer-Institute for High-Speed Dynamics, Ernst Mach Institute in
-Germany (georg.ganzenmueller at emi.fhg.de).  Contact him directly if
-you have questions.
-
-:line
-
-USER-SMTBQ package :h4
-
-This package implements the Second Moment Tight Binding - QEq (SMTB-Q)
-potential for the description of ionocovalent bonds in oxides.
-
-There are example scripts for using this package in
-examples/USER/smtbq.
-
-See this doc page to get started:
-
-"pair_style smtbq"_pair_smtbq.html
-
-The persons who created the USER-SMTBQ package are Nicolas Salles,
-Emile Maras, Olivier Politano, Robert Tetot, who can be contacted at
-these email addreses: lammps@u-bourgogne.fr, nsalles@laas.fr.  Contact
-them directly if you have any questions.
-
-:line
-
-USER-SPH package :h4
-
-This package implements smoothed particle hydrodynamics (SPH) in
-LAMMPS.  Currently, the package has the following features:
-
-* Tait, ideal gas, Lennard-Jones equation of states, full support for 
-  complete (i.e. internal-energy dependent) equations of state
-
-* Plain or Monaghans XSPH integration of the equations of motion
-
-* Density continuity or density summation to propagate the density field
-
-* Commands to set internal energy and density of particles from the 
-  input script
-
-* Output commands to access internal energy and density for dumping and 
-  thermo output
-
-See the file doc/PDF/SPH_LAMMPS_userguide.pdf to get started.
-
-There are example scripts for using this package in examples/USER/sph.
-
-The person who created this package is Georg Ganzenmuller at the
-Fraunhofer-Institute for High-Speed Dynamics, Ernst Mach Institute in
-Germany (georg.ganzenmueller at emi.fhg.de).  Contact him directly if
-you have questions.

doc/Section_perf.html

@@ -1,304 +0,0 @@
-
-
-<!DOCTYPE html>
-<!--[if IE 8]><html class="no-js lt-ie9" lang="en" > <![endif]-->
-<!--[if gt IE 8]><!--> <html class="no-js" lang="en" > <!--<![endif]-->
-<head>
-  <meta charset="utf-8">
-  
-  <meta name="viewport" content="width=device-width, initial-scale=1.0">
-  
-  <title>8. Performance &amp; scalability &mdash; LAMMPS documentation</title>
-  
-
-  
-  
-
-  
-
-  
-  
-    
-
-  
-
-  
-  
-    <link rel="stylesheet" href="_static/css/theme.css" type="text/css" />
-  
-
-  
-    <link rel="stylesheet" href="_static/sphinxcontrib-images/LightBox2/lightbox2/css/lightbox.css" type="text/css" />
-  
-
-  
-    <link rel="top" title="LAMMPS documentation" href="index.html"/>
-        <link rel="next" title="9. Additional tools" href="Section_tools.html"/>
-        <link rel="prev" title="7. Example problems" href="Section_example.html"/> 
-
-  
-  <script src="_static/js/modernizr.min.js"></script>
-
-</head>
-
-<body class="wy-body-for-nav" role="document">
-
-  <div class="wy-grid-for-nav">
-
-    
-    <nav data-toggle="wy-nav-shift" class="wy-nav-side">
-      <div class="wy-side-nav-search">
-        
-
-        
-          <a href="Manual.html" class="icon icon-home"> LAMMPS
-        
-
-        
-        </a>
-
-        
-<div role="search">
-  <form id="rtd-search-form" class="wy-form" action="search.html" method="get">
-    <input type="text" name="q" placeholder="Search docs" />
-    <input type="hidden" name="check_keywords" value="yes" />
-    <input type="hidden" name="area" value="default" />
-  </form>
-</div>
-
-        
-      </div>
-
-      <div class="wy-menu wy-menu-vertical" data-spy="affix" role="navigation" aria-label="main navigation">
-        
-          
-          
-              <ul class="current">
-<li class="toctree-l1"><a class="reference internal" href="Section_intro.html">1. Introduction</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_start.html">2. Getting Started</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_commands.html">3. Commands</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_packages.html">4. Packages</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_accelerate.html">5. Accelerating LAMMPS performance</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_howto.html">6. How-to discussions</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_example.html">7. Example problems</a></li>
-<li class="toctree-l1 current"><a class="current reference internal" href="">8. Performance &amp; scalability</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_tools.html">9. Additional tools</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_modify.html">10. Modifying &amp; extending LAMMPS</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_python.html">11. Python interface to LAMMPS</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_errors.html">12. Errors</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_history.html">13. Future and history</a></li>
-</ul>
-
-          
-        
-      </div>
-      &nbsp;
-    </nav>
-
-    <section data-toggle="wy-nav-shift" class="wy-nav-content-wrap">
-
-      
-      <nav class="wy-nav-top" role="navigation" aria-label="top navigation">
-        <i data-toggle="wy-nav-top" class="fa fa-bars"></i>
-        <a href="Manual.html">LAMMPS</a>
-      </nav>
-
-
-      
-      <div class="wy-nav-content">
-        <div class="rst-content">
-          <div role="navigation" aria-label="breadcrumbs navigation">
-  <ul class="wy-breadcrumbs">
-    <li><a href="Manual.html">Docs</a> &raquo;</li>
-      
-    <li>8. Performance &amp; scalability</li>
-      <li class="wy-breadcrumbs-aside">
-        
-          
-            <a href="http://lammps.sandia.gov">Website</a>
-            <a href="Section_commands.html#comm">Commands</a>
-        
-      </li>
-  </ul>
-  <hr/>
-  
-    <div class="rst-footer-buttons" style="margin-bottom: 1em" role="navigation" aria-label="footer navigation">
-      
-        <a href="Section_tools.html" class="btn btn-neutral float-right" title="9. Additional tools" accesskey="n">Next <span class="fa fa-arrow-circle-right"></span></a>
-      
-      
-        <a href="Section_example.html" class="btn btn-neutral" title="7. Example problems" accesskey="p"><span class="fa fa-arrow-circle-left"></span> Previous</a>
-      
-    </div>
-  
-</div>
-          <div role="main" class="document" itemscope="itemscope" itemtype="http://schema.org/Article">
-           <div itemprop="articleBody">
-            
-  <div class="section" id="performance-scalability">
-<h1>8. Performance &amp; scalability<a class="headerlink" href="#performance-scalability" title="Permalink to this headline">¶</a></h1>
-<p>LAMMPS performance on several prototypical benchmarks and machines is
-discussed on the Benchmarks page of the <a class="reference external" href="http://lammps.sandia.gov">LAMMPS WWW Site</a> where
-CPU timings and parallel efficiencies are listed.  Here, the
-benchmarks are described briefly and some useful rules of thumb about
-their performance are highlighted.</p>
-<p>These are the 5 benchmark problems:</p>
-<ol class="arabic simple">
-<li>LJ = atomic fluid, Lennard-Jones potential with 2.5 sigma cutoff (55</li>
-</ol>
-<blockquote>
-<div>neighbors per atom), NVE integration</div></blockquote>
-<ol class="arabic simple">
-<li>Chain = bead-spring polymer melt of 100-mer chains, FENE bonds and LJ
-pairwise interactions with a 2^(1/6) sigma cutoff (5 neighbors per
-atom), NVE integration</li>
-<li>EAM = metallic solid, Cu EAM potential with 4.95 Angstrom cutoff (45
-neighbors per atom), NVE integration</li>
-<li>Chute = granular chute flow, frictional history potential with 1.1
-sigma cutoff (7 neighbors per atom), NVE integration</li>
-<li>Rhodo = rhodopsin protein in solvated lipid bilayer, CHARMM force
-field with a 10 Angstrom LJ cutoff (440 neighbors per atom),
-particle-particle particle-mesh (PPPM) for long-range Coulombics, NPT
-integration</li>
-</ol>
-<p>The input files for running the benchmarks are included in the LAMMPS
-distribution, as are sample output files.  Each of the 5 problems has
-32,000 atoms and runs for 100 timesteps.  Each can be run as a serial
-benchmarks (on one processor) or in parallel.  In parallel, each
-benchmark can be run as a fixed-size or scaled-size problem.  For
-fixed-size benchmarking, the same 32K atom problem is run on various
-numbers of processors.  For scaled-size benchmarking, the model size
-is increased with the number of processors.  E.g. on 8 processors, a
-256K-atom problem is run; on 1024 processors, a 32-million atom
-problem is run, etc.</p>
-<p>A useful metric from the benchmarks is the CPU cost per atom per
-timestep.  Since LAMMPS performance scales roughly linearly with
-problem size and timesteps, the run time of any problem using the same
-model (atom style, force field, cutoff, etc) can then be estimated.
-For example, on a 1.7 GHz Pentium desktop machine (Intel icc compiler
-under Red Hat Linux), the CPU run-time in seconds/atom/timestep for
-the 5 problems is</p>
-<table border="1" class="docutils">
-<colgroup>
-<col width="25%" />
-<col width="14%" />
-<col width="14%" />
-<col width="14%" />
-<col width="14%" />
-<col width="17%" />
-</colgroup>
-<tbody valign="top">
-<tr class="row-odd"><td>Problem:</td>
-<td>LJ</td>
-<td>Chain</td>
-<td>EAM</td>
-<td>Chute</td>
-<td>Rhodopsin</td>
-</tr>
-<tr class="row-even"><td>CPU/atom/step:</td>
-<td>4.55E-6</td>
-<td>2.18E-6</td>
-<td>9.38E-6</td>
-<td>2.18E-6</td>
-<td>1.11E-4</td>
-</tr>
-<tr class="row-odd"><td>Ratio to LJ:</td>
-<td>1.0</td>
-<td>0.48</td>
-<td>2.06</td>
-<td>0.48</td>
-<td>24.5</td>
-</tr>
-</tbody>
-</table>
-<p>The ratios mean that if the atomic LJ system has a normalized cost of
-1.0, the bead-spring chains and granular systems run 2x faster, while
-the EAM metal and solvated protein models run 2x and 25x slower
-respectively.  The bulk of these cost differences is due to the
-expense of computing a particular pairwise force field for a given
-number of neighbors per atom.</p>
-<p>Performance on a parallel machine can also be predicted from the
-one-processor timings if the parallel efficiency can be estimated.
-The communication bandwidth and latency of a particular parallel
-machine affects the efficiency.  On most machines LAMMPS will give
-fixed-size parallel efficiencies on these benchmarks above 50% so long
-as the atoms/processor count is a few 100 or greater - i.e. on 64 to
-128 processors.  Likewise, scaled-size parallel efficiencies will
-typically be 80% or greater up to very large processor counts.  The
-benchmark data on the <a class="reference external" href="http://lammps.sandia.gov">LAMMPS WWW Site</a> gives specific examples on
-some different machines, including a run of 3/4 of a billion LJ atoms
-on 1500 processors that ran at 85% parallel efficiency.</p>
-</div>
-
-
-           </div>
-          </div>
-          <footer>
-  
-    <div class="rst-footer-buttons" role="navigation" aria-label="footer navigation">
-      
-        <a href="Section_tools.html" class="btn btn-neutral float-right" title="9. Additional tools" accesskey="n">Next <span class="fa fa-arrow-circle-right"></span></a>
-      
-      
-        <a href="Section_example.html" class="btn btn-neutral" title="7. Example problems" accesskey="p"><span class="fa fa-arrow-circle-left"></span> Previous</a>
-      
-    </div>
-  
-
-  <hr/>
-
-  <div role="contentinfo">
-    <p>
-        &copy; Copyright 2013 Sandia Corporation.
-    </p>
-  </div>
-  Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
-
-</footer>
-
-        </div>
-      </div>
-
-    </section>
-
-  </div>
-  
-
-
-  
-
-    <script type="text/javascript">
-        var DOCUMENTATION_OPTIONS = {
-            URL_ROOT:'./',
-            VERSION:'',
-            COLLAPSE_INDEX:false,
-            FILE_SUFFIX:'.html',
-            HAS_SOURCE:  true
-        };
-    </script>
-      <script type="text/javascript" src="_static/jquery.js"></script>
-      <script type="text/javascript" src="_static/underscore.js"></script>
-      <script type="text/javascript" src="_static/doctools.js"></script>
-      <script type="text/javascript" src="https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>
-      <script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/jquery-1.11.0.min.js"></script>
-      <script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/lightbox.min.js"></script>
-      <script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2-customize/jquery-noconflict.js"></script>
-
-  
-
-  
-  
-    <script type="text/javascript" src="_static/js/theme.js"></script>
-  
-
-  
-  
-  <script type="text/javascript">
-      jQuery(function () {
-          SphinxRtdTheme.StickyNav.enable();
-      });
-  </script>
-   
-
-</body>
-</html>

doc/Section_perf.txt

@@ -1,77 +0,0 @@
-"Previous Section"_Section_example.html - "LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next Section"_Section_tools.html :c
-
-:link(lws,http://lammps.sandia.gov)
-:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
-
-:line
-
-8. Performance & scalability :h3
-
-LAMMPS performance on several prototypical benchmarks and machines is
-discussed on the Benchmarks page of the "LAMMPS WWW Site"_lws where
-CPU timings and parallel efficiencies are listed.  Here, the
-benchmarks are described briefly and some useful rules of thumb about
-their performance are highlighted.
-
-These are the 5 benchmark problems:
-
-LJ = atomic fluid, Lennard-Jones potential with 2.5 sigma cutoff (55
-neighbors per atom), NVE integration :olb,l
-
-Chain = bead-spring polymer melt of 100-mer chains, FENE bonds and LJ
-pairwise interactions with a 2^(1/6) sigma cutoff (5 neighbors per
-atom), NVE integration :l
-
-EAM = metallic solid, Cu EAM potential with 4.95 Angstrom cutoff (45
-neighbors per atom), NVE integration :l
-
-Chute = granular chute flow, frictional history potential with 1.1
-sigma cutoff (7 neighbors per atom), NVE integration :l
-
-Rhodo = rhodopsin protein in solvated lipid bilayer, CHARMM force
-field with a 10 Angstrom LJ cutoff (440 neighbors per atom),
-particle-particle particle-mesh (PPPM) for long-range Coulombics, NPT
-integration :ole,l
-
-The input files for running the benchmarks are included in the LAMMPS
-distribution, as are sample output files.  Each of the 5 problems has
-32,000 atoms and runs for 100 timesteps.  Each can be run as a serial
-benchmarks (on one processor) or in parallel.  In parallel, each
-benchmark can be run as a fixed-size or scaled-size problem.  For
-fixed-size benchmarking, the same 32K atom problem is run on various
-numbers of processors.  For scaled-size benchmarking, the model size
-is increased with the number of processors.  E.g. on 8 processors, a
-256K-atom problem is run; on 1024 processors, a 32-million atom
-problem is run, etc.
-
-A useful metric from the benchmarks is the CPU cost per atom per
-timestep.  Since LAMMPS performance scales roughly linearly with
-problem size and timesteps, the run time of any problem using the same
-model (atom style, force field, cutoff, etc) can then be estimated.
-For example, on a 1.7 GHz Pentium desktop machine (Intel icc compiler
-under Red Hat Linux), the CPU run-time in seconds/atom/timestep for
-the 5 problems is
-
-Problem:, LJ, Chain, EAM, Chute, Rhodopsin
-CPU/atom/step:, 4.55E-6, 2.18E-6, 9.38E-6, 2.18E-6, 1.11E-4
-Ratio to LJ:, 1.0, 0.48, 2.06, 0.48, 24.5 :tb(ea=c,ca1=r)
-
-The ratios mean that if the atomic LJ system has a normalized cost of
-1.0, the bead-spring chains and granular systems run 2x faster, while
-the EAM metal and solvated protein models run 2x and 25x slower
-respectively.  The bulk of these cost differences is due to the
-expense of computing a particular pairwise force field for a given
-number of neighbors per atom.
-
-Performance on a parallel machine can also be predicted from the
-one-processor timings if the parallel efficiency can be estimated.
-The communication bandwidth and latency of a particular parallel
-machine affects the efficiency.  On most machines LAMMPS will give
-fixed-size parallel efficiencies on these benchmarks above 50% so long
-as the atoms/processor count is a few 100 or greater - i.e. on 64 to
-128 processors.  Likewise, scaled-size parallel efficiencies will
-typically be 80% or greater up to very large processor counts.  The
-benchmark data on the "LAMMPS WWW Site"_lws gives specific examples on
-some different machines, including a run of 3/4 of a billion LJ atoms
-on 1500 processors that ran at 85% parallel efficiency.

doc/Section_python.txt

@@ -1,839 +0,0 @@
-"Previous Section"_Section_modify.html - "LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next Section"_Section_errors.html :c
-
-:link(lws,http://lammps.sandia.gov)
-:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
-
-:line
-
-11. Python interface to LAMMPS :h3
-
-LAMMPS can work together with Python in two ways.  First, Python can
-wrap LAMMPS through the "LAMMPS library
-interface"_Section_howto.html#howto_19, so that a Python script can
-create one or more instances of LAMMPS and launch one or more
-simulations.  In Python lingo, this is "extending" Python with LAMMPS.
-
-Second, LAMMPS can use the Python interpreter, so that a LAMMPS input
-script can invoke Python code, and pass information back-and-forth
-between the input script and Python functions you write.  The Python
-code can also callback to LAMMPS to query or change its attributes.
-In Python lingo, this is "embedding" Python in LAMMPS.
-
-This section describes how to do both.
-
-11.1 "Overview of running LAMMPS from Python"_#py_1
-11.2 "Overview of using Python from a LAMMPS script"_#py_2 
-11.3 "Building LAMMPS as a shared library"_#py_3
-11.4 "Installing the Python wrapper into Python"_#py_4
-11.5 "Extending Python with MPI to run in parallel"_#py_5
-11.6 "Testing the Python-LAMMPS interface"_#py_6
-11.7 "Using LAMMPS from Python"_#py_7
-11.8 "Example Python scripts that use LAMMPS"_#py_8 :ul
-
-If you are not familiar with it, "Python"_http://www.python.org is a
-powerful scripting and programming language which can essentially do
-anything that faster, lower-level languages like C or C++ can do, but
-typically with much fewer lines of code.  When used in embedded mode,
-Python can perform operations that the simplistic LAMMPS input script
-syntax cannot.  Python can be also be used as a "glue" language to
-drive a program through its library interface, or to hook multiple
-pieces of software together, such as a simulation package plus a
-visualization package, or to run a coupled multiscale or multiphysics
-model.
-
-See "Section_howto 10"_Section_howto.html#howto_10 of the manual and
-the couple directory of the distribution for more ideas about coupling
-LAMMPS to other codes.  See "Section_howto
-19"_Section_howto.html#howto_19 for a description of the LAMMPS
-library interface provided in src/library.cpp and src/library.h, and
-how to extend it for your needs.  As described below, that interface
-is what is exposed to Python either when calling LAMMPS from Python or
-when calling Python from a LAMMPS input script and then calling back
-to LAMMPS from Python code.  The library interface is designed to be
-easy to add functions to.  Thus the Python interface to LAMMPS is also
-easy to extend as well.
-
-If you create interesting Python scripts that run LAMMPS or
-interesting Python functions that can be called from a LAMMPS input
-script, that you think would be useful to other users, please "email
-them to the developers"_http://lammps.sandia.gov/authors.html.  We can
-include them in the LAMMPS distribution.
-
-:line
-:line
-
-11.1 Overview of running LAMMPS from Python :link(py_1),h4
-
-The LAMMPS distribution includes a python directory with all you need
-to run LAMMPS from Python.  The python/lammps.py file wraps the LAMMPS
-library interface, with one wrapper function per LAMMPS library
-function.  This file makes it is possible to do the following either
-from a Python script, or interactively from a Python prompt: create
-one or more instances of LAMMPS, invoke LAMMPS commands or give it an
-input script, run LAMMPS incrementally, extract LAMMPS results, an
-modify internal LAMMPS variables.  From a Python script you can do
-this in serial or parallel.  Running Python interactively in parallel
-does not generally work, unless you have a version of Python that
-extends standard Python to enable multiple instances of Python to read
-what you type.
-
-To do all of this, you must first build LAMMPS as a shared library,
-then insure that your Python can find the python/lammps.py file and
-the shared library.  These steps are explained in subsequent sections
-11.3 and 11.4.  Sections 11.5 and 11.6 discuss using MPI from a
-parallel Python program and how to test that you are ready to use
-LAMMPS from Python.  Section 11.7 lists all the functions in the
-current LAMMPS library interface and how to call them from Python.
-
-Section 11.8 gives some examples of coupling LAMMPS to other tools via
-Python.  For example, LAMMPS can easily be coupled to a GUI or other
-visualization tools that display graphs or animations in real time as
-LAMMPS runs.  Examples of such scripts are inlcluded in the python
-directory.
-
-Two advantages of using Python to run LAMMPS are how concise the
-language is, and that it can be run interactively, enabling rapid
-development and debugging of programs.  If you use it to mostly invoke
-costly operations within LAMMPS, such as running a simulation for a
-reasonable number of timesteps, then the overhead cost of invoking
-LAMMPS thru Python will be negligible.
-
-The Python wrapper for LAMMPS uses the amazing and magical (to me)
-"ctypes" package in Python, which auto-generates the interface code
-needed between Python and a set of C interface routines for a library.
-Ctypes is part of standard Python for versions 2.5 and later.  You can
-check which version of Python you have installed, by simply typing
-"python" at a shell prompt.
-
-:line
-
-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 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.
-
-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
-are mapped to LAMMPS variables (also defined in the input script) and
-it can return a value to a LAMMPS variable.  This is thus a mechanism
-for your input script to pass information to a piece of Python code,
-ask Python to execute the code, and return information to your input
-script.
-
-Note that a Python function can be arbitrarily complex.  It can import
-other Python modules, instantiate Python classes, call other Python
-functions, etc.  The Python code that you provide can contain more
-code than the single function.  It can contain other functions or
-Python classes, as well as global variables or other mechanisms for
-storing state between calls from LAMMPS to the function.
-
-The Python function you provide can consist of "pure" Python code that
-only performs operations provided by standard Python.  However, the
-Python function can also "call back" to LAMMPS through its
-Python-wrapped library interface, in the manner described in the
-previous section 11.1.  This means it can issue LAMMPS input script
-commands or query and set internal LAMMPS state.  As an example, this
-can be useful in an input script to create a more complex loop with
-branching logic, than can be created using the simple looping and
-brancing logic enabled by the "next"_next.html and "if"_if.html
-commands.
-
-See the "python"_python.html doc page and the "variable"_variable.html
-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:
-
-make yes-python
-make machine :pre
-
-Note that this will link LAMMPS with the Python library on your
-system, which typically requires several auxiliary system libraries to
-also be linked.  The list of these libraries and the paths to find
-them are specified in the lib/python/Makefile.lammps file.  You need
-to insure that file contains the correct information for your version
-of Python and your machine to successfully build LAMMPS.  See the
-lib/python/README file for more info.
-
-If you want to write Python code with callbacks to LAMMPS, then you
-must also follow the steps overviewed in the preceeding section (11.1)
-for running LAMMPS from Python.  I.e. you must build LAMMPS as a
-shared library and insure that Python can find the python/lammps.py
-file and the shared library.
-
-:line
-
-11.3 Building LAMMPS as a shared library :link(py_3),h4
-
-Instructions on how to build LAMMPS as a shared library are given in
-"Section_start 5"_Section_start.html#start_5.  A shared library is one
-that is dynamically loadable, which is what Python requires to wrap
-LAMMPS.  On Linux this is a library file that ends in ".so", not ".a".
-
-From the src directory, type
-
-make foo mode=shlib :pre
-
-where foo is the machine target name, such as linux or g++ or serial.
-This should create the file liblammps_foo.so in the src directory, as
-well as a soft link liblammps.so, which is what the Python wrapper will
-load by default.  Note that if you are building multiple machine
-versions of the shared library, the soft link is always set to the
-most recently built version.
-
-NOTE: If you are building LAMMPS with an MPI or FFT library or other
-auxiliary libraries (used by various packages), then all of these
-extra libraries must also be shared libraries.  If the LAMMPS
-shared-library build fails with an error complaining about this, see
-"Section_start 5"_Section_start.html#start_5 for more details.
-
-:line
-
-11.4 Installing the Python wrapper into Python :link(py_4),h4
-
-For Python to invoke LAMMPS, there are 2 files it needs to know about:
-
-python/lammps.py
-src/liblammps.so :ul
-
-Lammps.py is the Python wrapper on the LAMMPS library interface.
-Liblammps.so is the shared LAMMPS library that Python loads, as
-described above.
-
-You can insure Python can find these files in one of two ways:
-
-set two environment variables
-run the python/install.py script :ul
-
-If you set the paths to these files as environment variables, you only
-have to do it once.  For the csh or tcsh shells, add something like
-this to your ~/.cshrc file, one line for each of the two files:
-
-setenv PYTHONPATH $\{PYTHONPATH\}:/home/sjplimp/lammps/python
-setenv LD_LIBRARY_PATH $\{LD_LIBRARY_PATH\}:/home/sjplimp/lammps/src :pre
-
-If you use the python/install.py script, you need to invoke it every
-time you rebuild LAMMPS (as a shared library) or make changes to the
-python/lammps.py file.
-
-You can invoke install.py from the python directory as
-
-% python install.py \[libdir\] \[pydir\] :pre
-
-The optional libdir is where to copy the LAMMPS shared library to; the
-default is /usr/local/lib.  The optional pydir is where to copy the
-lammps.py file to; the default is the site-packages directory of the
-version of Python that is running the install script.
-
-Note that libdir must be a location that is in your default
-LD_LIBRARY_PATH, like /usr/local/lib or /usr/lib.  And pydir must be a
-location that Python looks in by default for imported modules, like
-its site-packages dir.  If you want to copy these files to
-non-standard locations, such as within your own user space, you will
-need to set your PYTHONPATH and LD_LIBRARY_PATH environment variables
-accordingly, as above.
-
-If the install.py script does not allow you to copy files into system
-directories, prefix the python command with "sudo".  If you do this,
-make sure that the Python that root runs is the same as the Python you
-run.  E.g. you may need to do something like
-
-% sudo /usr/local/bin/python install.py \[libdir\] \[pydir\] :pre
-
-You can also invoke install.py from the make command in the src
-directory as
-
-% make install-python :pre
-
-In this mode you cannot append optional arguments.  Again, you may
-need to prefix this with "sudo".  In this mode you cannot control
-which Python is invoked by root.
-
-Note that if you want Python to be able to load different versions of
-the LAMMPS shared library (see "this section"_#py_5 below), you will
-need to manually copy files like liblammps_g++.so into the appropriate
-system directory.  This is not needed if you set the LD_LIBRARY_PATH
-environment variable as described above.
-
-:line
-
-11.5 Extending Python with MPI to run in parallel :link(py_5),h4
-
-If you wish to run LAMMPS in parallel from Python, you need to extend
-your Python with an interface to MPI.  This also allows you to
-make MPI calls directly from Python in your script, if you desire.
-
-There are several Python packages available that purport to wrap MPI
-as a library and allow MPI functions to be called from Python.
-
-These include
-
-"pyMPI"_http://pympi.sourceforge.net/
-"maroonmpi"_http://code.google.com/p/maroonmpi/
-"mpi4py"_http://code.google.com/p/mpi4py/
-"myMPI"_http://nbcr.sdsc.edu/forum/viewtopic.php?t=89&sid=c997fefc3933bd66204875b436940f16
-"Pypar"_http://code.google.com/p/pypar :ul
-
-All of these except pyMPI work by wrapping the MPI library and
-exposing (some portion of) its interface to your Python script.  This
-means Python cannot be used interactively in parallel, since they do
-not address the issue of interactive input to multiple instances of
-Python running on different processors.  The one exception is pyMPI,
-which alters the Python interpreter to address this issue, and (I
-believe) creates a new alternate executable (in place of "python"
-itself) as a result.
-
-In principle any of these Python/MPI packages should work to invoke
-LAMMPS in parallel and to make MPI calls themselves from a Python
-script which is itself running in parallel.  However, when I
-downloaded and looked at a few of them, their documentation was
-incomplete and I had trouble with their installation.  It's not clear
-if some of the packages are still being actively developed and
-supported.
-
-The packages Pypar and mpi4py have both been successfully tested with
-LAMMPS.  Pypar is simpler and easy to set up and use, but supports
-only a subset of MPI.  Mpi4py is more MPI-feature complete, but also a
-bit more complex to use.  As of version 2.0.0, mpi4py is the only
-python MPI wrapper that allows passing a custom MPI communicator to
-the LAMMPS constructor, which means one can easily run one or more
-LAMMPS instances on subsets of the total MPI ranks.
-
-:line
-
-Pypar requires the ubiquitous "Numpy package"_http://numpy.scipy.org
-be installed in your Python.  After launching Python, type
-
-import numpy :pre
-
-to see if it is installed.  If not, here is how to install it (version
-1.3.0b1 as of April 2009).  Unpack the numpy tarball and from its
-top-level directory, type
-
-python setup.py build
-sudo python setup.py install :pre
-
-The "sudo" is only needed if required to copy Numpy files into your
-Python distribution's site-packages directory.
-
-To install Pypar (version pypar-2.1.4_94 as of Aug 2012), unpack it
-and from its "source" directory, type
-
-python setup.py build
-sudo python setup.py install :pre
-
-Again, the "sudo" is only needed if required to copy Pypar files into
-your Python distribution's site-packages directory.
-
-If you have successully installed Pypar, you should be able to run
-Python and type
-
-import pypar :pre
-
-without error.  You should also be able to run python in parallel
-on a simple test script
-
-% mpirun -np 4 python test.py :pre
-
-where test.py contains the lines
-
-import pypar
-print "Proc %d out of %d procs" % (pypar.rank(),pypar.size()) :pre
-
-and see one line of output for each processor you run on.
-
-NOTE: To use Pypar and LAMMPS in parallel from Python, you must insure
-both are using the same version of MPI.  If you only have one MPI
-installed on your system, this is not an issue, but it can be if you
-have multiple MPIs.  Your LAMMPS build is explicit about which MPI it
-is using, since you specify the details in your lo-level
-src/MAKE/Makefile.foo file.  Pypar uses the "mpicc" command to find
-information about the MPI it uses to build against.  And it tries to
-load "libmpi.so" from the LD_LIBRARY_PATH.  This may or may not find
-the MPI library that LAMMPS is using.  If you have problems running
-both Pypar and LAMMPS together, this is an issue you may need to
-address, e.g. by moving other MPI installations so that Pypar finds
-the right one.
-
-:line
-
-To install mpi4py (version mpi4py-2.0.0 as of Oct 2015), unpack it
-and from its main directory, type
-
-python setup.py build
-sudo python setup.py install :pre
-
-Again, the "sudo" is only needed if required to copy mpi4py files into
-your Python distribution's site-packages directory. To install with
-user privilege into the user local directory type
-
-python setup.py install --user :pre
-
-If you have successully installed mpi4py, you should be able to run
-Python and type
-
-from mpi4py import MPI :pre
-
-without error.  You should also be able to run python in parallel
-on a simple test script
-
-% mpirun -np 4 python test.py :pre
-
-where test.py contains the lines
-
-from mpi4py import MPI
-comm = MPI.COMM_WORLD
-print "Proc %d out of %d procs" % (comm.Get_rank(),comm.Get_size()) :pre
-
-and see one line of output for each processor you run on.
-
-NOTE: To use mpi4py and LAMMPS in parallel from Python, you must
-insure both are using the same version of MPI.  If you only have one
-MPI installed on your system, this is not an issue, but it can be if
-you have multiple MPIs.  Your LAMMPS build is explicit about which MPI
-it is using, since you specify the details in your lo-level
-src/MAKE/Makefile.foo file.  Mpi4py uses the "mpicc" command to find
-information about the MPI it uses to build against.  And it tries to
-load "libmpi.so" from the LD_LIBRARY_PATH.  This may or may not find
-the MPI library that LAMMPS is using.  If you have problems running
-both mpi4py and LAMMPS together, this is an issue you may need to
-address, e.g. by moving other MPI installations so that mpi4py finds
-the right one.
-
-:line
-
-11.6 Testing the Python-LAMMPS interface :link(py_6),h4
-
-To test if LAMMPS is callable from Python, launch Python interactively
-and type:
-
->>> from lammps import lammps
->>> lmp = lammps() :pre
-
-If you get no errors, you're ready to use LAMMPS from Python.  If the
-2nd command fails, the most common error to see is
-
-OSError: Could not load LAMMPS dynamic library :pre
-
-which means Python was unable to load the LAMMPS shared library.  This
-typically occurs if the system can't find the LAMMPS shared library or
-one of the auxiliary shared libraries it depends on, or if something
-about the library is incompatible with your Python.  The error message
-should give you an indication of what went wrong.
-
-You can also test the load directly in Python as follows, without
-first importing from the lammps.py file:
-
->>> from ctypes import CDLL
->>> CDLL("liblammps.so") :pre
-
-If an error occurs, carefully go thru the steps in "Section_start
-5"_Section_start.html#start_5 and above about building a shared
-library and about insuring Python can find the necessary two files
-it needs.
-
-[Test LAMMPS and Python in serial:] :h5
-
-To run a LAMMPS test in serial, type these lines into Python
-interactively from the bench directory:
-
->>> from lammps import lammps
->>> lmp = lammps()
->>> lmp.file("in.lj") :pre
-
-Or put the same lines in the file test.py and run it as
-
-% python test.py :pre
-
-Either way, you should see the results of running the in.lj benchmark
-on a single processor appear on the screen, the same as if you had
-typed something like:
-
-lmp_g++ -in in.lj :pre
-
-[Test LAMMPS and Python in parallel:] :h5
-
-To run LAMMPS in parallel, assuming you have installed the
-"Pypar"_Pypar package as discussed above, create a test.py file
-containing these lines:
-
-import pypar
-from lammps import lammps
-lmp = lammps()
-lmp.file("in.lj")
-print "Proc %d out of %d procs has" % (pypar.rank(),pypar.size()),lmp
-pypar.finalize() :pre
-
-To run LAMMPS in parallel, assuming you have installed the
-"mpi4py"_mpi4py package as discussed above, create a test.py file
-containing these lines:
-
-from mpi4py import MPI
-from lammps import lammps
-lmp = lammps()
-lmp.file("in.lj")
-me = MPI.COMM_WORLD.Get_rank()
-nprocs = MPI.COMM_WORLD.Get_size()
-print "Proc %d out of %d procs has" % (me,nprocs),lmp
-MPI.Finalize() :pre
-
-You can either script in parallel as:
-
-% mpirun -np 4 python test.py :pre
-
-and you should see the same output as if you had typed
-
-% mpirun -np 4 lmp_g++ -in in.lj :pre
-
-Note that if you leave out the 3 lines from test.py that specify Pypar
-commands you will instantiate and run LAMMPS independently on each of
-the P processors specified in the mpirun command.  In this case you
-should get 4 sets of output, each showing that a LAMMPS run was made
-on a single processor, instead of one set of output showing that
-LAMMPS ran on 4 processors.  If the 1-processor outputs occur, it
-means that Pypar is not working correctly.
-
-Also note that once you import the PyPar module, Pypar initializes MPI
-for you, and you can use MPI calls directly in your Python script, as
-described in the Pypar documentation.  The last line of your Python
-script should be pypar.finalize(), to insure MPI is shut down
-correctly.
-
-[Running Python scripts:] :h5
-
-Note that any Python script (not just for LAMMPS) can be invoked in
-one of several ways:
-
-% python foo.script
-% python -i foo.script
-% foo.script :pre
-
-The last command requires that the first line of the script be
-something like this:
-
-#!/usr/local/bin/python 
-#!/usr/local/bin/python -i :pre
-
-where the path points to where you have Python installed, and that you
-have made the script file executable:
-
-% chmod +x foo.script :pre
-
-Without the "-i" flag, Python will exit when the script finishes.
-With the "-i" flag, you will be left in the Python interpreter when
-the script finishes, so you can type subsequent commands.  As
-mentioned above, you can only run Python interactively when running
-Python on a single processor, not in parallel.
-
-:line
-:line
-
-11.7 Using LAMMPS from Python :link(py_7),h4
-
-As described above, the Python interface to LAMMPS consists of a
-Python "lammps" module, the source code for which is in
-python/lammps.py, which creates a "lammps" object, with a set of
-methods that can be invoked on that object.  The sample Python code
-below assumes you have first imported the "lammps" module in your
-Python script, as follows:
-
-from lammps import lammps :pre
-
-These are the methods defined by the lammps module.  If you look at
-the files src/library.cpp and src/library.h you will see that they
-correspond one-to-one with calls you can make to the LAMMPS library
-from a C++ or C or Fortran program.
-
-lmp = lammps()           # create a LAMMPS object using the default liblammps.so library
-                         4 optional args are allowed: name, cmdargs, ptr, comm
-lmp = lammps(ptr=lmpptr) # use lmpptr as previously created LAMMPS object
-lmp = lammps(comm=split) # create a LAMMPS object with a custom communicator, requires mpi4py 2.0.0 or later
-lmp = lammps(name="g++")   # create a LAMMPS object using the liblammps_g++.so library
-lmp = lammps(name="g++",cmdargs=list)    # add LAMMPS command-line args, e.g. list = \["-echo","screen"\] :pre
-
-lmp.close()              # destroy a LAMMPS object :pre
-
-version = lmp.version()  # return the numerical version id, e.g. LAMMPS 2 Sep 2015 -> 20150902
-
-lmp.file(file)           # run an entire input script, file = "in.lj"
-lmp.command(cmd)         # invoke a single LAMMPS command, cmd = "run 100" :pre
-
-xlo = lmp.extract_global(name,type)  # extract a global quantity
-                                     # name = "boxxlo", "nlocal", etc
-				     # type = 0 = int
-				     #        1 = double :pre
-
-coords = lmp.extract_atom(name,type)      # extract a per-atom quantity
-                                          # name = "x", "type", etc
-				          # type = 0 = vector of ints
-				          #        1 = array of ints
-				          #        2 = vector of doubles
-				          #        3 = array of doubles :pre
-
-eng = lmp.extract_compute(id,style,type)  # extract value(s) from a compute
-v3 = lmp.extract_fix(id,style,type,i,j)   # extract value(s) from a fix
-                                          # id = ID of compute or fix
-					  # style = 0 = global data
-					  #	    1 = per-atom data
-					  #         2 = local data
-					  # type = 0 = scalar
-					  #	   1 = vector
-					  #        2 = array
-					  # i,j = indices of value in global vector or array :pre
-
-var = lmp.extract_variable(name,group,flag)  # extract value(s) from a variable
-	                                     # name = name of variable
-					     # group = group ID (ignored for equal-style variables)
-					     # flag = 0 = equal-style variable
-					     #        1 = atom-style variable :pre
-
-flag = lmp.set_variable(name,value)       # set existing named string-style variable to value, flag = 0 if successful
-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
-                                          # 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
-                                          # name = "x", "charge", "type", etc
-                                          # count = # of per-atom values, 1 or 3, etc :pre
-
-:line
-
-The lines
-
-from lammps import lammps
-lmp = lammps() :pre
-
-create an instance of LAMMPS, wrapped in a Python class by the lammps
-Python module, and return an instance of the Python class as lmp.  It
-is used to make all subequent calls to the LAMMPS library.
-
-Additional arguments can be used to tell Python the name of the shared
-library to load or to pass arguments to the LAMMPS instance, the same
-as if LAMMPS were launched from a command-line prompt.
-
-If the ptr argument is set like this:
-
-lmp = lammps(ptr=lmpptr) :pre
-
-then lmpptr must be an argument passed to Python via the LAMMPS
-"python"_python.html command, when it is used to define a Python
-function that is invoked by the LAMMPS input script.  This mode of
-using Python with LAMMPS is described above in 11.2.  The variable
-lmpptr refers to the instance of LAMMPS that called the embedded
-Python interpreter.  Using it as an argument to lammps() allows the
-returned Python class instance "lmp" to make calls to that instance of
-LAMMPS.  See the "python"_python.html command doc page for examples
-using this syntax.
-
-Note that you can create multiple LAMMPS objects in your Python
-script, and coordinate and run multiple simulations, e.g.
-
-from lammps import lammps
-lmp1 = lammps()
-lmp2 = lammps()
-lmp1.file("in.file1")
-lmp2.file("in.file2") :pre
-
-The file() and command() methods allow an input script or single
-commands to be invoked.
-
-The extract_global(), extract_atom(), extract_compute(),
-extract_fix(), and extract_variable() methods return values or
-pointers to data structures internal to LAMMPS.
-
-For extract_global() see the src/library.cpp file for the list of
-valid names.  New names could easily be added.  A double or integer is
-returned.  You need to specify the appropriate data type via the type
-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.
-
-For extract_compute() and extract_fix(), the global, per-atom, or
-local data calulated by the compute or fix can be accessed.  What is
-returned depends on whether the compute or fix calculates a scalar or
-vector or array.  For a scalar, a single double value is returned.  If
-the compute or fix calculates a vector or array, a pointer to the
-internal LAMMPS data is returned, which you can use via normal Python
-subscripting.  The one exception is that for a fix that calculates a
-global vector or array, a single double value from the vector or array
-is returned, indexed by I (vector) or I and J (array).  I,J are
-zero-based indices.  The I,J arguments can be left out if not needed.
-See "Section_howto 15"_Section_howto.html#howto_15 of the manual for a
-discussion of global, per-atom, and local data, and of scalar, vector,
-and array data types.  See the doc pages for individual
-"computes"_compute.html and "fixes"_fix.html for a description of what
-they calculate and store.
-
-For extract_variable(), an "equal-style or atom-style
-variable"_variable.html is evaluated and its result returned.
-
-For equal-style variables a single double value is returned and the
-group argument is ignored.  For atom-style variables, a vector of
-doubles is returned, one value per atom, which you can use via normal
-Python subscripting. The values will be zero for atoms not in the
-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.
-
-Note that the data structure gather_atoms("x") returns is different
-from the data structure returned by extract_atom("x") in four ways.
-(1) Gather_atoms() returns a vector which you index as x\[i\];
-extract_atom() returns an array which you index as x\[i\]\[j\].  (2)
-Gather_atoms() orders the atoms by atom ID while extract_atom() does
-not.  (3) Gathert_atoms() returns a list of all atoms in the
-simulation; extract_atoms() returns just the atoms local to each
-processor.  (4) Finally, the gather_atoms() data structure is a copy
-of the atom coords stored internally in LAMMPS, whereas extract_atom()
-returns an array that effectively points directly to the internal
-data.  This means you can change values inside LAMMPS from Python by
-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 array of coordinates passed to scatter_atoms() must be a ctypes
-vector of ints or doubles, allocated and initialized something like
-this:
-
-from ctypes import *
-natoms = lmp.get_natoms()
-n3 = 3*natoms
-x = (n3*c_double)()
-x\[0\] = x coord of atom with ID 1
-x\[1\] = y coord of atom with ID 1
-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
-
-Alternatively, you can just change values in the vector returned by
-gather_atoms("x",1,3), since it is a ctypes vector of doubles.
-
-:line 
-
-As noted above, these Python class methods correspond one-to-one with
-the functions in the LAMMPS library interface in src/library.cpp and
-library.h.  This means you can extend the Python wrapper via the
-following steps:
-
-Add a new interface function to src/library.cpp and
-src/library.h. :ulb,l
-
-Rebuild LAMMPS as a shared library. :l
-
-Add a wrapper method to python/lammps.py for this interface
-function. :l
-
-You should now be able to invoke the new interface function from a
-Python script.  Isn't ctypes amazing? :l,ule
-
-:line
-:line
-
-11.8 Example Python scripts that use LAMMPS :link(py_8),h4
-
-These are the Python scripts included as demos in the python/examples
-directory of the LAMMPS distribution, to illustrate the kinds of
-things that are possible when Python wraps LAMMPS.  If you create your
-own scripts, send them to us and we can include them in the LAMMPS
-distribution.
-
-trivial.py, read/run a LAMMPS input script thru Python,
-demo.py, invoke various LAMMPS library interface routines,
-simple.py, run in parallel, similar to examples/COUPLE/simple/simple.cpp,
-split.py, same as simple.py but running in parallel on a subset of procs,
-gui.py, GUI go/stop/temperature-slider to control LAMMPS,
-plot.py, real-time temeperature plot with GnuPlot via Pizza.py,
-viz_tool.py, real-time viz via some viz package,
-vizplotgui_tool.py, combination of viz_tool.py and plot.py and gui.py :tb(c=2)
-
-:line
-
-For the viz_tool.py and vizplotgui_tool.py commands, replace "tool"
-with "gl" or "atomeye" or "pymol" or "vmd", depending on what
-visualization package you have installed. 
-
-Note that for GL, you need to be able to run the Pizza.py GL tool,
-which is included in the pizza sub-directory.  See the "Pizza.py doc
-pages"_pizza for more info:
-
-:link(pizza,http://www.sandia.gov/~sjplimp/pizza.html)
-
-Note that for AtomEye, you need version 3, and there is a line in the
-scripts that specifies the path and name of the executable.  See the
-AtomEye WWW pages "here"_atomeye or "here"_atomeye3 for more details:
-
-http://mt.seas.upenn.edu/Archive/Graphics/A
-http://mt.seas.upenn.edu/Archive/Graphics/A3/A3.html :pre
-
-:link(atomeye,http://mt.seas.upenn.edu/Archive/Graphics/A)
-:link(atomeye3,http://mt.seas.upenn.edu/Archive/Graphics/A3/A3.html)
-
-The latter link is to AtomEye 3 which has the scriping
-capability needed by these Python scripts.
-
-Note that for PyMol, you need to have built and installed the
-open-source version of PyMol in your Python, so that you can import it
-from a Python script.  See the PyMol WWW pages "here"_pymol or
-"here"_pymolopen for more details:
-
-http://www.pymol.org
-http://sourceforge.net/scm/?type=svn&group_id=4546 :pre
-
-:link(pymol,http://www.pymol.org)
-:link(pymolopen,http://sourceforge.net/scm/?type=svn&group_id=4546)
-
-The latter link is to the open-source version.
-
-Note that for VMD, you need a fairly current version (1.8.7 works for
-me) and there are some lines in the pizza/vmd.py script for 4 PIZZA
-variables that have to match the VMD installation on your system.
-
-:line
-
-See the python/README file for instructions on how to run them and the
-source code for individual scripts for comments about what they do.
-
-Here are screenshots of the vizplotgui_tool.py script in action for
-different visualization package options.  Click to see larger images:
-
-:image(JPG/screenshot_gl_small.jpg,JPG/screenshot_gl.jpg)
-:image(JPG/screenshot_atomeye_small.jpg,JPG/screenshot_atomeye.jpg)
-:image(JPG/screenshot_pymol_small.jpg,JPG/screenshot_pymol.jpg)
-:image(JPG/screenshot_vmd_small.jpg,JPG/screenshot_vmd.jpg)

doc/Section_tools.html

@@ -1,707 +0,0 @@
-
-
-<!DOCTYPE html>
-<!--[if IE 8]><html class="no-js lt-ie9" lang="en" > <![endif]-->
-<!--[if gt IE 8]><!--> <html class="no-js" lang="en" > <!--<![endif]-->
-<head>
-  <meta charset="utf-8">
-  
-  <meta name="viewport" content="width=device-width, initial-scale=1.0">
-  
-  <title>9. Additional tools &mdash; LAMMPS documentation</title>
-  
-
-  
-  
-
-  
-
-  
-  
-    
-
-  
-
-  
-  
-    <link rel="stylesheet" href="_static/css/theme.css" type="text/css" />
-  
-
-  
-    <link rel="stylesheet" href="_static/sphinxcontrib-images/LightBox2/lightbox2/css/lightbox.css" type="text/css" />
-  
-
-  
-    <link rel="top" title="LAMMPS documentation" href="index.html"/>
-        <link rel="next" title="10. Modifying &amp; extending LAMMPS" href="Section_modify.html"/>
-        <link rel="prev" title="8. Performance &amp; scalability" href="Section_perf.html"/> 
-
-  
-  <script src="_static/js/modernizr.min.js"></script>
-
-</head>
-
-<body class="wy-body-for-nav" role="document">
-
-  <div class="wy-grid-for-nav">
-
-    
-    <nav data-toggle="wy-nav-shift" class="wy-nav-side">
-      <div class="wy-side-nav-search">
-        
-
-        
-          <a href="Manual.html" class="icon icon-home"> LAMMPS
-        
-
-        
-        </a>
-
-        
-<div role="search">
-  <form id="rtd-search-form" class="wy-form" action="search.html" method="get">
-    <input type="text" name="q" placeholder="Search docs" />
-    <input type="hidden" name="check_keywords" value="yes" />
-    <input type="hidden" name="area" value="default" />
-  </form>
-</div>
-
-        
-      </div>
-
-      <div class="wy-menu wy-menu-vertical" data-spy="affix" role="navigation" aria-label="main navigation">
-        
-          
-          
-              <ul class="current">
-<li class="toctree-l1"><a class="reference internal" href="Section_intro.html">1. Introduction</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_start.html">2. Getting Started</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_commands.html">3. Commands</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_packages.html">4. Packages</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_accelerate.html">5. Accelerating LAMMPS performance</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_howto.html">6. How-to discussions</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_example.html">7. Example problems</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_perf.html">8. Performance &amp; scalability</a></li>
-<li class="toctree-l1 current"><a class="current reference internal" href="">9. Additional tools</a><ul>
-<li class="toctree-l2"><a class="reference internal" href="#amber2lmp-tool">9.1. amber2lmp tool</a></li>
-<li class="toctree-l2"><a class="reference internal" href="#binary2txt-tool">9.2. binary2txt tool</a></li>
-<li class="toctree-l2"><a class="reference internal" href="#ch2lmp-tool">9.3. ch2lmp tool</a></li>
-<li class="toctree-l2"><a class="reference internal" href="#chain-tool">9.4. chain tool</a></li>
-<li class="toctree-l2"><a class="reference internal" href="#colvars-tools">9.5. colvars tools</a></li>
-<li class="toctree-l2"><a class="reference internal" href="#createatoms-tool">9.6. createatoms tool</a></li>
-<li class="toctree-l2"><a class="reference internal" href="#data2xmovie-tool">9.7. data2xmovie tool</a></li>
-<li class="toctree-l2"><a class="reference internal" href="#eam-database-tool">9.8. eam database tool</a></li>
-<li class="toctree-l2"><a class="reference internal" href="#eam-generate-tool">9.9. eam generate tool</a></li>
-<li class="toctree-l2"><a class="reference internal" href="#eff-tool">9.10. eff tool</a></li>
-<li class="toctree-l2"><a class="reference internal" href="#emacs-tool">9.11. emacs tool</a></li>
-<li class="toctree-l2"><a class="reference internal" href="#fep-tool">9.12. fep tool</a></li>
-<li class="toctree-l2"><a class="reference internal" href="#i-pi-tool">9.13. i-pi tool</a></li>
-<li class="toctree-l2"><a class="reference internal" href="#ipp-tool">9.14. ipp tool</a></li>
-<li class="toctree-l2"><a class="reference internal" href="#kate-tool">9.15. kate tool</a></li>
-<li class="toctree-l2"><a class="reference internal" href="#lmp2arc-tool">9.16. lmp2arc tool</a></li>
-<li class="toctree-l2"><a class="reference internal" href="#lmp2cfg-tool">9.17. lmp2cfg tool</a></li>
-<li class="toctree-l2"><a class="reference internal" href="#lmp2vmd-tool">9.18. lmp2vmd tool</a></li>
-<li class="toctree-l2"><a class="reference internal" href="#matlab-tool">9.19. matlab tool</a></li>
-<li class="toctree-l2"><a class="reference internal" href="#micelle2d-tool">9.20. micelle2d tool</a></li>
-<li class="toctree-l2"><a class="reference internal" href="#moltemplate-tool">9.21. moltemplate tool</a></li>
-<li class="toctree-l2"><a class="reference internal" href="#msi2lmp-tool">9.22. msi2lmp tool</a></li>
-<li class="toctree-l2"><a class="reference internal" href="#phonon-tool">9.23. phonon tool</a></li>
-<li class="toctree-l2"><a class="reference internal" href="#polymer-bonding-tool">9.24. polymer bonding tool</a></li>
-<li class="toctree-l2"><a class="reference internal" href="#pymol-asphere-tool">9.25. pymol_asphere tool</a></li>
-<li class="toctree-l2"><a class="reference internal" href="#python-tool">9.26. python tool</a></li>
-<li class="toctree-l2"><a class="reference internal" href="#reax-tool">9.27. reax tool</a></li>
-<li class="toctree-l2"><a class="reference internal" href="#restart2data-tool">9.28. restart2data tool</a></li>
-<li class="toctree-l2"><a class="reference internal" href="#vim-tool">9.29. vim tool</a></li>
-<li class="toctree-l2"><a class="reference internal" href="#xmgrace-tool">9.30. xmgrace tool</a></li>
-<li class="toctree-l2"><a class="reference internal" href="#xmovie-tool">9.31. xmovie tool</a></li>
-</ul>
-</li>
-<li class="toctree-l1"><a class="reference internal" href="Section_modify.html">10. Modifying &amp; extending LAMMPS</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_python.html">11. Python interface to LAMMPS</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_errors.html">12. Errors</a></li>
-<li class="toctree-l1"><a class="reference internal" href="Section_history.html">13. Future and history</a></li>
-</ul>
-
-          
-        
-      </div>
-      &nbsp;
-    </nav>
-
-    <section data-toggle="wy-nav-shift" class="wy-nav-content-wrap">
-
-      
-      <nav class="wy-nav-top" role="navigation" aria-label="top navigation">
-        <i data-toggle="wy-nav-top" class="fa fa-bars"></i>
-        <a href="Manual.html">LAMMPS</a>
-      </nav>
-
-
-      
-      <div class="wy-nav-content">
-        <div class="rst-content">
-          <div role="navigation" aria-label="breadcrumbs navigation">
-  <ul class="wy-breadcrumbs">
-    <li><a href="Manual.html">Docs</a> &raquo;</li>
-      
-    <li>9. Additional tools</li>
-      <li class="wy-breadcrumbs-aside">
-        
-          
-            <a href="http://lammps.sandia.gov">Website</a>
-            <a href="Section_commands.html#comm">Commands</a>
-        
-      </li>
-  </ul>
-  <hr/>
-  
-    <div class="rst-footer-buttons" style="margin-bottom: 1em" role="navigation" aria-label="footer navigation">
-      
-        <a href="Section_modify.html" class="btn btn-neutral float-right" title="10. Modifying &amp; extending LAMMPS" accesskey="n">Next <span class="fa fa-arrow-circle-right"></span></a>
-      
-      
-        <a href="Section_perf.html" class="btn btn-neutral" title="8. Performance &amp; scalability" accesskey="p"><span class="fa fa-arrow-circle-left"></span> Previous</a>
-      
-    </div>
-  
-</div>
-          <div role="main" class="document" itemscope="itemscope" itemtype="http://schema.org/Article">
-           <div itemprop="articleBody">
-            
-  <div class="section" id="additional-tools">
-<h1>9. Additional tools<a class="headerlink" href="#additional-tools" title="Permalink to this headline">¶</a></h1>
-<p>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.</p>
-<p>Our group has also written and released a separate toolkit called
-<a class="reference external" href="http://www.sandia.gov/~sjplimp/pizza.html">Pizza.py</a> which provides tools for doing setup, analysis,
-plotting, and visualization for LAMMPS simulations.  Pizza.py is
-written in <a class="reference external" href="http://www.python.org">Python</a> and is available for download from <a class="reference external" href="http://www.sandia.gov/~sjplimp/pizza.html">the Pizza.py WWW site</a>.</p>
-<p>Note that many users write their own setup or analysis tools or use
-other existing codes and convert their output to a LAMMPS input format
-or vice versa.  The tools listed here are included in the LAMMPS
-distribution as examples of auxiliary tools.  Some of them are not
-actively supported by Sandia, as they were contributed by LAMMPS
-users.  If you have problems using them, we can direct you to the
-authors.</p>
-<p>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.</p>
-<ul class="simple">
-<li><a class="reference internal" href="#amber"><span>amber2lmp</span></a></li>
-<li><a class="reference internal" href="#binary"><span>binary2txt</span></a></li>
-<li><a class="reference internal" href="#charmm"><span>ch2lmp</span></a></li>
-<li><a class="reference internal" href="#chain"><span>chain</span></a></li>
-<li><a class="reference internal" href="#colvars"><span>colvars</span></a></li>
-<li><a class="reference internal" href="#create"><span>createatoms</span></a></li>
-<li><a class="reference internal" href="#data"><span>data2xmovie</span></a></li>
-<li><a class="reference internal" href="#eamdb"><span>eam database</span></a></li>
-<li><a class="reference internal" href="#eamgn"><span>eam generate</span></a></li>
-<li><a class="reference internal" href="#eff"><span>eff</span></a></li>
-<li><a class="reference internal" href="#emacs"><span>emacs</span></a></li>
-<li><a class="reference internal" href="#fep"><span>fep</span></a></li>
-<li><a class="reference internal" href="fix_ipi.html#ipi"><span>i-pi</span></a></li>
-<li><a class="reference internal" href="#ipp"><span>ipp</span></a></li>
-<li><a class="reference internal" href="#kate"><span>kate</span></a></li>
-<li><a class="reference internal" href="#arc"><span>lmp2arc</span></a></li>
-<li><a class="reference internal" href="#cfg"><span>lmp2cfg</span></a></li>
-<li><a class="reference internal" href="#vmd"><span>lmp2vmd</span></a></li>
-<li><span class="xref std std-ref">matlab</span></li>
-<li><a class="reference internal" href="#micelle"><span>micelle2d</span></a></li>
-<li><a class="reference internal" href="#moltemplate"><span>moltemplate</span></a></li>
-<li><a class="reference internal" href="#msi"><span>msi2lmp</span></a></li>
-<li><a class="reference internal" href="#phonon"><span>phonon</span></a></li>
-<li><a class="reference internal" href="#polybond"><span>polymer bonding</span></a></li>
-<li><span class="xref std std-ref">pymol_asphere</span></li>
-<li><a class="reference internal" href="#pythontools"><span>python</span></a></li>
-<li><a class="reference internal" href="#reax"><span>reax</span></a></li>
-<li><a class="reference internal" href="#restart"><span>restart2data</span></a></li>
-<li><a class="reference internal" href="#vim"><span>vim</span></a></li>
-<li><a class="reference internal" href="#xmgrace"><span>xmgrace</span></a></li>
-<li><a class="reference internal" href="#xmovie"><span>xmovie</span></a></li>
-</ul>
-<hr class="docutils" />
-<div class="section" id="amber2lmp-tool">
-<span id="amber"></span><h2>9.1. amber2lmp tool<a class="headerlink" href="#amber2lmp-tool" title="Permalink to this headline">¶</a></h2>
-<p>The amber2lmp sub-directory contains two Python scripts for converting
-files back-and-forth between the AMBER MD code and LAMMPS.  See the
-README file in amber2lmp for more information.</p>
-<p>These tools were written by Keir Novik while he was at Queen Mary
-University of London.  Keir is no longer there and cannot support
-these tools which are out-of-date with respect to the current LAMMPS
-version (and maybe with respect to AMBER as well).  Since we don&#8217;t use
-these tools at Sandia, you&#8217;ll need to experiment with them and make
-necessary modifications yourself.</p>
-<hr class="docutils" />
-</div>
-<div class="section" id="binary2txt-tool">
-<span id="binary"></span><h2>9.2. binary2txt tool<a class="headerlink" href="#binary2txt-tool" title="Permalink to this headline">¶</a></h2>
-<p>The file binary2txt.cpp converts one or more binary LAMMPS dump file
-into ASCII text files.  The syntax for running the tool is</p>
-<div class="highlight-python"><div class="highlight"><pre>binary2txt file1 file2 ...
-</pre></div>
-</div>
-<p>which creates file1.txt, file2.txt, etc.  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.</p>
-<hr class="docutils" />
-</div>
-<div class="section" id="ch2lmp-tool">
-<span id="charmm"></span><h2>9.3. ch2lmp tool<a class="headerlink" href="#ch2lmp-tool" title="Permalink to this headline">¶</a></h2>
-<p>The ch2lmp sub-directory contains tools for converting files
-back-and-forth between the CHARMM MD code and LAMMPS.</p>
-<p>They are intended to make it easy to use CHARMM as a builder and as a
-post-processor for LAMMPS. Using charmm2lammps.pl, you can convert an
-ensemble built in CHARMM into its LAMMPS equivalent.  Using
-lammps2pdb.pl you can convert LAMMPS atom dumps into pdb files.</p>
-<p>See the README file in the ch2lmp sub-directory for more information.</p>
-<p>These tools were created by Pieter in&#8217;t Veld (pjintve at sandia.gov)
-and Paul Crozier (pscrozi at sandia.gov) at Sandia.</p>
-<hr class="docutils" />
-</div>
-<div class="section" id="chain-tool">
-<span id="chain"></span><h2>9.4. chain tool<a class="headerlink" href="#chain-tool" title="Permalink to this headline">¶</a></h2>
-<p>The file chain.f creates a LAMMPS data file containing bead-spring
-polymer chains and/or monomer solvent atoms.  It uses a text file
-containing chain definition parameters as an input.  The created
-chains and solvent atoms can strongly overlap, so LAMMPS needs to run
-the system initially with a &#8220;soft&#8221; pair potential to un-overlap it.
-The syntax for running the tool is</p>
-<div class="highlight-python"><div class="highlight"><pre>chain &lt; def.chain &gt; data.file
-</pre></div>
-</div>
-<p>See the def.chain or def.chain.ab files in the tools directory for
-examples of definition files.  This tool was used to create the
-system for the <a class="reference internal" href="Section_perf.html"><em>chain benchmark</em></a>.</p>
-<hr class="docutils" />
-</div>
-<div class="section" id="colvars-tools">
-<span id="colvars"></span><h2>9.5. colvars tools<a class="headerlink" href="#colvars-tools" title="Permalink to this headline">¶</a></h2>
-<p>The colvars directory contains a collection of tools for postprocessing
-data produced by the colvars collective variable library.
-To compile the tools, edit the makefile for your system and run &#8220;make&#8221;.</p>
-<p>Please report problems and issues the colvars library and its tools
-at: <a class="reference external" href="https://github.com/colvars/colvars/issues">https://github.com/colvars/colvars/issues</a></p>
-<p>abf_integrate:</p>
-<p>MC-based integration of multidimensional free energy gradient
-Version 20110511</p>
-<div class="highlight-python"><div class="highlight"><pre>Syntax: ./abf_integrate &lt; filename &gt; [-n &lt; nsteps &gt;] [-t &lt; temp &gt;] [-m [0|1] (metadynamics)] [-h &lt; hill_height &gt;] [-f &lt; variable_hill_factor &gt;]
-</pre></div>
-</div>
-<p>The LAMMPS interface to the colvars collective variable library, as
-well as these tools, were created by Axel Kohlmeyer (akohlmey at
-gmail.com) at ICTP, Italy.</p>
-<hr class="docutils" />
-</div>
-<div class="section" id="createatoms-tool">
-<span id="create"></span><h2>9.6. createatoms tool<a class="headerlink" href="#createatoms-tool" title="Permalink to this headline">¶</a></h2>
-<p>The tools/createatoms directory contains a Fortran program called
-createAtoms.f which can generate a variety of interesting crystal
-structures and geometries and output the resulting list of atom
-coordinates in LAMMPS or other formats.</p>
-<p>See the included Manual.pdf for details.</p>
-<p>The tool is authored by Xiaowang Zhou (Sandia), xzhou at sandia.gov.</p>
-<hr class="docutils" />
-</div>
-<div class="section" id="data2xmovie-tool">
-<span id="data"></span><h2>9.7. data2xmovie tool<a class="headerlink" href="#data2xmovie-tool" title="Permalink to this headline">¶</a></h2>
-<p>The file data2xmovie.c converts a LAMMPS data file into a snapshot
-suitable for visualizing with the <a class="reference internal" href="#xmovie"><span>xmovie</span></a> tool, as if it had
-been output with a dump command from LAMMPS itself.  The syntax for
-running the tool is</p>
-<div class="highlight-python"><div class="highlight"><pre><span class="n">data2xmovie</span> <span class="p">[</span><span class="n">options</span><span class="p">]</span> <span class="o">&lt;</span> <span class="n">infile</span> <span class="o">&gt;</span> <span class="n">outfile</span>
-</pre></div>
-</div>
-<p>See the top of the data2xmovie.c file for a discussion of the options.</p>
-<hr class="docutils" />
-</div>
-<div class="section" id="eam-database-tool">
-<span id="eamdb"></span><h2>9.8. eam database tool<a class="headerlink" href="#eam-database-tool" title="Permalink to this headline">¶</a></h2>
-<p>The tools/eam_database directory contains a Fortran program that will
-generate EAM alloy setfl potential files for any combination of 16
-elements: Cu, Ag, Au, Ni, Pd, Pt, Al, Pb, Fe, Mo, Ta, W, Mg, Co, Ti,
-Zr.  The files can then be used with the <a class="reference internal" href="pair_eam.html"><em>pair_style eam/alloy</em></a> command.</p>
-<p>The tool is authored by Xiaowang Zhou (Sandia), xzhou at sandia.gov,
-and is based on his paper:</p>
-<p>X. W. Zhou, R. A. Johnson, and H. N. G. Wadley, Phys. Rev. B, 69,
-144113 (2004).</p>
-<hr class="docutils" />
-</div>
-<div class="section" id="eam-generate-tool">
-<span id="eamgn"></span><h2>9.9. eam generate tool<a class="headerlink" href="#eam-generate-tool" title="Permalink to this headline">¶</a></h2>
-<p>The tools/eam_generate directory contains several one-file C programs
-that convert an analytic formula into a tabulated <a class="reference internal" href="pair_eam.html"><em>embedded atom method (EAM)</em></a> setfl potential file.  The potentials they
-produce are in the potentials directory, and can be used with the
-<a class="reference internal" href="pair_eam.html"><em>pair_style eam/alloy</em></a> command.</p>
-<p>The source files and potentials were provided by Gerolf Ziegenhain
-(gerolf at ziegenhain.com).</p>
-<hr class="docutils" />
-</div>
-<div class="section" id="eff-tool">
-<span id="eff"></span><h2>9.10. eff tool<a class="headerlink" href="#eff-tool" title="Permalink to this headline">¶</a></h2>
-<p>The tools/eff directory contains various scripts for generating
-structures and post-processing output for simulations using the
-electron force field (eFF).</p>
-<p>These tools were provided by Andres Jaramillo-Botero at CalTech
-(ajaramil at wag.caltech.edu).</p>
-<hr class="docutils" />
-</div>
-<div class="section" id="emacs-tool">
-<span id="emacs"></span><h2>9.11. emacs tool<a class="headerlink" href="#emacs-tool" title="Permalink to this headline">¶</a></h2>
-<p>The tools/emacs directory contains a Lips add-on file for Emacs that
-enables a lammps-mode for editing of input scripts when using Emacs,
-with various highlighting options setup.</p>
-<p>These tools were provided by Aidan Thompson at Sandia
-(athomps at sandia.gov).</p>
-<hr class="docutils" />
-</div>
-<div class="section" id="fep-tool">
-<span id="fep"></span><h2>9.12. fep tool<a class="headerlink" href="#fep-tool" title="Permalink to this headline">¶</a></h2>
-<p>The tools/fep directory contains Python scripts useful for
-post-processing results from performing free-energy perturbation
-simulations using the USER-FEP package.</p>
-<p>The scripts were contributed by Agilio Padua (Universite Blaise
-Pascal Clermont-Ferrand), agilio.padua at univ-bpclermont.fr.</p>
-<p>See README file in the tools/fep directory.</p>
-<hr class="docutils" />
-</div>
-<div class="section" id="i-pi-tool">
-<span id="ipi"></span><h2>9.13. i-pi tool<a class="headerlink" href="#i-pi-tool" title="Permalink to this headline">¶</a></h2>
-<p>The tools/i-pi directory contains a version of the i-PI package, with
-all the LAMMPS-unrelated files removed.  It is provided so that it can
-be used with the <a class="reference internal" href="fix_ipi.html"><em>fix ipi</em></a> command to perform
-path-integral molecular dynamics (PIMD).</p>
-<p>The i-PI package was created and is maintained by Michele Ceriotti,
-michele.ceriotti at gmail.com, to interface to a variety of molecular
-dynamics codes.</p>
-<p>See the tools/i-pi/manual.pdf file for an overview of i-PI, and the
-<a class="reference internal" href="fix_ipi.html"><em>fix ipi</em></a> doc page for further details on running PIMD
-calculations with LAMMPS.</p>
-<hr class="docutils" />
-</div>
-<div class="section" id="ipp-tool">
-<span id="ipp"></span><h2>9.14. ipp tool<a class="headerlink" href="#ipp-tool" title="Permalink to this headline">¶</a></h2>
-<p>The tools/ipp directory contains a Perl script ipp which can be used
-to facilitate the creation of a complicated file (say, a lammps input
-script or tools/createatoms input file) using a template file.</p>
-<p>ipp was created and is maintained by Reese Jones (Sandia), rjones at
-sandia.gov.</p>
-<p>See two examples in the tools/ipp directory.  One of them is for the
-tools/createatoms tool&#8217;s input file.</p>
-<hr class="docutils" />
-</div>
-<div class="section" id="kate-tool">
-<span id="kate"></span><h2>9.15. kate tool<a class="headerlink" href="#kate-tool" title="Permalink to this headline">¶</a></h2>
-<p>The file in the tools/kate directory is an add-on to the Kate editor
-in the KDE suite that allow syntax highlighting of LAMMPS input
-scripts.  See the README.txt file for details.</p>
-<p>The file was provided by Alessandro Luigi Sellerio
-(alessandro.sellerio at ieni.cnr.it).</p>
-<hr class="docutils" />
-</div>
-<div class="section" id="lmp2arc-tool">
-<span id="arc"></span><h2>9.16. lmp2arc tool<a class="headerlink" href="#lmp2arc-tool" title="Permalink to this headline">¶</a></h2>
-<p>The lmp2arc sub-directory contains a tool for converting LAMMPS output
-files to the format for Accelrys&#8217; Insight MD code (formerly
-MSI/Biosym and its Discover MD code).  See the README file for more
-information.</p>
-<p>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.</p>
-<p>This tool was updated for the current LAMMPS C++ version by Jeff
-Greathouse at Sandia (jagreat at sandia.gov).</p>
-<hr class="docutils" />
-</div>
-<div class="section" id="lmp2cfg-tool">
-<span id="cfg"></span><h2>9.17. lmp2cfg tool<a class="headerlink" href="#lmp2cfg-tool" title="Permalink to this headline">¶</a></h2>
-<p>The lmp2cfg sub-directory contains a tool for converting LAMMPS output
-files into a series of <a href="#id1"><span class="problematic" id="id2">*</span></a>.cfg files which can be read into the
-<a class="reference external" href="http://mt.seas.upenn.edu/Archive/Graphics/A">AtomEye</a> visualizer.  See
-the README file for more information.</p>
-<p>This tool was written by Ara Kooser at Sandia (askoose at sandia.gov).</p>
-<hr class="docutils" />
-</div>
-<div class="section" id="lmp2vmd-tool">
-<span id="vmd"></span><h2>9.18. lmp2vmd tool<a class="headerlink" href="#lmp2vmd-tool" title="Permalink to this headline">¶</a></h2>
-<p>The lmp2vmd sub-directory contains a README.txt file that describes
-details of scripts and plugin support within the <a class="reference external" href="http://www.ks.uiuc.edu/Research/vmd">VMD package</a> for visualizing LAMMPS
-dump files.</p>
-<p>The VMD plugins and other supporting scripts were written by Axel
-Kohlmeyer (akohlmey at cmm.chem.upenn.edu) at U Penn.</p>
-<hr class="docutils" />
-</div>
-<div class="section" id="matlab-tool">
-<span id="matlab"></span><h2>9.19. matlab tool<a class="headerlink" href="#matlab-tool" title="Permalink to this headline">¶</a></h2>
-<p>The matlab sub-directory contains several <span class="xref std std-ref">MATLAB</span> scripts for
-post-processing LAMMPS output.  The scripts include readers for log
-and dump files, a reader for EAM potential files, and a converter that
-reads LAMMPS dump files and produces CFG files that can be visualized
-with the <a class="reference external" href="http://mt.seas.upenn.edu/Archive/Graphics/A">AtomEye</a>
-visualizer.</p>
-<p>See the README.pdf file for more information.</p>
-<p>These scripts were written by Arun Subramaniyan at Purdue Univ
-(asubrama at purdue.edu).</p>
-<hr class="docutils" />
-</div>
-<div class="section" id="micelle2d-tool">
-<span id="micelle"></span><h2>9.20. micelle2d tool<a class="headerlink" href="#micelle2d-tool" title="Permalink to this headline">¶</a></h2>
-<p>The file micelle2d.f creates a LAMMPS data file containing short lipid
-chains in a monomer solution.  It uses a text file containing lipid
-definition parameters as an input.  The created molecules and solvent
-atoms can strongly overlap, so LAMMPS needs to run the system
-initially with a &#8220;soft&#8221; pair potential to un-overlap it.  The syntax
-for running the tool is</p>
-<div class="highlight-python"><div class="highlight"><pre>micelle2d &lt; def.micelle2d &gt; data.file
-</pre></div>
-</div>
-<p>See the def.micelle2d file in the tools directory for an example of a
-definition file.  This tool was used to create the system for the
-<a class="reference internal" href="Section_example.html"><em>micelle example</em></a>.</p>
-<hr class="docutils" />
-</div>
-<div class="section" id="moltemplate-tool">
-<span id="moltemplate"></span><h2>9.21. moltemplate tool<a class="headerlink" href="#moltemplate-tool" title="Permalink to this headline">¶</a></h2>
-<p>The moltemplate sub-directory contains a Python-based tool for
-building molecular systems based on a text-file description, and
-creating LAMMPS data files that encode their molecular topology as
-lists of bonds, angles, dihedrals, etc.  See the README.TXT file for
-more information.</p>
-<p>This tool was written by Andrew Jewett (jewett.aij at gmail.com), who
-supports it.  It has its own WWW page at
-<a class="reference external" href="http://moltemplate.org">http://moltemplate.org</a>.</p>
-<hr class="docutils" />
-</div>
-<div class="section" id="msi2lmp-tool">
-<span id="msi"></span><h2>9.22. msi2lmp tool<a class="headerlink" href="#msi2lmp-tool" title="Permalink to this headline">¶</a></h2>
-<p>The msi2lmp sub-directory contains a tool for creating LAMMPS input
-data files from Accelrys&#8217; Insight MD code (formerly MSI/Biosym and
-its Discover MD code).  See the README file for more information.</p>
-<p>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.</p>
-<p>This tool may be out-of-date with respect to the current LAMMPS and
-Insight versions.  Since we don&#8217;t use it at Sandia, you&#8217;ll need to
-experiment with it yourself.</p>
-<hr class="docutils" />
-</div>
-<div class="section" id="phonon-tool">
-<span id="phonon"></span><h2>9.23. phonon tool<a class="headerlink" href="#phonon-tool" title="Permalink to this headline">¶</a></h2>
-<p>The phonon sub-directory contains a post-processing tool useful for
-analyzing the output of the <a class="reference internal" href="fix_phonon.html"><em>fix phonon</em></a> command in
-the USER-PHONON package.</p>
-<p>See the README file for instruction on building the tool and what
-library it needs.  And see the examples/USER/phonon directory
-for example problems that can be post-processed with this tool.</p>
-<p>This tool was written by Ling-Ti Kong at Shanghai Jiao Tong
-University.</p>
-<hr class="docutils" />
-</div>
-<div class="section" id="polymer-bonding-tool">
-<span id="polybond"></span><h2>9.24. polymer bonding tool<a class="headerlink" href="#polymer-bonding-tool" title="Permalink to this headline">¶</a></h2>
-<p>The polybond sub-directory contains a Python-based tool useful for
-performing &#8220;programmable polymer bonding&#8221;.  The Python file
-lmpsdata.py provides a &#8220;Lmpsdata&#8221; class with various methods which can
-be invoked by a user-written Python script to create data files with
-complex bonding topologies.</p>
-<p>See the Manual.pdf for details and example scripts.</p>
-<p>This tool was written by Zachary Kraus at Georgia Tech.</p>
-<hr class="docutils" />
-</div>
-<div class="section" id="pymol-asphere-tool">
-<span id="pymol"></span><h2>9.25. pymol_asphere tool<a class="headerlink" href="#pymol-asphere-tool" title="Permalink to this headline">¶</a></h2>
-<p>The pymol_asphere sub-directory contains a tool for converting a
-LAMMPS dump file that contains orientation info for ellipsoidal
-particles into an input file for the <span class="xref std std-ref">PyMol visualization package</span>.</p>
-<p>Specifically, the tool triangulates the ellipsoids so they can be
-viewed as true ellipsoidal particles within PyMol.  See the README and
-examples directory within pymol_asphere for more information.</p>
-<p>This tool was written by Mike Brown at Sandia.</p>
-<hr class="docutils" />
-</div>
-<div class="section" id="python-tool">
-<span id="pythontools"></span><h2>9.26. python tool<a class="headerlink" href="#python-tool" title="Permalink to this headline">¶</a></h2>
-<p>The python sub-directory contains several Python scripts
-that perform common LAMMPS post-processing tasks, such as:</p>
-<ul class="simple">
-<li>extract thermodynamic info from a log file as columns of numbers</li>
-<li>plot two columns of thermodynamic info from a log file using GnuPlot</li>
-<li>sort the snapshots in a dump file by atom ID</li>
-<li>convert multiple <a class="reference internal" href="neb.html"><em>NEB</em></a> dump files into one dump file for viz</li>
-<li>convert dump files into XYZ, CFG, or PDB format for viz by other packages</li>
-</ul>
-<p>These are simple scripts built on <a class="reference external" href="http://www.sandia.gov/~sjplimp/pizza.html">Pizza.py</a> modules.  See the
-README for more info on Pizza.py and how to use these scripts.</p>
-<hr class="docutils" />
-</div>
-<div class="section" id="reax-tool">
-<span id="reax"></span><h2>9.27. reax tool<a class="headerlink" href="#reax-tool" title="Permalink to this headline">¶</a></h2>
-<p>The reax sub-directory contains stand-alond codes that can
-post-process the output of the <a class="reference internal" href="fix_reax_bonds.html"><em>fix reax/bonds</em></a>
-command from a LAMMPS simulation using <a class="reference internal" href="pair_reax.html"><em>ReaxFF</em></a>.  See
-the README.txt file for more info.</p>
-<p>These tools were written by Aidan Thompson at Sandia.</p>
-<hr class="docutils" />
-</div>
-<div class="section" id="restart2data-tool">
-<span id="restart"></span><h2>9.28. restart2data tool<a class="headerlink" href="#restart2data-tool" title="Permalink to this headline">¶</a></h2>
-<div class="admonition note">
-<p class="first admonition-title">Note</p>
-<p class="last">This tool is now obsolete and is not included in the current
-LAMMPS distribution.  This is becaues there is now a
-<a class="reference internal" href="write_data.html"><em>write_data</em></a> command, which can create a data file
-from within an input script.  Running LAMMPS with the &#8220;-r&#8221;
-<a class="reference internal" href="Section_start.html#start-7"><span>command-line switch</span></a> as follows:</p>
-</div>
-<p>lmp_g++ -r restartfile datafile</p>
-<p>is the same as running a 2-line input script:</p>
-<p>read_restart restartfile
-write_data datafile</p>
-<p>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.</p>
-<p>The file restart2data.cpp converts a binary LAMMPS restart file into
-an ASCII data file.  The syntax for running the tool is</p>
-<div class="highlight-python"><div class="highlight"><pre>restart2data restart-file data-file (input-file)
-</pre></div>
-</div>
-<p>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.</p>
-<p>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.</p>
-<p>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.</p>
-<p>If a &#8220;%&#8221; appears in the specified restart-file, the tool expects a set
-of multiple files to exist.  See the <a class="reference internal" href="restart.html"><em>restart</em></a> and
-<a class="reference internal" href="write_restart.html"><em>write_restart</em></a> commands for info on how such sets
-of files are written by LAMMPS, and how the files are named.</p>
-<hr class="docutils" />
-</div>
-<div class="section" id="vim-tool">
-<span id="vim"></span><h2>9.29. vim tool<a class="headerlink" href="#vim-tool" title="Permalink to this headline">¶</a></h2>
-<p>The files in the tools/vim directory are add-ons to the VIM editor
-that allow easier editing of LAMMPS input scripts.  See the README.txt
-file for details.</p>
-<p>These files were provided by Gerolf Ziegenhain (gerolf at
-ziegenhain.com)</p>
-<hr class="docutils" />
-</div>
-<div class="section" id="xmgrace-tool">
-<span id="xmgrace"></span><h2>9.30. xmgrace tool<a class="headerlink" href="#xmgrace-tool" title="Permalink to this headline">¶</a></h2>
-<p>The files in the tools/xmgrace directory can be used to plot the
-thermodynamic data in LAMMPS log files via the xmgrace plotting
-package.  There are several tools in the directory that can be used in
-post-processing mode.  The lammpsplot.cpp file can be compiled and
-used to create plots from the current state of a running LAMMPS
-simulation.</p>
-<p>See the README file for details.</p>
-<p>These files were provided by Vikas Varshney (vv0210 at gmail.com)</p>
-<hr class="docutils" />
-</div>
-<div class="section" id="xmovie-tool">
-<span id="xmovie"></span><h2>9.31. xmovie tool<a class="headerlink" href="#xmovie-tool" title="Permalink to this headline">¶</a></h2>
-<p>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.</p>
-<p>The syntax for running xmovie is</p>
-<div class="highlight-python"><div class="highlight"><pre>xmovie [options] dump.file1 dump.file2 ...
-</pre></div>
-</div>
-<p>If you just type &#8220;xmovie&#8221; 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.</p>
-<p>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&#8217;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 <a class="reference external" href="http://lammps.sandia.gov">LAMMPS WWW site</a> were created with xmovie.</p>
-<p>I&#8217;ve lost contact with Mike, so I hope he&#8217;s comfortable with us
-distributing his great tool!</p>
-</div>
-</div>
-
-
-           </div>
-          </div>
-          <footer>
-  
-    <div class="rst-footer-buttons" role="navigation" aria-label="footer navigation">
-      
-        <a href="Section_modify.html" class="btn btn-neutral float-right" title="10. Modifying &amp; extending LAMMPS" accesskey="n">Next <span class="fa fa-arrow-circle-right"></span></a>
-      
-      
-        <a href="Section_perf.html" class="btn btn-neutral" title="8. Performance &amp; scalability" accesskey="p"><span class="fa fa-arrow-circle-left"></span> Previous</a>
-      
-    </div>
-  
-
-  <hr/>
-
-  <div role="contentinfo">
-    <p>
-        &copy; Copyright 2013 Sandia Corporation.
-    </p>
-  </div>
-  Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
-
-</footer>
-
-        </div>
-      </div>
-
-    </section>
-
-  </div>
-  
-
-
-  
-
-    <script type="text/javascript">
-        var DOCUMENTATION_OPTIONS = {
-            URL_ROOT:'./',
-            VERSION:'',
-            COLLAPSE_INDEX:false,
-            FILE_SUFFIX:'.html',
-            HAS_SOURCE:  true
-        };
-    </script>
-      <script type="text/javascript" src="_static/jquery.js"></script>
-      <script type="text/javascript" src="_static/underscore.js"></script>
-      <script type="text/javascript" src="_static/doctools.js"></script>
-      <script type="text/javascript" src="https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>
-      <script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/jquery-1.11.0.min.js"></script>
-      <script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/lightbox.min.js"></script>
-      <script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2-customize/jquery-noconflict.js"></script>
-
-  
-
-  
-  
-    <script type="text/javascript" src="_static/js/theme.js"></script>
-  
-
-  
-  
-  <script type="text/javascript">
-      jQuery(function () {
-          SphinxRtdTheme.StickyNav.enable();
-      });
-  </script>
-   
-
-</body>
-</html>

doc/Section_tools.txt

@@ -1,566 +0,0 @@
-"Previous Section"_Section_perf.html - "LAMMPS WWW Site"_lws - "LAMMPS
-Documentation"_ld - "LAMMPS Commands"_lc - "Next
-Section"_Section_modify.html :c
-
-:link(lws,http://lammps.sandia.gov)
-:link(ld,Manual.html)
-:link(lc,Section_commands.html#comm)
-
-:line
-
-9. Additional tools :h3
-
-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.
-
-Our group has also written and released a separate toolkit called
-"Pizza.py"_pizza which provides tools for doing setup, analysis,
-plotting, and visualization for LAMMPS simulations.  Pizza.py is
-written in "Python"_python and is available for download from "the
-Pizza.py WWW site"_pizza.
-
-:link(pizza,http://www.sandia.gov/~sjplimp/pizza.html)
-:link(python,http://www.python.org)
-
-Note that many users write their own setup or analysis tools or use
-other existing codes and convert their output to a LAMMPS input format
-or vice versa.  The tools listed here are included in the LAMMPS
-distribution as examples of auxiliary tools.  Some of them are not
-actively supported by Sandia, as they were contributed by LAMMPS
-users.  If you have problems using them, we can direct you to the
-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.
-
-"amber2lmp"_#amber
-"binary2txt"_#binary
-"ch2lmp"_#charmm
-"chain"_#chain
-"colvars"_#colvars
-"createatoms"_#create
-"data2xmovie"_#data
-"eam database"_#eamdb
-"eam generate"_#eamgn
-"eff"_#eff
-"emacs"_#emacs
-"fep"_#fep
-"i-pi"_#ipi
-"ipp"_#ipp
-"kate"_#kate
-"lmp2arc"_#arc
-"lmp2cfg"_#cfg
-"lmp2vmd"_#vmd
-"matlab"_#matlab
-"micelle2d"_#micelle
-"moltemplate"_#moltemplate
-"msi2lmp"_#msi
-"phonon"_#phonon
-"polymer bonding"_#polybond
-"pymol_asphere"_#pymol
-"python"_#pythontools
-"reax"_#reax
-"restart2data"_#restart
-"vim"_#vim
-"xmgrace"_#xmgrace
-"xmovie"_#xmovie :ul
-
-:line
-
-amber2lmp tool :h4,link(amber)
-
-The amber2lmp sub-directory contains two Python scripts for converting
-files back-and-forth between the AMBER MD code and LAMMPS.  See the
-README file in amber2lmp for more information.
-
-These tools were written by Keir Novik while he was at Queen Mary
-University of London.  Keir is no longer there and cannot support
-these tools which are out-of-date with respect to the current LAMMPS
-version (and maybe with respect to AMBER as well).  Since we don't use
-these tools at Sandia, you'll need to experiment with them and make
-necessary modifications yourself.
-
-:line
-
-binary2txt tool :h4,link(binary)
-
-The file binary2txt.cpp converts one or more binary LAMMPS dump file
-into ASCII text files.  The syntax for running the tool is
-
-binary2txt file1 file2 ... :pre
-
-which creates file1.txt, file2.txt, etc.  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.
-
-:line
-
-ch2lmp tool :h4,link(charmm)
-
-The ch2lmp sub-directory contains tools for converting files
-back-and-forth between the CHARMM MD code and LAMMPS. 
-
-They are intended to make it easy to use CHARMM as a builder and as a
-post-processor for LAMMPS. Using charmm2lammps.pl, you can convert an
-ensemble built in CHARMM into its LAMMPS equivalent.  Using
-lammps2pdb.pl you can convert LAMMPS atom dumps into pdb files.
-
-See the README file in the ch2lmp sub-directory for more information.
-
-These tools were created by Pieter in't Veld (pjintve at sandia.gov)
-and Paul Crozier (pscrozi at sandia.gov) at Sandia.
-
-:line
-
-chain tool :h4,link(chain)
-
-The file chain.f creates a LAMMPS data file containing bead-spring
-polymer chains and/or monomer solvent atoms.  It uses a text file
-containing chain definition parameters as an input.  The created
-chains and solvent atoms can strongly overlap, so LAMMPS needs to run
-the system initially with a "soft" pair potential to un-overlap it.
-The syntax for running the tool is
-
-chain < def.chain > data.file :pre
-
-See the def.chain or def.chain.ab files in the tools directory for
-examples of definition files.  This tool was used to create the
-system for the "chain benchmark"_Section_perf.html.
-
-:line
-
-colvars tools :h4,link(colvars)
-
-The colvars directory contains a collection of tools for postprocessing
-data produced by the colvars collective variable library.
-To compile the tools, edit the makefile for your system and run "make".
-
-Please report problems and issues the colvars library and its tools
-at: https://github.com/colvars/colvars/issues
-
-abf_integrate:
-
-MC-based integration of multidimensional free energy gradient
-Version 20110511
-
-Syntax: ./abf_integrate < filename > \[-n < nsteps >\] \[-t < temp >\] \[-m \[0|1\] (metadynamics)\] \[-h < hill_height >\] \[-f < variable_hill_factor >\] :pre
-
-The LAMMPS interface to the colvars collective variable library, as
-well as these tools, were created by Axel Kohlmeyer (akohlmey at
-gmail.com) at ICTP, Italy.
-
-:line
-
-createatoms tool :h4,link(create)
-
-The tools/createatoms directory contains a Fortran program called
-createAtoms.f which can generate a variety of interesting crystal
-structures and geometries and output the resulting list of atom
-coordinates in LAMMPS or other formats.
-
-See the included Manual.pdf for details.
-
-The tool is authored by Xiaowang Zhou (Sandia), xzhou at sandia.gov.
-
-:line
-
-data2xmovie tool :h4,link(data)
-
-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
-
-data2xmovie \[options\] < infile > outfile :pre
-
-See the top of the data2xmovie.c file for a discussion of the options.
-
-:line
-
-eam database tool :h4,link(eamdb)
-
-The tools/eam_database directory contains a Fortran program that will
-generate EAM alloy setfl potential files for any combination of 16
-elements: Cu, Ag, Au, Ni, Pd, Pt, Al, Pb, Fe, Mo, Ta, W, Mg, Co, Ti,
-Zr.  The files can then be used with the "pair_style
-eam/alloy"_pair_eam.html command.
-
-The tool is authored by Xiaowang Zhou (Sandia), xzhou at sandia.gov,
-and is based on his paper:
-
-X. W. Zhou, R. A. Johnson, and H. N. G. Wadley, Phys. Rev. B, 69,
-144113 (2004).
-
-:line
-
-eam generate tool :h4,link(eamgn)
-
-The tools/eam_generate directory contains several one-file C programs
-that convert an analytic formula into a tabulated "embedded atom
-method (EAM)"_pair_eam.html setfl potential file.  The potentials they
-produce are in the potentials directory, and can be used with the
-"pair_style eam/alloy"_pair_eam.html command.
-
-The source files and potentials were provided by Gerolf Ziegenhain
-(gerolf at ziegenhain.com).
-
-:line
-
-eff tool :h4,link(eff)
-
-The tools/eff directory contains various scripts for generating
-structures and post-processing output for simulations using the
-electron force field (eFF).
-
-These tools were provided by Andres Jaramillo-Botero at CalTech
-(ajaramil at wag.caltech.edu).
-
-:line
-
-emacs tool :h4,link(emacs)
-
-The tools/emacs directory contains a Lips add-on file for Emacs that
-enables a lammps-mode for editing of input scripts when using Emacs,
-with various highlighting options setup.
-
-These tools were provided by Aidan Thompson at Sandia
-(athomps at sandia.gov).
-
-:line
-
-fep tool :h4,link(fep)
-
-The tools/fep directory contains Python scripts useful for
-post-processing results from performing free-energy perturbation
-simulations using the USER-FEP package.
-
-The scripts were contributed by Agilio Padua (Universite Blaise
-Pascal Clermont-Ferrand), agilio.padua at univ-bpclermont.fr.
-
-See README file in the tools/fep directory.
-
-:line
-
-i-pi tool :h4,link(ipi)
-
-The tools/i-pi directory contains a version of the i-PI package, with
-all the LAMMPS-unrelated files removed.  It is provided so that it can
-be used with the "fix ipi"_fix_ipi.html command to perform
-path-integral molecular dynamics (PIMD).
-
-The i-PI package was created and is maintained by Michele Ceriotti,
-michele.ceriotti at gmail.com, to interface to a variety of molecular
-dynamics codes.
-
-See the tools/i-pi/manual.pdf file for an overview of i-PI, and the
-"fix ipi"_fix_ipi.html doc page for further details on running PIMD
-calculations with LAMMPS.
-
-:line
-
-ipp tool :h4,link(ipp)
-
-The tools/ipp directory contains a Perl script ipp which can be used
-to facilitate the creation of a complicated file (say, a lammps input
-script or tools/createatoms input file) using a template file.
-
-ipp was created and is maintained by Reese Jones (Sandia), rjones at
-sandia.gov.
-
-See two examples in the tools/ipp directory.  One of them is for the
-tools/createatoms tool's input file.
-
-:line
-
-kate tool :h4,link(kate)
-
-The file in the tools/kate directory is an add-on to the Kate editor
-in the KDE suite that allow syntax highlighting of LAMMPS input
-scripts.  See the README.txt file for details.
-
-The file was provided by Alessandro Luigi Sellerio
-(alessandro.sellerio at ieni.cnr.it).
-
-:line
-
-lmp2arc tool :h4,link(arc)
-
-The lmp2arc sub-directory contains a tool for converting LAMMPS output
-files to the format for Accelrys' Insight MD code (formerly
-MSI/Biosym and its Discover MD code).  See the README file for more
-information.
-
-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.
-
-This tool was updated for the current LAMMPS C++ version by Jeff
-Greathouse at Sandia (jagreat at sandia.gov).
-
-:line
-
-lmp2cfg tool :h4,link(cfg)
-
-The lmp2cfg sub-directory contains a tool for converting LAMMPS output
-files into a series of *.cfg files which can be read into the
-"AtomEye"_http://mt.seas.upenn.edu/Archive/Graphics/A visualizer.  See
-the README file for more information.
-
-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"_matlab scripts for
-post-processing LAMMPS output.  The scripts include readers for log
-and dump files, a reader for EAM potential files, and a converter that
-reads LAMMPS dump files and produces CFG files that can be visualized
-with the "AtomEye"_http://mt.seas.upenn.edu/Archive/Graphics/A
-visualizer.
-
-See the README.pdf file for more information.
-
-These scripts were written by Arun Subramaniyan at Purdue Univ
-(asubrama at purdue.edu).
-
-:link(matlab,http://www.mathworks.com)
-
-:line
-
-micelle2d tool :h4,link(micelle)
-
-The file micelle2d.f creates a LAMMPS data file containing short lipid
-chains in a monomer solution.  It uses a text file containing lipid
-definition parameters as an input.  The created molecules and solvent
-atoms can strongly overlap, so LAMMPS needs to run the system
-initially with a "soft" pair potential to un-overlap it.  The syntax
-for running the tool is
-
-micelle2d < def.micelle2d > data.file :pre
-
-See the def.micelle2d file in the tools directory for an example of a
-definition file.  This tool was used to create the system for the
-"micelle example"_Section_example.html.
-
-:line
-
-moltemplate tool :h4,link(moltemplate)
-
-The moltemplate sub-directory contains a Python-based tool for
-building molecular systems based on a text-file description, and
-creating LAMMPS data files that encode their molecular topology as
-lists of bonds, angles, dihedrals, etc.  See the README.TXT file for
-more information.
-
-This tool was written by Andrew Jewett (jewett.aij at gmail.com), who
-supports it.  It has its own WWW page at
-"http://moltemplate.org"_http://moltemplate.org.
-
-:line
-
-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.
-
-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.
-
-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.
-
-:line
-
-phonon tool :h4,link(phonon)
-
-The phonon sub-directory contains a post-processing tool useful for
-analyzing the output of the "fix phonon"_fix_phonon.html command in
-the USER-PHONON package.
-
-See the README file for instruction on building the tool and what
-library it needs.  And see the examples/USER/phonon directory
-for example problems that can be post-processed with this tool.
-
-This tool was written by Ling-Ti Kong at Shanghai Jiao Tong
-University.
-
-:line
-
-polymer bonding tool :h4,link(polybond)
-
-The polybond sub-directory contains a Python-based tool useful for
-performing "programmable polymer bonding".  The Python file
-lmpsdata.py provides a "Lmpsdata" class with various methods which can
-be invoked by a user-written Python script to create data files with
-complex bonding topologies.
-
-See the Manual.pdf for details and example scripts.
-
-This tool was written by Zachary Kraus at Georgia Tech.
-
-:line
-
-pymol_asphere tool :h4,link(pymol)
-
-The pymol_asphere sub-directory contains a tool for converting a
-LAMMPS dump file that contains orientation info for ellipsoidal
-particles into an input file for the "PyMol visualization
-package"_pymol.
-
-:link(pymol,http://pymol.sourceforge.net)
-
-Specifically, the tool triangulates the ellipsoids so they can be
-viewed as true ellipsoidal particles within PyMol.  See the README and
-examples directory within pymol_asphere for more information.
-
-This tool was written by Mike Brown at Sandia.
-
-:line
-
-python tool :h4,link(pythontools)
-
-The python sub-directory contains several Python scripts
-that perform common LAMMPS post-processing tasks, such as:
-
-extract thermodynamic info from a log file as columns of numbers
-plot two columns of thermodynamic info from a log file using GnuPlot
-sort the snapshots in a dump file by atom ID
-convert multiple "NEB"_neb.html dump files into one dump file for viz
-convert dump files into XYZ, CFG, or PDB format for viz by other packages :ul
-
-These are simple scripts built on "Pizza.py"_pizza modules.  See the
-README for more info on Pizza.py and how to use these scripts.
-
-:line
-
-reax tool :h4,link(reax)
-
-The reax sub-directory contains stand-alond codes that can
-post-process the output of the "fix reax/bonds"_fix_reax_bonds.html
-command from a LAMMPS simulation using "ReaxFF"_pair_reax.html.  See
-the README.txt file for more info.
-
-These tools were written by Aidan Thompson at Sandia.
-
-:line
-
-restart2data tool :h4,link(restart)
-
-NOTE: This tool is now obsolete and is not included in the current
-LAMMPS distribution.  This is becaues 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:
-
-lmp_g++ -r restartfile datafile
-
-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.
-
-:line
-
-vim tool :h4,link(vim)
-
-The files in the tools/vim directory are add-ons to the VIM editor
-that allow easier editing of LAMMPS input scripts.  See the README.txt
-file for details.
-
-These files were provided by Gerolf Ziegenhain (gerolf at
-ziegenhain.com)
-
-:line
-
-xmgrace tool :h4,link(xmgrace)
-
-The files in the tools/xmgrace directory can be used to plot the
-thermodynamic data in LAMMPS log files via the xmgrace plotting
-package.  There are several tools in the directory that can be used in
-post-processing mode.  The lammpsplot.cpp file can be compiled and
-used to create plots from the current state of a running LAMMPS
-simulation.
-
-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!