Merge branch 'clean-master2' of github.com:julient31/lammps into gneb_spin
This commit is contained in:
julient31
@ -28,7 +28,7 @@ Makefile(s). Example:
|
||||
|
||||
cd lammps # change to the LAMMPS distribution directory
|
||||
mkdir build; cd build # create a new directory (folder) for build
|
||||
cmake ../cmake \[options ...\] # configuration with (command-line) cmake
|
||||
cmake \[options ...\] ../cmake # configuration with (command-line) cmake
|
||||
make # compilation :pre
|
||||
|
||||
The cmake command will detect available features, enable selected
|
||||
@ -41,7 +41,8 @@ If your machine has multiple CPU cores (most do these days), using a
|
||||
command like "make -jN" (with N being the number of available local
|
||||
CPU cores) can be much faster. If you plan to do development on
|
||||
LAMMPS or need to re-compile LAMMPS repeatedly, installation of the
|
||||
ccache (= Compiler Cache) software may speed up compilation even more.
|
||||
ccache (= Compiler Cache) software may speed up repeated compilation
|
||||
even more.
|
||||
|
||||
After compilation, you can optionally copy the LAMMPS executable and
|
||||
library into your system folders (by default under $HOME/.local) with:
|
||||
@ -108,7 +109,8 @@ command-line options. Several useful ones are:
|
||||
-D CMAKE_BUILD_TYPE=type # type = Release or Debug
|
||||
-G output # style of output CMake generates
|
||||
-DVARIABLE=value # setting for a LAMMPS feature to enable
|
||||
-D VARIABLE=value # ditto, but cannot come after CMakeLists.txt dir :pre
|
||||
-D VARIABLE=value # ditto, but cannot come after CMakeLists.txt dir
|
||||
-C path/to/preset/file # load some CMake settings before configuring :pre
|
||||
|
||||
All the LAMMPS-specific -D variables that a LAMMPS build supports are
|
||||
described on the pages linked to from the "Build"_Build.html doc page.
|
||||
|
||||
@ -859,23 +859,34 @@ file.
|
||||
USER-INTEL package :h4,link(user-intel)
|
||||
|
||||
To build with this package, you must choose which hardware you want to
|
||||
build for, either Intel CPUs or Intel KNLs. You should also typically
|
||||
"install the USER-OMP package"_#user-omp, as it can be used in tandem
|
||||
with the USER-INTEL package to good effect, as explained on the "Speed
|
||||
intel"_Speed_intel.html doc page.
|
||||
build for, either x86 CPUs or Intel KNLs in offload mode. You should
|
||||
also typically "install the USER-OMP package"_#user-omp, as it can be
|
||||
used in tandem with the USER-INTEL package to good effect, as explained
|
||||
on the "Speed intel"_Speed_intel.html doc page.
|
||||
|
||||
[CMake build]:
|
||||
|
||||
-D INTEL_ARCH=value # value = cpu (default) or knl
|
||||
-D BUILD_OMP=yes # also required to build with the USER-INTEl package :pre
|
||||
-D INTEL_LRT_MODE=value # value = threads, none, or c++11 :pre
|
||||
|
||||
Requires an Intel compiler as well as the Intel TBB and MKL libraries.
|
||||
In Long-range thread mode (LRT) a modified verlet style is used, that
|
||||
operates the Kspace calculation in a separate thread concurrently to
|
||||
other calculations. This has to be enabled in the "package intel"_package.html
|
||||
command at runtime. With the setting "threads" it used the pthreads
|
||||
library, while c++11 will use the built-in thread support of C++11
|
||||
compilers. The option "none" skips compilation of this feature. The
|
||||
default is to use "threads" if pthreads is available and otherwise "none".
|
||||
|
||||
Best performance is achieved with Intel hardware, Intel compilers, as well as
|
||||
the Intel TBB and MKL libraries. However, the code also compiles, links, and
|
||||
runs with other compilers and without TBB and MKL.
|
||||
|
||||
[Traditional make]:
|
||||
|
||||
Choose which hardware to compile for in Makefile.machine via the
|
||||
following settings. See src/MAKE/OPTIONS/Makefile.intel_cpu* and
|
||||
Makefile.knl files for examples.
|
||||
Makefile.knl files for examples. and src/USER-INTEL/README for
|
||||
additional information.
|
||||
|
||||
For CPUs:
|
||||
|
||||
|
||||
@ -149,26 +149,41 @@ system. Using these files you can enable/disable portions of the
|
||||
available packages in LAMMPS. If you need a custom preset you can take
|
||||
one of them as a starting point and customize it to your needs.
|
||||
|
||||
cmake -C ../cmake/presets/all_on.cmake \[OPTIONS\] ../cmake | enable all packages
|
||||
cmake -C ../cmake/presets/all_off.cmake \[OPTIONS\] ../cmake | disable all packages
|
||||
cmake -C ../cmake/presets/std.cmake \[OPTIONS\] ../cmake | enable standard packages
|
||||
cmake -C ../cmake/presets/user.cmake \[OPTIONS\] ../cmake | enable user packages
|
||||
cmake -C ../cmake/presets/std_nolib.cmake \[OPTIONS\] ../cmake | enable standard packages that do not require extra libraries
|
||||
cmake -C ../cmake/presets/nolib.cmake \[OPTIONS\] ../cmake | disable all packages that do not require extra libraries
|
||||
cmake -C ../cmake/presets/manual_selection.cmake \[OPTIONS\] ../cmake | example of how to create a manual selection of packages :tb(s=|,a=l)
|
||||
cmake -C ../cmake/presets/all_on.cmake \[OPTIONS\] ../cmake |
|
||||
enable all packages |
|
||||
cmake -C ../cmake/presets/all_off.cmake \[OPTIONS\] ../cmake |
|
||||
disable all packages |
|
||||
cmake -C ../cmake/presets/minimal.cmake \[OPTIONS\] ../cmake |
|
||||
enable just a few core packages |
|
||||
cmake -C ../cmake/presets/most.cmake \[OPTIONS\] ../cmake |
|
||||
enable most common packages |
|
||||
cmake -C ../cmake/presets/nolib.cmake \[OPTIONS\] ../cmake |
|
||||
disable packages that do require extra libraries or tools |
|
||||
cmake -C ../cmake/presets/clang.cmake \[OPTIONS\] ../cmake |
|
||||
change settings to use the Clang compilers by default |
|
||||
cmake -C ../cmake/presets/mingw.cmake \[OPTIONS\] ../cmake |
|
||||
enable all packages compatible with MinGW compilers :tb(c=2,s=|,a=l)
|
||||
|
||||
NOTE: Running cmake this way manipulates the variable cache in your
|
||||
current build directory. You can combine presets and options with
|
||||
multiple cmake runs.
|
||||
current build directory. You can combine multiple presets and options
|
||||
in a single cmake run, or change settings incrementally by running
|
||||
cmake with new flags.
|
||||
|
||||
[Example:]
|
||||
|
||||
# build LAMMPS with all "standard" packages which don't
|
||||
# use libraries and enable GPU package
|
||||
# build LAMMPS with most commonly used packages, but then remove
|
||||
# those requiring additional library or tools, but still enable
|
||||
# GPU package and configure it for using CUDA. You can run.
|
||||
mkdir build
|
||||
cd build
|
||||
cmake -C ../cmake/presets/std_nolib.cmake -D PKG_GPU=on ../cmake :pre
|
||||
cmake -C ../cmake/presets/most.cmake -C ../cmake/presets/nolib.cmake -D PKG_GPU=on -D GPU_API=cuda ../cmake :pre
|
||||
|
||||
# to add another package, say BODY to the previous configuration you can run:
|
||||
cmake -D PKG_BODY=on . :pre
|
||||
|
||||
# to reset the package selection from above to the default of no packages
|
||||
# but leaving all other settings untouched. You can run:
|
||||
cmake -C ../cmake/presets/no_all.cmake . :pre
|
||||
:line
|
||||
|
||||
[Make shortcuts for installing many packages]:
|
||||
|
||||
@ -57,10 +57,10 @@ FFT_INC = -DFFT_SINGLE # do not specify for double precision
|
||||
FFT_INC = -DFFT_PACK_ARRAY # or -DFFT_PACK_POINTER or -DFFT_PACK_MEMCPY :pre
|
||||
# default is FFT_PACK_ARRAY if not specified
|
||||
|
||||
FFT_INC = -I/usr/local/include
|
||||
FFT_INC = -I/usr/local/include
|
||||
FFT_PATH = -L/usr/local/lib
|
||||
FFT_LIB = -lfftw3 # FFTW3 double precision
|
||||
FFT_LIB = -lfftw3 -lfftw3f # FFTW3 single precision
|
||||
FFT_LIB = -lfftw3 # FFTW3 double precision
|
||||
FFT_LIB = -lfftw3 -lfftw3f # FFTW3 single precision
|
||||
FFT_LIB = -lmkl_intel_lp64 -lmkl_sequential -lmkl_core # MKL with Intel compiler
|
||||
FFT_LIB = -lmkl_gf_lp64 -lmkl_sequential -lmkl_core # MKL with GNU compier :pre
|
||||
|
||||
@ -179,8 +179,11 @@ e.g. from 511 to -512, which can cause diagnostics like the
|
||||
mean-squared displacement, as calculated by the "compute
|
||||
msd"_compute_msd.html command, to be faulty.
|
||||
|
||||
Note that the USER-ATC package is not currently compatible with the
|
||||
"bigbig" setting.
|
||||
Note that the USER-ATC package and the USER-INTEL package are currently
|
||||
not compatible with the "bigbig" setting. Also, there are limitations
|
||||
when using the library interface. Some functions with known issues
|
||||
have been replaced by dummy calls printing a corresponding error rather
|
||||
than crashing randomly or corrupting data.
|
||||
|
||||
Also note that the GPU package requires its lib/gpu library to be
|
||||
compiled with the same size setting, or the link will fail. A CMake
|
||||
|
||||
@ -51,11 +51,10 @@ provides a unix/linux interface to low-level Windows functions, so LAMMPS
|
||||
can be compiled on Windows. The necessary (minor) modifications to LAMMPS
|
||||
are included, but may not always up-to-date for recently added functionality
|
||||
and the corresponding new code. A machine makefile for using cygwin for
|
||||
the old build system is provided. The CMake build system is untested
|
||||
for this; you will have to request that makefiles are generated and
|
||||
manually set the compiler.
|
||||
the old build system is provided. Using CMake for this mode of compilation
|
||||
is untested and not likely to work.
|
||||
|
||||
When compiling for Windows [not] set the -DLAMMPS_MEMALIGN define
|
||||
When compiling for Windows do [not] set the -DLAMMPS_MEMALIGN define
|
||||
in the LMP_INC makefile variable and add -lwsock32 -lpsapi to the linker
|
||||
flags in LIB makefile variable. Try adding -static-libgcc or -static or
|
||||
both to the linker flags when your resulting LAMMPS Windows executable
|
||||
@ -79,7 +78,13 @@ probably the currently best tested and supported way to build LAMMPS
|
||||
executables for Windows. There are makefiles provided for the
|
||||
traditional build system, but CMake has also been successfully tested
|
||||
using the mingw32-cmake and mingw64-cmake wrappers that are bundled
|
||||
with the cross-compiler environment on Fedora machines.
|
||||
with the cross-compiler environment on Fedora machines. A CMake preset
|
||||
selecting all packages compatible with this cross-compilation build
|
||||
is provided. You likely need to disable the GPU package unless you
|
||||
download and install the contents of the pre-compiled "OpenCL ICD loader
|
||||
library"_https://download.lammps.org/thirdparty/opencl-win-devel.tar.gz
|
||||
into your MinGW64 cross-compiler environment. The cross-compilation
|
||||
currently will only produce non-MPI serial binaries.
|
||||
|
||||
Please keep in mind, though, that this only applies to compiling LAMMPS.
|
||||
Whether the resulting binaries do work correctly is no tested by the
|
||||
|
||||
@ -61,6 +61,7 @@ OPT.
|
||||
"edpd/source"_fix_dpd_source.html,
|
||||
"efield"_fix_efield.html,
|
||||
"ehex"_fix_ehex.html,
|
||||
"electron/stopping"_fix_electron_stopping.html,
|
||||
"enforce2d (k)"_fix_enforce2d.html,
|
||||
"eos/cv"_fix_eos_cv.html,
|
||||
"eos/table"_fix_eos_table.html,
|
||||
|
||||
@ -98,6 +98,7 @@ OPT.
|
||||
"gran/hertz/history (o)"_pair_gran.html,
|
||||
"gran/hooke (o)"_pair_gran.html,
|
||||
"gran/hooke/history (ko)"_pair_gran.html,
|
||||
"granular"_pair_granular.html,
|
||||
"gw"_pair_gw.html,
|
||||
"gw/zbl"_pair_gw.html,
|
||||
"hbond/dreiding/lj (o)"_pair_hbond_dreiding.html,
|
||||
|
||||
@ -148,7 +148,7 @@ END_RST -->
|
||||
|
||||
<!-- HTML_ONLY -->
|
||||
|
||||
"CHARMM, AMBER, and DREIDING force fields"_Howto_bioFF.html
|
||||
"CHARMM, AMBER, COMPASS, and DREIDING force fields"_Howto_bioFF.html
|
||||
"TIP3P water model"_Howto_tip3p.html
|
||||
"TIP4P water model"_Howto_tip4p.html
|
||||
"SPC water model"_Howto_spc.html :all(b)
|
||||
|
||||
@ -7,29 +7,31 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:line
|
||||
|
||||
CHARMM, AMBER, and DREIDING force fields :h3
|
||||
CHARMM, AMBER, COMPASS, and DREIDING force fields :h3
|
||||
|
||||
A force field has 2 parts: the formulas that define it and the
|
||||
coefficients used for a particular system. Here we only discuss
|
||||
formulas implemented in LAMMPS that correspond to formulas commonly
|
||||
used in the CHARMM, AMBER, and DREIDING force fields. Setting
|
||||
coefficients is done in the input data file via the
|
||||
"read_data"_read_data.html command or in the input script with
|
||||
used in the CHARMM, AMBER, COMPASS, and DREIDING force fields. Setting
|
||||
coefficients is done either from special sections in an input data file
|
||||
via the "read_data"_read_data.html command or in the input script with
|
||||
commands like "pair_coeff"_pair_coeff.html or
|
||||
"bond_coeff"_bond_coeff.html. See the "Tools"_Tools.html doc page for
|
||||
additional tools that can use CHARMM or AMBER to assign force field
|
||||
coefficients and convert their output into LAMMPS input.
|
||||
"bond_coeff"_bond_coeff.html and so on. See the "Tools"_Tools.html doc
|
||||
page for additional tools that can use CHARMM, AMBER, or Materials
|
||||
Studio generated files to assign force field coefficients and convert
|
||||
their output into LAMMPS input.
|
||||
|
||||
See "(MacKerell)"_#howto-MacKerell for a description of the CHARMM force
|
||||
field. See "(Cornell)"_#howto-Cornell for a description of the AMBER force
|
||||
field.
|
||||
field. See "(Cornell)"_#howto-Cornell for a description of the AMBER
|
||||
force field. See "(Sun)"_#howto-Sun for a description of the COMPASS
|
||||
force field.
|
||||
|
||||
:link(charmm,http://www.scripps.edu/brooks)
|
||||
:link(amber,http://amber.scripps.edu)
|
||||
|
||||
These style choices compute force field formulas that are consistent
|
||||
with common options in CHARMM or AMBER. See each command's
|
||||
documentation for the formula it computes.
|
||||
The interaction styles listed below compute force field formulas that
|
||||
are consistent with common options in CHARMM or AMBER. See each
|
||||
command's documentation for the formula it computes.
|
||||
|
||||
"bond_style"_bond_harmonic.html harmonic
|
||||
"angle_style"_angle_charmm.html charmm
|
||||
@ -44,28 +46,54 @@ documentation for the formula it computes.
|
||||
"special_bonds"_special_bonds.html charmm
|
||||
"special_bonds"_special_bonds.html amber :ul
|
||||
|
||||
NOTE: For CHARMM, newer {charmmfsw} or {charmmfsh} styles were
|
||||
released in March 2017. We recommend they be used instead of the
|
||||
older {charmm} styles. See discussion of the differences on the "pair
|
||||
charmm"_pair_charmm.html and "dihedral charmm"_dihedral_charmm.html
|
||||
doc pages.
|
||||
NOTE: For CHARMM, newer {charmmfsw} or {charmmfsh} styles were released
|
||||
in March 2017. We recommend they be used instead of the older {charmm}
|
||||
styles. See discussion of the differences on the "pair
|
||||
charmm"_pair_charmm.html and "dihedral charmm"_dihedral_charmm.html doc
|
||||
pages.
|
||||
|
||||
COMPASS is a general force field for atomistic simulation of common
|
||||
organic molecules, inorganic small molecules, and polymers which was
|
||||
developed using ab initio and empirical parameterization techniques.
|
||||
See the "Tools"_Tools.html doc page for the msi2lmp tool for creating
|
||||
LAMMPS template input and data files from BIOVIA’s Materials Studio
|
||||
files. Please note that the msi2lmp tool is very old and largely
|
||||
unmaintained, so it does not support all features of Materials Studio
|
||||
provided force field files, especially additions during the last decade.
|
||||
You should watch the output carefully and compare results, where
|
||||
possible. See "(Sun)"_#howto-Sun for a description of the COMPASS force
|
||||
field.
|
||||
|
||||
These interaction styles listed below compute force field formulas that
|
||||
are consistent with the COMPASS force field. See each command's
|
||||
documentation for the formula it computes.
|
||||
|
||||
"bond_style"_bond_class2.html class2
|
||||
"angle_style"_angle_class2.html class2
|
||||
"dihedral_style"_dihedral_class2.html class2
|
||||
"improper_style"_improper_class2.html class2 :ul
|
||||
|
||||
"pair_style"_pair_class2.html lj/class2
|
||||
"pair_style"_pair_class2.html lj/class2/coul/cut
|
||||
"pair_style"_pair_class2.html lj/class2/coul/long :ul
|
||||
|
||||
"special_bonds"_special_bonds.html lj/coul 0 0 1 :ul
|
||||
|
||||
DREIDING is a generic force field developed by the "Goddard
|
||||
group"_http://www.wag.caltech.edu at Caltech and is useful for
|
||||
predicting structures and dynamics of organic, biological and
|
||||
main-group inorganic molecules. The philosophy in DREIDING is to use
|
||||
general force constants and geometry parameters based on simple
|
||||
hybridization considerations, rather than individual force constants
|
||||
and geometric parameters that depend on the particular combinations of
|
||||
atoms involved in the bond, angle, or torsion terms. DREIDING has an
|
||||
"explicit hydrogen bond term"_pair_hbond_dreiding.html to describe
|
||||
interactions involving a hydrogen atom on very electronegative atoms
|
||||
(N, O, F).
|
||||
predicting structures and dynamics of organic, biological and main-group
|
||||
inorganic molecules. The philosophy in DREIDING is to use general force
|
||||
constants and geometry parameters based on simple hybridization
|
||||
considerations, rather than individual force constants and geometric
|
||||
parameters that depend on the particular combinations of atoms involved
|
||||
in the bond, angle, or torsion terms. DREIDING has an "explicit hydrogen
|
||||
bond term"_pair_hbond_dreiding.html to describe interactions involving a
|
||||
hydrogen atom on very electronegative atoms (N, O, F).
|
||||
|
||||
See "(Mayo)"_#howto-Mayo for a description of the DREIDING force field
|
||||
|
||||
These style choices compute force field formulas that are consistent
|
||||
with the DREIDING force field. See each command's
|
||||
The interaction styles listed below compute force field formulas that
|
||||
are consistent with the DREIDING force field. See each command's
|
||||
documentation for the formula it computes.
|
||||
|
||||
"bond_style"_bond_harmonic.html harmonic
|
||||
@ -100,6 +128,9 @@ Fischer, Gao, Guo, Ha, et al, J Phys Chem, 102, 3586 (1998).
|
||||
[(Cornell)] Cornell, Cieplak, Bayly, Gould, Merz, Ferguson,
|
||||
Spellmeyer, Fox, Caldwell, Kollman, JACS 117, 5179-5197 (1995).
|
||||
|
||||
:link(howto-Sun)
|
||||
[(Sun)] Sun, J. Phys. Chem. B, 102, 7338–7364 (1998).
|
||||
|
||||
:link(howto-Mayo)
|
||||
[(Mayo)] Mayo, Olfason, Goddard III, J Phys Chem, 94, 8897-8909
|
||||
(1990).
|
||||
|
||||
@ -166,9 +166,6 @@ void lammps_gather_atoms_subset(void *, char *, int, int, int, int *, void *)
|
||||
void lammps_scatter_atoms(void *, char *, int, int, void *)
|
||||
void lammps_scatter_atoms_subset(void *, char *, int, int, int, int *, void *) :pre
|
||||
|
||||
void lammps_create_atoms(void *, int, tagint *, int *, double *, double *,
|
||||
imageint *, int) :pre
|
||||
|
||||
The gather functions collect peratom info of the requested type (atom
|
||||
coords, atom types, forces, etc) from all processors, and returns the
|
||||
same vector of values to each calling processor. The scatter
|
||||
@ -176,6 +173,11 @@ functions do the inverse. They distribute a vector of peratom values,
|
||||
passed by all calling processors, to individual atoms, which may be
|
||||
owned by different processors.
|
||||
|
||||
IMPORTANT NOTE: These functions are not compatible with the
|
||||
-DLAMMPS_BIGBIG setting when compiling LAMMPS. Dummy functions
|
||||
that result in an error message and abort will be substituted
|
||||
instead of resulting in random crashes and memory corruption.
|
||||
|
||||
The lammps_gather_atoms() function does this for all N atoms in the
|
||||
system, ordered by atom ID, from 1 to N. The
|
||||
lammps_gather_atoms_concat() function does it for all N atoms, but
|
||||
@ -196,6 +198,9 @@ those values to each atom in the system. The
|
||||
lammps_scatter_atoms_subset() function takes a subset of IDs as an
|
||||
argument and only scatters those values to the owning atoms.
|
||||
|
||||
void lammps_create_atoms(void *, int, tagint *, int *, double *, double *,
|
||||
imageint *, int) :pre
|
||||
|
||||
The lammps_create_atoms() function takes a list of N atoms as input
|
||||
with atom types and coords (required), an optionally atom IDs and
|
||||
velocities and image flags. It uses the coords of each atom to assign
|
||||
|
||||
@ -10,7 +10,7 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
TIP3P water model :h3
|
||||
|
||||
The TIP3P water model as implemented in CHARMM
|
||||
"(MacKerell)"_#howto-MacKerell specifies a 3-site rigid water molecule with
|
||||
"(MacKerell)"_#howto-tip3p specifies a 3-site rigid water molecule with
|
||||
charges and Lennard-Jones parameters assigned to each of the 3 atoms.
|
||||
In LAMMPS the "fix shake"_fix_shake.html command can be used to hold
|
||||
the two O-H bonds and the H-O-H angle rigid. A bond style of
|
||||
@ -60,6 +60,10 @@ models"_http://en.wikipedia.org/wiki/Water_model.
|
||||
|
||||
:line
|
||||
|
||||
:link(howto-tip3p)
|
||||
[(MacKerell)] MacKerell, Bashford, Bellott, Dunbrack, Evanseck, Field,
|
||||
Fischer, Gao, Guo, Ha, et al, J Phys Chem, 102, 3586 (1998).
|
||||
|
||||
:link(Jorgensen1)
|
||||
[(Jorgensen)] Jorgensen, Chandrasekhar, Madura, Impey, Klein, J Chem
|
||||
Phys, 79, 926 (1983).
|
||||
|
||||
@ -79,7 +79,7 @@ stdin.
|
||||
Explicitly enable or disable KOKKOS support, as provided by the KOKKOS
|
||||
package. Even if LAMMPS is built with this package, as described
|
||||
in "Speed kokkos"_Speed_kokkos.html, this switch must be set to enable
|
||||
running with the KOKKOS-enabled styles the package provides. If the
|
||||
running with KOKKOS-enabled styles the package provides. If the
|
||||
switch is not set (the default), LAMMPS will operate as if the KOKKOS
|
||||
package were not installed; i.e. you can run standard LAMMPS or with
|
||||
the GPU or USER-OMP packages, for testing or benchmarking purposes.
|
||||
@ -448,7 +448,7 @@ partition screen files file.N.
|
||||
[-suffix style args] :link(suffix)
|
||||
|
||||
Use variants of various styles if they exist. The specified style can
|
||||
be {cuda}, {gpu}, {intel}, {kk}, {omp}, {opt}, or {hybrid}. These
|
||||
be {gpu}, {intel}, {kk}, {omp}, {opt}, or {hybrid}. These
|
||||
refer to optional packages that LAMMPS can be built with, as described
|
||||
in "Accelerate performance"_Speed.html. The "gpu" style corresponds to the
|
||||
GPU package, the "intel" style to the USER-INTEL package, the "kk"
|
||||
|
||||
@ -24,7 +24,7 @@ LAMMPS to run on the CPU cores and co-processor cores simultaneously.
|
||||
|
||||
Angle Styles: charmm, harmonic :ulb,l
|
||||
Bond Styles: fene, fourier, harmonic :l
|
||||
Dihedral Styles: charmm, harmonic, opls :l
|
||||
Dihedral Styles: charmm, fourier, harmonic, opls :l
|
||||
Fixes: nve, npt, nvt, nvt/sllod, nve/asphere :l
|
||||
Improper Styles: cvff, harmonic :l
|
||||
Pair Styles: airebo, airebo/morse, buck/coul/cut, buck/coul/long,
|
||||
|
||||
@ -201,6 +201,7 @@ accelerated styles exist.
|
||||
"edpd/source"_fix_dpd_source.html -
|
||||
"efield"_fix_efield.html - impose electric field on system
|
||||
"ehex"_fix_ehex.html - enhanced heat exchange algorithm
|
||||
"electron/stopping"_fix_electron_stopping.html - electronic stopping power as a friction force
|
||||
"enforce2d"_fix_enforce2d.html - zero out z-dimension velocity and force
|
||||
"eos/cv"_fix_eos_cv.html -
|
||||
"eos/table"_fix_eos_table.html -
|
||||
|
||||
165
doc/src/fix_electron_stopping.txt
Normal file
165
doc/src/fix_electron_stopping.txt
Normal file
@ -0,0 +1,165 @@
|
||||
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
:line
|
||||
|
||||
fix electron/stopping command :h3
|
||||
|
||||
[Syntax:]
|
||||
|
||||
fix ID group-ID electron/stopping Ecut file keyword value ... :pre
|
||||
|
||||
ID, group-ID are documented in "fix"_fix.html command :ulb,l
|
||||
electron/stopping = style name of this fix command :l
|
||||
Ecut = minimum kinetic energy for electronic stopping (energy units) :l
|
||||
file = name of the file containing the electronic stopping power table :l
|
||||
zero or more keyword/value pairs may be appended to args :l
|
||||
keyword = {region} or {minneigh} :l
|
||||
{region} value = region-ID
|
||||
region-ID = region, whose atoms will be affected by this fix
|
||||
{minneigh} value = minneigh
|
||||
minneigh = minimum number of neighbors an atom to have stopping applied :pre
|
||||
:ule
|
||||
|
||||
[Examples:]
|
||||
|
||||
fix el all electron/stopping 10.0 elstop-table.txt
|
||||
fix el all electron/stopping 10.0 elstop-table.txt minneigh 3
|
||||
fix el mygroup electron/stopping 1.0 elstop-table.txt region bulk :pre
|
||||
|
||||
[Description:]
|
||||
|
||||
This fix implements inelastic energy loss for fast projectiles in solids. It
|
||||
applies a friction force to fast moving atoms to slow them down due to
|
||||
"electronic stopping"_#elstopping (energy lost via electronic collisions per
|
||||
unit of distance). This fix should be used for simulation of irradiation
|
||||
damage or ion implantation, where the ions can lose noticeable amounts of
|
||||
energy from electron excitations. If the electronic stopping power is not
|
||||
considered, the simulated range of the ions can be severely overestimated
|
||||
("Nordlund98"_#Nordlund98, "Nordlund95"_#Nordlund95).
|
||||
|
||||
The electronic stopping is implemented by applying a friction force
|
||||
to each atom as:
|
||||
|
||||
\begin\{equation\}
|
||||
\vec\{F\}_i = \vec\{F\}^0_i - \frac\{\vec\{v\}_i\}\{\|\vec\{v\}_i\|\} \cdot S_e
|
||||
\end\{equation\}
|
||||
|
||||
where \(\vec\{F\}_i\) is the resulting total force on the atom.
|
||||
\(\vec\{F\}^0_i\) is the original force applied to the atom, \(\vec\{v\}_i\) is
|
||||
its velocity and \(S_e\) is the stopping power of the ion.
|
||||
|
||||
NOTE: In addition to electronic stopping, atomic cascades and irradiation
|
||||
simulations require the use of an adaptive timestep (see
|
||||
"fix dt/reset"_fix_dt_reset.html) and the repulsive ZBL potential (see
|
||||
"ZBL"_pair_zbl.html potential) or similar. Without these settings the
|
||||
interaction between the ion and the target atoms will be faulty. It is also
|
||||
common to use in such simulations a thermostat ("fix_nvt"_fix_nh.html) in
|
||||
the borders of the simulation cell.
|
||||
|
||||
NOTE: This fix removes energy from fast projectiles without depositing it as a
|
||||
heat to the simulation cell. Such implementation might lead to the unphysical
|
||||
results when the amount of energy deposited to the electronic system is large,
|
||||
e.g. simulations of Swift Heavy Ions (energy per nucleon of 100 keV/amu or
|
||||
higher) or multiple projectiles. You could compensate energy loss by coupling
|
||||
bulk atoms with some thermostat or control heat transfer between electronic and
|
||||
atomic subsystems with the two-temperature model ("fix_ttm"_fix_ttm.html).
|
||||
|
||||
At low velocities the electronic stopping is negligible. The electronic
|
||||
friction is not applied to atoms whose kinetic energy is smaller than {Ecut},
|
||||
or smaller than the lowest energy value given in the table in {file}.
|
||||
Electronic stopping should be applied only when a projectile reaches bulk
|
||||
material. This fix scans neighbor list and excludes atoms with fewer than
|
||||
{minneigh} neighbors (by default one). If the pair potential cutoff is large,
|
||||
minneigh should be increased, though not above the number of nearest neighbors
|
||||
in bulk material. An alternative is to disable the check for neighbors by
|
||||
setting {minneigh} to zero and using the {region} keyword. This is necessary
|
||||
when running simulations of cluster bombardment.
|
||||
|
||||
If the {region} keyword is used, the atom must also be in the specified
|
||||
geometric "region"_region.html in order to have electronic stopping applied to
|
||||
it. This is useful if the position of the bulk material is fixed. By default
|
||||
the electronic stopping is applied everywhere in the simulation cell.
|
||||
|
||||
:line
|
||||
|
||||
The energy ranges and stopping powers are read from the file {file}.
|
||||
Lines starting with {#} and empty lines are ignored. Otherwise each
|
||||
line must contain exactly [N+1] numbers, where [N] is the number of atom
|
||||
types in the simulation.
|
||||
|
||||
The first column is the energy for which the stopping powers on that
|
||||
line apply. The energies must be sorted from the smallest to the largest.
|
||||
The other columns are the stopping powers \(S_e\) for each atom type,
|
||||
in ascending order, in force "units"_units.html. The stopping powers for
|
||||
intermediate energy values are calculated with linear interpolation between
|
||||
2 nearest points.
|
||||
|
||||
For example:
|
||||
|
||||
# This is a comment
|
||||
# atom-1 atom-2
|
||||
# eV eV/Ang eV/Ang # units metal
|
||||
10 0 0
|
||||
250 60 80
|
||||
750 100 150 :pre
|
||||
|
||||
|
||||
If an atom which would have electronic stopping applied to it has a
|
||||
kinetic energy higher than the largest energy given in {file}, LAMMPS
|
||||
will exit with an error message.
|
||||
|
||||
The stopping power depends on the energy of the ion and the target
|
||||
material. The electronic stopping table can be obtained from
|
||||
scientific publications, experimental databases or by using
|
||||
"SRIM"_#SRIM software. Other programs such as "CasP"_#CasP or
|
||||
"PASS"_#PASS can calculate the energy deposited as a function
|
||||
of the impact parameter of the ion; these results can be used
|
||||
to derive the stopping power.
|
||||
|
||||
[Restart, fix_modify, output, run start/stop, minimize info:]
|
||||
|
||||
No information about this fix is written to "binary restart
|
||||
files"_restart.html.
|
||||
|
||||
The "fix_modify"_fix_modify.html options are not supported.
|
||||
|
||||
This fix computes a global scalar, which can be accessed by various
|
||||
"output commands"_Howto_output.html. The scalar is the total energy
|
||||
loss from electronic stopping applied by this fix since the start of
|
||||
the latest run. It is considered "intensive".
|
||||
|
||||
The {start/stop} keywords of the "run"_run.html command have no effect
|
||||
on this fix.
|
||||
|
||||
[Restrictions:]
|
||||
|
||||
This pair style is part of the USER-MISC package. It is only enabled if
|
||||
LAMMPS was built with that package. See the "Build package"_Build_package.html
|
||||
doc page for more info.
|
||||
|
||||
[Default:]
|
||||
|
||||
The default is no limitation by region, and minneigh = 1.
|
||||
|
||||
:line
|
||||
:link(elstopping)
|
||||
[(electronic stopping)] Wikipedia - Electronic Stopping Power: https://en.wikipedia.org/wiki/Stopping_power_%28particle_radiation%29
|
||||
|
||||
:link(Nordlund98)
|
||||
[(Nordlund98)] Nordlund, Kai, et al. Physical Review B 57.13 (1998): 7556.
|
||||
|
||||
:link(Nordlund95)
|
||||
[(Nordlund95)] Nordlund, Kai. Computational materials science 3.4 (1995): 448-456.
|
||||
|
||||
:link(SRIM)
|
||||
[(SRIM)] SRIM webpage: http://www.srim.org/
|
||||
|
||||
:link(CasP)
|
||||
[(CasP)] CasP webpage: https://www.helmholtz-berlin.de/people/gregor-schiwietz/casp_en.html
|
||||
|
||||
:link(PASS)
|
||||
[(PASS)] PASS webpage: https://www.sdu.dk/en/DPASS
|
||||
@ -40,6 +40,7 @@ Fixes :h1
|
||||
fix_dt_reset
|
||||
fix_efield
|
||||
fix_ehex
|
||||
fix_electron_stopping
|
||||
fix_enforce2d
|
||||
fix_eos_cv
|
||||
fix_eos_table
|
||||
|
||||
@ -26,12 +26,13 @@ kim_query latconst get_test_result test=TE_156715955670 model=MO_800509458712 &
|
||||
The kim_query command allows to retrieve properties from the OpenKIM
|
||||
through a web query. The result is stored in a string style
|
||||
"variable"_variable.html, the name of which must be given as the first
|
||||
argument of the kim_query command. The second required argument is the
|
||||
name of the actual query function (e.g. {get_test_result}). All following
|
||||
argument of the kim_query command. The second required argument is the
|
||||
name of the actual query function (e.g. {get_test_result}). All following
|
||||
arguments are parameters handed over to the web query in the format
|
||||
{keyword=value}. This list of supported keywords and the type of how
|
||||
the value has to be encoded depends on the query function used.
|
||||
For more details on this, please refer to the OpenKIM homepage.
|
||||
{keyword=value}. The list of supported keywords and the type of how
|
||||
the value has to be encoded depends on the query function used. This
|
||||
mirrors the functionality available on the OpenKIM webpage at
|
||||
"https://query.openkim.org"_https://query.openkim.org/
|
||||
|
||||
[Restrictions:]
|
||||
|
||||
|
||||
@ -266,6 +266,7 @@ fix_drude_transform.html
|
||||
fix_dt_reset.html
|
||||
fix_efield.html
|
||||
fix_ehex.html
|
||||
fix_electron_stopping.html
|
||||
fix_enforce2d.html
|
||||
fix_eos_cv.html
|
||||
fix_eos_table.html
|
||||
|
||||
@ -19,7 +19,7 @@ pair_style granular command :h3
|
||||
|
||||
pair_style granular cutoff :pre
|
||||
|
||||
cutoff = global cutoff (optional). See discussion below. :l
|
||||
cutoff = global cutoff (optional). See discussion below. :ul
|
||||
|
||||
[Examples:]
|
||||
|
||||
|
||||
@ -47,11 +47,16 @@ equation can be found in "(Leven1)"_#Leven1 and "(Maaravi)"_#Maaravi2.
|
||||
It is important to include all the pairs to build the neighbor list for
|
||||
calculating the normals.
|
||||
|
||||
NOTE: This potential is intended for interactions between two different
|
||||
layers of graphene or hexagonal boron nitride. Therefore, to avoid
|
||||
interaction within the same layers, each layer should have a separate
|
||||
molecule id and is recommended to use "full" atom style in the data
|
||||
file.
|
||||
NOTE: This potential (ILP) is intended for interlayer interactions between two
|
||||
different layers of graphene, hexagonal boron nitride (h-BN) and their hetero-junction.
|
||||
To perform a realistic simulation, this potential must be used in combination with
|
||||
intra-layer potential, such as "AIREBO"_pair_airebo.html or "Tersoff"_pair_tersoff.html potential.
|
||||
To keep the intra-layer properties unaffected, the interlayer interaction
|
||||
within the same layers should be avoided. Hence, each atom has to have a layer
|
||||
identifier such that atoms residing on the same layer interact via the
|
||||
appropriate intra-layer potential and atoms residing on different layers
|
||||
interact via the ILP. Here, the molecule id is chosen as the layer identifier,
|
||||
thus a data file with the "full" atom style is required to use this potential.
|
||||
|
||||
The parameter file (e.g. BNCH.ILP), is intended for use with {metal}
|
||||
"units"_units.html, with energies in meV. Two additional parameters,
|
||||
@ -62,6 +67,10 @@ list for calculating the normals for each atom pair.
|
||||
NOTE: The parameters presented in the parameter file (e.g. BNCH.ILP),
|
||||
are fitted with taper function by setting the cutoff equal to 16.0
|
||||
Angstrom. Using different cutoff or taper function should be careful.
|
||||
The parameters for atoms pairs between Boron and Nitrogen are fitted with
|
||||
a screened Coulomb interaction "coul/shield"_pair_coul_shield.html. Therefore,
|
||||
to simulated the properties of h-BN correctly, this potential must be used in
|
||||
combination with the pair style "coul/shield"_pair_coul_shield.html.
|
||||
|
||||
NOTE: Two new sets of parameters of ILP for two-dimensional hexagonal
|
||||
Materials are presented in "(Ouyang)"_#Ouyang. These parameters provide
|
||||
|
||||
@ -42,10 +42,16 @@ the last term in the equation for {Vij} above. This is essential only
|
||||
when the tapper function is turned off. The formula of taper function
|
||||
can be found in pair style "ilp/graphene/hbn"_pair_ilp_graphene_hbn.html.
|
||||
|
||||
NOTE: This potential is intended for interactions between two different
|
||||
graphene layers. Therefore, to avoid interaction within the same layers,
|
||||
each layer should have a separate molecule id and is recommended to use
|
||||
"full" atom style in the data file.
|
||||
NOTE: This potential (ILP) is intended for interlayer interactions between two
|
||||
different layers of graphene. To perform a realistic simulation, this potential
|
||||
must be used in combination with intra-layer potential, such as
|
||||
"AIREBO"_pair_airebo.html or "Tersoff"_pair_tersoff.html potential.
|
||||
To keep the intra-layer properties unaffected, the interlayer interaction
|
||||
within the same layers should be avoided. Hence, each atom has to have a layer
|
||||
identifier such that atoms residing on the same layer interact via the
|
||||
appropriate intra-layer potential and atoms residing on different layers
|
||||
interact via the ILP. Here, the molecule id is chosen as the layer identifier,
|
||||
thus a data file with the "full" atom style is required to use this potential.
|
||||
|
||||
The parameter file (e.g. CH.KC), is intended for use with {metal}
|
||||
"units"_units.html, with energies in meV. Two additional parameters, {S},
|
||||
|
||||
@ -357,6 +357,13 @@ The {meam/c} style is provided in the USER-MEAMC package. It is
|
||||
only enabled if LAMMPS was built with that package.
|
||||
See the "Build package"_Build_package.html doc page for more info.
|
||||
|
||||
The maximum number of elements, that can be read from the MEAM
|
||||
library file, is determined at compile time. The default is 5.
|
||||
If you need support for more elements, you have to change the
|
||||
define for the constant 'maxelt' at the beginning of the file
|
||||
src/USER-MEAMC/meam.h and update/recompile LAMMPS. There is no
|
||||
limit on the number of atoms types.
|
||||
|
||||
[Related commands:]
|
||||
|
||||
"pair_coeff"_pair_coeff.html, "pair_style eam"_pair_eam.html,
|
||||
|
||||
@ -134,7 +134,7 @@ The {mom} and {rot} keywords are used by {create}. If mom = yes, the
|
||||
linear momentum of the newly created ensemble of velocities is zeroed;
|
||||
if rot = yes, the angular momentum is zeroed.
|
||||
|
||||
*line
|
||||
:line
|
||||
|
||||
If specified, the {temp} keyword is used by {create} and {scale} to
|
||||
specify a "compute"_compute.html that calculates temperature in a
|
||||
|
||||
Reference in New Issue
Block a user