There was a logic error in the outside() function used by fix pour.
The previous implementation was essentially doing this:
outside = outside_pbc_range || outside_regular_range
It should have been:
outside = outside_pbc_range && outside_regular_range
print a warning if there are bonds/angles/dihedrals/impropers in the
bond topology, but no corresponding style defined.
print an additional warning when special bonds scaling factors
for this kind of interaction is not 1.0 and thus the neighbor list
for pair styles may be affected, too.
- modified min spin names (removed oso from spin/cg and spin/lbfgs)
- modified associated option name (from spin_oso_cg to spin/cg, same for
lbfgs)
- modified .gitignore, doc pages, and examples accordingly
- correct formula for tangent forces in style with no history in compute() and in single() functions
- remove tangent history update in the single() function
- implement correct output for tangent, normal and rolling forces in single() function
- correct typos in documentation
Modified PairGranular::single function to return the total normal force into argument fforce.
This was done for pair styles gran/* but not for the granular pari_style, resulting in the variable fforce being uninitialized.
- flatten directory structure
- remove CPU time and reduce excess precision from output
- delete redundant and unused files
- regenerate reference outputs
default to shared linkage on MacOSX to avoid linker issues from
configure/cmake library detection differences
link/depend on GSL and LAPACK explicitly only for static linkage
Fix bugs with CMake potentials and frc folder installation. Include base C++ headers for library install, too, so one can use the C++ interface as well.
- use MathSpecial::square(x) instead of pow(x,2) for improved precision
and handling of small and negative numbers
- remove unused include statements
- no need to refetch the compute in every step. during init() is sufficient
make so that for the "serial" make target we not only automatically build
the STUBS library, if it is missing, but also update its compilation when
there are changes and remove it on the "clean-serial" target.
This can be a scenario where the user has KIM installed but does not have the
environment setup correctly to be found. The config. step should provide some
warning of this. Otherwise, it is easy to miss the fact that KIM is being
downloaded and built.
the header lines are now checked using regular expressions
instead of strstr() which allows for stricter checking, but
also is more forgiving in terms of extra or different whitespace
return value of sscanf() calls is checked and on failure LAMMPS errors out
- added doc for read_data spin
- corrected an error in pack/unpack data hybrid
- added mask flags in fix_nve_spin::initial_integrate
- removed spin renormalization in min_spin (was causing a bug)
these new functions allow to choose between aborting with Error::one()
and exiting with Error::all(). in the long run those should replace
all of the functions in Force.
* CMake change to use KIM-API SimulatorModels branch
* Minimal changes to pair_kim to illustrate use of KIM API
interface. Only c++ interface is implemented for development.
* Added example input: in.kim.simulator-model
@ -68,7 +68,8 @@ How quickly your contribution will be integrated depends largely on how much eff
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, 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.
* 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, 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.txt'.
* 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.
set(LAMMPS_MEMALIGN"0"CACHESTRING"posix_memalign() is not available on Windows"FORCE)
else()
set(LAMMPS_MEMALIGN"64"CACHESTRING"enables the use of the posix_memalign() call instead of malloc() when large chunks or memory are allocated by LAMMPS. Set to 0 to disable")
message(WARNING"Unsuitable KIM-API version \"${KIM-API_VERSION}\"found,butrequiredisatleast\"${KIM-API_MIN_VERSION}\".Defaultbehaviorsettodownloadandbuildourown.")
<p>A pair style for the modified embedded atom (MEAM) potential.</p>
<p><strong>Please note that the MEAM package has been superseded by the USER-MEAMC package,
which is a direct translation of the MEAM package to C++. USER-MEAMC contains
additional optimizations making it run faster than MEAM on most machines, while
providing the identical features and USER interface.</strong></p>
</td>
<td>
<dl>
<dt><code>off</code> (default)</dt>
<dt><code>on</code></dt>
</dl>
</td>
</tr>
<tr>
<td><code>PKG_MISC</code></td>
<td>
@ -634,21 +641,6 @@ providing the identical features and USER interface.</strong></p>
</dl>
</td>
</tr>
<tr>
<td><code>PKG_REAX</code></td>
<td>
A pair style which wraps a Fortran library which implements the ReaxFF
potential, which is a universal reactive force field. See the USER-REAXC
package for an alternate implementation in C/C++. Also a fix reax/bonds
command for monitoring molecules as bonds are created and destroyed.
</td>
<td>
<dl>
<dt><code>off</code> (default)</dt>
<dt><code>on</code></dt>
</dl>
</td>
</tr>
<tr>
<td><code>PKG_REPLICA</code></td>
<td>
@ -695,6 +687,16 @@ providing the identical features and USER interface.</strong></p>
</dl>
</td>
</tr>
<tr>
<td><code>PKG_SPIN</code></td>
<td>Model atomic magnetic spins classically, coupled to atoms moving in the usual manner via MD. Various pair, fix, and compute styles.</td>
<td>
<dl>
<dt><code>off</code> (default)</dt>
<dt><code>on</code></dt>
</dl>
</td>
</tr>
<tr>
<td><code>PKG_SNAP</code></td>
<td>
@ -757,6 +759,16 @@ providing the identical features and USER interface.</strong></p>
</dl>
</td>
</tr>
<tr>
<td><code>PKG_MESSAGE</code></td>
<td>Commands to use LAMMPS as either a client or server and couple it to another application.</td>
<td>
<dl>
<dt><code>off</code> (default)</dt>
<dt><code>on</code></dt>
</dl>
</td>
</tr>
<tr>
<td><code>PKG_MSCG</code></td>
<td>
@ -811,6 +823,18 @@ providing the identical features and USER interface.</strong></p>
</dl>
</td>
</tr>
<tr>
<td><code>PKG_VORONOI</code></td>
<td>
A compute command which calculates the Voronoi tesselation of a collection of atoms by wrapping the Voro++ library. This can be used to calculate the local volume or each atoms or its near neighbors.
</td>
<td>
<dl>
<dt><code>off</code> (default)</dt>
<dt><code>on</code></dt>
</dl>
</td>
</tr>
</tbody>
</table>
@ -825,6 +849,16 @@ providing the identical features and USER interface.</strong></p>
</tr>
</thead>
<tbody>
<tr>
<td><code>PKG_USER-ADIOS</code></td>
<td>ADIOS is a high-performance I/O library. This package implements the dump “atom/adios” and dump “custom/adios” commands to write data using the ADIOS library.</td>
<td>
<dl>
<dt><code>off</code> (default)</dt>
<dt><code>on</code></dt>
</dl>
</td>
</tr>
<tr>
<td><code>PKG_USER-ATC</code></td>
<td>
@ -853,6 +887,18 @@ providing the identical features and USER interface.</strong></p>
</dl>
</td>
</tr>
<tr>
<td><code>PKG_USER-BOCS</code></td>
<td>
This package provides fix bocs, a modified version of fix npt which includes the pressure correction to the barostat as outlined in: N. J. H. Dunn and W. G. Noid, “Bottom-up coarse-grained models that accurately describe the structure, pressure, and compressibility of molecular liquids,” J. Chem. Phys. 143, 243148 (2015).
</td>
<td>
<dl>
<dt><code>off</code> (default)</dt>
<dt><code>on</code></dt>
</dl>
</td>
</tr>
<tr>
<td><code>PKG_USER-CGDNA</code></td>
<td>
@ -1142,6 +1188,30 @@ providing the identical features and USER interface.</strong></p>
</dl>
</td>
</tr>
<tr>
<td><code>PKG_USER-PLUMED</code></td>
<td>
The fix plumed command allows you to use the PLUMED free energy plugin for molecular dynamics to analyze and bias your LAMMPS trajectory on the fly. The PLUMED library is called from within the LAMMPS input script by using the <code>fix plumed</code> command.
</td>
<td>
<dl>
<dt><code>off</code> (default)</dt>
<dt><code>on</code></dt>
</dl>
</td>
</tr>
<tr>
<td><code>PKG_USER-PTM</code></td>
<td>
A <code>compute ptm/atom</code> command that calculates local structure characterization using the Polyhedral Template Matching methodology.
</td>
<td>
<dl>
<dt><code>off</code> (default)</dt>
<dt><code>on</code></dt>
</dl>
</td>
</tr>
<tr>
<td><code>PKG_USER-QTB</code></td>
<td>
@ -1197,6 +1267,33 @@ providing the identical features and USER interface.</strong></p>
</dl>
</td>
</tr>
<tr>
<td><code>PKG_USER-SCAFACOS</code></td>
<td>
A KSpace style which wraps the ScaFaCoS Coulomb solver library to compute long-range Coulombic interactions.
</td>
<td>
<dl>
<dt><code>off</code> (default)</dt>
<dt><code>on</code></dt>
</dl>
</td>
</tr>
<tr>
<td><code>PKG_USER-SDPD</code></td>
<td>
A pair style for smoothed dissipative particle dynamics (SDPD), which is an
extension of smoothed particle hydrodynamics (SPH) to mesoscale where thermal
fluctuations are important (see the USER-SPH package). Also two fixes for
moving and rigid body integration of SPH/SDPD particles (particles of
<code>atom_style meso</code>).</td>
<td>
<dl>
<dt><code>off</code> (default)</dt>
<dt><code>on</code></dt>
</dl>
</td>
</tr>
<tr>
<td><code>PKG_USER-SMD</code></td>
<td>
@ -1280,6 +1377,23 @@ providing the identical features and USER interface.</strong></p>
</dl>
</td>
</tr>
<tr>
<td><code>PKG_USER-YAFF</code></td>
<td>
Some potentials that are also implemented in the Yet Another Force Field (YAFF) code.
The expressions and their use are discussed in the following papers:
<ul>
<li><ahref="http://dx.doi.org/10.1002/jcc.23877"target="_blank">Vanduyfhuys et al., J. Comput. Chem., 36 (13), 1015-1027 (2015)</a></li>
<li><ahref="http://dx.doi.org/10.1002/jcc.25173"target="_blank">Vanduyfhuys et al., J. Comput. Chem., 39 (16), 999-1011 (2018)</a></li>
</ul>
</td>
<td>
<dl>
<dt><code>off</code> (default)</dt>
<dt><code>on</code></dt>
</dl>
</td>
</tr>
</tbody>
</table>
@ -1300,14 +1414,27 @@ providing the identical features and USER interface.</strong></p>
<td><code>FFT</code></td>
<td>
<p>FFT library for KSPACE package</p>
<p>If either MKL or FFTW is selected <code>cmake</code> will try to locate these libraries automatically. To control which one should be used please see the options below for each FFT library.</p>
<p>If either MKL or FFTW is selected <code>cmake</code> will try to locate
these libraries automatically. To control which one should be used please see
the options below for each FFT library. Otherwise it will default to KISS
FFT.</p>
</td>
<td>
<dl>
<dt><code>KISS</code></dt>
<dt><code>FFTW3</code></dt>
<dt><code>FFTW2</code></dt>
<dt><code>MKL</code></dt>
<dt><code>KISS</code> (default)</dt>
</dl>
</td>
</tr>
<tr>
<td><code>FFT_SINGLE</code></td>
<td>Use single-precision floating-point in FFT</td>
@ -1325,60 +1452,6 @@ providing the identical features and USER interface.</strong></p>
</tbody>
</table>
### MKL
<table>
<thead>
<tr>
<th>Option</th>
<th>Description</th>
<th>Values</th>
</tr>
</thead>
<tbody>
<tr>
<td><code>MKL_INCLUDE_DIRS</code></td>
<td></td>
<td>
</td>
</tr>
<tr>
<td><code>MKL_LIBRARIES</code></td>
<td></td>
<td>
</td>
</tr>
</tbody>
</table>
TODO static vs dynamic linking
### FFTW2
<table>
<thead>
<tr>
<th>Option</th>
<th>Description</th>
<th>Values</th>
</tr>
</thead>
<tbody>
<tr>
<td><code>FFTW2_INCLUDE_DIRS</code></td>
<td></td>
<td>
</td>
</tr>
<tr>
<td><code>FFTW2_LIBRARIES</code></td>
<td></td>
<td>
</td>
</tr>
</tbody>
</table>
### FFTW3
<table>
@ -1392,24 +1465,57 @@ TODO static vs dynamic linking
<tbody>
<tr>
<td><code>FFTW3_INCLUDE_DIRS</code></td>
<td></td>
<td>path to FFTW3 include files</td>
<td>
</td>
</tr>
<tr>
<td><code>FFTW3_LIBRARIES</code></td>
<td></td>
<td>list of paths to FFTW3 libraries</td>
<td>
</td>
</tr>
</tbody>
</table>
### MKL
<table>
<thead>
<tr>
<th>Option</th>
<th>Description</th>
<th>Values</th>
</tr>
</thead>
<tbody>
<tr>
<td><code>MKL_INCLUDE_DIRS</code></td>
<td>path to MKL include files</td>
<td>
</td>
</tr>
<tr>
<td><code>MKL_LIBRARIES</code></td>
<td>list of paths to MKL libraries</td>
<td>
</td>
</tr>
</tbody>
</table>
### BLAS
See [FindBLAS documentation](https://cmake.org/cmake/help/latest/module/FindBLAS.html)
### LAPACK
TODO
See [FindLAPACK documentation](https://cmake.org/cmake/help/latest/module/FindLAPACK.html)
### PYTHON Package
See [FindPYTHON documentation](https://cmake.org/cmake/help/latest/module/FindPython.html)
### USER-INTEL Package
<table>
@ -1499,10 +1605,11 @@ target API.
<td>
<dl>
<dt><code>sm_20</code> (Fermi)</dt>
<dt><code>sm_30</code> (Kepler)</dt>
<dt><code>sm_30</code> (Kepler) (default)</dt>
<dt><code>sm_50</code> (Maxwell)</dt>
<dt><code>sm_60</code> (Pascal)</dt>
<dt><code>sm_70</code> (Volta)</dt>
<dt><code>sm_75</code> (Turing)</dt>
</dl>
</td>
</tr>
@ -1534,13 +1641,14 @@ target API.
</tbody>
</table>
### VORONOI Package
### KIM Package
TODO
Requires installation of the KIM library with API v2
### USER-SMD Package
Requires a Eigen3 installation
If `DOWNLOAD_KIM` is set, the KIM library will be downloaded and built inside
the CMake build directory. If the KIM library is already on your system (in a
location CMake cannot find it), set the `PKG_CONFIG_PATH` environment variable
so that `libkim-api` can be found.
<table>
<thead>
@ -1551,9 +1659,349 @@ Requires a Eigen3 installation
</tr>
</thead>
<tbody>
<tr>
<td><code>DOWNLOAD_KIM</code></td>
<td>Download KIM API v2 and compile it as part of the build.</td>
<td>
<dl>
<dt><code>off</code> (default)</dt>
<dt><code>on</code></dt>
</dl>
</td>
</tr>
</tbody>
</table>
### MESSAGE Package
This package can optionally include support for messaging via sockets, using the open-source [ZeroMQ library](http://zeromq.org/), which must be installed on your system.
<table>
<thead>
<tr>
<th>Option</th>
<th>Description</th>
<th>Values</th>
</tr>
</thead>
<tbody>
<tr>
<td><code>MESSAGE_ZMQ</code></td>
<td>Build with ZeroMQ support</td>
<td>
<dl>
<dt><code>off</code> (default)</dt>
<dt><code>on</code></dt>
</dl>
</td>
</tr>
<tr>
<td><code>ZMQ_LIBRARY</code></td>
<td>
ZMQ library file (only needed if at custom location)
</td>
<td>
</td>
</tr>
<tr>
<td><code>ZMG_INCLUDE_DIR</code></td>
<td>
Provide include directory of existing ZMQ installation (only needed if at custom location)
</td>
<td>
</td>
</tr>
</tbody>
</table>
### MSCG Package
Requires installation of the MSCG library
<table>
<thead>
<tr>
<th>Option</th>
<th>Description</th>
<th>Values</th>
</tr>
</thead>
<tbody>
<tr>
<td><code>DOWNLOAD_MSCG</code></td>
<td>Download MSCG and compile it as part of the build</td>
<td>
<dl>
<dt><code>off</code> (default)</dt>
<dt><code>on</code></dt>
</dl>
</td>
</tr>
<tr>
<td><code>MSCG_LIBRARY</code></td>
<td>
MSCG library file (only needed if at custom location)
</td>
<td>
</td>
</tr>
<tr>
<td><code>MSCG_INCLUDE_DIR</code></td>
<td>
Provide include directory of existing MSCG installation (only needed if at custom location)
</td>
<td>
</td>
</tr>
</tbody>
</table>
### VORONOI Package
Requires installation of the Voro++ library
<table>
<thead>
<tr>
<th>Option</th>
<th>Description</th>
<th>Values</th>
</tr>
</thead>
<tbody>
<tr>
<td><code>DOWNLOAD_VORO</code></td>
<td>Download Voro++ and compile it as part of the build</td>
<td>
<dl>
<dt><code>off</code> (default)</dt>
<dt><code>on</code></dt>
</dl>
</td>
</tr>
<tr>
<td><code>VORO_LIBRARY</code></td>
<td>
Voro++ library file (only needed if at custom location)
</td>
<td>
</td>
</tr>
<tr>
<td><code>VORO_INCLUDE_DIR</code></td>
<td>
Provide include directory of existing Voro++ installation (only needed if at custom location)
</td>
<td>
</td>
</tr>
</tbody>
</table>
### USER-COLVARS Package
Requires a C++11 compiler to compile with the Lepton library included.
<table>
<thead>
<tr>
<th>Option</th>
<th>Description</th>
<th>Values</th>
</tr>
</thead>
<tbody>
<tr>
<td><code>COLVARS_LEPTON</code></td>
<td>Enable the use of the Lepton library inside the Colvars library.
<td>
<dl>
<dt><code>on</code> (default)</dt>
<dt><code>off</code></dt>
</dl>
</td>
</tr>
</tbody>
</table>
### USER-LATTE Package
Requires installation of the LATTE library
<table>
<thead>
<tr>
<th>Option</th>
<th>Description</th>
<th>Values</th>
</tr>
</thead>
<tbody>
<tr>
<td><code>DOWNLOAD_LATTE</code></td>
<td>Download LATTE and compile it as part of the build</td>
<td>
<dl>
<dt><code>off</code> (default)</dt>
<dt><code>on</code></dt>
</dl>
</td>
</tr>
<tr>
<td><code>LATTE_LIBRARY</code></td>
<td>
LATTE library file (only needed if at custom location)
</td>
<td>
</td>
</tr>
</tbody>
</table>
### USER-PLUMED Package
Requires installation of the PLUMED library
<table>
<thead>
<tr>
<th>Option</th>
<th>Description</th>
<th>Values</th>
</tr>
</thead>
<tbody>
<tr>
<td><code>DOWNLOAD_PLUMED</code></td>
<td>Download PLUMED and compile it as part of the build</td>
<td>
<dl>
<dt><code>off</code> (default)</dt>
<dt><code>on</code></dt>
</dl>
</td>
</tr>
<tr>
<td><code>PLUMED_MODE</code></td>
<td>
Determines the linkage mode for the PLUMED library.
</td>
<td>
<dl>
<dt><code>static</code> (default)</dt>
<dt><code>shared</code></dt>
<dt><code>runtime</code></dt>
</dl>
</td>
</tr>
</tbody>
</table>
### USER-LATTE Package
Requires installation of the LATTE library
<table>
<thead>
<tr>
<th>Option</th>
<th>Description</th>
<th>Values</th>
</tr>
</thead>
<tbody>
<tr>
<td><code>DOWNLOAD_LATTE</code></td>
<td>Download LATTE and compile it as part of the build</td>
<td>
<dl>
<dt><code>off</code> (default)</dt>
<dt><code>on</code></dt>
</dl>
</td>
</tr>
<tr>
<td><code>LATTE_LIBRARY</code></td>
<td>
LATTE library file (only needed if at custom location)
</td>
<td>
</td>
</tr>
</tbody>
</table>
### USER-SMD Package
Requires installation of the Eigen3 library
<table>
<thead>
<tr>
<th>Option</th>
<th>Description</th>
<th>Values</th>
</tr>
</thead>
<tbody>
<tr>
<td><code>DOWNLOAD_EIGEN3</code></td>
<td>Download Eigen3 and compile it as part of the build</td>
<td>
<dl>
<dt><code>off</code> (default)</dt>
<dt><code>on</code></dt>
</dl>
</td>
</tr>
<tr>
<td><code>EIGEN3_INCLUDE_DIR</code></td>
<td></td>
<td>
Provide include directory of existing Eigen3 installation (only needed if at custom location)
</td>
<td>
</td>
</tr>
</tbody>
</table>
### USER-SCAFACOS Package
To build with this package, you must download and build the [ScaFaCoS Coulomb solver library](http://www.scafacos.de/)
<table>
<thead>
<tr>
<th>Option</th>
<th>Description</th>
<th>Values</th>
</tr>
</thead>
<tbody>
<tr>
<td><code>DOWNLOAD_SCAFACOS</code></td>
<td>Download SCAFACOS and compile it as part of the build</td>
<td>
<dl>
<dt><code>off</code> (default)</dt>
<dt><code>on</code></dt>
</dl>
</td>
</tr>
<tr>
<td><code>SCAFACOS_LIBRARY</code></td>
<td>
SCAFACOS library file (only needed if at custom location)
</td>
<td>
</td>
</tr>
<tr>
<td><code>SCAFACOS_INCLUDE_DIR</code></td>
<td>
SCAFACOS include directory (only needed if at custom location)
<td>Custom location of lammps-testing repository (optional). If not specified it will download it via Git</td>
<td>
</td>
</tr>
<tr>
<td><code>LAMMPS_TESTING_GIT_TAG</code></td>
<td>If lammps-testing repository is cloned, this is the tag/commit that will be checked out</td>
<td>
<dl>
<dt><code>master</code> (default)</dt>
</dl>
</td>
</tr>
<tr>
<td><code>ENABLE_COVERAGE</code></td>
<td>Enables code coverage support via gcov and adds a gcovr build target to generate a coverage report.</td>
<td>
<dl>
<dt><code>off</code> (default)</dt>
<dt><code>on</code></dt>
</dl>
</td>
</tr>
<tr>
<td><code>ENABLE_SANITIZE_ADDRESS</code></td>
<td>Enables Address Sanitizer support when compiling using GCC or Clang for detecting memory leaks in binaries while running them. See https://clang.llvm.org/docs/AddressSanitizer.html</td>
<td>
<dl>
<dt><code>off</code> (default)</dt>
<dt><code>on</code></dt>
</dl>
</td>
</tr>
<tr>
<td><code>ENABLE_SANITIZE_UNDEFINED</code></td>
<td>Enables Undefined Behavior Sanitizer support when compiling using GCC or Clang for detecting code that is running into undefined behavior of the language. See https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html</td>
<td>
<dl>
<dt><code>off</code> (default)</dt>
<dt><code>on</code></dt>
</dl>
</td>
</tr>
<tr>
<td><code>ENABLE_SANITIZE_THREAD</code></td>
<td>Enables Thread Sanitizer support when compiling using GCC or Clang for detecting data races in binaries while running them. See https://clang.llvm.org/docs/ThreadSanitizer.html</td>
@ -46,16 +46,15 @@ software version 7.5 or later must be installed on your system. See
the discussion for the "GPU package"_Speed_gpu.html for details of how
to check and do this.
NOTE: Kokkos with CUDA currently implicitly assumes that the MPI
library is CUDA-aware and has support for GPU-direct. This is not
always the case, especially when using pre-compiled MPI libraries
provided by a Linux distribution. This is not a problem when using
only a single GPU and a single MPI rank on a desktop. When running
with multiple MPI ranks, you may see segmentation faults without
GPU-direct support. These can be avoided by adding the flags "-pk
kokkos gpu/direct off"_Run_options.html to the LAMMPS command line or
by using the command "package kokkos gpu/direct off"_package.html in
the input file.
NOTE: Kokkos with CUDA currently implicitly assumes that the MPI library
is CUDA-aware. This is not always the case, especially when using
pre-compiled MPI libraries provided by a Linux distribution. This is not
a problem when using only a single GPU with a single MPI rank. When
running with multiple MPI ranks, you may see segmentation faults without
CUDA-aware MPI support. These can be avoided by adding the flags "-pk
kokkos cuda/aware off"_Run_options.html to the LAMMPS command line or by
using the command "package kokkos cuda/aware off"_package.html in the
input file.
[Building LAMMPS with the KOKKOS package:]
@ -111,10 +110,10 @@ Makefile.kokkos_mpi_only) will give better performance than the OpenMP
back end (i.e. Makefile.kokkos_omp) because some of the overhead to make
the code thread-safe is removed.
NOTE: Use the "-pk kokkos" "command-line switch"_Run_options.html to
change the default "package kokkos"_package.html options. See its doc
page for details and default settings. Experimenting with its options
can provide a speed-up for specific calculations. For example:
NOTE: Use the "-pk kokkos" "command-line switch"_Run_options.html to
change the default "package kokkos"_package.html options. See its doc
page for details and default settings. Experimenting with its options
can provide a speed-up for specific calculations. For example:
mpirun -np 16 lmp_kokkos_mpi_only -k on -sf kk -pk kokkos newton on neigh half comm no -in in.lj # Newton on, Half neighbor list, non-threaded comm :pre
@ -184,15 +183,15 @@ tasks/node. The "-k on t Nt" command-line switch sets the number of
threads/task as Nt. The product of these two values should be N, i.e.
256 or 264.
NOTE: The default for the "package kokkos"_package.html command when
running on KNL is to use "half" neighbor lists and set the Newton flag
to "on" for both pairwise and bonded interactions. This will typically
be best for many-body potentials. For simpler pair-wise potentials, it
may be faster to use a "full" neighbor list with Newton flag to "off".
Use the "-pk kokkos" "command-line switch"_Run_options.html to change
the default "package kokkos"_package.html options. See its doc page for
details and default settings. Experimenting with its options can provide
a speed-up for specific calculations. For example:
NOTE: The default for the "package kokkos"_package.html command when
running on KNL is to use "half" neighbor lists and set the Newton flag
to "on" for both pairwise and bonded interactions. This will typically
be best for many-body potentials. For simpler pair-wise potentials, it
may be faster to use a "full" neighbor list with Newton flag to "off".
Use the "-pk kokkos" "command-line switch"_Run_options.html to change
the default "package kokkos"_package.html options. See its doc page for
details and default settings. Experimenting with its options can provide
a speed-up for specific calculations. For example:
mpirun -np 64 lmp_kokkos_phi -k on t 4 -sf kk -pk kokkos comm host -in in.reax # Newton on, half neighbor list, threaded comm
mpirun -np 64 lmp_kokkos_phi -k on t 4 -sf kk -pk kokkos newton off neigh full comm no -in in.lj # Newton off, full neighbor list, non-threaded comm :pre
@ -207,20 +206,19 @@ supports.
[Running on GPUs:]
Use the "-k" "command-line switch"_Run_options.html to specify the
number of GPUs per node. Typically the -np setting of the mpirun command
should set the number of MPI tasks/node to be equal to the number of
physical GPUs on the node. You can assign multiple MPI tasks to the same
GPU with the KOKKOS package, but this is usually only faster if some
portions of the input script have not been ported to use Kokkos. In this
case, also packing/unpacking communication buffers on the host may give
speedup (see the KOKKOS "package"_package.html command). Using CUDA MPS
Use the "-k" "command-line switch"_Run_options.html to specify the
number of GPUs per node. Typically the -np setting of the mpirun command
should set the number of MPI tasks/node to be equal to the number of
physical GPUs on the node. You can assign multiple MPI tasks to the same
GPU with the KOKKOS package, but this is usually only faster if some
portions of the input script have not been ported to use Kokkos. In this
case, also packing/unpacking communication buffers on the host may give
speedup (see the KOKKOS "package"_package.html command). Using CUDA MPS
is recommended in this scenario.
Using a CUDA-aware MPI library with
support for GPU-direct is highly recommended. GPU-direct use can be
avoided by using "-pk kokkos gpu/direct no"_package.html. As above for
multi-core CPUs (and no GPU), if N is the number of physical cores/node,
Using a CUDA-aware MPI library is highly recommended. CUDA-aware MPI use can be
avoided by using "-pk kokkos cuda/aware no"_package.html. As above for
multi-core CPUs (and no GPU), if N is the number of physical cores/node,
then the number of MPI tasks/node should not exceed N.
-k on g Ng :pre
@ -231,18 +229,18 @@ one or more nodes, each with two GPUs:
mpirun -np 2 lmp_kokkos_cuda_openmpi -k on g 2 -sf kk -in in.lj # 1 node, 2 MPI tasks/node, 2 GPUs/node
mpirun -np 32 -ppn 2 lmp_kokkos_cuda_openmpi -k on g 2 -sf kk -in in.lj # 16 nodes, 2 MPI tasks/node, 2 GPUs/node (32 GPUs total) :pre
NOTE: The default for the "package kokkos"_package.html command when
running on GPUs is to use "full" neighbor lists and set the Newton flag
to "off" for both pairwise and bonded interactions, along with threaded
communication. When running on Maxwell or Kepler GPUs, this will
typically be best. For Pascal GPUs, using "half" neighbor lists and
setting the Newton flag to "on" may be faster. For many pair styles,
setting the neighbor binsize equal to twice the CPU default value will
give speedup, which is the default when running on GPUs. Use the "-pk
kokkos" "command-line switch"_Run_options.html to change the default
"package kokkos"_package.html options. See its doc page for details and
default settings. Experimenting with its options can provide a speed-up
for specific calculations. For example:
NOTE: The default for the "package kokkos"_package.html command when
running on GPUs is to use "full" neighbor lists and set the Newton flag
to "off" for both pairwise and bonded interactions, along with threaded
communication. When running on Maxwell or Kepler GPUs, this will
typically be best. For Pascal GPUs, using "half" neighbor lists and
setting the Newton flag to "on" may be faster. For many pair styles,
setting the neighbor binsize equal to twice the CPU default value will
give speedup, which is the default when running on GPUs. Use the "-pk
kokkos" "command-line switch"_Run_options.html to change the default
"package kokkos"_package.html options. See its doc page for details and
default settings. Experimenting with its options can provide a speed-up
for specific calculations. For example:
mpirun -np 2 lmp_kokkos_cuda_openmpi -k on g 2 -sf kk -pk kokkos newton on neigh half binsize 2.8 -in in.lj # Newton on, half neighbor list, set binsize = neighbor ghost cutoff :pre
@ -485,6 +487,21 @@ README for more info on Pizza.py and how to use these scripts.
:line
replica tool :h4,link(replica)
The tools/replica directory contains the reorder_remd_traj python script which
can be used to reorder the replica trajectories (resulting from the use of the
temper command) according to temperature. This will produce discontinuous
trajectories with all frames at the same temperature in each trajectory.
Additional options can be used to calculate the canonical configurational
log-weight for each frame at each temperature using the pymbar package. See
the README.md file for further details. Try out the peptide example provided.
This tool was written by (and is maintained by) Tanmoy Sanyal,
while at the Shell lab at UC Santa Barbara. (tanmoy dot 7989 at gmail.com)
:line
reax tool :h4,link(reax_tool)
The reax sub-directory contains stand-alone codes that can
@ -515,17 +532,26 @@ Ernst Mach Institute in Germany (georg.ganzenmueller at emi.fhg.de).
spin tool :h4,link(spin)
The spin sub-directory contains a C file interpolate.c which can
be compiled and used to perform a cubic polynomial interpolation of
be compiled and used to perform a cubic polynomial interpolation of
the MEP following a GNEB calculation.
See the README file in tools/spin/interpolate_gneb for more details.
This tool was written by the SPIN package author, Julien
Tranchida at Sandia National Labs (jtranch at sandia.gov, and by Aleksei
Tranchida at Sandia National Labs (jtranch at sandia.gov, and by Aleksei
Ivanov, at University of Iceland (ali5 at hi.is).
:line
singularity tool :h4,link(singularity_tool)
The singularity sub-directory contains container definitions files
that can be used to build container images for building and testing
LAMMPS on specific OS variants using the "Singularity"_https://sylabs.io
container software. Contributions for additional variants are welcome.
:line
vim tool :h4,link(vim)
The files in the tools/vim directory are add-ons to the VIM editor
@ -549,3 +575,4 @@ simulation.
See the README file for details.
These files were provided by Vikas Varshney (vv0210 at gmail.com)
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.