finalize merge

This commit is contained in:
jguenole 2019-05-27 16:43:06 +02:00
commit 9f08b1c316
4598 changed files with 481137 additions and 332240 deletions

72
.github/CODEOWNERS vendored
View File

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

67
.github/CODE_OF_CONDUCT.md vendored Normal file
View File

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

View File

@ -2,11 +2,11 @@
Thank your for considering to contribute to the LAMMPS software project.
The following is a set of guidelines as well as explanations of policies and workflows for contributing to the LAMMPS molecular dynamics software project. These guidelines focus on submitting issues or pull requests on the LAMMPS GitHub project.
The following is a set of guidelines as well as explanations of policies and work flows for contributing to the LAMMPS molecular dynamics software project. These guidelines focus on submitting issues or pull requests on the LAMMPS GitHub project.
Thus please also have a look at:
* [The Section on submitting new features for inclusion in LAMMPS of the Manual](http://lammps.sandia.gov/doc/Section_modify.html#mod-15)
* [The LAMMPS GitHub Tutorial in the Manual](http://lammps.sandia.gov/doc/tutorial_github.html)
* [The Section on submitting new features for inclusion in LAMMPS of the Manual](https://lammps.sandia.gov/doc/Modify_contribute.html)
* [The LAMMPS GitHub Tutorial in the Manual](http://lammps.sandia.gov/doc/Howto_github.html)
## Table of Contents
@ -18,7 +18,7 @@ Thus please also have a look at:
* [Suggesting Enhancements](#suggesting-enhancements)
* [Contributing Code](#contributing-code)
[GitHub Workflows](#github-workflows)
[GitHub Work flows](#github-workflows)
* [Issues](#issues)
* [Pull Requests](#pull-requests)
@ -26,17 +26,17 @@ __
## I don't want to read this whole thing I just have a question!
> **Note:** Please do not file an issue to ask a general question about LAMMPS, its features, how to use specific commands, or how perform simulations or analysis in LAMMPS. Instead post your question to the ['lammps-users' mailing list](http://lammps.sandia.gov/mail.html). You do not need to be subscribed to post to the list (but a mailing list subscription avoids having your post delayed until it is approved by a mailing list moderator). Most posts to the mailing list receive a response within less than 24 hours. Before posting to the mailing list, please read the [mailing list guidelines](http://lammps.sandia.gov/guidelines.html). Following those guidelines will help greatly to get a helpful response. Always mention which LAMMPS version you are using.
> **Note:** Please do not file an issue to ask a general question about LAMMPS, its features, how to use specific commands, or how perform simulations or analysis in LAMMPS. Instead post your question to the ['lammps-users' mailing list](https://lammps.sandia.gov/mail.html). You do not need to be subscribed to post to the list (but a mailing list subscription avoids having your post delayed until it is approved by a mailing list moderator). Most posts to the mailing list receive a response within less than 24 hours. Before posting to the mailing list, please read the [mailing list guidelines](https://lammps.sandia.gov/guidelines.html). Following those guidelines will help greatly to get a helpful response. Always mention which LAMMPS version you are using.
## How Can I Contribute?
There are several ways how you can actively contribute to the LAMMPS project: you can discuss compiling and using LAMMPS, and solving LAMMPS related problems with other LAMMPS users on the lammps-users mailing list, you can report bugs or suggest enhancements by creating issues on GitHub (or posting them to the lammps-users mailing list), and you can contribute by submitting pull requests on GitHub or e-mail your code
to one of the [LAMMPS core developers](http://lammps.sandia.gov/authors.html). As you may see from the aforementioned developer page, the LAMMPS software package includes the efforts of a very large number of contributors beyond the principal authors and maintainers.
to one of the [LAMMPS core developers](https://lammps.sandia.gov/authors.html). As you may see from the aforementioned developer page, the LAMMPS software package includes the efforts of a very large number of contributors beyond the principal authors and maintainers.
### Discussing How To Use LAMMPS
The LAMMPS mailing list is hosted at SourceForge. The mailing list began in 2005, and now includes tens of thousands of messages in thousands of threads. LAMMPS developers try to respond to posted questions in a timely manner, but there are no guarantees. Please consider that people live in different timezone and may not have time to answer e-mails outside of their work hours.
You can post to list by sending your email to lammps-users at lists.sourceforge.net (no subscription required), but before posting, please read the [mailing list guidelines](http://lammps.sandia.gov/guidelines.html) to maximize your chances to receive a helpful response.
You can post to list by sending your email to lammps-users at lists.sourceforge.net (no subscription required), but before posting, please read the [mailing list guidelines](https://lammps.sandia.gov/guidelines.html) to maximize your chances to receive a helpful response.
Anyone can browse/search previous questions/answers in the archives. You do not have to subscribe to the list to post questions, receive answers (to your questions), or browse/search the archives. You **do** need to subscribe to the list if you want emails for **all** the posts (as individual messages or in digest form), or to answer questions yourself. Feel free to sign up and help us out! Answering questions from fellow LAMMPS users is a great way to pay back the community for providing you a useful tool for free, and to pass on the advice you have received yourself to others. It improves your karma and helps you understand your own research better.
@ -44,7 +44,7 @@ If you post a message and you are a subscriber, your message will appear immedia
### Reporting Bugs
While developers writing code for LAMMPS are careful to test their code, LAMMPS is such a large and complex software, that it is impossible to test for all combinations of features under all normal and not so normal circumstances. Thus bugs do happen, and if you suspect, that you have encountered one, please try to document it and report it as an [Issue](https://github.com/lammps/lammps/issues) on the LAMMPS GitHub project web page. However, before reporting a bug, you need to check whether this is something that may have already been corrected. The [Latest Features and Bug Fixes in LAMMPS](http://lammps.sandia.gov/bug.html) web page lists all significant changes to LAMMPS over the years. It also tells you what the current latest development version of LAMMPS is, and you should test whether your issue still applies to that version.
While developers writing code for LAMMPS are careful to test their code, LAMMPS is such a large and complex software, that it is impossible to test for all combinations of features under all normal and not so normal circumstances. Thus bugs do happen, and if you suspect, that you have encountered one, please try to document it and report it as an [Issue](https://github.com/lammps/lammps/issues) on the LAMMPS GitHub project web page. However, before reporting a bug, you need to check whether this is something that may have already been corrected. The [Latest Features and Bug Fixes in LAMMPS](https://lammps.sandia.gov/bug.html) web page lists all significant changes to LAMMPS over the years. It also tells you what the current latest development version of LAMMPS is, and you should test whether your issue still applies to that version.
When you click on the green "New Issue" button, you will be provided with a text field, where you can enter your message. That text field with contain a template with several headlines and some descriptions. Keep the headlines that are relevant to your reported potential bug and replace the descriptions with the information as suggested by the descriptions.
You can also attach small text files (please add the file name extension `.txt` or it will be rejected), images, or small compressed text files (using gzip, do not use RAR or 7-ZIP or similar tools that are uncommon outside of Windows machines). In many cases, bugs are best illustrated by providing a small input deck (do **not** attach your entire production input, but remove everything that is not required to reproduce the issue, and scale down your system size, that the resulting calculation runs fast and can be run on small desktop quickly).
@ -62,13 +62,13 @@ To be able to submit an issue on GitHub, you have to register for an account (fo
We encourage users to submit new features or modifications for LAMMPS to the core developers so they can be added to the LAMMPS distribution. The preferred way to manage and coordinate this is by submitting a pull request at the LAMMPS project on GitHub. For any larger modifications or programming project, you are encouraged to contact the LAMMPS developers ahead of time, in order to discuss implementation strategies and coding guidelines, that will make it easier to integrate your contribution and result in less work for everybody involved. You are also encouraged to search through the list of open issues on GitHub and submit a new issue for a planned feature, so you would not duplicate the work of others (and possibly get scooped by them) or have your work duplicated by others.
How quickly your contribution will be integrated depends largely on how much effort it will cause to integrate and test it, how much it requires changes to the core code base, and of how much interest it is to the larger LAMMPS community. Please see below for a checklist of typical requirements. Once you have prepared everything, see [this tutorial](http://lammps.sandia.gov/doc/tutorial_github.html)
How quickly your contribution will be integrated depends largely on how much effort it will cause to integrate and test it, how much it requires changes to the core code base, and of how much interest it is to the larger LAMMPS community. Please see below for a checklist of typical requirements. Once you have prepared everything, see [this tutorial](https://lammps.sandia.gov/doc/Howto_github.html)
for instructions on how to submit your changes or new files through a GitHub pull request
Here is a checklist of steps you need to follow to submit a single file or user package for our consideration. Following these steps will save both you and us time. See existing files in packages in the source directory for examples. If you are uncertain, please ask on the lammps-users mailing list.
* All source files you provide must compile with the most current version of LAMMPS with multiple configurations. In particular you need to test compiling LAMMPS from scratch with `-DLAMMPS_BIGBIG` set in addition to the default `-DLAMMPS_SMALLBIG` setting. Your code will need to work correctly in serial and in parallel using MPI.
* For consistency with the rest of LAMMPS and especially, if you want your contribution(s) to be added to main LAMMPS code or one of its standard packages, it needs to be written in a style compatible with other LAMMPS source files. This means: 2-character indentation per level, no tabs, no lines over 80 characters. I/O is done via the C-style stdio library, class header files should not import any system headers outside <stdio.h>, STL containers should be avoided in headers, and forward declarations used where possible or needed. All added code should be placed into the LAMMPS_NS namespace or a sub-namespace; global or static variables should be avoided, as they conflict with the modular nature of LAMMPS and the C++ class structure. Header files must not import namespaces with using. This all is so the developers can more easily understand, integrate, and maintain your contribution and reduce conflicts with other parts of LAMMPS. This basically means that the code accesses data structures, performs its operations, and is formatted similar to other LAMMPS source files, including the use of the error class for error and warning messages.
* For consistency with the rest of LAMMPS and especially, if you want your contribution(s) to be added to main LAMMPS code or one of its standard packages, it needs to be written in a style compatible with other LAMMPS source files. This means: 2-character indentation per level, no tabs, no lines over 80 characters. I/O is done via the C-style stdio library, style class header files should not import any system headers outside of <cstdio>, STL containers should be avoided in headers, and forward declarations used where possible or needed. All added code should be placed into the LAMMPS_NS namespace or a sub-namespace; global or static variables should be avoided, as they conflict with the modular nature of LAMMPS and the C++ class structure. There MUST NOT be any "using namespace XXX;" statements in headers. In the implementation file (<name>.cpp) system includes should be placed in angular brackets (<>) and for c-library functions the C++ style header files should be included (<cstdio> instead of <stdio.h>, or <cstring> instead of <string.h>). This all is so the developers can more easily understand, integrate, and maintain your contribution and reduce conflicts with other parts of LAMMPS. This basically means that the code accesses data structures, performs its operations, and is formatted similar to other LAMMPS source files, including the use of the error class for error and warning messages.
* If you want your contribution to be added as a user-contributed feature, and it is a single file (actually a `<name>.cpp` and `<name>.h` file) it can be rapidly added to the USER-MISC directory. Include the one-line entry to add to the USER-MISC/README file in that directory, along with the 2 source files. You can do this multiple times if you wish to contribute several individual features.
* If you want your contribution to be added as a user-contribution and it is several related features, it is probably best to make it a user package directory with a name like USER-FOO. In addition to your new files, the directory should contain a README text file. The README should contain your name and contact information and a brief description of what your new package does. If your files depend on other LAMMPS style files also being installed (e.g. because your file is a derived class from the other LAMMPS class), then an Install.sh file is also needed to check for those dependencies. See other README and Install.sh files in other USER directories as examples. Send us a tarball of this USER-FOO directory.
* Your new source files need to have the LAMMPS copyright, GPL notice, and your name and email address at the top, like other user-contributed LAMMPS source files. They need to create a class that is inside the LAMMPS namespace. If the file is for one of the USER packages, including USER-MISC, then we are not as picky about the coding style (see above). I.e. the files do not need to be in the same stylistic format and syntax as other LAMMPS files, though that would be nice for developers as well as users who try to read your code.
@ -102,11 +102,11 @@ For bug reports, the next step is that one of the core LAMMPS developers will se
### Pull Requests
For submitting pull requests, there is a [detailed tutorial](http://lammps.sandia.gov/doc/tutorial_github.html) in the LAMMPS manual. Thus only a brief breakdown of the steps is presented here.
For submitting pull requests, there is a [detailed tutorial](https://lammps.sandia.gov/doc/Howto_github.html) in the LAMMPS manual. Thus only a brief breakdown of the steps is presented here. Please note, that the LAMMPS developers are still reviewing and trying to improve the process. If you are unsure about something, do not hesitate to post a question on the lammps-users mailing list or contact one fo the core LAMMPS developers.
Immediately after the submission, the LAMMPS continuing integration server at ci.lammps.org will download your submitted branch and perform a simple compilation test, i.e. will test whether your submitted code can be compiled under various conditions. It will also do a check on whether your included documentation translates cleanly. Whether these tests are successful or fail will be recorded. If a test fails, please inspect the corresponding output on the CI server and take the necessary steps, if needed, so that the code can compile cleanly again. The test will be re-run each the pull request is updated with a push to the remote branch on GitHub.
Next a LAMMPS core developer will self-assign and do an overall technical assessment of the submission. If you are not yet registered as a LAMMPS collaborator, you will receive an invitation for that.
You may also receive comments and suggestions on the overall submission or specific details. If permitted, additional changes may be pushed into your pull request branch or a pull request may be filed in your LAMMPS fork on GitHub to include those changes.
Next a LAMMPS core developer will self-assign and do an overall technical assessment of the submission. If you are not yet registered as a LAMMPS collaborator, you will receive an invitation for that. As part of the assesment, the pull request will be categorized with labels. There are two special labels: `needs_work` (indicates that work from the submitter of the pull request is needed) and `work_in_progress` (indicates, that the assigned LAMMPS developer will make changes, if not done by the contributor who made the submit).
You may also receive comments and suggestions on the overall submission or specific details and on occasion specific requests for changes as part of the review. If permitted, also additional changes may be pushed into your pull request branch or a pull request may be filed in your LAMMPS fork on GitHub to include those changes.
The LAMMPS developer may then decide to assign the pull request to another developer (e.g. when that developer is more knowledgeable about the submitted feature or enhancement or has written the modified code). It may also happen, that additional developers are requested to provide a review and approve the changes. For submissions, that may change the general behavior of LAMMPS, or where a possibility of unwanted side effects exists, additional tests may be requested by the assigned developer.
If the assigned developer is satisfied and considers the submission ready for inclusion into LAMMPS, the pull request will be assigned to the LAMMPS lead developer, Steve Plimpton (@sjplimp), who will then have the final decision on whether the submission will be included, additional changes are required or it will be ultimately rejected. After the pull request is merged, you may delete the pull request branch in your personal LAMMPS fork.
Since the learning curve for git is quite steep for efficiently managing remote repositories, local and remote branches, pull requests and more, do not hesitate to ask questions, if you are not sure about how to do certain steps that are asked of you. Even if the changes asked of you do not make sense to you, they may be important for the LAMMPS developers. Please also note, that these all are guidelines and not set in stone.
If the assigned developer is satisfied and considers the submission ready for inclusion into LAMMPS, the pull request will receive approvals and be merged into the master branch by one of the core LAMMPS developers. After the pull request is merged, you may delete the feature branch used for the pull request in your personal LAMMPS fork.
Since the learning curve for git is quite steep for efficiently managing remote repositories, local and remote branches, pull requests and more, do not hesitate to ask questions, if you are not sure about how to do certain steps that are asked of you. Even if the changes asked of you do not make sense to you, they may be important for the LAMMPS developers. Please also note, that these all are guidelines and nothing set in stone. So depending on the nature of the contribution, the workflow may be adjusted.

View File

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

32
.github/ISSUE_TEMPLATE/bug_report.md vendored Normal file
View File

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

View File

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

21
.github/ISSUE_TEMPLATE/generic.md vendored Normal file
View File

@ -0,0 +1,21 @@
---
name: Generic Issue
about: For issues that do not fit any of the other categories
title: "_Replace With a Descriptive Title_"
labels:
assignees: ''
---
**Summary**
_Please provide a clear and concise description of what this issue report is about._
**LAMMPS Version and Platform**
_Please specify precisely which LAMMPS version this issue was detected with (the first line of the output) and what platform (operating system and its version, hardware) you are running on. If possible, test with the most recent LAMMPS patch version_
**Details**
_Please explain the issue in detail here_

15
.github/ISSUE_TEMPLATE/help_request.md vendored Normal file
View File

@ -0,0 +1,15 @@
---
name: Request for Help
about: "Don't post help requests here, email the lammps-users mailing list"
title: ""
labels: invalid
assignees: ''
---
Please **do not** post requests for help (e.g. with installing or using LAMMPS) here.
Instead send an e-mail to the lammps-users mailing list.
This issue tracker is for tracking LAMMPS development related issues only.
Thanks for your cooperation.

View File

@ -1,28 +1,43 @@
## Purpose
**Summary**
_Briefly describe the new feature(s), enhancement(s), or bugfix(es) included in this pull request. If this addresses an open GitHub Issue, mention the issue number, e.g. with `fixes #221` or `closes #135`, so that issue will be automatically closed when the pull request is merged_
_Briefly describe the new feature(s), enhancement(s), or bugfix(es) included in this pull request._
## Author(s)
**Related Issues**
_Please state name and affiliation of the author or authors that should be credited with the changes in this pull request_
_If this addresses an open GitHub issue for this project, please mention the issue number here, and describe the relation. Use the phrases `fixes #221` or `closes #135`, when you want an issue to be automatically closed when the pull request is merged_
## Backward Compatibility
**Author(s)**
_Please state whether any changes in the pull request break backward compatibility for inputs, and - if yes - explain what has been changed and why_
_Please state name and affiliation of the author or authors that should be credited with the changes in this pull request. If this pull request adds new files to the distribution, please also provide a suitable "long-lived" e-mail address (ideally something that can outlive your institution's e-mail, in case you change jobs) for the *corresponding* author, i.e. the person the LAMMPS developers can contact directly with questions and requests related to maintenance and support of this contributed code._
## Implementation Notes
**Licensing**
By submitting this pull request, I agree, that my contribution will be included in LAMMPS and redistributed under either the GNU General Public License version 2 (GPL v2) or the GNU Lesser General Public License version 2.1 (LGPL v2.1).
**Backward Compatibility**
_Please state whether any changes in the pull request will 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
**Post Submission Checklist**
_Please check the fields below as they are completed **after** the pull request has been submitted. Delete lines that don't apply_
_Please check the fields below as they are completed_
- [ ] The feature or features in this pull request is complete
- [ ] Suitable new documentation files and/or updates to the existing docs are included
- [ ] One or more example input decks are included
- [ ] Licensing information is complete
- [ ] Corresponding author information is complete
- [ ] The source code follows the LAMMPS formatting guidelines
- [ ] Suitable new documentation files and/or updates to the existing docs are included
- [ ] The added/updated documentation is integrated and tested with the documentation build system
- [ ] The feature has been verified to work with the conventional build system
- [ ] The feature has been verified to work with the CMake based build system
- [ ] A package specific README file has been included or updated
- [ ] One or more example input decks are included
## Further Information, Files, and Links
**Further Information, Files, and Links**
_Put any additional information here, attach relevant text or image files, and URLs to external sites (e.g. DOIs or webpages)_

View File

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

View File

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

View File

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

View File

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

3
.gitignore vendored
View File

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

15
README
View File

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

File diff suppressed because it is too large Load Diff

48
cmake/FindLAMMPS.cmake.in Normal file
View File

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

View File

@ -0,0 +1,59 @@
#
# CDDL HEADER START
#
# The contents of this file are subject to the terms of the Common Development
# and Distribution License Version 1.0 (the "License").
#
# You can obtain a copy of the license at
# http://www.opensource.org/licenses/CDDL-1.0. See the License for the
# specific language governing permissions and limitations under the License.
#
# When distributing Covered Code, include this CDDL HEADER in each file and
# include the License file in a prominent location with the name LICENSE.CDDL.
# If applicable, add the following below this CDDL HEADER, with the fields
# enclosed by brackets "[]" replaced with your own identifying information:
#
# Portions Copyright (c) [yyyy] [name of copyright owner]. All rights reserved.
#
# CDDL HEADER END
#
#
# Copyright (c) 2013--2019, Regents of the University of Minnesota.
# All rights reserved.
#
# Contributors:
# Richard Berger
# Christoph Junghans
# Ryan S. Elliott
#
# - Find KIM-API
#
# sets standard pkg_check_modules variables plus:
#
# KIM-API-CMAKE_C_COMPILER
# KIM-API-CMAKE_CXX_COMPILER
# KIM-API-CMAKE_Fortran_COMPILER
#
if(KIM-API_FIND_QUIETLY)
set(REQ_OR_QUI "QUIET")
else()
set(REQ_OR_QUI "REQUIRED")
endif()
find_package(PkgConfig ${REQ_OR_QUI})
include(FindPackageHandleStandardArgs)
pkg_check_modules(KIM-API ${REQ_OR_QUI} libkim-api>=2.0)
if(KIM-API_FOUND)
pkg_get_variable(KIM-API-CMAKE_C_COMPILER libkim-api CMAKE_C_COMPILER)
pkg_get_variable(KIM-API-CMAKE_CXX_COMPILER libkim-api CMAKE_CXX_COMPILER)
pkg_get_variable(KIM-API_CMAKE_Fortran_COMPILER libkim-api CMAKE_Fortran_COMPILER)
endif()
# handle the QUIETLY and REQUIRED arguments and set KIM-API_FOUND to TRUE
# if all listed variables are TRUE
find_package_handle_standard_args(KIM-API REQUIRED_VARS KIM-API_LIBRARIES)

View File

@ -1,22 +0,0 @@
# - Find kim
# Find the native KIM headers and libraries.
#
# KIM_INCLUDE_DIRS - where to find kim.h, etc.
# KIM_LIBRARIES - List of libraries when using kim.
# KIM_FOUND - True if kim found.
#
find_path(KIM_INCLUDE_DIR KIM_API.h PATH_SUFFIXES kim-api-v1)
find_library(KIM_LIBRARY NAMES kim-api-v1)
set(KIM_LIBRARIES ${KIM_LIBRARY})
set(KIM_INCLUDE_DIRS ${KIM_INCLUDE_DIR})
include(FindPackageHandleStandardArgs)
# handle the QUIETLY and REQUIRED arguments and set KIM_FOUND to TRUE
# if all listed variables are TRUE
find_package_handle_standard_args(KIM DEFAULT_MSG KIM_LIBRARY KIM_INCLUDE_DIR)
mark_as_advanced(KIM_INCLUDE_DIR KIM_LIBRARY )

View File

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

View File

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

View File

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

View File

@ -6,7 +6,7 @@ function(GenerateOpenCLHeader varname outfile files)
foreach(IDX RANGE 2 ${ARG_END})
list(GET ARGV ${IDX} filename)
file(READ ${filename} content)
string(REGEX REPLACE "\\s*//[^\n]*\n" "" content "${content}")
string(REGEX REPLACE "\\s*//[^\n]*\n" "\n" content "${content}")
string(REGEX REPLACE "\\\\" "\\\\\\\\" content "${content}")
string(REGEX REPLACE "\"" "\\\\\"" content "${content}")
string(REGEX REPLACE "([^\n]+)\n" "\"\\1\\\\n\"\n" content "${content}")

View File

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

View File

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

View File

@ -0,0 +1,30 @@
set(temp "#ifndef LMP_GIT_VERSION_H\n#define LMP_GIT_VERSION_H\n")
set(temp_git_commit "(unknown)")
set(temp_git_branch "(unknown)")
set(temp_git_describe "(unknown)")
set(temp_git_info "false")
if(GIT_FOUND AND EXISTS ${CMAKE_CURRENT_SOURCE_DIR}/../.git)
set(temp_git_info "true")
execute_process(COMMAND ${GIT_EXECUTABLE} -C ${CMAKE_CURRENT_SOURCE_DIR}/.. rev-parse HEAD
OUTPUT_VARIABLE temp_git_commit
ERROR_QUIET
OUTPUT_STRIP_TRAILING_WHITESPACE)
execute_process(COMMAND ${GIT_EXECUTABLE} -C ${CMAKE_CURRENT_SOURCE_DIR}/.. rev-parse --abbrev-ref HEAD
OUTPUT_VARIABLE temp_git_branch
ERROR_QUIET
OUTPUT_STRIP_TRAILING_WHITESPACE)
execute_process(COMMAND ${GIT_EXECUTABLE} -C ${CMAKE_CURRENT_SOURCE_DIR}/.. describe --dirty=-modified
OUTPUT_VARIABLE temp_git_describe
ERROR_QUIET
OUTPUT_STRIP_TRAILING_WHITESPACE)
endif()
set(temp "${temp}const bool LAMMPS_NS::LAMMPS::has_git_info = ${temp_git_info};\n")
set(temp "${temp}const char LAMMPS_NS::LAMMPS::git_commit[] = \"${temp_git_commit}\";\n")
set(temp "${temp}const char LAMMPS_NS::LAMMPS::git_branch[] = \"${temp_git_branch}\";\n")
set(temp "${temp}const char LAMMPS_NS::LAMMPS::git_descriptor[] = \"${temp_git_describe}\";\n")
set(temp "${temp}#endif\n\n")
message(STATUS "Generating lmpgitversion.h...")
file(WRITE "${LAMMPS_STYLE_HEADERS_DIR}/lmpgitversion.h.tmp" "${temp}" )
execute_process(COMMAND ${CMAKE_COMMAND} -E copy_if_different "${LAMMPS_STYLE_HEADERS_DIR}/lmpgitversion.h.tmp" "${LAMMPS_STYLE_HEADERS_DIR}/lmpgitversion.h")

View File

@ -24,7 +24,7 @@ tasks, act as a reference and provide examples of typical use cases.
* [Build directory vs. Source Directory](#build-directory-vs-source-directory)
* [Defining and using presets](#defining-and-using-presets)
* [Reference](#reference)
* [Common CMAKE Configuration Options](#common-cmake-configuration-options)
* [Common CMake Configuration Options](#common-cmake-configuration-options)
* [LAMMPS Configuration Options](#lammps-configuration-options)
* [Parallelization and Accelerator Packages](#parallelization-and-accelerator-packages)
* [Default Packages](#default-packages)
@ -62,7 +62,7 @@ should get you started.
git clone https://github.com/lammps/lammps.git
mkdir lammps/build
cd lammps/build
cmake ../cmake [-DOPTION_A=VALUE_A -DOPTION_B=VALUE_B ...]
cmake [-D OPTION_A=VALUE_A -D OPTION_B=VALUE_B ...] ../cmake
make
```
@ -155,11 +155,13 @@ make
The CMake build exposes a lot of different options. In the old build system
some of the package selections were possible by using special make target like
`make yes-std` or `make no-lib`. Achieving the same result with cmake requires
`make yes-std` or `make no-lib`. Achieving a similar result with cmake requires
specifying all options manually. This can quickly become a very long command
line that is hard to handle. While these could be stored in a simple script
file, there is another way of defining "presets" to compile LAMMPS in a certain
way.
way. Since the cmake build process - contrary to the conventional build system -
includes the compilation of the bundled libraries into the standard build process,
the grouping of those presets is somewhat different.
A preset is a regular CMake script file that can use constructs such as
variables, lists and for-loops to manipulate configuration options and create
@ -171,15 +173,15 @@ Such a file can then be passed to cmake via the `-C` flag. Several examples of
presets can be found in the `cmake/presets` folder.
```bash
# build LAMMPS with all "standard" packages which don't use libraries and enable GPU package
# build LAMMPS with all packages enabled which don't use external libraries and enable GPU package
mkdir build
cd build
cmake -C ../cmake/presets/std_nolib.cmake ../cmake -DPKG_GPU=on
cmake -C ../cmake/presets/all_on.cmake -C ../cmake/presets/nolib.cmake -D PKG_GPU=on ../cmake
```
# Reference
## Common CMAKE Configuration Options
## Common CMake Configuration Options
<table>
@ -195,6 +197,7 @@ cmake -C ../cmake/presets/std_nolib.cmake ../cmake -DPKG_GPU=on
<td><code>CMAKE_INSTALL_PREFIX</code></td>
<td>Install location where LAMMPS files will be copied to. In the Unix/Linux case with Makefiles this controls what `make install` will do.</td>
<td>
Default setting is <code>$HOME/.local</code>.
</td>
</tr>
<tr>
@ -207,6 +210,16 @@ cmake -C ../cmake/presets/std_nolib.cmake ../cmake -DPKG_GPU=on
</dl>
</td>
</tr>
<tr>
<td><code>CMAKE_VERBOSE_MAKEFILE</code></td>
<td>Enable verbose output from Makefile builds (useful for debugging), the same can be achived by adding `VERBOSE=1` to the `make` call.</td>
<td>
<dl>
<dt><code>off</code> (default)</dt>
<dt><code>on</code></dt>
</dl>
</td>
</tr>
</tbody>
</table>
@ -265,6 +278,26 @@ cmake -C ../cmake/presets/std_nolib.cmake ../cmake -DPKG_GPU=on
</dl>
</td>
</tr>
<tr>
<td><code>BUILD_LIB</code></td>
<td>control whether to build LAMMPS as a library</td>
<td>
<dl>
<dt><code>off</code> (default)</dt>
<dt><code>on</code></dt>
</dl>
</td>
</tr>
<tr>
<td><code>BUILD_EXE</code></td>
<td>control whether to build LAMMPS executable</td>
<td>
<dl>
<dt><code>on</code> (default)</dt>
<dt><code>off</code></dt>
</dl>
</td>
</tr>
<tr>
<td><code>BUILD_SHARED_LIBS</code></td>
<td>control whether to build LAMMPS as a shared-library</td>
@ -315,8 +348,8 @@ cmake -C ../cmake/presets/std_nolib.cmake ../cmake -DPKG_GPU=on
`mpicxx` in your path and use this MPI implementation.</td>
<td>
<dl>
<dt><code>off</code> (default)</dt>
<dt><code>on</code></dt>
<dt><code>on</code> (default, if found)</dt>
<dt><code>off</code></dt>
</dl>
</td>
</tr>
@ -325,8 +358,8 @@ cmake -C ../cmake/presets/std_nolib.cmake ../cmake -DPKG_GPU=on
<td>control whether to build LAMMPS with OpenMP support.</td>
<td>
<dl>
<dt><code>off</code> (default)</dt>
<dt><code>on</code></dt>
<dt><code>on</code> (default, if found)</dt>
<dt><code>off</code></dt>
</dl>
</td>
</tr>
@ -1271,7 +1304,7 @@ providing the identical features and USER interface.</strong></p>
</td>
<td>
<dl>
<dt><code>KISSFFT</code></dt>
<dt><code>KISS</code></dt>
<dt><code>FFTW3</code></dt>
<dt><code>FFTW2</code></dt>
<dt><code>MKL</code></dt>
@ -1279,13 +1312,13 @@ providing the identical features and USER interface.</strong></p>
</td>
</tr>
<tr>
<td><code>PACK_ARRAY</code></td>
<td><code>FFT_PACK</code></td>
<td>Optimization for FFT</td>
<td>
<dl>
<dt><code>PACK_ARRAY</code></dt>
<dt><code>PACK_POINTER</code></dt>
<dt><code>PACK_MEMCPY</code></dt>
<dt><code>array (default)</code></dt>
<dt><code>pointer</code></dt>
<dt><code>memcpy</code></dt>
</dl>
</td>
</tr>
@ -1377,6 +1410,40 @@ TODO
### PYTHON Package
### USER-INTEL Package
<table>
<thead>
<tr>
<th>Option</th>
<th>Description</th>
<th>Values</th>
</tr>
</thead>
<tbody>
<tr>
<td><code>INTEL_ARCH</code></td>
<td>Target architecture for USER-INTEL package</td>
<td>
<dl>
<dt><code>cpu</code> (default)</dt>
<dt><code>knl</code></dt>
</dl>
</td>
</tr>
<tr>
<td><code>INTEL_LRT_MODE</code></td>
<td>How to support Long-range thread mode in Verlet integration</td>
<td>
<dl>
<dt><code>threads</code> (default, if pthreads available)</dt>
<dt><code>none</code> (default, if pthreads not available)</dt>
<dt><code>c++11</code></dt>
</dl>
</td>
</tr>
</tbody>
</table>
### GPU Package
The GPU package builds a support library which can either use OpenCL or CUDA as
@ -1396,8 +1463,8 @@ target API.
<td>API used by GPU package</td>
<td>
<dl>
<dt><code>OpenCL</code> (default)</dt>
<dt><code>CUDA</code></dt>
<dt><code>opencl</code> (default)</dt>
<dt><code>cuda</code></dt>
</dl>
</td>
</tr>
@ -1406,9 +1473,9 @@ target API.
<td>Precision size used by GPU package kernels</td>
<td>
<dl>
<dt><code>SINGLE_DOUBLE</code></dt>
<dt><code>SINGLE_SINGLE</code></dt>
<dt><code>DOUBLE_DOUBLE</code></dt>
<dt><code>mixed</code> (default)</dt>
<dt><code>single</code></dt>
<dt><code>double</code></dt>
</dl>
</td>
</tr>
@ -1417,12 +1484,12 @@ target API.
<td>Tuning target for OpenCL driver code</td>
<td>
<dl>
<dt><code>GENERIC</code> (default)</dt>
<dt><code>INTEL</code> (Intel CPU)</dt>
<dt><code>PHI</code> (Intel Xeon Phi)</dt>
<dt><code>FERMI</code> (NVIDIA)</dt>
<dt><code>KEPLER</code> (NVIDIA)</dt>
<dt><code>CYPRESS</code> (AMD)</dt>
<dt><code>generic</code> (default)</dt>
<dt><code>intel</code> (Intel CPU)</dt>
<dt><code>phi</code> (Intel Xeon Phi)</dt>
<dt><code>fermi</code> (NVIDIA)</dt>
<dt><code>kepler</code> (NVIDIA)</dt>
<dt><code>cypress</code> (AMD)</dt>
</dl>
</td>
</tr>
@ -1449,6 +1516,21 @@ target API.
</dl>
</td>
</tr>
<tr>
<td><code>CUDA_MPS_SUPPORT</code> (CUDA only)</td>
<td>Enable tweaks for running with Nvidia CUDA Multi-process services daemon</td>
<td>
<dl>
<dt><code>on</code></dt>
<dt><code>off</code> (default)</dt>
</dl>
</td>
</tr>
<tr>
<td><code>BIN2C</code> (CUDA only)</td>
<td>Path to bin2c executable, will automatically pick up the first one in your $PATH.</td>
<td>(automatic)</td>
</tr>
</tbody>
</table>
@ -1517,6 +1599,16 @@ Requires a Eigen3 installation
</tr>
</thead>
<tbody>
<tr>
<td><code>WITH_JPEG</code></td>
<td>Enables/Disable JPEG support in LAMMPS</td>
<td>
<dl>
<dt><code>yes</code> (default, if found)</dt>
<dt><code>no</code></dt>
</dl>
</td>
</tr>
<tr>
<td><code>JPEG_INCLUDE_DIR</code></td>
<td></td>
@ -1544,6 +1636,16 @@ Requires a Eigen3 installation
</tr>
</thead>
<tbody>
<tr>
<td><code>WITH_PNG</code></td>
<td>Enables/Disable PNG support in LAMMPS</td>
<td>
<dl>
<dt><code>yes</code> (default, if found)</dt>
<dt><code>no</code></dt>
</dl>
</td>
</tr>
<tr>
<td><code>PNG_INCLUDE_DIR</code></td>
<td></td>
@ -1573,11 +1675,20 @@ requires `gzip` to be in your `PATH`
</thead>
<tbody>
<tr>
<td><code>GZIP_EXECUTABLE</code></td>
<td></td>
<td><code>WITH_GZIP</code></td>
<td>Enables/Disable GZIP support in LAMMPS</td>
<td>
<dl>
<dt><code>yes</code> (default, if found)</dt>
<dt><code>no</code></dt>
</dl>
</td>
</tr>
<tr>
<td><code>GZIP_EXECUTABLE</code></td>
<td>Path to gzip executable, will automatically pick up the first one in your $PATH.</td>
<td>(automatic)</td>
</tr>
</tbody>
</table>
@ -1595,19 +1706,33 @@ requires `ffmpeg` to be in your `PATH`
</thead>
<tbody>
<tr>
<td><code>FFMPEG_EXECUTABLE</code></td>
<td></td>
<td><code>WITH_FFMPEG</code></td>
<td>Enables/Disable FFMPEG support in LAMMPS</td>
<td>
<dl>
<dt><code>yes</code> (default, if found)</dt>
<dt><code>no</code></dt>
</dl>
</td>
</tr>
<tr>
<td><code>FFMPEG_EXECUTABLE</code></td>
<td>Path to ffmpeg executable, will automatically pick up the first one in your $PATH.</td>
<td>(automatic)</td>
</tr>
</tbody>
</table>
## Compilers
By default, `cmake` will use your environment C/C++/Fortran compilers for a build. It uses the `CC`, `CXX` and `FC` environment variables to detect which compilers should be used. However, these values
will be cached after the first run of `cmake`. Subsequent runs of `cmake` will ignore changes in these environment variables. To ensure the correct values are used you avoid the cache by setting the `CMAKE_C_COMPILER`, `CMAKE_CXX_COMPILER`, `CMAKE_Fortran_COMPILER` options directly.
By default, `cmake` will use your environment C/C++/Fortran compilers for a
build. It uses the `CC`, `CXX` and `FC` environment variables to detect which
compilers should be used. However, these values will be cached after the first
run of `cmake`. Subsequent runs of `cmake` will ignore changes in these
environment variables. To ensure the correct values are used you avoid the
cache by setting the `CMAKE_C_COMPILER`, `CMAKE_CXX_COMPILER`,
`CMAKE_Fortran_COMPILER` options directly.
<table>
<thead>
@ -1637,26 +1762,33 @@ will be cached after the first run of `cmake`. Subsequent runs of `cmake` will i
value of `FC` environment variable at first `cmake` run
</td>
</tr>
<tr>
<td><code>CXX_COMPILER_LAUNCHER</code></td>
<td>CMake will run this tool and pass the compiler and its arguments to the tool. Some example tools are distcc and ccache.</td>
<td>
(empty)
</td>
</tr>
</tbody>
</table>
### Building with GNU Compilers
```bash
cmake ../cmake -DCMAKE_C_COMPILER=gcc -DCMAKE_CXX_COMPILER=g++ -DCMAKE_Fortran_COMPILER=gfortran
cmake -D CMAKE_C_COMPILER=gcc -D CMAKE_CXX_COMPILER=g++ -D CMAKE_Fortran_COMPILER=gfortran ../cmake
```
### Building with Intel Compilers
```bash
cmake ../cmake -DCMAKE_C_COMPILER=icc -DCMAKE_CXX_COMPILER=icpc -DCMAKE_Fortran_COMPILER=ifort
cmake -D CMAKE_C_COMPILER=icc -D CMAKE_CXX_COMPILER=icpc -D CMAKE_Fortran_COMPILER=ifort ../cmake
```
### Building with LLVM/Clang Compilers
```bash
cmake ../cmake -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_Fortran_COMPILER=flang
cmake -D CMAKE_C_COMPILER=clang -D CMAKE_CXX_COMPILER=clang++ -D CMAKE_Fortran_COMPILER=flang ../cmake
```

View File

@ -1,2 +1,4 @@
# set environment for LAMMPS executables to find potential files
# set environment for LAMMPS and msi2lmp executables
# to find potential and force field files
if ( "$?LAMMPS_POTENTIALS" == 0 ) setenv LAMMPS_POTENTIALS @LAMMPS_POTENTIALS_DIR@
if ( "$?MSI2LMP_LIBRARY" == 0 ) setenv MSI2LMP_LIBRARY @LAMMPS_FRC_FILES_DIR@

View File

@ -1,2 +1,5 @@
# set environment for LAMMPS executables to find potential files
export LAMMPS_POTENTIALS=${LAMMPS_POTENTIALS-@LAMMPS_POTENTIALS_DIR@}
# set environment for LAMMPS and msi2lmp executables
# to find potential and force field files
LAMMPS_POTENTIALS=${LAMMPS_POTENTIALS-@LAMMPS_POTENTIALS_DIR@}
MSI2LMP_LIBRARY=${MSI2LMP_LIBRARY-@LAMMPS_FRC_FILES_DIR@}
export LAMMPS_POTENTIALS MSI2LMP_LIBRARY

View File

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

View File

@ -1,21 +1,17 @@
set(STANDARD_PACKAGES ASPHERE BODY CLASS2 COLLOID COMPRESS CORESHELL DIPOLE GPU
GRANULAR KIM KOKKOS KSPACE LATTE MANYBODY MC MEAM MISC
MOLECULE MPIIO MSCG OPT PERI POEMS
PYTHON QEQ REAX REPLICA RIGID SHOCK SNAP SRD VORONOI)
# preset that turns on all existing packages off. can be used to reset
# an existing package selection without losing any other settings
set(USER_PACKAGES USER-ATC USER-AWPMD USER-BOCS USER-CGDNA USER-CGSDK USER-COLVARS
USER-DIFFRACTION USER-DPD USER-DRUDE USER-EFF USER-FEP USER-H5MD
USER-INTEL USER-LB USER-MANIFOLD USER-MEAMC USER-MESO
USER-MGPT USER-MISC USER-MOFFF USER-MOLFILE
USER-NETCDF USER-OMP USER-PHONON USER-QMMM USER-QTB
USER-QUIP USER-REAXC USER-SMD USER-SMTBQ USER-SPH USER-TALLY
USER-UEF USER-VTK)
set(PACKAGES_WITH_LIB COMPRESS GPU KIM KOKKOS LATTE MEAM MPIIO MSCG POEMS PYTHON REAX VORONOI
USER-ATC USER-AWPMD USER-COLVARS USER-H5MD USER-LB USER-MOLFILE
USER-NETCDF USER-QMMM USER-QUIP USER-SMD USER-VTK)
set(ALL_PACKAGES ${STANDARD_PACKAGES} ${USER_PACKAGES})
set(ALL_PACKAGES ASPHERE BODY CLASS2 COLLOID COMPRESS CORESHELL DIPOLE GPU
GRANULAR KIM KOKKOS KSPACE LATTE MANYBODY MC MISC MESSAGE MOLECULE
MPIIO MSCG OPT PERI POEMS PYTHON QEQ REPLICA RIGID SHOCK SNAP SPIN
SRD VORONOI
USER-ADIOS USER-ATC USER-AWPMD USER-BOCS USER-CGDNA USER-CGSDK
USER-COLVARS USER-DIFFRACTION USER-DPD USER-DRUDE USER-EFF USER-FEP
USER-H5MD USER-INTEL USER-LB USER-MANIFOLD USER-MEAMC USER-MESO
USER-MGPT USER-MISC USER-MOFFF USER-MOLFILE USER-NETCDF USER-OMP
USER-PHONON USER-PLUMED USER-PTM USER-QMMM USER-QTB USER-QUIP
USER-REAXC USER-SCAFACOS USER-SDPD USER-SMD USER-SMTBQ USER-SPH
USER-TALLY USER-UEF USER-VTK USER-YAFF)
foreach(PKG ${ALL_PACKAGES})
set(PKG_${PKG} OFF CACHE BOOL "" FORCE)

View File

@ -1,21 +1,19 @@
set(STANDARD_PACKAGES ASPHERE BODY CLASS2 COLLOID COMPRESS CORESHELL DIPOLE GPU
GRANULAR KIM KOKKOS KSPACE LATTE MANYBODY MC MEAM MISC
MOLECULE MPIIO MSCG OPT PERI POEMS
PYTHON QEQ REAX REPLICA RIGID SHOCK SNAP SRD VORONOI)
# preset that turns on all existing packages. using the combination
# this preset followed by the nolib.cmake preset should configure a
# LAMMPS binary, with as many packages included, that can be compiled
# with just a working C++ compiler and an MPI library.
set(USER_PACKAGES USER-ATC USER-AWPMD USER-BOCS USER-CGDNA USER-CGSDK USER-COLVARS
USER-DIFFRACTION USER-DPD USER-DRUDE USER-EFF USER-FEP USER-H5MD
USER-INTEL USER-LB USER-MANIFOLD USER-MEAMC USER-MESO
USER-MGPT USER-MISC USER-MOFFF USER-MOLFILE
USER-NETCDF USER-OMP USER-PHONON USER-QMMM USER-QTB
USER-QUIP USER-REAXC USER-SMD USER-SMTBQ USER-SPH USER-TALLY
USER-UEF USER-VTK)
set(PACKAGES_WITH_LIB COMPRESS GPU KIM KOKKOS LATTE MEAM MPIIO MSCG POEMS PYTHON REAX VORONOI
USER-ATC USER-AWPMD USER-COLVARS USER-H5MD USER-LB USER-MOLFILE
USER-NETCDF USER-QMMM USER-QUIP USER-SMD USER-VTK)
set(ALL_PACKAGES ${STANDARD_PACKAGES} ${USER_PACKAGES})
set(ALL_PACKAGES ASPHERE BODY CLASS2 COLLOID COMPRESS CORESHELL DIPOLE GPU
GRANULAR KIM KOKKOS KSPACE LATTE MANYBODY MC MISC MESSAGE MOLECULE
MPIIO MSCG OPT PERI POEMS PYTHON QEQ REPLICA RIGID SHOCK SNAP SPIN
SRD VORONOI
USER-ADIOS USER-ATC USER-AWPMD USER-BOCS USER-CGDNA USER-CGSDK
USER-COLVARS USER-DIFFRACTION USER-DPD USER-DRUDE USER-EFF USER-FEP
USER-H5MD USER-INTEL USER-LB USER-MANIFOLD USER-MEAMC USER-MESO
USER-MGPT USER-MISC USER-MOFFF USER-MOLFILE USER-NETCDF USER-OMP
USER-PHONON USER-PLUMED USER-PTM USER-QMMM USER-QTB USER-QUIP
USER-REAXC USER-SCAFACOS USER-SDPD USER-SMD USER-SMTBQ USER-SPH
USER-TALLY USER-UEF USER-VTK USER-YAFF)
foreach(PKG ${ALL_PACKAGES})
set(PKG_${PKG} ON CACHE BOOL "" FORCE)

17
cmake/presets/clang.cmake Normal file
View File

@ -0,0 +1,17 @@
# preset that will enable clang/clang++ with support for MPI and OpenMP (on Linux boxes)
set(CMAKE_CXX_COMPILER "clang++" CACHE STRING "" FORCE)
set(CMAKE_C_COMPILER "clang" CACHE STRING "" FORCE)
set(CMAKE_CXX_FLAGS "-Wall -Wextra -g -O2 -DNDEBG" CACHE STRING "" FORCE)
set(MPI_CXX "clang++" CACHE STRING "" FORCE)
set(MPI_CXX_COMPILER "mpicxx" CACHE STRING "" FORCE)
unset(HAVE_OMP_H_INCLUDE CACHE)
set(OpenMP_C "clang" CACHE STRING "" FORCE)
set(OpenMP_C_FLAGS "-fopenmp" CACHE STRING "" FORCE)
set(OpenMP_C_LIB_NAMES "omp" CACHE STRING "" FORCE)
set(OpenMP_CXX "clang++" CACHE STRING "" FORCE)
set(OpenMP_CXX_FLAGS "-fopenmp" CACHE STRING "" FORCE)
set(OpenMP_CXX_LIB_NAMES "omp" CACHE STRING "" FORCE)
set(OpenMP_omp_LIBRARY "/usr/lib64/libomp.so" CACHE PATH "" FORCE)

View File

@ -1,69 +0,0 @@
set(PKG_ASPHERE OFF CACHE BOOL "" FORCE)
set(PKG_BODY OFF CACHE BOOL "" FORCE)
set(PKG_CLASS2 OFF CACHE BOOL "" FORCE)
set(PKG_COLLOID OFF CACHE BOOL "" FORCE)
set(PKG_COMPRESS OFF CACHE BOOL "" FORCE)
set(PKG_CORESHELL OFF CACHE BOOL "" FORCE)
set(PKG_DIPOLE OFF CACHE BOOL "" FORCE)
set(PKG_GPU OFF CACHE BOOL "" FORCE)
set(PKG_GRANULAR OFF CACHE BOOL "" FORCE)
set(PKG_KIM OFF CACHE BOOL "" FORCE)
set(PKG_KOKKOS OFF CACHE BOOL "" FORCE)
set(PKG_KSPACE OFF CACHE BOOL "" FORCE)
set(PKG_LATTE OFF CACHE BOOL "" FORCE)
set(PKG_LIB OFF CACHE BOOL "" FORCE)
set(PKG_MANYBODY OFF CACHE BOOL "" FORCE)
set(PKG_MC OFF CACHE BOOL "" FORCE)
set(PKG_MEAM OFF CACHE BOOL "" FORCE)
set(PKG_MISC OFF CACHE BOOL "" FORCE)
set(PKG_MOLECULE OFF CACHE BOOL "" FORCE)
set(PKG_MPIIO OFF CACHE BOOL "" FORCE)
set(PKG_MSCG OFF CACHE BOOL "" FORCE)
set(PKG_OPT OFF CACHE BOOL "" FORCE)
set(PKG_PERI OFF CACHE BOOL "" FORCE)
set(PKG_POEMS OFF CACHE BOOL "" FORCE)
set(PKG_PYTHOFF OFF CACHE BOOL "" FORCE)
set(PKG_QEQ OFF CACHE BOOL "" FORCE)
set(PKG_REAX OFF CACHE BOOL "" FORCE)
set(PKG_REPLICA OFF CACHE BOOL "" FORCE)
set(PKG_RIGID OFF CACHE BOOL "" FORCE)
set(PKG_SHOCK OFF CACHE BOOL "" FORCE)
set(PKG_SNAP OFF CACHE BOOL "" FORCE)
set(PKG_SRD OFF CACHE BOOL "" FORCE)
set(PKG_VOROFFOI OFF CACHE BOOL "" FORCE)
set(PKG_USER OFF CACHE BOOL "" FORCE)
set(PKG_USER-ATC OFF CACHE BOOL "" FORCE)
set(PKG_USER-AWPMD OFF CACHE BOOL "" FORCE)
set(PKG_USER-BOCS OFF CACHE BOOL "" FORCE)
set(PKG_USER-CGDNA OFF CACHE BOOL "" FORCE)
set(PKG_USER-CGSDK OFF CACHE BOOL "" FORCE)
set(PKG_USER-COLVARS OFF CACHE BOOL "" FORCE)
set(PKG_USER-DIFFRACTIOFF OFF CACHE BOOL "" FORCE)
set(PKG_USER-DPD OFF CACHE BOOL "" FORCE)
set(PKG_USER-DRUDE OFF CACHE BOOL "" FORCE)
set(PKG_USER-EFF OFF CACHE BOOL "" FORCE)
set(PKG_USER-FEP OFF CACHE BOOL "" FORCE)
set(PKG_USER-H5MD OFF CACHE BOOL "" FORCE)
set(PKG_USER-INTEL OFF CACHE BOOL "" FORCE)
set(PKG_USER-LB OFF CACHE BOOL "" FORCE)
set(PKG_USER-MANIFOLD OFF CACHE BOOL "" FORCE)
set(PKG_USER-MEAMC OFF CACHE BOOL "" FORCE)
set(PKG_USER-MESO OFF CACHE BOOL "" FORCE)
set(PKG_USER-MGPT OFF CACHE BOOL "" FORCE)
set(PKG_USER-MISC OFF CACHE BOOL "" FORCE)
set(PKG_USER-MOFFF OFF CACHE BOOL "" FORCE)
set(PKG_USER-MOLFILE OFF CACHE BOOL "" FORCE)
set(PKG_USER-NETCDF OFF CACHE BOOL "" FORCE)
set(PKG_USER-OMP OFF CACHE BOOL "" FORCE)
set(PKG_USER-PHOFFOFF OFF CACHE BOOL "" FORCE)
set(PKG_USER-QMMM OFF CACHE BOOL "" FORCE)
set(PKG_USER-QTB OFF CACHE BOOL "" FORCE)
set(PKG_USER-QUIP OFF CACHE BOOL "" FORCE)
set(PKG_USER-REAXC OFF CACHE BOOL "" FORCE)
set(PKG_USER-SMD OFF CACHE BOOL "" FORCE)
set(PKG_USER-SMTBQ OFF CACHE BOOL "" FORCE)
set(PKG_USER-SPH OFF CACHE BOOL "" FORCE)
set(PKG_USER-TALLY OFF CACHE BOOL "" FORCE)
set(PKG_USER-UEF OFF CACHE BOOL "" FORCE)
set(PKG_USER-VTK OFF CACHE BOOL "" FORCE)

View File

@ -0,0 +1,17 @@
set(WIN_PACKAGES ASPHERE BODY CLASS2 COLLOID COMPRESS CORESHELL DIPOLE GPU
GRANULAR KSPACE MANYBODY MC MISC MOLECULE OPT PERI POEMS QEQ
REPLICA RIGID SHOCK SNAP SPIN SRD VORONOI USER-ATC USER-AWPMD
USER-BOCS USER-CGDNA USER-CGSDK USER-COLVARS USER-DIFFRACTION
USER-DPD USER-DRUDE USER-EFF USER-FEP USER-INTEL USER-MANIFOLD
USER-MEAMC USER-MESO USER-MISC USER-MOFFF USER-MOLFILE USER-OMP
USER-PHONON USER-PTM USER-QTB USER-REAXC USER-SDPD USER-SMD
USER-SMTBQ USER-SPH USER-TALLY USER-UEF USER-YAFF)
foreach(PKG ${WIN_PACKAGES})
set(PKG_${PKG} ON CACHE BOOL "" FORCE)
endforeach()
set(DOWNLOAD_VORO ON CACHE BOOL "" FORCE)
set(DOWNLOAD_EIGEN3 ON CACHE BOOL "" FORCE)
set(LAMMPS_MEMALIGN "0" CACHE STRING "" FORCE)
set(INTEL_LRT_MODE "none" CACHE STRING "" FORCE)

View File

@ -0,0 +1,8 @@
# preset that turns on just a few, frequently used packages
# this will be compiled quickly and handle a lot of common inputs.
set(ALL_PACKAGES KSPACE MANYBODY MOLECULE RIGID)
foreach(PKG ${ALL_PACKAGES})
set(PKG_${PKG} ON CACHE BOOL "" FORCE)
endforeach()

15
cmake/presets/most.cmake Normal file
View File

@ -0,0 +1,15 @@
# preset that turns on a wide range of packages, some of which require
# external libraries. Compared to all_on.cmake some more unusual packages
# are removed. The resulting binary should be able to run most inputs.
set(ALL_PACKAGES ASPHERE CLASS2 COLLOID CORESHELL DIPOLE
GRANULAR KSPACE MANYBODY MC MISC MOLECULE OPT PERI
PYTHON QEQ REPLICA RIGID SHOCK SRD VORONOI
USER-CGDNA USER-CGSDK USER-COLVARS USER-DIFFRACTION USER-DPD
USER-DRUDE USER-FEP USER-MEAMC USER-MESO
USER-MISC USER-MOFFF USER-OMP USER-PLUMED USER-PHONON USER-REAXC
USER-SPH USER-SMD USER-UEF USER-YAFF)
foreach(PKG ${ALL_PACKAGES})
set(PKG_${PKG} ON CACHE BOOL "" FORCE)
endforeach()

View File

@ -1,21 +1,10 @@
set(STANDARD_PACKAGES ASPHERE BODY CLASS2 COLLOID COMPRESS CORESHELL DIPOLE GPU
GRANULAR KIM KOKKOS KSPACE LATTE MANYBODY MC MEAM MISC
MOLECULE MPIIO MSCG OPT PERI POEMS
PYTHON QEQ REAX REPLICA RIGID SHOCK SNAP SRD VORONOI)
# preset that turns off all packages that require some form of external
# library or special compiler (fortran or cuda) or equivalent.
set(USER_PACKAGES USER-ATC USER-AWPMD USER-BOCS USER-CGDNA USER-CGSDK USER-COLVARS
USER-DIFFRACTION USER-DPD USER-DRUDE USER-EFF USER-FEP USER-H5MD
USER-INTEL USER-LB USER-MANIFOLD USER-MEAMC USER-MESO
USER-MGPT USER-MISC USER-MOFFF USER-MOLFILE
USER-NETCDF USER-OMP USER-PHONON USER-QMMM USER-QTB
USER-QUIP USER-REAXC USER-SMD USER-SMTBQ USER-SPH USER-TALLY
USER-UEF USER-VTK)
set(PACKAGES_WITH_LIB COMPRESS GPU KIM KOKKOS LATTE MEAM MPIIO MSCG POEMS PYTHON REAX VORONOI
USER-ATC USER-AWPMD USER-COLVARS USER-H5MD USER-LB USER-MOLFILE
USER-NETCDF USER-QMMM USER-QUIP USER-SMD USER-VTK)
set(ALL_PACKAGES ${STANDARD_PACKAGES} ${USER_PACKAGES})
set(PACKAGES_WITH_LIB COMPRESS GPU KIM KOKKOS LATTE MPIIO MSCG PYTHON
VORONOI USER-ADIOS USER-ATC USER-AWPMD USER-H5MD USER-LB
USER-MOLFILE USER-NETCDF USER-PLUMED USER-QMMM USER-QUIP
USER-SCAFACOS USER-SMD USER-VTK)
foreach(PKG ${PACKAGES_WITH_LIB})
set(PKG_${PKG} OFF CACHE BOOL "" FORCE)

View File

@ -1,22 +0,0 @@
set(STANDARD_PACKAGES ASPHERE BODY CLASS2 COLLOID COMPRESS CORESHELL DIPOLE GPU
GRANULAR KIM KOKKOS KSPACE LATTE MANYBODY MC MEAM MISC
MOLECULE MPIIO MSCG OPT PERI POEMS
PYTHON QEQ REAX REPLICA RIGID SHOCK SNAP SRD VORONOI)
set(USER_PACKAGES USER-ATC USER-AWPMD USER-BOCS USER-CGDNA USER-CGSDK USER-COLVARS
USER-DIFFRACTION USER-DPD USER-DRUDE USER-EFF USER-FEP USER-H5MD
USER-INTEL USER-LB USER-MANIFOLD USER-MEAMC USER-MESO
USER-MGPT USER-MISC USER-MOFFF USER-MOLFILE
USER-NETCDF USER-OMP USER-PHONON USER-QMMM USER-QTB
USER-QUIP USER-REAXC USER-SMD USER-SMTBQ USER-SPH USER-TALLY
USER-UEF USER-VTK)
set(PACKAGES_WITH_LIB COMPRESS GPU KIM KOKKOS LATTE MEAM MPIIO MSCG POEMS PYTHON REAX VORONOI
USER-ATC USER-AWPMD USER-COLVARS USER-H5MD USER-LB USER-MOLFILE
USER-NETCDF USER-QMMM USER-QUIP USER-SMD USER-VTK)
set(ALL_PACKAGES ${STANDARD_PACKAGES} ${USER_PACKAGES})
foreach(PKG ${STANDARD_PACKAGES})
set(PKG_${PKG} ON CACHE BOOL "" FORCE)
endforeach()

View File

@ -1,26 +0,0 @@
set(STANDARD_PACKAGES ASPHERE BODY CLASS2 COLLOID COMPRESS CORESHELL DIPOLE GPU
GRANULAR KIM KOKKOS KSPACE LATTE MANYBODY MC MEAM MISC
MOLECULE MPIIO MSCG OPT PERI POEMS
PYTHON QEQ REAX REPLICA RIGID SHOCK SNAP SRD VORONOI)
set(USER_PACKAGES USER-ATC USER-AWPMD USER-BOCS USER-CGDNA USER-CGSDK USER-COLVARS
USER-DIFFRACTION USER-DPD USER-DRUDE USER-EFF USER-FEP USER-H5MD
USER-INTEL USER-LB USER-MANIFOLD USER-MEAMC USER-MESO
USER-MGPT USER-MISC USER-MOFFF USER-MOLFILE
USER-NETCDF USER-OMP USER-PHONON USER-QMMM USER-QTB
USER-QUIP USER-REAXC USER-SMD USER-SMTBQ USER-SPH USER-TALLY
USER-UEF USER-VTK)
set(PACKAGES_WITH_LIB COMPRESS GPU KIM KOKKOS LATTE MEAM MPIIO MSCG POEMS PYTHON REAX VORONOI
USER-ATC USER-AWPMD USER-COLVARS USER-H5MD USER-LB USER-MOLFILE
USER-NETCDF USER-QMMM USER-QUIP USER-SMD USER-VTK)
set(ALL_PACKAGES ${STANDARD_PACKAGES} ${USER_PACKAGES})
foreach(PKG ${STANDARD_PACKAGES})
set(PKG_${PKG} ON CACHE BOOL "" FORCE)
endforeach()
foreach(PKG ${PACKAGES_WITH_LIB})
set(PKG_${PKG} OFF CACHE BOOL "" FORCE)
endforeach()

View File

@ -1,22 +0,0 @@
set(STANDARD_PACKAGES ASPHERE BODY CLASS2 COLLOID COMPRESS CORESHELL DIPOLE GPU
GRANULAR KIM KOKKOS KSPACE LATTE MANYBODY MC MEAM MISC
MOLECULE MPIIO MSCG OPT PERI POEMS
PYTHON QEQ REAX REPLICA RIGID SHOCK SNAP SRD VORONOI)
set(USER_PACKAGES USER-ATC USER-AWPMD USER-BOCS USER-CGDNA USER-CGSDK USER-COLVARS
USER-DIFFRACTION USER-DPD USER-DRUDE USER-EFF USER-FEP USER-H5MD
USER-INTEL USER-LB USER-MANIFOLD USER-MEAMC USER-MESO
USER-MGPT USER-MISC USER-MOFFF USER-MOLFILE
USER-NETCDF USER-OMP USER-PHONON USER-QMMM USER-QTB
USER-QUIP USER-REAXC USER-SMD USER-SMTBQ USER-SPH USER-TALLY
USER-UEF USER-VTK)
set(PACKAGES_WITH_LIB COMPRESS GPU KIM KOKKOS LATTE MEAM MPIIO MSCG POEMS PYTHON REAX VORONOI
USER-ATC USER-AWPMD USER-COLVARS USER-H5MD USER-LB USER-MOLFILE
USER-NETCDF USER-QMMM USER-QUIP USER-SMD USER-VTK)
set(ALL_PACKAGES ${STANDARD_PACKAGES} ${USER_PACKAGES})
foreach(PKG ${USER_PACKAGES})
set(PKG_${PKG} ON CACHE BOOL "" FORCE)
endforeach()

2
doc/.gitignore vendored
View File

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

View File

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

View File

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

264
doc/lammps.1 Normal file
View File

@ -0,0 +1,264 @@
.TH LAMMPS "15 May 2019" "2019-05-15"
.SH NAME
.B LAMMPS
\- Molecular Dynamics Simulator.
.SH SYNOPSIS
.B lmp
\-in <input file> [OPTIONS] ...
or
mpirun \-np 2
.B lmp
<input file> [OPTIONS] ...
or
.B lmp
\-r2data file.restart file.data
.SH DESCRIPTION
.B LAMMPS
is a classical molecular dynamics code, and an acronym for \fBL\fRarge-scale
\fBA\fRtomic/\fBM\fRolecular \fBM\fRassively \fBP\fRarallel \fBS\fRimulator.
.B LAMMPS
has potentials for soft
materials (bio-molecules, polymers) and solid-state materials (metals,
semiconductors) and coarse-grained or mesoscopic systems. It can be used to
model atoms or, more generically, as a parallel particle simulator at the
atomic, meso, or continuum scale.
See https://lammps.sandia.gov/ for more information and documentation.
.SH EXECUTABLE NAME
The
.B LAMMPS
executable can have different names depending on how it was configured,
compiled and installed. It will be either
.B lmp
or
.B lmp_<machine name>.
The <machine name> suffix corresponds to the (machine specific) makefile
used to compile
.B LAMMPS
when using the conventional build process. When building
.B LAMMPS
using
.B CMake
this <machine name> parameter can be chosen arbitrarily at configuration
time, but more common is to just use
.B lmp
without a suffix. In this manpage we will use
.B lmp
to represent any of those names.
.SH OPTIONS
.TP
\fB\-h\fR or \fB\-help\fR
Print a brief help summary and a list of settings and options compiled
into this executable. It also explicitly lists all LAMMPS styles
(atom_style, fix, compute, pair_style, bond_style, etc) available in
the specific executable. This can tell you if the command you want to
use was included via the appropriate package at compile time.
LAMMPS will print the info and immediately exit if this switch is used.
.TP
\fB\-e\fR or \fB\-echo\fR
Set the style of command echoing. The style can be
.B none
or
.B screen
or
.B log
or
.B both.
Depending on the style, each command read from the input script will
be echoed to the screen and/or logfile. This can be useful to figure
out which line of your script is causing an input error.
The default value is
.B log.
.TP
\fB\-i <input file>\fR or \fB\-in <input file>\fR
Specify a file to use as an input script. If it is not specified,
LAMMPS reads its script from standard input. This is a required
switch when running LAMMPS in multi-partition mode.
.TP
\fB\-k on/off [keyword value]\fR or \fB\-kokkos on/off [keyword value]\fR
Enable or disable general KOKKOS support, as provided by the KOKKOS
package. Even if LAMMPS is built with this package, this switch must
be set to \fBon\fR to enable running with KOKKOS-enabled styles. More
details on this switch and its optional keyword value pairs are discussed
at: https://lammps.sandia.gov/doc/Run_options.html
.TP
\fB\-l <log file>\fR or \fB\-log <log file>\fR
Specify a log file for LAMMPS to write status information to.
The default value is "log.lammps". If the file name "none" is used,
\fBLAMMPS\fR will not write a log file. In multi-partition mode only
some high-level all-partition information is written to the "<log file>"
file, the remainder is written in a per-partition file "<log file>.N"
with "N" being the respective partition number, unless overridden
by the \-plog flag (see below).
.TP
\fB\-m <number>\fR or \fB\-mpicolor <number>\fR
If used, this must be the first command-line argument after the
.B LAMMPS
executable name. It is only used when
.B LAMMPS
is launched by an mpirun command which also launches one or more
other executable(s) at the same time.
.B LAMMPS
and the other executable(s) perform an MPI_Comm_split(), each with
their own different colors, to split the MPI_COMM_WORLD communicator
for each executable to the subset of processors they are supposed to
be actually running on. Currently, this is only used in
.B LAMMPS
to perform client/server messaging with another application.
.B LAMMPS
can act as either a client or server (or both).
.TP
\fB\-nc\fR or \fB\-nocite\fR
Disable writing the "log.cite" file which is normally written to
list references for specific cite-able features used during a
.B LAMMPS
run.
.TP
\fB\-pk <style> [options]\fR or \fB\-package <style> [options]\fR
Invoke the \fBpackage\R command with <style> and optional arguments.
The syntax is the same as if the command appeared in an input script.
For example "-pk gpu 2" is the same as "package gpu 2" in the input
script. The possible styles and options are discussed in the
.B LAMMPS
manual for the "package" command. This switch can be used multiple
times, e.g. to set options for the USER-INTEL and USER-OMP packages
when used together. Along with the "-sf" or "-suffix" switch, this
is a convenient mechanism for invoking accelerator packages and their
options without having to edit an input script.
.TP
\fB\-p\fR or \fB\-partition\fR
Invoke
.B LAMMPS
in multi-partition mode. Without this,
.B LAMMPS
uses all P processors allocated via MPI to run a single simulation.
If this switch is used, the P processors are split into separate
partitions and each partition runs its own simulation. The arguments
to the switch specify the number of processors in each partition.
Arguments of the form "MxN" mean M partitions, each with N processors.
Arguments of the form "N" mean a single partition with N processors.
The sum of processors in all partitions must be equal P. Thus the
command “-partition 8x2 4 5” has 10 partitions and runs on a total
of 25 processors. Running with multiple partitions is required for
multi-replica simulations, where each replica runs on on one or more
few processors.
.TP
\fB\-pl <basename>\fR or \fB\-plog <basename>\fR
Specify the base name for the per-partition log files in multi-partition
runs, where partition N writes log information to <basename>.N.
If basename is set to "none", then no per-partition log files are created.
This overrides the name specified in the \-log command-line option.
.TP
\fB\-ps <basename>\fR or \fB\-pscreen <basename>\fR
Specify the base name for the per-partition screen files in multi-partition
runs, where partition N writes screen output to <basename>.N.
If basename is set to "none", then no per-partition screen files are created.
The default value is "screen" or whatever is set by the \-screen flag.
.TP
\fB\-r2data <restart file> [remap] <data file>\fR or
\fB\-restart2data <restart file> [remap] <data file>\fR
Convert <restart file> previously written by
.B LAMMPS
into a data file and immediately exit. This option has replaced the
external restart2data executable. Following <restart file>
argument, the optional word "remap" may be used. This has the
same effect like adding it to a "read_restart" command.
The syntax following the <data file> name is identical to the
arguments of the "write_data" command. See the
.B LAMMPS
manual for details on either of the two commands.
.TP
\fB\-r2dump <restart file> [remap] <dump file>\fR or
\fB\-restart2dump <restart file> [remap] <dump file>\fR
Convert <restart file> previously written by
.B LAMMPS
into a dump file and immediately exit. Following <restart file>
argument, the optional word "remap" may be used. This has the
same effect like adding it to a "read_restart" command.
The syntax following the <dump file> name is identical to the
arguments of the "dump" command. See the
.B LAMMPS
manual for details on either of the two commands.
.TP
\fB\-sc <file name>\fR or \fB\-screen <file name>\fR
Specify a file for
.B LAMMPS
to write its screen information to. By default, this will be
the standard output. If <file name> is "none", (most) screen
output will be suppressed. In multi-partition mode only
some high-level all-partition information is written to the
screen or "<file name>" file, the remainder is written in a
per-partition file "screen.N" or "<file name>.N"
with "N" being the respective partition number, and unless
overridden by the \-pscreen flag (see above).
.TP
\fB\-sf <suffix>\fR or \fB\-suffix <suffix>\fR
Use variants of various styles in the input, if they exist. This is
achieved by transparently trying to convert a style named <my/style>
into <my/style/suffix> if that latter style exists, but otherwise
fall back to the former. The most useful suffixes are "gpu",
"intel", "kk", "omp", "opt", or "hybrid". These refer to styles from
optional packages that LAMMPS can be built with. The hybrid suffix is
special, as it enables, having two suffixes tried (e.g. first "intel"
and then "omp") and thus requires two arguments. Along with the
"-package" command-line switch, this is a convenient mechanism for
invoking styles from accelerator packages and setting their options
without having to edit an input script.
See https://lammps.sandia.gov/doc/Run_options.html for additional
details and discussions on command-line options.
.SH LAMMPS BASICS
LAMMPS executes by reading commands from a input script (text file),
one line at a time. When the input script ends, LAMMPS exits. Each
command causes LAMMPS to take some action. It may set or change an
internal, read and parse a file, or run a simulation. Most commands
have default settings, which means you only need to use the command
if you wish to change the default.
The ordering of commands in an input script is usually not very important
unless a command like "run" is encountered, which starts some calculation
using the current internal state. Also, if a "pair_style" or "bond_style"
other similar style command is issued that has a different name from what
was previously active, it will replace the previous style and wipe out
all corresponding "pair_coeff" or "bond_coeff" or equivalent settings.
Some commands are only valid when they follow other commands. For
example you cannot set the temperature of a group of atoms until atoms
have been defined and a group command is used to define which atoms
belong to the group of a given name. Sometimes command B will use values
that can be set by command A. This means command A must precede command
B in the input to have the desired effect. Some commands must be issued
.B before
the simulation box is defined and others can only be issued
.B after.
Many input script errors are detected by
.B LAMMPS
and an ERROR or WARNING message is printed. The documentation for
each command lists restrictions on how the command can be used, and
the chapter on errors in the
.B LAMMPS
manual gives some additional information about error messages, if possible.
.SH COPYRIGHT
© 2003--2019 Sandia Corporation
This package is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License version 2 as
published by the Free Software Foundation.
This package is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
On Debian systems, the complete text of the GNU General
Public License can be found in `/usr/share/common-licenses/GPL-2'.

111
doc/msi2lmp.1 Normal file
View File

@ -0,0 +1,111 @@
.TH MSI2LMP "v3.9.9" "2018-11-05"
.SH NAME
.B MSI2LMP
\- Converter for Materials Studio files to LAMMPS
.SH SYNOPSIS
.B msi2lmp
<ROOTNAME> [-class <I|1|II|2|O|0>] [-frc <path to frc file>] [-print #] [-ignore] [-nocenter] [-oldstyle] [-shift <x> <y> <z>]
.SH DESCRIPTION
.PP
.B MSI2LMP
is a tool bundled with LAMMPS to aide in the conversion of simulation
inputs from Biovia's Materials Studio software for use with LAMMPS.
It is a standalone program that generates a LAMMPS data file based on
the information in an MS .car file (atom coordinates), an .mdf file
(molecular topology and atom types) and an .frc (forcefield parameters)
file. The .car and .mdf files are specific to a molecular system while
the .frc file is specific to a forcefield (variant). The only coherency
needed between .frc and .car/.mdf files are the atom types.
.PP
.SH OPTIONS
.TP
\fB\<ROOTNAME>\fR
This has to be the first argument and is a
.B mandatory
argument. It defines the root of the file names; i.e. for a
.B <ROOTNAME>
of benzene, you have to provide the files 'benzene.car' and 'benzene.mdf'
in the current working directory.
.B msi2lmp
will then read and process those files according to its remaining settings.
All other settins are optional and have defaults as listed.
.TP
\fB\-c <I,1,II,2,O,0>\fR, \fB\-class <I,1,II,2,O,0>\fR
The \-c or \-class option selects the force field class, i.e which pair
styles and bond styles and so on are required in the LAMMPS input file.
Class I or class 1 uses similar combination of functional forms as Amber
and Charmm force field and support the force fields
.B cvff
and
.B clayff.
Class II or class 2 corresponds to the more complex force fields
.B COMPASS
and
.B pcff.
Class O or class 0 finally is an experimental and incomplete extension
and supports generating output for
.B OPLS-AA
.TP
\fB\-f <ffname>\fR, \fB\-frc <ffname>\fR
The \-c or \-frc option allows the selection of the force field parameter
file
.B<ffname>.frc.
Valid names for <ffname> with this distribution are: cvff, clayff, cvff_aug,
pcff, compass_published, cff91, and oplsaa. If the argument is a pathname,
i.e. it starts with a '.' or a '/', then this absolute path is used to read
the force field, otherwise
.B msi2lmp
will look in the folder pointed to by the environment variable
$MSI2LMP_LIBRARY. If the variable is not set, then it will look in the current
directory. The extension '.frc' is appended, if missing.
Default is to look for the cvff.frc force field file.
.TP
\fB\-p <loglevel>\fR, \fB\-print <loglevel>\fR,
Selects the amount of information messages about the progress of the
conversion printed to the screen.
.B <loglevel>
can be a number from 0 (silent except for errors) to 3 (very detailed).
.TP
\fB\-i\fR, \fB\-ignore\fR,
Ignore errors about missing parameters and use 0.0 for the respective
force constants making these no-ops. Is correct to be used for a few
molecules and settings, but often an indication, that either the atom
type assignment have errors, or the force field file is missing entries.
.TP
\fB\-n\fR, \fB\-nocenter\fR,
Do not center the box around the (geometrical) center of the atoms,
but around the origin. Default is to recenter.
.TP
\fB\-o\fR, \fB\-oldstyle\fR,
Write out a data file without style hint comments to be compatible
with old LAMMPS versions. Default is to write out those comments.
.TP
\fB-s <x> <y> <z>\fR, \fB-shift <x> <y> <z>\fR,
Shift the entire system (box and coordinates) by a vector
(default: 0.0 0.0 0.0).
.TP
.SH EXAMPLES
msi2lmp benzene -c 2 -p 1 -f ../frc_files/pcff.frc
msi2lmp benzene-class1 -c I
msi2lmp decane -c 0 -f oplsaa
.SH COPYRIGHT
© 2003--2019 Sandia Corporation
This package is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License version 2 as
published by the Free Software Foundation.
This package is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.

49
doc/src/Build.txt Normal file
View File

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

331
doc/src/Build_basics.txt Normal file
View File

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

198
doc/src/Build_cmake.txt Normal file
View File

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

1119
doc/src/Build_extras.txt Normal file

File diff suppressed because it is too large Load Diff

85
doc/src/Build_link.txt Normal file
View File

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

85
doc/src/Build_make.txt Normal file
View File

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

240
doc/src/Build_package.txt Normal file
View File

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

344
doc/src/Build_settings.txt Normal file
View File

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

102
doc/src/Build_windows.txt Normal file
View File

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

View File

@ -1,4 +1,4 @@
"Previous Section"_Run.html - "LAMMPS WWW Site"_lws -
"Previous Section"_Run_head.html - "LAMMPS WWW Site"_lws -
"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
Section"_Packages.html :c
@ -16,6 +16,7 @@ commands in it are used to define a LAMMPS simulation.
<!-- RST
.. toctree::
:maxdepth: 1
Commands_input
Commands_parse
@ -23,6 +24,7 @@ commands in it are used to define a LAMMPS simulation.
Commands_category
.. toctree::
:maxdepth: 1
Commands_all
Commands_fix
@ -40,10 +42,10 @@ END_RST -->
"Input script structure"_Commands_structure.html
"Commands by category"_Commands_category.html :all(b)
"All commands"_Commands_all.html
"Fix commands"_Commands_fix.html
"Compute commands"_Commands_compute.html
"Pair commands"_Commands_pair.html
"General commands"_Commands_all.html
"Fix commands"_Commands_fix.html
"Compute commands"_Commands_compute.html
"Pair commands"_Commands_pair.html
"Bond, angle, dihedral, improper commands"_Commands_bond.html
"KSpace solvers"_Commands_kspace.html :all(b)

View File

@ -7,7 +7,7 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
:line
"All commands"_Commands_all.html,
"General commands"_Commands_all.html,
"Fix styles"_Commands_fix.html,
"Compute styles"_Commands_compute.html,
"Pair styles"_Commands_pair.html,
@ -17,9 +17,9 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
"Improper styles"_Commands_bond.html#improper,
"KSpace styles"_Commands_kspace.html :tb(c=3,ea=c)
All commands :h3
General commands :h3
An alphabetic list of all LAMMPS commmands.
An alphabetic list of all general LAMMPS commands.
"angle_coeff"_angle_coeff.html,
"angle_style"_angle_style.html,
@ -48,35 +48,42 @@ An alphabetic list of all LAMMPS commmands.
"dimension"_dimension.html,
"displace_atoms"_displace_atoms.html,
"dump"_dump.html,
"dump adios"_dump_adios.html,
"dump image"_dump_image.html,
"dump_modify"_dump_modify.html,
"dump movie"_dump_image.html,
"dump netcdf"_dump_netcdf.html,
"dump netcdf/mpiio"_dump_netcdf.html,
"dump vtk"_dump_vtk.html,
"dynamical_matrix"_dynamical_matrix.html,
"echo"_echo.html,
"fix"_fix.html,
"fix_modify"_fix_modify.html,
"group"_group.html,
"group2ndx"_group2ndx.html,
"hyper"_hyper.html,
"if"_if.html,
"info"_info.html,
"improper_coeff"_improper_coeff.html,
"improper_style"_improper_style.html,
"include"_include.html,
"jump"_jump.html,
"kim_query"_kim_query.html,
"kspace_modify"_kspace_modify.html,
"kspace_style"_kspace_style.html,
"label"_label.html,
"lattice"_lattice.html,
"log"_log.html,
"mass"_mass.html,
"message"_message.html,
"minimize"_minimize.html,
"min_modify"_min_modify.html,
"min_style"_min_style.html,
"min_style spin"_min_spin.html,
"molecule"_molecule.html,
"ndx2group"_group2ndx.html,
"neb"_neb.html,
"neb/spin"_neb_spin.html,
"neigh_modify"_neigh_modify.html,
"neighbor"_neighbor.html,
"newton"_newton.html,
@ -103,6 +110,7 @@ An alphabetic list of all LAMMPS commmands.
"restart"_restart.html,
"run"_run.html,
"run_style"_run_style.html,
"server"_server.html,
"set"_set.html,
"shell"_shell.html,
"special_bonds"_special_bonds.html,

View File

@ -5,11 +5,11 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
:link(ld,Manual.html)
:link(lc,Commands_all.html)
"All commands"_Commands_all.html,
"General commands"_Commands_all.html,
"Fix styles"_Commands_fix.html,
"Compute styles"_Commands_compute.html,
"Pair styles"_Commands_pair.html,
"Bond styles"_Commands_bond.html,
"Bond styles"_Commands_bond.html#bond,
"Angle styles"_Commands_bond.html#angle,
"Dihedral styles"_Commands_bond.html#dihedral,
"Improper styles"_Commands_bond.html#improper,
@ -34,9 +34,10 @@ OPT.
"fene (iko)"_bond_fene.html,
"fene/expand (o)"_bond_fene_expand.html,
"gromos (o)"_bond_gromos.html,
"harmonic (ko)"_bond_harmonic.html,
"harmonic (iko)"_bond_harmonic.html,
"harmonic/shift (o)"_bond_harmonic_shift.html,
"harmonic/shift/cut (o)"_bond_harmonic_shift_cut.html,
"mm3"_bond_mm3.html,
"morse (o)"_bond_morse.html,
"nonlinear (o)"_bond_nonlinear.html,
"oxdna/fene"_bond_oxdna.html,
@ -57,20 +58,24 @@ OPT.
"zero"_angle_zero.html,
"hybrid"_angle_hybrid.html :tb(c=3,ea=c)
"charmm (ko)"_angle_charmm.html,
"charmm (iko)"_angle_charmm.html,
"class2 (ko)"_angle_class2.html,
"cosine (o)"_angle_cosine.html,
"class2/p6"_angle_class2.html,
"cosine (ko)"_angle_cosine.html,
"cosine/buck6d"_angle_cosine_buck6d.html,
"cosine/delta (o)"_angle_cosine_delta.html,
"cosine/periodic (o)"_angle_cosine_periodic.html,
"cosine/shift (o)"_angle_cosine_shift.html,
"cosine/shift/exp (o)"_angle_cosine_shift_exp.html,
"cosine/squared (o)"_angle_cosine_squared.html,
"cross"_angle_cross.html,
"dipole (o)"_angle_dipole.html,
"fourier (o)"_angle_fourier.html,
"fourier/simple (o)"_angle_fourier_simple.html,
"harmonic (iko)"_angle_harmonic.html,
"mm3"_angle_mm3.html,
"quartic (o)"_angle_quartic.html,
"sdk"_angle_sdk.html,
"sdk (o)"_angle_sdk.html,
"table (o)"_angle_table.html :tb(c=4,ea=c)
:line
@ -95,9 +100,9 @@ OPT.
"helix (o)"_dihedral_helix.html,
"multi/harmonic (o)"_dihedral_multi_harmonic.html,
"nharmonic (o)"_dihedral_nharmonic.html,
"opls (iko)"_dihedral_opls.htm;,
"opls (iko)"_dihedral_opls.html,
"quadratic (o)"_dihedral_quadratic.html,
"spherical (o)"_dihedral_spherical.html,
"spherical"_dihedral_spherical.html,
"table (o)"_dihedral_table.html,
"table/cut"_dihedral_table_cut.html :tb(c=4,ea=c)
@ -112,13 +117,16 @@ OPT.
"none"_improper_none.html,
"zero"_improper_zero.html,
"hybrid"_improper_hybrid.html :tb(c=3,ea=c)
"hybrid"_improper_hybrid.html :tb(c=3,ea=c)
"class2 (ko)"_improper_class2.html,
"cossq (o)"_improper_cossq.html,
"cvff (io)"_improper_cvff.html,
"distance"_improper_distance.html,
"distharm"_improper_distharm.html,
"fourier (o)"_improper_fourier.html,
"harmonic (iko)"_improper_harmonic.html,
"inversion/harmonic"_improper_inversion_harmonic.html,
"ring (o)"_improper_ring.html,
"sqdistharm"_improper_sqdistharm.html,
"umbrella (o)"_improper_umbrella.html :tb(c=4,ea=c)

View File

@ -10,10 +10,9 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
Commands by category :h3
This page lists most of the LAMMPS commands, grouped by category. The
"Commands all"_Commands_all.html doc page lists all commands
alphabetically. It also includes long lists of style options for
entries that appear in the following categories as a single command
(fix, compute, pair, etc).
"General commands"_Commands_all.html doc page lists all general commands
alphabetically. Style options for entries like fix, compute, pair etc.
have their own pages where they are listed alphabetically.
Initialization:
@ -117,6 +116,7 @@ Actions:
"minimize"_minimize.html,
"neb"_neb.html,
"neb_spin"_neb_spin.html,
"prd"_prd.html,
"rerun"_rerun.html,
"run"_run.html,

View File

@ -7,7 +7,7 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
:line
"All commands"_Commands_all.html,
"General commands"_Commands_all.html,
"Fix styles"_Commands_fix.html,
"Compute styles"_Commands_compute.html,
"Pair styles"_Commands_pair.html,
@ -25,6 +25,7 @@ additional letters in parenthesis: g = GPU, i = USER-INTEL, k =
KOKKOS, o = USER-OMP, t = OPT.
"ackland/atom"_compute_ackland_atom.html,
"adf"_compute_adf.html,
"aggregate/atom"_compute_cluster_atom.html,
"angle"_compute_angle.html,
"angle/local"_compute_angle_local.html,
@ -35,6 +36,7 @@ KOKKOS, o = USER-OMP, t = OPT.
"bond/local"_compute_bond_local.html,
"centro/atom"_compute_centro_atom.html,
"chunk/atom"_compute_chunk_atom.html,
"chunk/spread/atom"_compute_chunk_spread_atom.html,
"cluster/atom"_compute_cluster_atom.html,
"cna/atom"_compute_cna_atom.html,
"cnp/atom"_compute_cnp_atom.html,
@ -91,12 +93,15 @@ KOKKOS, o = USER-OMP, t = OPT.
"pe/tally"_compute_tally.html,
"plasticity/atom"_compute_plasticity_atom.html,
"pressure"_compute_pressure.html,
"pressure/cylinder"_compute_pressure_cylinder.html,
"pressure/uef"_compute_pressure_uef.html,
"property/atom"_compute_property_atom.html,
"property/chunk"_compute_property_chunk.html,
"property/local"_compute_property_local.html,
"ptm/atom"_compute_ptm_atom.html,
"rdf"_compute_rdf.html,
"reduce"_compute_reduce.html,
"reduce/chunk"_compute_reduce_chunk.html,
"reduce/region"_compute_reduce.html,
"rigid/local"_compute_rigid_local.html,
"saed"_compute_saed.html,
@ -115,7 +120,7 @@ KOKKOS, o = USER-OMP, t = OPT.
"smd/tlsph/strain"_compute_smd_tlsph_strain.html,
"smd/tlsph/strain/rate"_compute_smd_tlsph_strain_rate.html,
"smd/tlsph/stress"_compute_smd_tlsph_stress.html,
"smd/triangle/mesh/vertices"_compute_smd_triangle_mesh_vertices.html,
"smd/triangle/vertices"_compute_smd_triangle_vertices.html,
"smd/ulsph/num/neighs"_compute_smd_ulsph_num_neighs.html,
"smd/ulsph/strain"_compute_smd_ulsph_strain.html,
"smd/ulsph/strain/rate"_compute_smd_ulsph_strain_rate.html,
@ -126,6 +131,8 @@ KOKKOS, o = USER-OMP, t = OPT.
"snav/atom"_compute_sna_atom.html,
"spin"_compute_spin.html,
"stress/atom"_compute_stress_atom.html,
"stress/mop"_compute_stress_mop.html,
"stress/mop/profile"_compute_stress_mop.html,
"stress/tally"_compute_tally.html,
"tdpd/cc/atom"_compute_tdpd_cc_atom.html,
"temp (k)"_compute_temp.html,
@ -133,6 +140,7 @@ KOKKOS, o = USER-OMP, t = OPT.
"temp/body"_compute_temp_body.html,
"temp/chunk"_compute_temp_chunk.html,
"temp/com"_compute_temp_com.html,
"temp/cs"_compute_temp_cs.html,
"temp/deform"_compute_temp_deform.html,
"temp/deform/eff"_compute_temp_deform_eff.html,
"temp/drude"_compute_temp_drude.html,

View File

@ -7,7 +7,7 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
:line
"All commands"_Commands_all.html,
"General commands"_Commands_all.html,
"Fix styles"_Commands_fix.html,
"Compute styles"_Commands_compute.html,
"Pair styles"_Commands_pair.html,
@ -40,11 +40,13 @@ OPT.
"ave/time"_fix_ave_time.html,
"aveforce"_fix_aveforce.html,
"balance"_fix_balance.html,
"bocs"_fix_bocs.html,
"bond/break"_fix_bond_break.html,
"bond/create"_fix_bond_create.html,
"bond/react"_fix_bond_react.html,
"bond/swap"_fix_bond_swap.html,
"box/relax"_fix_box_relax.html,
"client/md"_fix_client_md.html,
"cmap"_fix_cmap.html,
"colvars"_fix_colvars.html,
"controller"_fix_controller.html,
@ -54,27 +56,31 @@ OPT.
"drag"_fix_drag.html,
"drude"_fix_drude.html,
"drude/transform/direct"_fix_drude_transform.html,
"drude/transform/reverse"_fix_drude_transform.html,
"drude/transform/inverse"_fix_drude_transform.html,
"dt/reset"_fix_dt_reset.html,
"edpd/source"_fix_dpd_source.html,
"efield"_fix_efield.html,
"ehex"_fix_ehex.html,
"electron/stopping"_fix_electron_stopping.html,
"enforce2d (k)"_fix_enforce2d.html,
"eos/cv"_fix_eos_cv.html,
"eos/table"_fix_eos_table.html,
"eos/table/rx (k)"_fix_eos_table_rx.html,
"evaporate"_fix_evaporate.html,
"external"_fix_external.html,
"ffl"_fix_ffl.html,
"filter/corotate"_fix_filter_corotate.html,
"flow/gauss"_fix_flow_gauss.html,
"freeze"_fix_freeze.html,
"freeze (k)"_fix_freeze.html,
"gcmc"_fix_gcmc.html,
"gld"_fix_gld.html,
"gle"_fix_gle.html,
"gravity (o)"_fix_gravity.html,
"gravity (ko)"_fix_gravity.html,
"grem"_fix_grem.html,
"halt"_fix_halt.html,
"heat"_fix_heat.html,
"hyper/global"_fix_hyper_global.html,
"hyper/local"_fix_hyper_local.html,
"imd"_fix_imd.html,
"indent"_fix_indent.html,
"ipi"_fix_ipi.html,
@ -91,6 +97,7 @@ OPT.
"lineforce"_fix_lineforce.html,
"manifoldforce"_fix_manifoldforce.html,
"meso"_fix_meso.html,
"meso/move"_fix_meso_move.html,
"meso/stationary"_fix_meso_stationary.html,
"momentum (k)"_fix_momentum.html,
"move"_fix_move.html,
@ -100,21 +107,23 @@ OPT.
"mvv/edpd"_fix_mvv_dpd.html,
"mvv/tdpd"_fix_mvv_dpd.html,
"neb"_fix_neb.html,
"neb_spin"_fix_neb_spin.html,
"nph (ko)"_fix_nh.html,
"nph/asphere (o)"_fix_nph_asphere.html,
"nph/body"_fix_nph_body.html,
"nph/eff"_fix_nh_eff.html,
"nph/sphere (o)"_fix_nph_sphere.html,
"nphug (o)"_fix_nphug.html,
"npt (kio)"_fix_nh.html,
"npt (iko)"_fix_nh.html,
"npt/asphere (o)"_fix_npt_asphere.html,
"npt/body"_fix_npt_body.html,
"npt/eff"_fix_nh_eff.html,
"npt/sphere (o)"_fix_npt_sphere.html,
"npt/uef"_fix_nh_uef.html,
"nve (kio)"_fix_nve.html,
"nve (iko)"_fix_nve.html,
"nve/asphere (i)"_fix_nve_asphere.html,
"nve/asphere/noforce"_fix_nve_asphere_noforce.html,
"nve/awpmd"_fix_nve_awpmd.html,
"nve/body"_fix_nve_body.html,
"nve/dot"_fix_nve_dot.html,
"nve/dotc/langevin"_fix_nve_dotc_langevin.html,
@ -123,7 +132,7 @@ OPT.
"nve/line"_fix_nve_line.html,
"nve/manifold/rattle"_fix_nve_manifold_rattle.html,
"nve/noforce"_fix_nve_noforce.html,
"nve/sphere (o)"_fix_nve_sphere.html,
"nve/sphere (ko)"_fix_nve_sphere.html,
"nve/spin"_fix_nve_spin.html,
"nve/tri"_fix_nve_tri.html,
"nvk"_fix_nvk.html,
@ -142,6 +151,7 @@ OPT.
"phonon"_fix_phonon.html,
"pimd"_fix_pimd.html,
"planeforce"_fix_planeforce.html,
"plumed"_fix_plumed.html,
"poems"_fix_poems.html,
"pour"_fix_pour.html,
"precession/spin"_fix_precession_spin.html,
@ -161,34 +171,34 @@ OPT.
"qmmm"_fix_qmmm.html,
"qtb"_fix_qtb.html,
"rattle"_fix_shake.html,
"reax/bonds"_fix_reax_bonds.html,
"reax/c/bonds (k)"_fix_reax_bonds.html,
"reax/c/bonds (k)"_fix_reaxc_bonds.html,
"reax/c/species (k)"_fix_reaxc_species.html,
"recenter"_fix_recenter.html,
"restrain"_fix_restrain.html,
"rhok"_fix_rhok.html,
"rigid (o)"_fix_rigid.html,
"rigid/meso"_fix_rigid_meso.html,
"rigid/nph (o)"_fix_rigid.html,
"rigid/nph/small"_fix_rigid.html,
"rigid/npt (o)"_fix_rigid.html,
"rigid/npt/small"_fix_rigid.html,
"rigid/nve (o)"_fix_rigid.html,
"rigid/nve/small"_fix_rigid.html,
"rigid/nvt (o)"_fix_rigid.html,
"rigid/nvt/small"_fix_rigid.html,
"rigid/small (o)"_fix_rigid.html,
"rigid/small/nph"_fix_rigid.html,
"rigid/small/npt"_fix_rigid.html,
"rigid/small/nve"_fix_rigid.html,
"rigid/small/nvt"_fix_rigid.html,
"rx (k)"_fix_rx.html,
"saed/vtk"_fix_saed_vtk.html,
"setforce (k)"_fix_setforce.html,
"shake"_fix_shake.html,
"shardlow (k)"_fix_shardlow.html,
"smd"_fix_smd.html,
"smd/adjust/dt"_fix_smd_adjust_dt.html,
"smd/integrate/tlsph"_fix_smd_integrate_tlsph.html,
"smd/integrate/ulsph"_fix_smd_integrate_ulsph.html,
"smd/move/triangulated/surface"_fix_smd_move_triangulated_surface.html,
"smd/adjust_dt"_fix_smd_adjust_dt.html,
"smd/integrate_tlsph"_fix_smd_integrate_tlsph.html,
"smd/integrate_ulsph"_fix_smd_integrate_ulsph.html,
"smd/move_tri_surf"_fix_smd_move_triangulated_surface.html,
"smd/setvel"_fix_smd_setvel.html,
"smd/wall/surface"_fix_smd_wall_surface.html,
"smd/wall_surface"_fix_smd_wall_surface.html,
"spring"_fix_spring.html,
"spring/chunk"_fix_spring_chunk.html,
"spring/rg"_fix_spring_rg.html,
@ -226,4 +236,4 @@ OPT.
"wall/reflect (k)"_fix_wall_reflect.html,
"wall/region"_fix_wall_region.html,
"wall/region/ees"_fix_wall_ees.html,
"wall/srd"_fix_wall_srd.html :tb(c=8,ea=c)
"wall/srd"_fix_wall_srd.html :tb(c=6,ea=c)

View File

@ -7,7 +7,7 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
:line
"All commands"_Commands_all.html,
"General commands"_Commands_all.html,
"Fix styles"_Commands_fix.html,
"Compute styles"_Commands_compute.html,
"Pair styles"_Commands_pair.html,
@ -33,4 +33,5 @@ OPT.
"pppm/disp (i)"_kspace_style.html,
"pppm/disp/tip4p"_kspace_style.html,
"pppm/stagger"_kspace_style.html,
"pppm/tip4p (o)"_kspace_style.html :tb(c=4,ea=c)
"pppm/tip4p (o)"_kspace_style.html,
"scafacos"_kspace_style.html :tb(c=4,ea=c)

View File

@ -7,7 +7,7 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
:line
"All commands"_Commands_all.html,
"General commands"_Commands_all.html,
"Fix styles"_Commands_fix.html,
"Compute styles"_Commands_compute.html,
"Pair styles"_Commands_pair.html,
@ -26,13 +26,14 @@ OPT.
"none"_pair_none.html,
"zero"_pair_zero.html,
"hybrid"_pair_hybrid.html,
"hybrid (k)"_pair_hybrid.html,
"hybrid/overlay (k)"_pair_hybrid.html :tb(c=4,ea=c)
"adp (o)"_pair_adp.html,
"agni (o)"_pair_agni.html,
"airebo (oi)"_pair_airebo.html,
"airebo/morse (oi)"_pair_airebo.html,
"airebo (io)"_pair_airebo.html,
"airebo/morse (io)"_pair_airebo.html,
"atm"_pair_atm.html,
"awpmd/cut"_pair_awpmd.html,
"beck (go)"_pair_beck.html,
"body/nparticle"_pair_body_nparticle.html,
@ -41,45 +42,50 @@ OPT.
"bop"_pair_bop.html,
"born (go)"_pair_born.html,
"born/coul/dsf"_pair_born.html,
"born/coul/dsf/cs"_pair_born.html,
"born/coul/dsf/cs"_pair_cs.html,
"born/coul/long (go)"_pair_born.html,
"born/coul/long/cs"_pair_born.html,
"born/coul/long/cs (g)"_pair_cs.html,
"born/coul/msm (o)"_pair_born.html,
"born/coul/wolf (go)"_pair_born.html,
"born/coul/wolf/cs"_pair_born.html,
"born/coul/wolf/cs (g)"_pair_cs.html,
"brownian (o)"_pair_brownian.html,
"brownian/poly (o)"_pair_brownian.html,
"buck (giko)"_pair_buck.html,
"buck/coul/cut (giko)"_pair_buck.html,
"buck/coul/long (giko)"_pair_buck.html,
"buck/coul/long/cs"_pair_buck.html,
"buck/coul/long/cs"_pair_cs.html,
"buck/coul/msm (o)"_pair_buck.html,
"buck/long/coul/long (o)"_pair_buck_long.html,
"buck/mdf"_pair_mdf.html,
"buck6d/coul/gauss/dsf"_pair_buck6d_coul_gauss.html,
"buck6d/coul/gauss/long"_pair_buck6d_coul_gauss.html,
"colloid (go)"_pair_colloid.html,
"comb (o)"_pair_comb.html,
"comb3"_pair_comb.html,
"coul/cut (gko)"_pair_coul.html,
"coul/cut/soft (o)"_pair_lj_soft.html,
"coul/cut/soft (o)"_pair_fep_soft.html,
"coul/debye (gko)"_pair_coul.html,
"coul/diel (o)"_pair_coul_diel.html,
"coul/dsf (gko)"_pair_coul.html,
"coul/long (gko)"_pair_coul.html,
"coul/long/cs"_pair_coul.html,
"coul/long/soft (o)"_pair_lj_soft.html,
"coul/msm"_pair_coul.html,
"coul/long/cs (g)"_pair_cs.html,
"coul/long/soft (o)"_pair_fep_soft.html,
"coul/msm (o)"_pair_coul.html,
"coul/shield"_pair_coul_shield.html,
"coul/streitz"_pair_coul.html,
"coul/wolf (ko)"_pair_coul.html,
"coul/wolf/cs"_pair_coul.html,
"coul/wolf/cs"_pair_cs.html,
"dpd (gio)"_pair_dpd.html,
"dpd/fdt"_pair_dpd_fdt.html,
"dpd/fdt/energy (k)"_pair_dpd_fdt.html,
"dpd/tstat (go)"_pair_dpd.html,
"dsmc"_pair_dsmc.html,
"e3b"_pair_e3b.html,
"drip"_pair_drip.html,
"eam (gikot)"_pair_eam.html,
"eam/alloy (gikot)"_pair_eam.html,
"eam/cd (o)"_pair_eam.html,
"eam/cd/old (o)"_pair_eam.html,
"eam/fs (gikot)"_pair_eam.html,
"edip (o)"_pair_edip.html,
"edip/multi"_pair_edip.html,
@ -89,11 +95,12 @@ OPT.
"exp6/rx (k)"_pair_exp6_rx.html,
"extep"_pair_extep.html,
"gauss (go)"_pair_gauss.html,
"gauss/cut"_pair_gauss.html,
"gauss/cut (o)"_pair_gauss.html,
"gayberne (gio)"_pair_gayberne.html,
"gran/hertz/history (o)"_pair_gran.html,
"gran/hooke (o)"_pair_gran.html,
"gran/hooke/history (o)"_pair_gran.html,
"gran/hooke/history (ko)"_pair_gran.html,
"granular"_pair_granular.html,
"gw"_pair_gw.html,
"gw/zbl"_pair_gw.html,
"hbond/dreiding/lj (o)"_pair_hbond_dreiding.html,
@ -103,50 +110,57 @@ OPT.
"kolmogorov/crespi/full"_pair_kolmogorov_crespi_full.html,
"kolmogorov/crespi/z"_pair_kolmogorov_crespi_z.html,
"lcbop"_pair_lcbop.html,
"lebedeva/z"_pair_lebedeva_z.html,
"lennard/mdf"_pair_mdf.html,
"line/lj"_pair_line_lj.html,
"list"_pair_list.html,
"lj/charmm/coul/charmm (iko)"_pair_charmm.html,
"lj/charmm/coul/charmm/implicit (ko)"_pair_charmm.html,
"lj/charmm/coul/long (giko)"_pair_charmm.html,
"lj/charmm/coul/long/soft (o)"_pair_charmm.html,
"lj/charmm/coul/msm"_pair_charmm.html,
"lj/charmm/coul/long (gikot)"_pair_charmm.html,
"lj/charmm/coul/long/soft (o)"_pair_fep_soft.html,
"lj/charmm/coul/msm (o)"_pair_charmm.html,
"lj/charmmfsw/coul/charmmfsh"_pair_charmm.html,
"lj/charmmfsw/coul/long"_pair_charmm.html,
"lj/class2 (gko)"_pair_class2.html,
"lj/class2/coul/cut (ko)"_pair_class2.html,
"lj/class2/coul/cut/soft"_pair_fep_soft.html,
"lj/class2/coul/long (gko)"_pair_class2.html,
"lj/class2/coul/long/soft"_pair_fep_soft.html,
"lj/class2/soft"_pair_fep_soft.html,
"lj/cubic (go)"_pair_lj_cubic.html,
"lj/cut (gikot)"_pair_lj.html,
"lj/cut/coul/cut (gko)"_pair_lj.html,
"lj/cut/coul/cut/soft (o)"_pair_lj_soft.html,
"lj/cut/coul/cut/soft (o)"_pair_fep_soft.html,
"lj/cut/coul/debye (gko)"_pair_lj.html,
"lj/cut/coul/dsf (gko)"_pair_lj.html,
"lj/cut/coul/long (gikot)"_pair_lj.html,
"lj/cut/coul/long/cs"_pair_lj.html,
"lj/cut/coul/long/soft (o)"_pair_lj_soft.html,
"lj/cut/coul/long/cs"_pair_cs.html,
"lj/cut/coul/long/soft (o)"_pair_fep_soft.html,
"lj/cut/coul/msm (go)"_pair_lj.html,
"lj/cut/coul/wolf (o)"_pair_lj.html,
"lj/cut/dipole/cut (go)"_pair_dipole.html,
"lj/cut/dipole/long"_pair_dipole.html,
"lj/cut/dipole/long (g)"_pair_dipole.html,
"lj/cut/dipole/sf (go)"_pair_dipole.html,
"lj/cut/soft (o)"_pair_lj_soft.html,
"lj/cut/soft (o)"_pair_fep_soft.html,
"lj/cut/thole/long (o)"_pair_thole.html,
"lj/cut/tip4p/cut (o)"_pair_lj.html,
"lj/cut/tip4p/long (ot)"_pair_lj.html,
"lj/cut/tip4p/long/soft (o)"_pair_lj_soft.html,
"lj/cut/tip4p/long/soft (o)"_pair_fep_soft.html,
"lj/expand (gko)"_pair_lj_expand.html,
"lj/expand/coul/long (g)"_pair_lj_expand.html,
"lj/gromacs (gko)"_pair_gromacs.html,
"lj/gromacs/coul/gromacs (ko)"_pair_gromacs.html,
"lj/long/coul/long (io)"_pair_lj_long.html,
"lj/long/coul/long (iot)"_pair_lj_long.html,
"lj/long/dipole/long"_pair_dipole.html,
"lj/long/tip4p/long"_pair_lj_long.html,
"lj/long/tip4p/long (o)"_pair_lj_long.html,
"lj/mdf"_pair_mdf.html,
"lj/sdk (gko)"_pair_sdk.html,
"lj/sdk/coul/long (go)"_pair_sdk.html,
"lj/sdk/coul/msm (o)"_pair_sdk.html,
"lj/sf/dipole/sf (go)"_pair_dipole.html,
"lj/smooth (o)"_pair_lj_smooth.html,
"lj/smooth/linear (o)"_pair_lj_smooth_linear.html,
"lj/switch3/coulgauss/long"_pair_lj_switch3_coulgauss.html,
"lj96/cut (go)"_pair_lj96.html,
"lubricate (o)"_pair_lubricate.html,
"lubricate/poly (o)"_pair_lubricate.html,
@ -154,19 +168,18 @@ OPT.
"lubricateU/poly"_pair_lubricateU.html,
"mdpd"_pair_meso.html,
"mdpd/rhosum"_pair_meso.html,
"meam"_pair_meam.html,
"meam/c"_pair_meam.html,
"meam/c"_pair_meamc.html,
"meam/spline (o)"_pair_meam_spline.html,
"meam/sw/spline"_pair_meam_sw_spline.html,
"mgpt"_pair_mgpt.html,
"mie/cut (o)"_pair_mie.html,
"mie/cut (g)"_pair_mie.html,
"momb"_pair_momb.html,
"morse (gkot)"_pair_morse.html,
"morse/smooth/linear"_pair_morse.html,
"morse/soft"_pair_morse.html,
"morse/smooth/linear (o)"_pair_morse.html,
"morse/soft"_pair_fep_soft.html,
"multi/lucy"_pair_multi_lucy.html,
"multi/lucy/rx (k)"_pair_multi_lucy_rx.html,
"nb3b/harmonic (o)"_pair_nb3b_harmonic.html,
"nb3b/harmonic"_pair_nb3b_harmonic.html,
"nm/cut (o)"_pair_nm.html,
"nm/cut/coul/cut (o)"_pair_nm.html,
"nm/cut/coul/long (o)"_pair_nm.html,
@ -178,7 +191,9 @@ OPT.
"oxdna2/coaxstk"_pair_oxdna2.html,
"oxdna2/dh"_pair_oxdna2.html,
"oxdna2/excv"_pair_oxdna2.html,
"oxdna2/hbond"_pair_oxdna2.html,
"oxdna2/stk"_pair_oxdna2.html,
"oxdna2/xstk"_pair_oxdna2.html,
"peri/eps"_pair_peri.html,
"peri/lps (o)"_pair_peri.html,
"peri/pmb (o)"_pair_peri.html,
@ -186,13 +201,13 @@ OPT.
"polymorphic"_pair_polymorphic.html,
"python"_pair_python.html,
"quip"_pair_quip.html,
"reax"_pair_reax.html,
"reax/c (ko)"_pair_reaxc.html,
"rebo (oi)"_pair_airebo.html,
"rebo (io)"_pair_airebo.html,
"resquared (go)"_pair_resquared.html,
"sdpd/taitwater/isothermal"_pair_sdpd_taitwater_isothermal.html,
"smd/hertz"_pair_smd_hertz.html,
"smd/tlsph"_pair_smd_tlsph.html,
"smd/triangulated/surface"_pair_smd_triangulated_surface.html,
"smd/tri_surface"_pair_smd_triangulated_surface.html,
"smd/ulsph"_pair_smd_ulsph.html,
"smtbq"_pair_smtbq.html,
"snap (k)"_pair_snap.html,
@ -221,11 +236,11 @@ OPT.
"thole"_pair_thole.html,
"tip4p/cut (o)"_pair_coul.html,
"tip4p/long (o)"_pair_coul.html,
"tip4p/long/soft (o)"_pair_lj_soft.html,
"tip4p/long/soft (o)"_pair_fep_soft.html,
"tri/lj"_pair_tri_lj.html,
"ufm (got)"_pair_ufm.html,
"vashishta (ko)"_pair_vashishta.html,
"vashishta (gko)"_pair_vashishta.html,
"vashishta/table (o)"_pair_vashishta.html,
"yukawa (gok)"_pair_yukawa.html,
"yukawa (gko)"_pair_yukawa.html,
"yukawa/colloid (go)"_pair_yukawa_colloid.html,
"zbl (gok)"_pair_zbl.html :tb(c=4,ea=c)
"zbl (gko)"_pair_zbl.html :tb(c=4,ea=c)

View File

@ -14,7 +14,7 @@ LAMMPS commands are case sensitive. Command names are lower-case, as
are specified command arguments. Upper case letters may be used in
file names or user-chosen ID strings.
Here are 6 rulse for how each line in the input script is parsed by
Here are 6 rules for how each line in the input script is parsed by
LAMMPS:
(1) If the last printable character on the line is a "&" character,
@ -71,7 +71,7 @@ floating-point value. The format string is used to output the result
of the variable expression evaluation. If a format string is not
specified a high-precision "%.20g" is used as the default.
This can be useful for formatting print output to a desired precion:
This can be useful for formatting print output to a desired precision:
print "Final energy per atom: $(pe/atoms:%10.3f) eV/atom" :pre
@ -91,7 +91,7 @@ See the "variable"_variable.html command for more details of how
strings are assigned to variables and evaluated, and how they can be
used in input script commands.
(4) The line is broken into "words" separated by whitespace (tabs,
(4) The line is broken into "words" separated by white-space (tabs,
spaces). Note that words can thus contain letters, digits,
underscores, or punctuation characters.

3
doc/src/Developer/.gitignore vendored Normal file
View File

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

View File

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

BIN
doc/src/Eqs/angle_cross.jpg Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 7.8 KiB

View File

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

BIN
doc/src/Eqs/angle_mm3.jpg Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 9.0 KiB

View File

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

BIN
doc/src/Eqs/bond_mm3.jpg Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 5.7 KiB

9
doc/src/Eqs/bond_mm3.tex Normal file
View File

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

BIN
doc/src/Eqs/e3b.jpg Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 28 KiB

15
doc/src/Eqs/e3b.tex Normal file
View File

@ -0,0 +1,15 @@
\documentclass[12pt]{article}
\usepackage{amsmath}
\begin{document}
\begin{align*}
E =& E_2 \sum_{i,j}e^{-k_2 r_{ij}} + E_A \sum_{\substack{i,j,k,\ell \\\in \textrm{type A}}} f(r_{ij})f(r_{k\ell}) + E_B \sum_{\substack{i,j,k,\ell \\\in \textrm{type B}}} f(r_{ij})f(r_{k\ell}) + E_C \sum_{\substack{i,j,k,\ell \\\in \textrm{type C}}} f(r_{ij})f(r_{k\ell}) \\
f(r) =& e^{-k_3 r}s(r) \\
s(r) =& \begin{cases}
1 & r<R_s \\
\displaystyle\frac{(R_f-r)^2(R_f-3R_s+2r)}{(R_f-R_s)^3} & R_s\leq r\leq R_f \\
0 & r>R_f\\
\end{cases}
\end{align*}
\end{document}

Binary file not shown.

After

Width:  |  Height:  |  Size: 25 KiB

View File

@ -0,0 +1,21 @@
\documentclass[preview]{standalone}
\usepackage{varwidth}
\usepackage[utf8x]{inputenc}
\usepackage{amsmath,amssymb,amsthm,bm}
\begin{document}
\begin{varwidth}{50in}
\begin{equation}
\bm{H}_{cubic} = -\sum_{{ i}=1}^{N} K_{1}
\Big[
\left(\vec{s}_{i} \cdot \vec{n1} \right)^2
\left(\vec{s}_{i} \cdot \vec{n2} \right)^2 +
\left(\vec{s}_{i} \cdot \vec{n2} \right)^2
\left(\vec{s}_{i} \cdot \vec{n3} \right)^2 +
\left(\vec{s}_{i} \cdot \vec{n1} \right)^2
\left(\vec{s}_{i} \cdot \vec{n3} \right)^2 \Big]
+K_{2}^{(c)} \left(\vec{s}_{i} \cdot \vec{n1} \right)^2
\left(\vec{s}_{i} \cdot \vec{n2} \right)^2
\left(\vec{s}_{i} \cdot \vec{n3} \right)^2 \nonumber
\end{equation}
\end{varwidth}
\end{document}

Binary file not shown.

After

Width:  |  Height:  |  Size: 2.1 KiB

View File

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

Binary file not shown.

After

Width:  |  Height:  |  Size: 2.2 KiB

View File

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

Binary file not shown.

After

Width:  |  Height:  |  Size: 6.9 KiB

View File

@ -0,0 +1,13 @@
\documentclass[preview]{standalone}
\usepackage{varwidth}
\usepackage[utf8x]{inputenc}
\usepackage{amsmath, amssymb, graphics, setspace}
\begin{document}
\begin{varwidth}{50in}
\begin{equation}
\frac{d \vec{s}_{i}}{dt} = \lambda\, \vec{s}_{i} \times\left( \vec{\omega}_{i} \times\vec{s}_{i} \right)
\nonumber
\end{equation}
\end{varwidth}
\end{document}

Binary file not shown.

After

Width:  |  Height:  |  Size: 5.8 KiB

View File

@ -0,0 +1,14 @@
\documentclass[preview]{standalone}
\usepackage{varwidth}
\usepackage[utf8x]{inputenc}
\usepackage{amsmath, amssymb, graphics, setspace}
\begin{document}
\begin{varwidth}{50in}
\begin{equation}
{\Delta t}_{\rm max} = \frac{2\pi}{\kappa
\left|\vec{\omega}_{\rm max} \right|}
\nonumber
\end{equation}
\end{varwidth}
\end{document}

Binary file not shown.

After

Width:  |  Height:  |  Size: 9.4 KiB

View File

@ -0,0 +1,15 @@
\documentclass[preview]{standalone}
\usepackage{varwidth}
\usepackage[utf8x]{inputenc}
\usepackage{amsmath, amssymb, graphics, setspace}
\begin{document}
\begin{varwidth}{50in}
\begin{equation}
\omega_i^{\nu} =
(\nu - 1) \Delta \omega_i
{\rm ~~and~~} \Delta \omega_i = \frac{\omega_i}{Q-1}
, \nonumber
\end{equation}
\end{varwidth}
\end{document}

BIN
doc/src/Eqs/neb_spin_k.jpg Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 8.2 KiB

View File

@ -0,0 +1,16 @@
\documentclass[preview]{standalone}
\usepackage{varwidth}
\usepackage[utf8x]{inputenc}
\usepackage{amsmath, amssymb, graphics, setspace}
\begin{document}
\begin{varwidth}{50in}
\begin{equation}
\vec{k}_i =
\frac{\vec{m}_i^I \times \vec{m}_i^F}{\left|\vec{m}_i^I
\times \vec{m}_i^F\right|}
%&{\rm ~if~}& \vec{m}_i^I \times \vec{m}_i^F
, \nonumber
\end{equation}
\end{varwidth}
\end{document}

Binary file not shown.

After

Width:  |  Height:  |  Size: 20 KiB

View File

@ -0,0 +1,16 @@
\documentclass[preview]{standalone}
\usepackage{varwidth}
\usepackage[utf8x]{inputenc}
\usepackage{amsmath, amssymb, graphics, setspace}
\begin{document}
\begin{varwidth}{50in}
\begin{equation}
\vec{m}_i^{\nu} = \vec{m}_i^{I} \cos(\omega_i^{\nu})
+ (\vec{k}_i \times \vec{m}_i^{I}) \sin(\omega_i^{\nu})
+ (1.0-\cos(\omega_i^{\nu})) \vec{k}_i (\vec{k}_i\cdot
\vec{m}_i^{I})
, \nonumber
\end{equation}
\end{varwidth}
\end{document}

BIN
doc/src/Eqs/pair_atm.jpg Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 5.3 KiB

9
doc/src/Eqs/pair_atm.tex Normal file
View File

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

Binary file not shown.

After

Width:  |  Height:  |  Size: 4.5 KiB

View File

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

BIN
doc/src/Eqs/pair_drip.jpg Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 58 KiB

14
doc/src/Eqs/pair_drip.tex Normal file
View File

@ -0,0 +1,14 @@
\documentclass[12pt]{article}
\usepackage{amsmath}
\usepackage{bm}
\begin{document}
\begin{eqnarray*}
E &=& \frac{1}{2} \sum_{i} \sum_{j\notin\text{layer}\,i} \phi_{ij} \\\phi_{ij} &=& f_\text{c}(x_r) \left[ e^{-\lambda(r_{ij} - z_0 )} \left[C+f(\rho_{ij})+ g(\rho_{ij}, \{\alpha_{ij}^{(m)}\}) \right]- A\left (\frac{z_0}{r_{ij}} \right)^6 \right] \\
\end{eqnarray*}
\end{document}

Binary file not shown.

After

Width:  |  Height:  |  Size: 30 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 3.6 KiB

View File

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

Binary file not shown.

Before

Width:  |  Height:  |  Size: 2.4 KiB

After

Width:  |  Height:  |  Size: 2.5 KiB

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