With this alias it is possible to transparently refer to either the
real imported MPI library or to the MPI stub library. this further
reduced the need for if statements related to MPI. Some uses of
MPI::MPI_CXX remain but they are all in branches of the script code
where BUILD_MPI is enabled and thus the imported target will be present.
this is to work around the situation that windows
has no equivalent to LD_LIBRARY_PATH (short of augmenting %PATH%,
which is tricky for CMake before 3.20)
With the introduction of LAMMPS_UPDATE, version.h is no longer a single line
file. With this change the CMake utility will only process the LAMMPS_VERSION
line. Fixes issue #3038
With the introduction of LAMMPS_UPDATE, version.h is no longer a single line
file. With this change the CMake utility will only process the LAMMPS_VERSION
line. Fixes issue #3038
Adds an optional "tags" entry in the force style test YAML. This is a
comma-separated list of keywords, which are parsed by CMake and added as labels
for CTest. This allows more fine-grained filtering of tests. Any
newly-generated YAML file automatically adds the "generated" tag.
* hbond comm added for rsq_hb
* lrefpos removed, extract scaled for oxDNA1
* Update pair_oxdna_hbond.cpp
* nxyz extract scaled across DNA2/RNA2
* oxDNA2/RNA2 updated to match oxDNA styling from upstream merge
* whitespace corrections
also removed unnecessary local unit vector from oxRNA2_xstk
* whitespace correction in oxdna_coaxstk
using this mechanism we can reject custom section names that will
conflict with existing section names and thus avoid misleading errors.
apply this also to fix property atom, where the section name is
determined by the fix ID.
in addition, allow to specify NULL as section name, which will use
the fix ID.
* use the term 'website' consistently (and not also 'web site')
* update for clang-format
* clarify
* split off the programming/submission style guide to a separate file
* Updates to support ROCm 4.3 in GPU package
* update and reorder the description of the process for submitting contributions
* correct and clarify Python compatibility
* refactor style guide and integrate text from issue
* update contribution guidelines for github
* mention when testing may be added
* integrate file with description of include file conventions
* update github workflow doc
* adapt section about domain decomposition from paper
* use a more compact image
* add communication section
* update man page with missing flags and correct URLs
* improve the load imbalance viz
* add section about neighbor list construction
* break large file into multiple smaller files by section and add toctree
* fix typo
* add section about parallelization in the OPENMP package
* add -skipruin to help message
* add discussion of OpenMP parallelization
* spelling
* add section on PPPM
* use larger version of FFT grid comm image
* minor tweak
* Update compute angle doc page
* Update Singularity definitions to use ROCm 4.3
* Update CUDA container definitions to CUDA 11.4
* Update container definitions to include PLUMED 2.7.2
* Update more definition files
* RHEL8/CentOS8 PowerTools is now powertools
* Add Rocky Linux 8 container definition
* Add omega field to numpy_wrapper detection
* Return None in case of null pointer
* Add more atom fields in numpy_wrapper and correct csforce size
* must not clear force array. will segfault in hybrid atom styles
* update example for dynamically loading LAMMPS with current library API
* update example to use current library interface. No need to use the namespace.
* add note to README files about age of the example
* simplify building shared libs on windows
* detect a few more compilers
* Revert "simplify building shared libs on windows"
This reverts commit fa3429ab02.
* step version strings for next patch release
* fix mingw 32-bit vs 64-bit craziness
* detect C++20 standard
* build "fat" cuda binaries only with known toolkits
* spelling
* Try to improve the pair style hybrid docs
This specifically tries to avoid the ambiguous use of "mixing" and
clarify that similar is still different when pair styles are concerned.
See discussion here: https://matsci.org/t/confusion-about-mixing-and-pair-coeff-section/38317/3
* spelling
* use nullptr
* use symbolic constant
* small optimization
* use cmath header instead of math.h
* use explicit scoping when virtual dispatch is not available.
* cosmetic changes
* simplify/optimize code
* simplify
* Bugfix from Trung for crashes in pppm/gpu without local atoms
* fix typo
* refer to "XXX Coeffs" sections consistently
* small tweaks from static code analysis
* fix small bug
* small tweaks
* simplify and modernize code a little
* use correct data type for MPI calls
* simplify/modernize
* remove dead code
* about 1.5x speedup for pair style comb3 by using MathSpecial::powint()
* small performance optimization for pair style comb
* simplify
* modernize
* simplify
* removed dead code, reformat
* modernize
* use explicit scoping when virtual dispatch is not (yet) available
* reformat for increased readability
* move misplaced #endif and make code more readable
* make sure err_flag is initialized
* modernize
* remove redundant code: all struct members are initialized to defaults in the constructor
* enforce initialization and thus silence compiler warnings
* fix typo
* provide more comprehensive suggestions for GPU neighbor list errors
* add utils::logical() function to complement the *numeric() functions
* Add stable link in docs
* revert modernization change (for now)
* remove unused variable
* include EXTRA-DUMP in "most"
* small tweaks
* simplify
* Add log file printing of KIM search directories in 'kim init'
* use clang-format on kim_init.cpp
* Improve style in response to Axel's suggestions
* initialize all members
* format changes
* simplify. use utils::strdup() more.
* small corrections
* apply fix from balance command to fix balance
* dead code removal
* reformat strings
* implement utils::current_date() convenience function to reduce replicated code
* update list and order of include files from include-what-you-use analysis
* handle changes in GAP repo
* a few remaining updates to include statements
* expand mapping to handle "style_*.h" header files correctly.
* add support for compilation of OpenCL loader on FreeBSD
* more iwyu header updates
* small correction
* fix typo
* a few more (final?) IWYU updates
* expand tests for numeric values
* return int instead of bool to minimize code changes
* fix spelling issues
* some applications of the new function
* fix typo
* Change "offsite" to "external" to correct broken URLs to lammps.org
* improve error message
* insert missing atom-ID
* convert yes/no on/off flags in the package command(s)
* update version strings
* update death tests for change in error message
* correctly specify the destructor function name.
* apply utils::logical() to more commands
* apply utils::logical() in more places
* for consistency with utils::logical()
* only accept lower case to be consistent with the rest of the input
* a few more converted commands and updates for unit tests
* modernize and fix some memory leaks
* adjust for compatibility with C++20 compilers
* do not downgrade C++ standard when adding the KOKKOS package
* undo "risky" C++20 related changes
* mention how to set the path to the fftw3_omp library
* correct paths to downloaded PACE package sources in lib
* Update CMake variable descriptions
* possible workaround for some GPU package neighbor list issue
* final chunk of changes to apply utils::logical()
* update suffix command unit tests
* update citation info with new LAMMPS paper reference and acknowledge it
* update some formulations as suggested by @sjplimp
* add check and suitable error message when fp64 is required but not available
* do not call memset on a null pointer
* fix string formatting bugs in fix npt/cauchy
* must use a soft core potential to avoid a singularity
* in floating point math a*b may be zero even if both a>0 and b>0
* use proper integer type for atom IDs
* Building voro++ lib as part of LAMMPS requires the "patch" program
* silence output from hwloc when launching LAMMPS
* detect double precision support according to OpenCL specs (1.2 and later)
* Fix bug in Kokkos pair_eam_alloy
* calling fwrite() with a null pointer causes undefined behavior. avoid it.
* cosmetic
* apply current include file conventions
* include zstd libs in windows build
* update .gitignore for recent additions
* make check more obvious
* step version strings for stable release
* Adjust for kim-api bug
* cleaner variant of version check, add directory numbering
* hbond comm added for rsq_hb
* rsq_hb removed, exyz added (no MPI comm yet)
* Fix Colvars output files not written with "run 0"
See:
https://github.com/Colvars/colvars/commit/ff2f0d39ee5
which fixes a bug introduced in:
https://github.com/Colvars/colvars/commit/1e964a542b
The message applies to NAMD, but the logic used in LAMMPS when handling "run 0" is very similar.
The Colvars version string is also updated, however this commit does not
include other changes, such as the following:
https://github.com/Colvars/colvars/pull/419
which were not fully completed before the LAMMPS Summer 2021 finalization.
* add -std=c++11 to a number of machine makefiles for traditional make build
* copy request to mention lammps.org form home page instructions for citing
* be more specific about what the name of the LAMMPS executable can be
also provide a few more examples without a machine suffix
* small tweak
* remove references to USER packages, have package lists alphabetically sorted
"make package-update" or "make pu" must be processed in the special order
because of inter-package dependencies
* make "make package-update" and "make package-overwrite" less verbose
* freeze versions of pip packages for processing the manual of the stable version
this way we avoid surprises in case one of the packages get updated
to an incompatible new version. these are know-to-work versions.
* make sure the one_coeff flag is applied to sub-styles
since the check for Pair::one_coeff was moved to the Input class (to
reduce redundant code), hybrid substyles could "escape" that requirement.
Thus checks have to be added to the hybrid coeff() methods.
* Prevent neigh list from copying "unique" stencil/bin
* compiling ML-HDNNP with downloaded n2p2 lib requires the sed command
* detect and error out if BLAS/LAPACK libraries variables are a list
This will cause external project compilation to fail since the semi-colons
are converted to blanks, but one cannot properly escape the variables.
So far the only viable solution seems to be to convert the scripts from
using ExternalProject_add() to FetchContent and add_subdirectory()
* portability improvement
* must have patch command available to compile ScaFaCoS
* only need Tcl not Tk to compile Tcl swig wrapper
* correctly handle Tcl stub library if available
* add missing keyword
* hbond_pos added, MPI and values ok, Pair time slow.
* make C library example work with strict C compilers
* silence compiler warnings
* make Nevery keyword per-reaction
* recover cross-compilation with mingw64
* reverted wrong approach from last commits
- now intpos flag
- hbond_pos added
- (a/b)xyz WiP
* lrefpos working in serial, MPI wrong
* attempt to merge doubles into n(xyz)[3]
* save
* Update pair_oxdna_hbond.cpp
* hbond now working for MPI, comming lrefpos
* extracting nxyz in excv/bond working
Co-authored-by: Axel Kohlmeyer <akohlmey@gmail.com>
Co-authored-by: Richard Berger <richard.berger@temple.edu>
Co-authored-by: Ryan S. Elliott <relliott@umn.edu>
Co-authored-by: Stan Gerald Moore <stamoor@sandia.gov>
Co-authored-by: Giacomo Fiorin <giacomo.fiorin@gmail.com>
Co-authored-by: Jacob Gissinger <jrgiss05@gmail.com>
Co-authored-by: Oliver Henrich <ohenrich@users.noreply.github.com>
This is for informative output only, so that any code depending
on the LAMMPS_VERSION define will not have to be changed and no
warnings will be printed etc.
* use the term 'website' consistently (and not also 'web site')
* update for clang-format
* clarify
* split off the programming/submission style guide to a separate file
* Updates to support ROCm 4.3 in GPU package
* update and reorder the description of the process for submitting contributions
* correct and clarify Python compatibility
* refactor style guide and integrate text from issue
* update contribution guidelines for github
* mention when testing may be added
* integrate file with description of include file conventions
* update github workflow doc
* adapt section about domain decomposition from paper
* use a more compact image
* add communication section
* update man page with missing flags and correct URLs
* improve the load imbalance viz
* add section about neighbor list construction
* break large file into multiple smaller files by section and add toctree
* fix typo
* add section about parallelization in the OPENMP package
* add -skipruin to help message
* add discussion of OpenMP parallelization
* spelling
* add section on PPPM
* use larger version of FFT grid comm image
* minor tweak
* Update compute angle doc page
* Update Singularity definitions to use ROCm 4.3
* Update CUDA container definitions to CUDA 11.4
* Update container definitions to include PLUMED 2.7.2
* Update more definition files
* RHEL8/CentOS8 PowerTools is now powertools
* Add Rocky Linux 8 container definition
* Add omega field to numpy_wrapper detection
* Return None in case of null pointer
* Add more atom fields in numpy_wrapper and correct csforce size
* must not clear force array. will segfault in hybrid atom styles
* update example for dynamically loading LAMMPS with current library API
* update example to use current library interface. No need to use the namespace.
* add note to README files about age of the example
* simplify building shared libs on windows
* detect a few more compilers
* Revert "simplify building shared libs on windows"
This reverts commit fa3429ab02.
* step version strings for next patch release
* fix mingw 32-bit vs 64-bit craziness
* detect C++20 standard
* build "fat" cuda binaries only with known toolkits
* spelling
* Try to improve the pair style hybrid docs
This specifically tries to avoid the ambiguous use of "mixing" and
clarify that similar is still different when pair styles are concerned.
See discussion here: https://matsci.org/t/confusion-about-mixing-and-pair-coeff-section/38317/3
* spelling
* use nullptr
* use symbolic constant
* small optimization
* use cmath header instead of math.h
* use explicit scoping when virtual dispatch is not available.
* cosmetic changes
* simplify/optimize code
* simplify
* Bugfix from Trung for crashes in pppm/gpu without local atoms
* fix typo
* refer to "XXX Coeffs" sections consistently
* small tweaks from static code analysis
* fix small bug
* small tweaks
* simplify and modernize code a little
* use correct data type for MPI calls
* simplify/modernize
* remove dead code
* about 1.5x speedup for pair style comb3 by using MathSpecial::powint()
* small performance optimization for pair style comb
* simplify
* modernize
* simplify
* removed dead code, reformat
* modernize
* use explicit scoping when virtual dispatch is not (yet) available
* reformat for increased readability
* move misplaced #endif and make code more readable
* make sure err_flag is initialized
* modernize
* remove redundant code: all struct members are initialized to defaults in the constructor
* enforce initialization and thus silence compiler warnings
* fix typo
* provide more comprehensive suggestions for GPU neighbor list errors
* add utils::logical() function to complement the *numeric() functions
* Add stable link in docs
* revert modernization change (for now)
* remove unused variable
* include EXTRA-DUMP in "most"
* small tweaks
* simplify
* Add log file printing of KIM search directories in 'kim init'
* use clang-format on kim_init.cpp
* Improve style in response to Axel's suggestions
* initialize all members
* format changes
* simplify. use utils::strdup() more.
* small corrections
* apply fix from balance command to fix balance
* dead code removal
* reformat strings
* implement utils::current_date() convenience function to reduce replicated code
* update list and order of include files from include-what-you-use analysis
* handle changes in GAP repo
* a few remaining updates to include statements
* expand mapping to handle "style_*.h" header files correctly.
* add support for compilation of OpenCL loader on FreeBSD
* more iwyu header updates
* small correction
* fix typo
* a few more (final?) IWYU updates
* expand tests for numeric values
* return int instead of bool to minimize code changes
* fix spelling issues
* some applications of the new function
* fix typo
* Change "offsite" to "external" to correct broken URLs to lammps.org
* improve error message
* insert missing atom-ID
* convert yes/no on/off flags in the package command(s)
* update version strings
* update death tests for change in error message
* correctly specify the destructor function name.
* apply utils::logical() to more commands
* apply utils::logical() in more places
* for consistency with utils::logical()
* only accept lower case to be consistent with the rest of the input
* a few more converted commands and updates for unit tests
* modernize and fix some memory leaks
* adjust for compatibility with C++20 compilers
* do not downgrade C++ standard when adding the KOKKOS package
* undo "risky" C++20 related changes
* mention how to set the path to the fftw3_omp library
* correct paths to downloaded PACE package sources in lib
* Update CMake variable descriptions
* possible workaround for some GPU package neighbor list issue
* final chunk of changes to apply utils::logical()
* update suffix command unit tests
* update citation info with new LAMMPS paper reference and acknowledge it
* update some formulations as suggested by @sjplimp
* add check and suitable error message when fp64 is required but not available
* do not call memset on a null pointer
* fix string formatting bugs in fix npt/cauchy
* must use a soft core potential to avoid a singularity
* in floating point math a*b may be zero even if both a>0 and b>0
* use proper integer type for atom IDs
* Building voro++ lib as part of LAMMPS requires the "patch" program
* silence output from hwloc when launching LAMMPS
* detect double precision support according to OpenCL specs (1.2 and later)
* Fix bug in Kokkos pair_eam_alloy
* calling fwrite() with a null pointer causes undefined behavior. avoid it.
* cosmetic
* apply current include file conventions
* include zstd libs in windows build
* update .gitignore for recent additions
* make check more obvious
* step version strings for stable release
* Adjust for kim-api bug
* cleaner variant of version check, add directory numbering
* hbond comm added for rsq_hb
* rsq_hb removed, exyz added (no MPI comm yet)
* Fix Colvars output files not written with "run 0"
See:
https://github.com/Colvars/colvars/commit/ff2f0d39ee5
which fixes a bug introduced in:
https://github.com/Colvars/colvars/commit/1e964a542b
The message applies to NAMD, but the logic used in LAMMPS when handling "run 0" is very similar.
The Colvars version string is also updated, however this commit does not
include other changes, such as the following:
https://github.com/Colvars/colvars/pull/419
which were not fully completed before the LAMMPS Summer 2021 finalization.
* add -std=c++11 to a number of machine makefiles for traditional make build
* copy request to mention lammps.org form home page instructions for citing
* be more specific about what the name of the LAMMPS executable can be
also provide a few more examples without a machine suffix
* small tweak
* remove references to USER packages, have package lists alphabetically sorted
"make package-update" or "make pu" must be processed in the special order
because of inter-package dependencies
* make "make package-update" and "make package-overwrite" less verbose
* freeze versions of pip packages for processing the manual of the stable version
this way we avoid surprises in case one of the packages get updated
to an incompatible new version. these are know-to-work versions.
* make sure the one_coeff flag is applied to sub-styles
since the check for Pair::one_coeff was moved to the Input class (to
reduce redundant code), hybrid substyles could "escape" that requirement.
Thus checks have to be added to the hybrid coeff() methods.
* Prevent neigh list from copying "unique" stencil/bin
* compiling ML-HDNNP with downloaded n2p2 lib requires the sed command
* detect and error out if BLAS/LAPACK libraries variables are a list
This will cause external project compilation to fail since the semi-colons
are converted to blanks, but one cannot properly escape the variables.
So far the only viable solution seems to be to convert the scripts from
using ExternalProject_add() to FetchContent and add_subdirectory()
* portability improvement
* must have patch command available to compile ScaFaCoS
* only need Tcl not Tk to compile Tcl swig wrapper
* correctly handle Tcl stub library if available
* add missing keyword
* hbond_pos added, MPI and values ok, Pair time slow.
* make C library example work with strict C compilers
* silence compiler warnings
* make Nevery keyword per-reaction
* recover cross-compilation with mingw64
* reverted wrong approach from last commits
- now intpos flag
- hbond_pos added
- (a/b)xyz WiP
* lrefpos working in serial, MPI wrong
* attempt to merge doubles into n(xyz)[3]
* save
* Update pair_oxdna_hbond.cpp
* hbond now working for MPI, comming lrefpos
Co-authored-by: Axel Kohlmeyer <akohlmey@gmail.com>
Co-authored-by: Richard Berger <richard.berger@temple.edu>
Co-authored-by: Ryan S. Elliott <relliott@umn.edu>
Co-authored-by: Stan Gerald Moore <stamoor@sandia.gov>
Co-authored-by: Giacomo Fiorin <giacomo.fiorin@gmail.com>
Co-authored-by: Jacob Gissinger <jrgiss05@gmail.com>
- brief description should not end in a dot as it becomes a title line
- add empty line to separate title from body of description
- revert order of file/path separator constants so that the Linux version shows up in doxygen
This will cause external project compilation to fail since the semi-colons
are converted to blanks, but one cannot properly escape the variables.
So far the only viable solution seems to be to convert the scripts from
using ExternalProject_add() to FetchContent and add_subdirectory()
since the check for Pair::one_coeff was moved to the Input class (to
reduce redundant code), hybrid substyles could "escape" that requirement.
Thus checks have to be added to the hybrid coeff() methods.
this addresses some (cross) compilation issues locally.
in the long run, this should be addressed by implementing issue #1884
where platform specific functionality is wrapped into a small library
of generic functions adapted for LAMMPS' needs (like utils:: does for
non-portable convenience functions).
this is done by
- not automatically calling Py_Finalize() when destructing a python interpreter
- adding wrapper functions so that the call to Py_Finalize() is hidden
and skipped if Python support is no included.
- call the Python::finalize() wrapper in main.cpp (similar to the equivalent Kokkos function)
- add a wrapper of that call to the C library interface
the fixes atom/swap, gcmc, widom, and charge_regulation would call
Modify::end_of_step() in order to make certain that all energy contributions
to the total energy are properly tallied. However, this is no longer
true and it causes lots of unexpected problems, since fixes like
fix ave/time, fix store/state, fix print and many more are called at
the wrong time during a timestep and possibly multiple times which can
lead to very unexpected and incorrect results. fix atc and fix colvars
are currently the only fixes that signal that they contribute to the
global energy *and* run during Modify::end_of_step(). However, they
do not perform any actions related to the global energy in those calls.
This fix should probably be considered a temporary fix - it relies on a
3-dimensional Kokkos range which seems to be disfavoured in the rest of
LAMMPS' codebase.
this changes the computation of "next_reneighbor" so that it is based
on "nfirst" which is set during the constructor of the class.
This still maintains the property that the first deposit attempt is not
done during setup, but on the next step.
The gyration_tensor[4] element as computed by "compute gyration" corresponds to the xz component of the gyration tensor and the gyration_tensor[5] to the yz component. The code assumed that gyration_tensor[4] corresponds to the yz component and the gyration_tensor[5] to the xz.
- add a "warn no/yes" keyword/value pair to allow turning of the convergence warning
- add a scalar compute to retrieve the number of QEq itration from the fix
- update the buck example input to run all QEq methods from a common restart
- document changes
make behavior handling the maximum number of iterations consistent
across USER-REAXC, USER-OMP and KOKKOS package variants so that
they all give the same results for the same number of iterations
in serial and parallel
@ -5,8 +5,9 @@ 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 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](https://lammps.sandia.gov/doc/Modify_contribute.html)
* [The LAMMPS GitHub Tutorial in the Manual](http://lammps.sandia.gov/doc/Howto_github.html)
* [The guide for submitting new features in the LAMMPS manual](https://lammps.sandia.gov/doc/Modify_contribute.html)
* [The guide on programming style and requirement in the LAMMPS manual](https://lammps.sandia.gov/doc/Modify_contribute.html)
* [The GitHub tutorial in the LAMMPS manual](http://lammps.sandia.gov/doc/Howto_github.html)
## Table of Contents
@ -26,11 +27,11 @@ __
## 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 either the ['lammps-users' mailing list](https://lammps.sandia.gov/mail.html) or the [LAMMPS Material Science Discourse forum](https://matsci.org/lammps). 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. The LAMMPS forum was recently created as part of a larger effort to build a materials science community and have discussions not just about using LAMMPS. Thus the forum may be also used for discussions that would be off-topic for the mailing list. Those will just have to be moved to a more general category.
> **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 either the ['lammps-users' mailing list](https://lammps.sandia.gov/mail.html) or the [LAMMPS Material Science Discourse forum](https://matsci.org/lammps). 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. The LAMMPS forum was recently created as part of a larger effort to build a materials science community and have discussions not just about using LAMMPS. Thus the forum may be also used for discussions that would be off-topic for the mailing list. Those will just have to be posted to a more general category.
## 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 or posting in the LAMMPS Materials Science Discourse forum), and you can contribute by submitting pull requests on GitHub or e-mail your code
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 or the forum, you can report bugs or suggest enhancements by creating issues on GitHub (or posting them to the lammps-users mailing list or posting in the LAMMPS Materials Science Discourse forum), and you can contribute by submitting pull requests on GitHub or e-mail your code
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
@ -62,37 +63,12 @@ To be able to submit an issue on GitHub, you have to register for an account (fo
### Contributing Code
We encourage users to submit new features or modifications for LAMMPS to the core developers so they can be added to the LAMMPS distribution. The preferred way to manage and coordinate this is by submitting a pull request at the LAMMPS project on GitHub. For any larger modifications or programming project, you are encouraged to contact the LAMMPS developers ahead of time, in order to discuss implementation strategies and coding guidelines, that will make it easier to integrate your contribution and result in less work for everybody involved. You are also encouraged to search through the list of open issues on GitHub and submit a new issue for a planned feature, so you would not duplicate the work of others (and possibly get scooped by them) or have your work duplicated by others.
We encourage users to submit new features or modifications for LAMMPS. Instructions, guidelines, requirements,
and recommendations are in the following sections of the LAMMPS manual:
* [The guide for submitting new features in the LAMMPS manual](https://lammps.sandia.gov/doc/Modify_contribute.html)
* [The guide on programming style and requirement in the LAMMPS manual](https://lammps.sandia.gov/doc/Modify_contribute.html)
* [The GitHub tutorial in the LAMMPS manual](http://lammps.sandia.gov/doc/Howto_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.
* C++ source code must be compatible with the C++-11 standard. Packages may require a later standard, if justified.
* 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 trailing whitespace, 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, 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.
* Source, style name, and documentation file should follow the following naming convention: style names should be lowercase and words separated by a forward slash; for a new fix style 'foo/bar', the class should be named FixFooBar, the name of the source files should be 'fix_foo_bar.h' and 'fix_foo_bar.cpp' and the corresponding documentation should be in a file 'fix_foo_bar.rst'.
* 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 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 FOO directory.
* Your new source files need to have the LAMMPS copyright, GPL notice, and your name and email address at the top, like other user-contributed LAMMPS source files. They need to create a class that is inside the LAMMPS namespace. If the file is for one of the USER packages, including USER-MISC, then we are not as picky about the coding style (see above). I.e. the files do not need to be in the same stylistic format and syntax as other LAMMPS files, though that would be nice for developers as well as users who try to read your code.
* You **must** also create or extend a documentation file for each new command or style you are adding to LAMMPS. For simplicity and convenience, the documentation of groups of closely related commands or styles may be combined into a single file. This will be one file for a single-file feature. For a package, it might be several files. These are files in the [reStructuredText](https://docutils.sourceforge.io/rst.html) markup language, that are then converted to HTML and PDF. The tools for this conversion are included in the source distribution, and the translation can be as simple as doing "make html pdf" in the doc folder. Thus the documentation source files must be in the same format and style as other `<name>.rst` files in the lammps/doc/src directory for similar commands and styles; use one or more of them as a starting point. An introduction to reStructuredText can be found at [https://docutils.sourceforge.io/docs/user/rst/quickstart.html](https://docutils.sourceforge.io/docs/user/rst/quickstart.html). The text files can include mathematical expressions and symbol in ".. math::" sections or ":math:" expressions or figures (see doc/JPG for examples), or even additional PDF files with further details (see doc/PDF for examples). The doc page should also include literature citations as appropriate; see the bottom of doc/fix_nh.rst for examples and the earlier part of the same file for how to format the cite itself. The "Restrictions" section of the doc page should indicate that your command is only available if LAMMPS is built with the appropriate USER-MISC or FOO package. See other user package doc files for examples of how to do this. The prerequisite for building the HTML format files are Python 3.x and virtualenv. Please run at least `make html`, `make pdf` and `make spelling` and carefully inspect and proofread the resulting HTML format doc page as well as the output produced to the screen. Make sure that all spelling errors are fixed or the necessary false positives are added to the `doc/utils/sphinx-config/false_positives.txt` file. For new styles, those usually also need to be added to lists on the respective overview pages. This can be checked for also with `make style_check`.
* For a new package (or even a single command) you should include one or more example scripts demonstrating its use. These should run in no more than a couple minutes, even on a single processor, and not require large data files as input. See directories under examples/PACKAGES for examples of input scripts other users provided for their packages. These example inputs are also required for validating memory accesses and testing for memory leaks with valgrind
* For new utility functions or class (i.e. anything that does not depend on a LAMMPS object), new unit tests should be added to the unittest tree.
* When adding a new LAMMPS style, a .yaml file with a test configuration and reference data should be added for the styles where a suitable tester program already exists (e.g. pair styles, bond styles, etc.).
* If there is a paper of yours describing your feature (either the algorithm/science behind the feature itself, or its initial usage, or its implementation in LAMMPS), you can add the citation to the <name>.cpp source file. See src/EFF/atom_vec_electron.cpp for an example. A LaTeX citation is stored in a variable at the top of the file and a single line of code that references the variable is added to the constructor of the class. Whenever a user invokes your feature from their input script, this will cause LAMMPS to output the citation to a log.cite file and prompt the user to examine the file. Note that you should only use this for a paper you or your group authored. E.g. adding a cite in the code for a paper by Nose and Hoover if you write a fix that implements their integrator is not the intended usage. That kind of citation should just be in the doc page you provide.
Finally, as a general rule-of-thumb, the more clear and self-explanatory you make your documentation and README files, and the easier you make it for people to get started, e.g. by providing example scripts, the more likely it is that users will try out your new feature.
If the new features/files are broadly useful we may add them as core files to LAMMPS or as part of a standard package. Else we will add them as a user-contributed file or package. Examples of user packages are in src sub-directories that start with USER. The USER-MISC package is simply a collection of (mostly) unrelated single files, which is the simplest way to have your contribution quickly added to the LAMMPS distribution. You can see a list of the both standard and user packages by typing "make package" in the LAMMPS src directory.
Note that by providing us files to release, you are agreeing to make them open-source, i.e. we can release them under the terms of the GPL, used as a license for the rest of LAMMPS. See Section 1.4 for details.
With user packages and files, all we are really providing (aside from the fame and fortune that accompanies having your name in the source code and on the Authors page of the LAMMPS WWW site), is a means for you to distribute your work to the LAMMPS user community, and a mechanism for others to easily try out your new feature. This may help you find bugs or make contact with new collaborators. Note that you are also implicitly agreeing to support your code which means answer questions, fix bugs, and maintain it if LAMMPS changes in some way that breaks it (an unusual event).
To be able to submit an issue on GitHub, you have to register for an account (for GitHub in general). If you do not want to do that, or have other reservations or difficulties to submit a pull request, you can - as an alternative - contact one or more of the core LAMMPS developers and ask if one of them would be interested in manually merging your code into LAMMPS and send them your source code. Since the effort to merge a pull request is a small fraction of the effort of integrating source code manually (which would usually be done by converting the contribution into a pull request), your chances to have your new code included quickly are the best with a pull request.
If you prefer to submit patches or full files, you should first make certain, that your code works correctly with the latest patch-level version of LAMMPS and contains all bug fixes from it. Then create a gzipped tar file of all changed or added files or a corresponding patch file using 'diff -u' or 'diff -c' and compress it with gzip. Please only use gzip compression, as this works well on all platforms.
## GitHub Workflows
@ -102,17 +78,17 @@ This section briefly summarizes the steps that will happen **after** you have su
After submitting an issue, one or more of the LAMMPS developers will review it and categorize it by assigning labels. Confirmed bug reports will be labeled `bug`; if the bug report also contains a suggestion for how to fix it, it will be labeled `bugfix`; if the issue is a feature request, it will be labeled `enhancement`. Other labels may be attached as well, depending on which parts of the LAMMPS code are affected. If the assessment is, that the issue does not warrant any changes, the `wontfix` label will be applied and if the submission is incorrect or something that should not be submitted as an issue, the `invalid` label will be applied. In both of the last two cases, the issue will then be closed without further action.
For feature requests, what happens next is that developers may comment on the viability or relevance of the request, discuss and make suggestions for how to implement it. If a LAMMPS developer or user is planning to implement the feature, the issue will be assigned to that developer. For developers, that are not yet listed as LAMMPS project collaborators, they will receive an invitation to be added to the LAMMPS project as a collaborator so they can get assigned. If the requested feature or enhancement is implemented, it will usually be submitted as a pull request, which will contain a reference to the issue number. And once the pull request is reviewed and accepted for inclusion into LAMMPS, the issue will be closed. For details on how pull requests are processed, please see below.
For feature requests, what happens next is that developers may comment on the viability or relevance of the request, discuss and make suggestions for how to implement it. If a LAMMPS developer or user is planning to implement the feature, the issue will be assigned to that developer. For developers, that are not yet listed as LAMMPS project collaborators, they will receive an invitation to be added to the LAMMPS project as a collaborator so they can get assigned. If the requested feature or enhancement is implemented, it will be submitted as a pull request, which will contain a reference to the issue number. And once the pull request is reviewed and accepted for inclusion into LAMMPS, the issue will be closed. For details on how pull requests are processed, please see below. Feature requests may be labeled with `volunteer_needed` if none of the LAMMPS developers has the time and the required knowledge implement the feature.
For bug reports, the next step is that one of the core LAMMPS developers will self-assign to the issue and try to confirm the bug. If confirmed, the `bug` label and potentially other labels are added to classify the issue and its impact to LAMMPS. Before confirming, further questions may be asked or requests for providing additional input files or details about the steps required to reproduce the issue. Any bugfix is likely to be submitted as a pull request (more about that below) and since most bugs require only local changes, the bugfix may be included in a pull request specifically set up to collect such local bugfixes or small enhancements. Once the bugfix is included in the master branch, the issue will be closed.
For bug reports, the next step is that one of the core LAMMPS developers will self-assign to the issue and try to confirm the bug. If confirmed, the `bug` label and potentially other labels are added to classify the issue and its impact to LAMMPS. Otherwise the `unconfirmed` label will be applied and some comment about what was tried to confirm the bug added. Before confirming, further questions may be asked or requests for providing additional input files or details about the steps required to reproduce the issue. Any bugfix will be submitted as a pull request (more about that below) and since most bugs require only local changes, the bugfix may be included in a pull request specifically set up to collect such local bugfixes or small enhancements. Once the bugfix is included in the master branch, the issue will be closed.
### Pull Requests
For submitting pull requests, there is a [detailed tutorial](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. As part of the assessment, 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).
Pull requests are the **only** way that changes get made to the LAMMPS distribution. So also the LAMMPS core developers will submit pull requests for their own changes and discuss them on GitHub. Thus if you submit a pull request it will be treated in a similar fashion. When you submit a pull request you may opt to submit a "Draft" pull request. That means your changes are visible and will be subject to testing, but reviewers will not be (auto-)assigned and comments will take into account that this is not complete. On the other hand, this is a perfect way to ask the LAMMPS developers for comments on non-obvious changes and get feedback and possible suggestions for improvements or recommendations about what to avoid.
Immediately after the submission, the LAMMPS continuing integration server at ci.lammps.org will download your submitted branch and perform a number of tests: it will tests whether it compiles cleanly under various conditions, it will also do a check on whether your included documentation translates cleanly and run some unit tests and other checks. 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 time the pull request is updated with a push to the remote branch on GitHub. If you are unsure about what you need to change, ask a question in the discussion area of the pull request.
Next a LAMMPS core developer will self-assign and do an overall technical assessment of the submission. If you submitted a draft pull request, this will not happen unless you mark it "ready for review". If you are not yet invited as a LAMMPS collaborator, and your contribution seems significant, you may also receive an invitation for collaboration on the LAMMPS repository. As part of the assessment, 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 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.
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. The minimum requirement to merge a pull request is that all automated tests have to pass and at least one LAMMPS developer has approved integrating the submitted code. Since the approver will not be the person merging a pull request, you will have at least two LAMMPS developers that looked at your contribution.
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.
A.\ Calhoun, M. Pavese, G. Voth, Chem Phys Letters, 262, 415 (1996).
**(Campana)**
C.\ Campana and M. H. Muser, *Practical Green's function approach to the simulation of elastic semi-infinite solids*\ , `Phys. Rev. B [74], 075420 (2006) <https://doi.org/10.1103/PhysRevB.74.075420>`_
C.\ Campana and M. H. Muser, *Practical Green's function approach to the simulation of elastic semi-infinite solids*, `Phys. Rev. B [74], 075420 (2006) <https://doi.org/10.1103/PhysRevB.74.075420>`_
**(Cao1)**
J.\ Cao and B. Berne, J Chem Phys, 99, 2902 (1993).
Sabry G. Moustafa, Andrew J. Schultz, and David A. Kofke, *Very fast averaging of thermal properties of crystals by molecular simulation*\ , `Phys. Rev. E [92], 043303 (2015) <https://link.aps.org/doi/10.1103/PhysRevE.92.043303>`_
Sabry G. Moustafa, Andrew J. Schultz, and David A. Kofke, *Very fast averaging of thermal properties of crystals by molecular simulation*, `Phys. Rev. E [92], 043303 (2015) <https://link.aps.org/doi/10.1103/PhysRevE.92.043303>`_
**(Muller-Plathe1)**
Muller-Plathe, J Chem Phys, 106, 6082 (1997).
@ -1123,9 +1123,12 @@ Bibliography
**(Sun)**
Sun, J. Phys. Chem. B, 102, 7338-7364 (1998).
**(Surblys)**
**(Surblys2019)**
Surblys, Matsubara, Kikugawa, Ohara, Phys Rev E, 99, 051301(R) (2019).
@ -31,36 +31,36 @@ This is the list of packages that may require additional steps.
..table_from_list::
:columns:6
*:ref:`COMPRESS <compress>`
*:ref:`GPU <gpu>`
*:ref:`KIM <kim>`
*:ref:`KOKKOS <kokkos>`
*:ref:`LATTE <latte>`
*:ref:`MESSAGE <message>`
*:ref:`ML-IAP <mliap>`
*:ref:`MSCG <mscg>`
*:ref:`OPT <opt>`
*:ref:`POEMS <poems>`
*:ref:`PYTHON <python>`
*:ref:`VORONOI <voronoi>`
*:ref:`ADIOS <adios>`
*:ref:`ATC <atc>`
*:ref:`AWPMD <awpmd>`
*:ref:`COLVARS <colvars>`
*:ref:`COMPRESS <compress>`
*:ref:`GPU <gpu>`
*:ref:`H5MD <h5md>`
*:ref:`ML-HDNNP <ml-hdnnp>`
*:ref:`INTEL <intel>`
*:ref:`KIM <kim>`
*:ref:`KOKKOS <kokkos>`
*:ref:`LATTE <latte>`
*:ref:`MACHDYN <machdyn>`
*:ref:`MDI <mdi>`
*:ref:`MESONT <mesont>`
*:ref:`MOLFILE <molfile>`
*:ref:`NETCDF <netcdf>`
*:ref:`MESSAGE <message>`
*:ref:`ML-HDNNP <ml-hdnnp>`
*:ref:`ML-IAP <mliap>`
*:ref:`ML-PACE <ml-pace>`
*:ref:`PLUMED <plumed>`
*:ref:`OPENMP <openmp>`
*:ref:`QMMM <qmmm>`
*:ref:`ML-QUIP <ml-quip>`
*:ref:`MOLFILE <molfile>`
*:ref:`MSCG <mscg>`
*:ref:`NETCDF <netcdf>`
*:ref:`OPENMP <openmp>`
*:ref:`OPT <opt>`
*:ref:`PLUMED <plumed>`
*:ref:`POEMS <poems>`
*:ref:`PYTHON <python>`
*:ref:`QMMM <qmmm>`
*:ref:`SCAFACOS <scafacos>`
*:ref:`MACHDYN <machdyn>`
*:ref:`VORONOI <voronoi>`
*:ref:`VTK <vtk>`
----------
@ -74,7 +74,8 @@ To build with this package you must have the `zlib compression library
<https://zlib.net>`_ available on your system to build dump styles with
a '/gz' suffix. There are also styles using the
`Zstandard <https://facebook.github.io/zstd/>`_ library which have a
'/zstd' suffix.
'/zstd' suffix. The zstd library version must be at least 1.4. Older
versions use an incompatible API and thus LAMMPS will fail to compile.
..tabs::
@ -340,6 +341,18 @@ minutes to hours) to build. Of course you only need to do that once.)
$ make lib-kim args="-p /usr/local"# use an existing KIM API installation at the provided location
$ make lib-kim args="-p /usr/local -a EAM_Dynamo_Ackland_W__MO_141627196590_002"# ditto but add one model or driver
When using the "-b " option, the KIM library is built using its native
cmake build system. The ``lib/kim/Install.py`` script supports a
``CMAKE`` environment variable if the cmake executable is named other
than ``cmake`` on your system. Additional environment variables may be
provided on the command line for use by cmake. For example, to use the
``cmake3`` executable and tell it to use the gnu version 11 compilers
to build KIM, one could use the following command line.
..code-block::bash
$ CMAKE=cmake3 CXX=g++-11 CC=gcc-11 FC=gfortran-11 make lib-kim args="-b "# (re-)install KIM API lib using cmake3 and gnu v11 compilers with only example models
Settings for debugging OpenKIM web queries discussed below need to
be applied by adding them to the ``LMP_INC`` variable through
editing the ``Makefile.machine`` you are using. For example:
@ -559,11 +572,26 @@ They must be specified in uppercase.
* - VEGA908
- GPU
- AMD GPU MI100 GFX908
* - INTEL_GEN
* - VEGA90A
- GPU
- Intel GPUs Gen9+
- AMD GPU
* - INTEL_DG1
- GPU
- Intel Iris XeMAX GPU
* - INTEL_GEN9
- GPU
- Intel GPU Gen9
* - INTEL_GEN11
- GPU
- Intel GPU Gen11
* - INTEL_GEN12LP
- GPU
- Intel GPU Gen12LP
* - INTEL_XEHP
- GPU
- Intel GPUs Xe-HP
This list was last updated for version 3.4.1 of the Kokkos library.
This list was last updated for version 3.5.0 of the Kokkos library.
..tabs::
@ -1856,8 +1884,8 @@ ML-QUIP package
To build with this package, you must download and build the QUIP
library. It can be obtained from GitHub. For support of GAP
potentials, additional files with specific licensing conditions need
to be downloaded and configured. See step 1 and step 1.1 in the
``lib/quip/README`` file for details on how to do this.
to be downloaded and configured. The automatic download will from
within CMake will download the non-commercial use version.
..tabs::
@ -1865,11 +1893,14 @@ to be downloaded and configured. See step 1 and step 1.1 in the
..code-block::bash
-D DOWNLOAD_QUIP=value # download OpenKIM API v2 for build, value = no (default) or yes
-D QUIP_LIBRARY=path # path to libquip.a (only needed if a custom location)
CMake will **not** download and build the QUIP library. But once you have
done that, a CMake build of LAMMPS with ``-D PKG_ML-QUIP=yes`` should
work. Set the ``QUIP_LIBRARY`` variable if CMake cannot find the QUIP library.
CMake will try to download and build the QUIP library from GitHub, if it is not
found on the local machine. This requires to have git installed. It will use the same compilers
and flags as used for compiling LAMMPS. Currently this is only supported for the GNU and the
Intel compilers. Set the ``QUIP_LIBRARY`` variable if you want to use a previously compiled
and installed QUIP library and CMake cannot find it.
@ -91,7 +91,7 @@ DRUDE package) to convert a non-polarizable data file (here
This will automatically insert the new atoms and bonds.
The masses and charges of DCs and DPs are computed
from *phenol.dff*\ , as well as the DC-DP bond constants. The file
from *phenol.dff*, as well as the DC-DP bond constants. The file
*phenol.dff* contains the polarizabilities of the atom types
and the mass of the Drude particles, for instance:
@ -106,7 +106,7 @@ and the mass of the Drude particles, for instance:
The hydrogen atoms are absent from this file, so they will be treated
as non-polarizable atoms. In the non-polarizable data file
*data.102494.lmp*\ , atom names corresponding to the atom type numbers
*data.102494.lmp*, atom names corresponding to the atom type numbers
have to be specified as comments at the end of lines of the *Masses*
section. You probably need to edit it to add these names. It should
look like
@ -125,7 +125,7 @@ look like
**Basic input file**
The atom style should be set to (or derive from) *full*\ , so that you
The atom style should be set to (or derive from) *full*, so that you
can define atomic charges and molecular bonds, angles, dihedrals...
The *polarizer* tool also outputs certain lines related to the input
@ -143,7 +143,7 @@ and N for non-polarizable atoms. Here the atom types 1 to 3 (C and O
atoms) are DC, atom types 4 and 5 (H atoms) are non-polarizable and
the atom types 6 to 8 are the newly created DPs.
By recognizing the fix *drude*\ , LAMMPS will find and store matching
By recognizing the fix *drude*, LAMMPS will find and store matching
DC-DP pairs and will treat DP as equivalent to their DC in the
*special bonds* relations. It may be necessary to extend the space
for storing such special relations. In this case extra space should
@ -340,11 +340,11 @@ For the *thole* pair style the coefficients are
The special neighbors have charge-charge and charge-dipole
interactions screened by the *coul* factors of the *special_bonds*
command (0.0, 0.0, and 0.5 in the example above). Without using the
pair_style *thole*\ , dipole-dipole interactions are screened by the
same factor. By using the pair_style *thole*\ , dipole-dipole
pair_style *thole*, dipole-dipole interactions are screened by the
same factor. By using the pair_style *thole*, dipole-dipole
interactions are screened by Thole's function, whatever their special
relationship (except within each DC-DP pair of course). Consider for
example 1-2 neighbors: using the pair_style *thole*\ , their dipoles
example 1-2 neighbors: using the pair_style *thole*, their dipoles
will see each other (despite the *coul* factor being 0.) and the
interactions between these dipoles will be damped by Thole's function.
@ -384,7 +384,7 @@ For our phenol example, the groups would be defined as
group CORES type 1 2 3 # DCs
group DRUDES type 6 7 8 # DPs
Note that with the fixes *drude/transform*\ , it is not required to
Note that with the fixes *drude/transform*, it is not required to
specify *comm_modify vel yes* because the fixes do it anyway (several
times and for the forces also).
@ -491,11 +491,6 @@ NPT ensemble using Nose-Hoover thermostat:
**(Schroeder)** Schroeder and Steinhauser, J Chem Phys, 133,
154511 (2010).
.._Jiang2:
**(Jiang)** Jiang, Hardy, Phillips, MacKerell, Schulten, and Roux,
J Phys Chem Lett, 2, 87-92 (2011).
.._Thole2:
**(Thole)** Chem Phys, 59, 341 (1981).
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
