diff --git a/bench/FERMI/README b/bench/FERMI/README index b81356dee893706e3a7cb6b564c672928630a707..f8772483d138959b34b004698547ddf9e4418f4b 100644 --- a/bench/FERMI/README +++ b/bench/FERMI/README @@ -19,33 +19,33 @@ directories for instructions on how to build the packages with different precisions. The GPU and USER-CUDA sub-sections of the doc/Section_accelerate.html file also describes this process. -Make.py -d ~/lammps -j 16 -p #all orig -m linux -o cpu exe -Make.py -d ~/lammps -j 16 -p #all opt orig -m linux -o opt exe -Make.py -d ~/lammps -j 16 -p #all omp orig -m linux -o omp exe +Make.py -d ~/lammps -j 16 -p #all orig -m linux -o cpu -a exe +Make.py -d ~/lammps -j 16 -p #all opt orig -m linux -o opt -a exe +Make.py -d ~/lammps -j 16 -p #all omp orig -m linux -o omp -a exe Make.py -d ~/lammps -j 16 -p #all gpu orig -m linux \ - -gpu mode=double arch=20 -o gpu_double libs exe + -gpu mode=double arch=20 -o gpu_double -a libs exe Make.py -d ~/lammps -j 16 -p #all gpu orig -m linux \ - -gpu mode=mixed arch=20 -o gpu_mixed libs exe + -gpu mode=mixed arch=20 -o gpu_mixed -a libs exe Make.py -d ~/lammps -j 16 -p #all gpu orig -m linux \ - -gpu mode=single arch=20 -o gpu_single libs exe + -gpu mode=single arch=20 -o gpu_single -a libs exe Make.py -d ~/lammps -j 16 -p #all cuda orig -m linux \ - -cuda mode=double arch=20 -o cuda_double libs exe + -cuda mode=double arch=20 -o cuda_double -a libs exe Make.py -d ~/lammps -j 16 -p #all cuda orig -m linux \ - -cuda mode=mixed arch=20 -o cuda_mixed libs exe + -cuda mode=mixed arch=20 -o cuda_mixed -a libs exe Make.py -d ~/lammps -j 16 -p #all cuda orig -m linux \ - -cuda mode=single arch=20 -o cuda_single libs exe -Make.py -d ~/lammps -j 16 -p #all intel orig -m linux -o intel_cpu exe -Make.py -d ~/lammps -j 16 -p #all kokkos orig -m linux -o kokkos_omp exe + -cuda mode=single arch=20 -o cuda_single -a libs exe +Make.py -d ~/lammps -j 16 -p #all intel orig -m linux -o intel_cpu -a exe +Make.py -d ~/lammps -j 16 -p #all kokkos orig -m linux -o kokkos_omp -a exe Make.py -d ~/lammps -j 16 -p #all kokkos orig -kokkos cuda arch=20 \ - -m cuda -o kokkos_cuda exe + -m cuda -o kokkos_cuda -a exe Make.py -d ~/lammps -j 16 -p #all opt omp gpu cuda intel kokkos orig \ -gpu mode=double arch=20 -cuda mode=double arch=20 -m linux \ - -o all libs exe + -o all -a libs exe Make.py -d ~/lammps -j 16 -p #all opt omp gpu cuda intel kokkos orig \ -kokkos cuda arch=20 -gpu mode=double arch=20 \ - -cuda mode=double arch=20 -m cuda -o all_cuda libs exe + -cuda mode=double arch=20 -m cuda -o all_cuda -a libs exe ------------------------------------------------------------------------ diff --git a/bench/README b/bench/README index 5d1a3bc057ae2226deb04b8f1c3931fdb85c5ec0..85d71cbb5d9ca41a46fff4b4cb22fbdd5e7af233 100644 --- a/bench/README +++ b/bench/README @@ -82,7 +82,7 @@ also leave off the "-fft fftw3" switch if you do not have the FFTW library will be used. cd src -Make.py -j 16 -p none molecule manybody kspace granular orig \ +Make.py -j 16 -p none molecule manybody kspace granular rigid orig \ -cc mpi wrap=icc -fft fftw3 -a file mpi ---------------------------------------------------------------------- diff --git a/bench/in.chute b/bench/in.chute index cf43fd7ff86616bfdc37b009a78e96943403f672..9f7c28ada3edeb4bf2b96a30b13ec8fc5b97b605 100644 --- a/bench/in.chute +++ b/bench/in.chute @@ -5,7 +5,7 @@ units lj atom_style sphere boundary p p fs newton off -communicate single vel yes +comm_modify vel yes read_data data.chute diff --git a/bench/in.chute.scaled b/bench/in.chute.scaled index cda244562089c5354a1f6baa65edcb462b712750..7bac8fe12dbaf61e052a0546bb300e075a3c1f58 100644 --- a/bench/in.chute.scaled +++ b/bench/in.chute.scaled @@ -8,7 +8,7 @@ units lj atom_style sphere boundary p p fs newton off -communicate single vel yes +comm_modify vel yes read_data data.chute diff --git a/doc/Eqs/fix_rattle_constraints.jpg b/doc/Eqs/fix_rattle_constraints.jpg new file mode 100644 index 0000000000000000000000000000000000000000..2ba86095cd3c3682160dedebb745413be563243b Binary files /dev/null and b/doc/Eqs/fix_rattle_constraints.jpg differ diff --git a/doc/Eqs/fix_rattle_constraints.tex b/doc/Eqs/fix_rattle_constraints.tex new file mode 100644 index 0000000000000000000000000000000000000000..daff0ce77587ed936989f060a89e08b487e9b4bd --- /dev/null +++ b/doc/Eqs/fix_rattle_constraints.tex @@ -0,0 +1,9 @@ +\documentclass[12pt]{article} +\usepackage{amsmath} + +\begin{document} +\begin{align*} +\mathbf r^{n+1}_{ij} \cdot \mathbf r^{n+1}_{ij} &= d^2_{ij} \quad \text{and} \\ +\mathbf v^{n+1}_{ij} \cdot \mathbf r^{n+1}_{ij} &= 0, \label{eq:velcon} +\end{align*} +\end{document} diff --git a/doc/Eqs/fix_rattle_rij.jpg b/doc/Eqs/fix_rattle_rij.jpg new file mode 100644 index 0000000000000000000000000000000000000000..b08e2fe02e650dab39f5f9b09930e2baece5436e Binary files /dev/null and b/doc/Eqs/fix_rattle_rij.jpg differ diff --git a/doc/Eqs/fix_rattle_rij.tex b/doc/Eqs/fix_rattle_rij.tex new file mode 100644 index 0000000000000000000000000000000000000000..fae0457c60c826baebcad3de458a41a656c59689 --- /dev/null +++ b/doc/Eqs/fix_rattle_rij.tex @@ -0,0 +1,8 @@ +\documentclass[12pt]{article} +\usepackage{amsmath} +\begin{document} +$$ + \mathbf r^{n+1}_{ij} = \mathbf r^n_j - \mathbf r^n_i +$$ +\end{document} + diff --git a/doc/Eqs/fix_ttm_blast.jpg b/doc/Eqs/fix_ttm_blast.jpg new file mode 100644 index 0000000000000000000000000000000000000000..d4ffe05f129715572923fcd32c547b64aee902f1 Binary files /dev/null and b/doc/Eqs/fix_ttm_blast.jpg differ diff --git a/doc/Eqs/fix_ttm_blast.tex b/doc/Eqs/fix_ttm_blast.tex new file mode 100644 index 0000000000000000000000000000000000000000..6871ed5cc68cce4012a9a382edc9bfec35a9d35b --- /dev/null +++ b/doc/Eqs/fix_ttm_blast.tex @@ -0,0 +1,13 @@ +\documentclass[12pt]{article} + +\begin{document} + +$$ + {\vec F}_i = - \partial U / \partial {\vec r}_i + {\vec F}_{langevin} - \nabla P_e/n_{ion} +$$ + +\end{document} + + + + diff --git a/doc/Eqs/fix_ttm_blast1.jpg b/doc/Eqs/fix_ttm_blast1.jpg new file mode 100644 index 0000000000000000000000000000000000000000..1106c627cbdc5c8d48cf9272513c799e4e65524a Binary files /dev/null and b/doc/Eqs/fix_ttm_blast1.jpg differ diff --git a/doc/Eqs/fix_ttm_blast1.tex b/doc/Eqs/fix_ttm_blast1.tex new file mode 100644 index 0000000000000000000000000000000000000000..642afe43003b8a426a74409a103a5af7297680cc --- /dev/null +++ b/doc/Eqs/fix_ttm_blast1.tex @@ -0,0 +1,13 @@ +\documentclass[12pt]{article} + +\begin{document} + +$$ + \nabla_x P_e = \left[\frac{C_e{}T_e(x)\lambda}{(x+\lambda)^2} + \frac{x}{x+\lambda}\frac{(C_e{}T_e)_{x+\Delta x}-(C_e{}T_e)_{x}}{\Delta x} \right] +$$ + +\end{document} + + + + diff --git a/doc/Eqs/fix_ttm_ce.jpg b/doc/Eqs/fix_ttm_ce.jpg new file mode 100644 index 0000000000000000000000000000000000000000..4f439e31e6b22ed3268e19d3d06852801812f93a Binary files /dev/null and b/doc/Eqs/fix_ttm_ce.jpg differ diff --git a/doc/Eqs/fix_ttm_ce.tex b/doc/Eqs/fix_ttm_ce.tex new file mode 100644 index 0000000000000000000000000000000000000000..f787590b8f3d84c7f0bd660e667c64f5c4317883 --- /dev/null +++ b/doc/Eqs/fix_ttm_ce.tex @@ -0,0 +1,13 @@ +\documentclass[12pt]{article} + +\begin{document} + +$$ + C_e = C_0 + (a_0 + a_1 X + a_2 X^2 + a_3 X^3 + a_4 X^4) \exp (-(AX)^2) +$$ + +\end{document} + + + + diff --git a/doc/Eqs/fix_ttm_mod.jpg b/doc/Eqs/fix_ttm_mod.jpg new file mode 100644 index 0000000000000000000000000000000000000000..7cc67200f96bae3be7633d8d0c52ed76eabd1474 Binary files /dev/null and b/doc/Eqs/fix_ttm_mod.jpg differ diff --git a/doc/Eqs/fix_ttm_mod.tex b/doc/Eqs/fix_ttm_mod.tex new file mode 100644 index 0000000000000000000000000000000000000000..d0a313e6761f094e363fd7c59b407be9ae073583 --- /dev/null +++ b/doc/Eqs/fix_ttm_mod.tex @@ -0,0 +1,15 @@ +\documentclass[12pt]{article} + +\begin{document} + +$$ + C_e \rho_e \frac{\partial T_e}{\partial t} = + \bigtriangledown (\kappa_e \bigtriangledown T_e) - + g_p (T_e - T_a) + g_s T_a' + \theta (x-x_{surface})I_0 \exp(-x/l_{skin}) +$$ + +\end{document} + + + + diff --git a/doc/Eqs/pair_cs.jpg b/doc/Eqs/pair_cs.jpg new file mode 100644 index 0000000000000000000000000000000000000000..b870a3bdf4617f353a739d0d7148dd27ac02669e Binary files /dev/null and b/doc/Eqs/pair_cs.jpg differ diff --git a/doc/Eqs/pair_cs.tex b/doc/Eqs/pair_cs.tex new file mode 100644 index 0000000000000000000000000000000000000000..b7eacb8d5b2704a0f39314e586724376ab4b0dae --- /dev/null +++ b/doc/Eqs/pair_cs.tex @@ -0,0 +1,9 @@ +\documentstyle[12pt]{article} + +\begin{document} + +$$ + E = \frac{C q_i q_j}{\epsilon (r + r_{min})} \qquad r \rightarrow 0 +$$ + +\end{document} diff --git a/doc/Manual.html b/doc/Manual.html index d997dee571a8d163b71898dfa365905e2afa45a3..42dbfd34ce21191a58c861cad2820b93281833ee 100644 --- a/doc/Manual.html +++ b/doc/Manual.html @@ -1,7 +1,7 @@ LAMMPS Users Manual - + @@ -22,7 +22,7 @@

LAMMPS Documentation

-

26 Nov 2014 version +

6 Apr 2015 version

Version info:

@@ -200,6 +200,10 @@ it gives quick access to documentation for all LAMMPS commands. 6.21 Calculating viscosity
6.22 Calculating a diffusion coefficient +
+ 6.23 Using chunks to calculate system properties +
+ 6.24 Setting parameters for pppm/disp
  • Example problems @@ -241,17 +245,21 @@ it gives quick access to documentation for all LAMMPS commands.
  • Python interface - -

    All but the first 3 calculate velocity biases (i.e. advection +

    All but the first 3 calculate velocity biases directly (e.g. advection velocities) that are removed when computing the thermal temperature. Compute temp/sphere and compute temp/asphere compute kinetic energy for finite-size particles that includes rotational degrees of freedom. -They both allow, as an extra argument, which is another temperature -compute that subtracts a velocity bias. This allows the translational -velocity of spherical or aspherical particles to be adjusted in -prescribed ways. +They both allow for velocity biases indirectly, via an optional extra +argument, another temperature compute that subtracts a velocity bias. +This allows the translational velocity of spherical or aspherical +particles to be adjusted in prescribed ways.

    Thermostatting in LAMMPS is performed by fixes, or in one case by a pair style. Several thermostatting fixes are available: @@ -1657,15 +1660,21 @@ to the per-particle thermostatting of fix langevin.

    Any of the thermostatting fixes can use temperature computes that -remove bias for two purposes: (a) computing the current temperature to -compare to the requested target temperature, and (b) adjusting only -the thermal temperature component of the particle's velocities. See -the doc pages for the individual fixes and for the +remove bias which has two effects. First, the current calculated +temperature, which is compared to the requested target temperature, is +caluclated with the velocity bias removed. Second, the thermostat +adjusts only the thermal temperature component of the particle's +velocities, which are the velocities with the bias removed. The +removed bias is then added back to the adjusted velocities. See the +doc pages for the individual fixes and for the fix_modify command for instructions on how to assign a temperature compute to a thermostatting fix. For example, you can apply a thermostat to only the x and z components of velocity by using it in conjunction with compute -temp/partial. +temp/partial. Of you could thermostat only +the thermal temperature of a streaming flow of particles without +affecting the streaming velocity, by using compute +temp/profile.

    IMPORTANT NOTE: Only the nvt fixes perform time integration, meaning they update the velocities and positions of particles due to forces @@ -1905,15 +1914,18 @@ void *lammps_extract_atom(void *, char *) void *lammps_extract_compute(void *, char *, int, int) void *lammps_extract_fix(void *, char *, int, int, int, int) void *lammps_extract_variable(void *, char *, char *) +int lammps_set_variable(void *, char *, char *) int lammps_get_natoms(void *) void lammps_get_coords(void *, double *) void lammps_put_coords(void *, double *)

    These can extract various global or per-atom quantities from LAMMPS as -well as values calculated by a compute, fix, or variable. The "get" -and "put" operations can retrieve and reset atom coordinates. -See the library.cpp file and its associated header file library.h for -details. +well as values calculated by a compute, fix, or variable. The +"set_variable" function can set an existing string-style variable to a +new value, so that subsequent LAMMPS commands can access the variable. +The "get" and "put" operations can retrieve and reset atom +coordinates. See the library.cpp file and its associated header file +library.h for details.

    The key idea of the library interface is that you can write any functions you wish to define how your code talks to LAMMPS and add @@ -2146,6 +2158,455 @@ and thus extract D.

    +

    6.23 Using chunks to calculate system properties +

    +

    In LAMMS, "chunks" are collections of atoms, as defined by the +compute chunk/atom command, which assigns +each atom to a chunk ID (or to no chunk at all). The number of chunks +and the assignment of chunk IDs to atoms can be static or change over +time. Examples of "chunks" are molecules or spatial bins or atoms +with similar values (e.g. coordination number or potential energy). +

    +

    The per-atom chunk IDs can be used as input to two other kinds of +commands, to calculate various properties of a system: +

    + +

    Here, each of the 3 kinds of chunk-related commands is briefly +overviewed. Then some examples are given of how to compute different +properties with chunk commands. +

    +
    Compute chunk/atom command: +
    +

    This compute can assign atoms to chunks of various styles. Only atoms +in the specified group and optional specified region are assigned to a +chunk. Here are some possible chunk definitions: +

    +
    + + + + + + + +
    atoms in same molecule chunk ID = molecule ID
    atoms of same atom type chunk ID = atom type
    all atoms with same atom property (charge, radius, etc) chunk ID = output of compute property/atom
    atoms in same cluster chunk ID = output of compute cluster/atom command
    atoms in same spatial bin chunk ID = bin ID
    atoms in same rigid body chunk ID = molecule ID used to define rigid bodies
    atoms with similar potential energy chunk ID = output of compute pe/atom
    atoms with same local defect structure chunk ID = output of compute centro/atom or compute coord/atom command +
    + +

    Note that chunk IDs are integer values, so for atom properties or +computes that produce a floating point value, they will be truncated +to an integer. You could also use the compute in a variable that +scales the floating point value to spread it across multiple intergers. +

    +

    Spatial bins can be of various kinds, e.g. 1d bins = slabs, 2d bins = +pencils, 3d bins = boxes, spherical bins, cylindrical bins. +

    +

    This compute also calculates the number of chunks Nchunk, which is +used by other commands to tally per-chunk data. Nchunk can be a +static value or change over time (e.g. the number of clusters). The +chunk ID for an individual atom can also be static (e.g. a molecule +ID), or dynamic (e.g. what spatial bin an atom is in as it moves). +

    +

    Note that this compute allows the per-atom output of other +computes, fixes, and +variables to be used to define chunk IDs for each +atom. This means you can write your own compute or fix to output a +per-atom quantity to use as chunk ID. See +Section_modify of the documentation for how to +do this. You can also define a per-atom variable in +the input script that uses a formula to generate a chunk ID for each +atom. +

    +
    Fix ave/chunk command: +
    +

    This fix takes the ID of a compute +chunk/atom command as input. For each chunk, +it then sums one or more specified per-atom values over the atoms in +each chunk. The per-atom values can be any atom property, such as +velocity, force, charge, potential energy, kinetic energy, stress, +etc. Additional keywords are defined for per-chunk properties like +density and temperature. More generally any per-atom value generated +by other computes, fixes, and per-atom +variables, can be summed over atoms in each chunk. +

    +

    Similar to other averaging fixes, this fix allows the summed per-chunk +values to be time-averaged in various ways, and output to a file. The +fix produces a global array as output with one row of values per +chunk. +

    +
    Compute */chunk commands: +
    +

    Currently the following computes operate on chunks of atoms to produce +per-chunk values. +

    + +

    They each take the ID of a compute +chunk/atom command as input. As their names +indicate, they calculate the center-of-mass, radius of gyration, +moments of inertia, mean-squared displacement, temperature, torque, +and velocity of center-of-mass for each chunk of atoms. The compute +property/chunk command can tally the +count of atoms in each chunk and extract other per-chunk properties. +

    +

    The reason these various calculations are not part of the fix +ave/chunk command, is that each requires a more +complicated operation than simply summing and averaging over per-atom +values in each chunk. For example, many of them require calculation +of a center of mass, which requires summing mass*position over the +atoms and then dividing by summed mass. +

    +

    All of these computes produce a global vector or global array as +output, wih one or more values per chunk. They can be used +in various ways: +

    + +
    Example calculations with chunks +
    +

    Here are eaxmples using chunk commands to calculate various +properties: +

    +

    (1) Average velocity in each of 1000 2d spatial bins: +

    +
    compute cc1 all chunk/atom bin/2d x 0.0 0.1 y lower 0.01 units reduced
+fix 1 all ave/chunk 100 10 1000 cc1 vx vy file tmp.out 
+
    +

    (2) Temperature in each spatial bin, after subtracting a flow +velocity: +

    +
    compute cc1 all chunk/atom bin/2d x 0.0 0.1 y lower 0.1 units reduced
+compute vbias all temp/profile 1 0 0 y 10
+fix 1 all ave/chunk 100 10 1000 cc1 temp bias vbias file tmp.out 
+
    +

    (3) Center of mass of each molecule: +

    +
    compute cc1 all chunk/atom molecule
+compute myChunk all com/chunk cc1
+fix 1 all ave/time 100 1 100 c_myChunk file tmp.out mode vector 
+
    +

    (4) Total force on each molecule and ave/max across all molecules: +

    +
    compute cc1 all chunk/atom molecule
+fix 1 all ave/chunk 1000 1 1000 cc1 fx fy fz file tmp.out
+variable xave equal ave(f_12)
+variable xmax equal max(f_12)
+thermo 1000
+thermo_style custom step temp v_xave v_xmax 
+
    +

    (5) Histogram of cluster sizes: +

    +
    compute cluster all cluster/atom 1.0
+compute cc1 all chunk/atom c_cluster compress yes
+compute size all property/chunk cc1 count
+fix 1 all ave/histo 100 1 100 0 20 20 c_size mode vector ave running beyond ignore file tmp.histo 
+
    +
    + +

    6.24 Setting parameters for the kspace_style pppm/disp command +

    +

    The PPPM method computes interactions by splitting the pair potential +into two parts, one of which is computed in a normal pairwise fashion, +the so-called real-space part, and one of which is computed using the +Fourier transform, the so called reciprocal-space or kspace part. For +both parts, the potential is not computed exactly but is approximated. +Thus, there is an error in both parts of the computation, the +real-space and the kspace error. The just mentioned facts are true +both for the PPPM for Coulomb as well as dispersion interactions. The +deciding difference - and also the reason why the parameters for +pppm/disp have to be selected with more care - is the impact of the +errors on the results: The kspace error of the PPPM for Coulomb and +dispersion interaction and the real-space error of the PPPM for +Coulomb interaction have the character of noise. In contrast, the +real-space error of the PPPM for dispersion has a clear physical +interpretation: the underprediction of cohesion. As a consequence, the +real-space error has a much stronger effect than the kspace error on +simulation results for pppm/disp. Parameters must thus be chosen in a +way that this error is much smaller than the kspace error. +

    +

    When using pppm/disp and not making any specifications on the PPPM +parameters via the kspace modify command, parameters will be tuned +such that the real-space error and the kspace error are equal. This +will result in simulations that are either inaccurate or slow, both of +which is not desirable. For selecting parameters for the pppm/disp +that provide fast and accurate simulations, there are two approaches, +which both have their up- and downsides. +

    +

    The first approach is to set desired real-space an kspace accuracies +via the kspace_modify force/disp/real and kspace_modify +force/disp/kspace commands. Note that the accuracies have to be +specified in force units and are thus dependend on the chosen unit +settings. For real units, 0.0001 and 0.002 seem to provide reasonable +accurate and efficient computations for the real-space and kspace +accuracies. 0.002 and 0.05 work well for most systems using lj +units. PPPM parameters will be generated based on the desired +accuracies. The upside of this approach is that it usually provides a +good set of parameters and will work for both the kspace_modify diff +ad and kspace_modify diff ik options. The downside of the method +is that setting the PPPM parameters will take some time during the +initialization of the simulation. +

    +

    The second approach is to set the parameters for the pppm/disp +explicitly using the kspace_modify mesh/disp, kspace_modify +order/disp, and kspace_modify gewald/disp commands. This approach +requires a more experienced user who understands well the impact of +the choice of parameters on the simulation accuracy and +performance. This approach provides a fast initialization of the +simulation. However, it is sensitive to errors: A combination of +parameters that will perform well for one system might result in +far-from-optimal conditions for other simulations. For example, +parametes that provide accurate and fast computations for +all-atomistic force fields can provide insufficient accuracy or +united-atomistic force fields (which is related to that the latter +typically have larger dispersion coefficients). +

    +

    To avoid inaccurate or inefficient simulations, the pppm/disp stops +simulations with an error message if no action is taken to control the +PPPM parameters. If the automatic parameter generation is desired and +real-space and kspace accuracies are desired to be equal, this error +message can be suppressed using the kspace_modify disp/auto yes +command. +

    +

    A reasonable approach that combines the upsides of both methods is to +make the first run using the kspace_modify force/disp/real and +kspace_modify force/disp/kspace commands, write down the PPPM +parameters from the outut, and specify these parameters using the +second approach in subsequent runs (which have the same composition, +force field, and approximately the same volume). +

    +

    Concerning the performance of the pppm/disp there are two more things +to consider. The first is that when using the pppm/disp, the cutoff +parameter does no longer affect the accuracy of the simulation +(subject to that gewald/disp is adjusted when changing the cutoff). +The performance can thus be increased by examining different values +for the cutoff parameter. A lower bound for the cutoff is only set by +the truncation error of the repulsive term of pair potentials. +

    +

    The second is that the mixing rule of the pair style has an impact on +the computation time when using the pppm/disp. Fastest computations +are achieved when using the geometric mixing rule. Using the +arithmetic mixing rule substantially increases the computational cost. +The computational overhead can be reduced using the kspace_modify +mix/disp geom and kspace_modify splittol commands. The first +command simply enforces geometric mixing of the dispersion +coeffiecients in kspace computations. This introduces some error in +the computations but will also significantly speed-up the +simulations. The second keyword sets the accuracy with which the +dispersion coefficients are approximated using a matrix factorization +approach. This may result in better accuracy then using the first +command, but will usually also not provide an equally good increase of +efficiency. +

    +

    Finally, pppm/disp can also be used when no mixing rules apply. +This can be achieved using the kspace_modify mix/disp none command. +Note that the code does not check automatically whether any mixing +rule is fulfilled. If mixing rules do not apply, the user will have +to specify this command explicitly. +

    +
    + +

    6.25 Adiabatic core/shell model +

    +

    The adiabatic core-shell model by Mitchell and +Finchham is a simple method for adding +polarizability to a system. In order to mimic the electron shell of +an ion, a ghost atom is attached to it. This way the ions are split +into a core and a shell where the latter is meant to react to the +electrostatic environment inducing polarizability. +

    +

    Technically, shells are attached to the cores by a spring force f = +k*r where k is a parametrized spring constant and r is the distance +between the core and the shell. The charges of the core and the shell +add up to the ion charge, thus q(ion) = q(core) + q(shell). In a +similar fashion the mass of the ion is distributed on the core and the +shell with the core having the larger mass. +

    +

    To run this model in LAMMPS, atom_style full can +be used since atom charge and bonds are needed. Each kind of +core/shell pair requires two atom types and a bond type. The core and +shell of a core/shell pair should be bonded to each other with a +harmonic bond that provides the spring force. For example, a data file +for NaCl, as found in examples/coreshell, has this format: +

    +
    432   atoms  # core and shell atoms
+216   bonds  # number of core/shell springs 
+
    +
    4     atom types  # 2 cores and 2 shells for Na and Cl 
+2     bond types 
+
    +
    0.0 24.09597 xlo xhi
+0.0 24.09597 ylo yhi
+0.0 24.09597 zlo zhi 
+
    +
    Masses       # core/shell mass ratio = 0.1 
+
    +
    1 20.690784  # Na core
+2 31.90500   # Cl core
+3 2.298976   # Na shell
+4 3.54500    # Cl shell 
+
    +
    Atoms 
+
    +
    1    1    2   1.5005    0.00000000   0.00000000   0.00000000 # core of core/shell pair 1
+2    1    4  -2.5005    0.00000000   0.00000000   0.00000000 # shell of core/shell pair 1
+3    2    1   1.5056    4.01599500   4.01599500   4.01599500 # core of core/shell pair 2
+4    2    3  -0.5056    4.01599500   4.01599500   4.01599500 # shell of core/shell pair 2 
+(...) 
+
    +
    Bonds   # Bond topology for spring forces 
+
    +
    1     2     1     2   # spring for core/shell pair 1
+2     2     3     4   # spring for core/shell pair 2 
+(...) 
+
    +

    Non-Coulombic (e.g. Lennard-Jones) pairwise interactions are only +defined between the shells. Coulombic interactions are defined +between all cores and shells. If desired, additional bonds can be +specified between cores. +

    +

    The special_bonds command should be used to +turn-off the Coulombic interaction within core/shell pairs, since that +interaction is set by the bond spring. This is done using the +special_bonds command with a 1-2 weight = 0.0, +which is the default value. +

    +

    Since the core/shell model permits distances of r = 0.0 between the +core and shell, a pair style with a "cs" suffix needs to be used to +implement a valid long-range Coulombic correction. Several such pair +styles are provided in the CORESHELL package. See this doc +page for details. All of the core/shell enabled pair +styles require the use of a long-range Coulombic solver, as specified +by the kspace_style command. Either the PPPM or +Ewald solvers can be used. +

    +

    For the NaCL example problem, these pair style and bond style settings +are used: +

    +
    pair_style      born/coul/long/cs 20.0 20.0
+pair_coeff      * *      0.0 1.000   0.00  0.00   0.00
+pair_coeff      3 3    487.0 0.23768 0.00  1.05   0.50 #Na-Na
+pair_coeff      3 4 145134.0 0.23768 0.00  6.99   8.70 #Na-Cl
+pair_coeff      4 4 405774.0 0.23768 0.00 72.40 145.40 #Cl-Cl 
+
    +
    bond_style      harmonic
+bond_coeff      1 63.014 0.0
+bond_coeff      2 25.724 0.0 
+
    +

    When running dynamics with the adiabatic core/shell model, the +following issues should be considered. Since the relative motion of +the core and shell particles corresponds to the polarization, typical +thermostats can alter the polarization behaviour, meaining the shell +will not react freely to its electrostatic environment. Therefore +it's typically desirable to decouple the relative motion of the +core/shell pair, which is an imaginary degree of freedom, from the +real physical system. To do that, the compute +temp/cs command can be used, in conjunction with +any of the thermostat fixes, such as fix nvt or fix +langevin. This compute uses the center-of-mass velocity +of the core/shell pairs to calculate a temperature, and insures that +velocity is what is rescaled for thermostatting purposes. The +compute temp/cs command requires input of two +groups, one for the core atoms, another for the shell atoms. These +can be defined using the group type command. Note that +to perform thermostatting using this definition of temperature, the +fix modify temp command should be used to assign the +comptue to the thermostat fix. Likewise the thermo_modify +temp command can be used to make this temperature +be output for the overall system. +

    +

    For the NaCl example, this can be done as follows: +

    +
    group cores type 1 2
+group shells type 3 4
+compute CSequ all temp/cs cores shells
+fix thermoberendsen all temp/berendsen 1427 1427 0.4    # thermostat for the true physical system
+fix thermostatequ all nve                               # integrator as needed for the berendsen thermostat
+fix_modify thermoberendsen temp CSequ
+thermo_modify temp CSequ                                # output of center-of-mass derived temperature 
+
    +

    When intializing the velocities of a system with core/shell pairs, it +is also desirable to not introduce energy into the relative motion of +the core/shell particles, but only assign a center-of-mass velocity to +the pairs. This can be done by using the bias keyword of the +velocity create command and assigning the compute +temp/cs command to the temp keyword of the +velocity commmand, e.g. +

    +
    velocity all create 1427 134 bias yes temp CSequ
+velocity all scale 1427 temp CSequ 
+
    +

    It is important to note that the polarizability of the core/shell +pairs is based on their relative motion. Therefore the choice of +spring force and mass ratio need to ensure much faster relative motion +of the 2 atoms within the core/shell pair than their center-of-mass +velocity. This allow the shells to effectively react instantaneously +to the electrostatic environment. This fast movement also limits the +timestep size that can be used. +

    +

    Additionally, the mass mismatch of the core and shell particles means +that only a small amount of energy is transfered to the decoupled +imaginary degrees of freedom. However, this transfer will typically +lead to a a small drift in total energy over time. This internal +energy can be monitored using the compute +chunk/atom and compute +temp/chunk commands. The internal kinetic +energies of each core/shell pair can then be summed using the sum() +special functino of the variable command. Or they can +be time/averaged and output using the fix ave/time +command. To use these commands, each core/shell pair must be defined +as a "chunk". If each core/shell pair is defined as its own molecule, +the molecule ID can be used to define the chunks. If cores are bonded +to each other to form larger molecules, then another way to define the +chunks is to use the fix property/atom to +assign a core/shell ID to each atom via a special field in the data +file read by the read_data command. This field can +then be accessed by the compute +property/atom command, to use as input to +the compute chunk/atom command to define the +core/shell pairs as chunks. +

    +

    For example, +

    +
    fix csinfo all property/atom i_CSID                       # property/atom command
+read_data NaCl_CS_x0.1_prop.data fix csinfo NULL CS-Info  # atom property added in the data-file
+compute prop all property/atom i_CSID
+compute cs_chunk all chunk/atom c_prop
+compute cstherm all temp/chunk cs_chunk temp internal com yes cdof 3.0     # note the chosen degrees of freedom for the core/shell pairs
+fix ave_chunk all ave/time 10 1 10 c_cstherm file chunk.dump mode vector 
+
    +

    The additional section in the date file would be formatted like this: +

    +
    CS-Info         # header of additional section 
+
    +
    1   1           # column 1 = atom ID, column 2 = core/shell ID 
+2   1   
+3   2   
+4   2   
+5   3   
+6   3   
+7   4   
+8   4   
+(...) 
+
    +
    +
    @@ -2191,4 +2652,9 @@ Phys, 79, 926 (1983).

    (Shinoda) Shinoda, Shiga, and Mikami, Phys Rev B, 69, 134103 (2004).

    + + +

    (Mitchell and Finchham) Mitchell, Finchham, J Phys Condensed Matter, +5, 1031-1038 (1993). +

    diff --git a/doc/Section_howto.txt b/doc/Section_howto.txt index cbbf92334a0a39b8a1f6aece1e27726087d76d94..bccfea188296407451f06d3af348529fb962e3dd 100644 --- a/doc/Section_howto.txt +++ b/doc/Section_howto.txt @@ -31,7 +31,10 @@ This section describes how to perform common tasks using LAMMPS. 6.19 "Library interface to LAMMPS"_#howto_19 6.20 "Calculating thermal conductivity"_#howto_20 6.21 "Calculating viscosity"_#howto_21 -6.22 "Calculating a diffusion coefficient"_#howto_22 :all(b) +6.22 "Calculating a diffusion coefficient"_#howto_22 +6.23 "Using chunks to calculate system properties"_#howto_23 +6.24 "Setting parameters for the kspace_style pppm/disp command"_#howto_24 +6.25 "Adiabatic core/shell model"_#howto_25 :all(b) The example input scripts included in the LAMMPS distribution and highlighted in "Section_example"_Section_example.html also show how to @@ -1603,15 +1606,15 @@ pressure"_compute_pressure.html command calculates pressure. "compute temp/ramp"_compute_temp_ramp.html "compute temp/region"_compute_temp_region.html :ul -All but the first 3 calculate velocity biases (i.e. advection +All but the first 3 calculate velocity biases directly (e.g. advection velocities) that are removed when computing the thermal temperature. "Compute temp/sphere"_compute_temp_sphere.html and "compute temp/asphere"_compute_temp_asphere.html compute kinetic energy for finite-size particles that includes rotational degrees of freedom. -They both allow, as an extra argument, which is another temperature -compute that subtracts a velocity bias. This allows the translational -velocity of spherical or aspherical particles to be adjusted in -prescribed ways. +They both allow for velocity biases indirectly, via an optional extra +argument, another temperature compute that subtracts a velocity bias. +This allows the translational velocity of spherical or aspherical +particles to be adjusted in prescribed ways. Thermostatting in LAMMPS is performed by "fixes"_fix.html, or in one case by a pair style. Several thermostatting fixes are available: @@ -1644,15 +1647,21 @@ to the per-particle thermostatting of "fix langevin"_fix_langevin.html. Any of the thermostatting fixes can use temperature computes that -remove bias for two purposes: (a) computing the current temperature to -compare to the requested target temperature, and (b) adjusting only -the thermal temperature component of the particle's velocities. See -the doc pages for the individual fixes and for the +remove bias which has two effects. First, the current calculated +temperature, which is compared to the requested target temperature, is +caluclated with the velocity bias removed. Second, the thermostat +adjusts only the thermal temperature component of the particle's +velocities, which are the velocities with the bias removed. The +removed bias is then added back to the adjusted velocities. See the +doc pages for the individual fixes and for the "fix_modify"_fix_modify.html command for instructions on how to assign a temperature compute to a thermostatting fix. For example, you can apply a thermostat to only the x and z components of velocity by using it in conjunction with "compute -temp/partial"_compute_temp_partial.html. +temp/partial"_compute_temp_partial.html. Of you could thermostat only +the thermal temperature of a streaming flow of particles without +affecting the streaming velocity, by using "compute +temp/profile"_compute_temp_profile.html. IMPORTANT NOTE: Only the nvt fixes perform time integration, meaning they update the velocities and positions of particles due to forces @@ -1892,15 +1901,18 @@ void *lammps_extract_atom(void *, char *) void *lammps_extract_compute(void *, char *, int, int) void *lammps_extract_fix(void *, char *, int, int, int, int) void *lammps_extract_variable(void *, char *, char *) +int lammps_set_variable(void *, char *, char *) int lammps_get_natoms(void *) void lammps_get_coords(void *, double *) void lammps_put_coords(void *, double *) :pre These can extract various global or per-atom quantities from LAMMPS as -well as values calculated by a compute, fix, or variable. The "get" -and "put" operations can retrieve and reset atom coordinates. -See the library.cpp file and its associated header file library.h for -details. +well as values calculated by a compute, fix, or variable. The +"set_variable" function can set an existing string-style variable to a +new value, so that subsequent LAMMPS commands can access the variable. +The "get" and "put" operations can retrieve and reset atom +coordinates. See the library.cpp file and its associated header file +library.h for details. The key idea of the library interface is that you can write any functions you wish to define how your code talks to LAMMPS and add @@ -2131,6 +2143,453 @@ accumulated in a vector via the "fix vector"_fix_vector.html command, and time integrated via the "variable trap"_variable.html function, and thus extract D. +:line + +6.23 Using chunks to calculate system properties :link(howto_23),h4 + +In LAMMS, "chunks" are collections of atoms, as defined by the +"compute chunk/atom"_compute_chunk_atom.html command, which assigns +each atom to a chunk ID (or to no chunk at all). The number of chunks +and the assignment of chunk IDs to atoms can be static or change over +time. Examples of "chunks" are molecules or spatial bins or atoms +with similar values (e.g. coordination number or potential energy). + +The per-atom chunk IDs can be used as input to two other kinds of +commands, to calculate various properties of a system: + +"fix ave/chunk"_fix_ave_chunk.html +any of the "compute */chunk"_compute.html commands :ul + +Here, each of the 3 kinds of chunk-related commands is briefly +overviewed. Then some examples are given of how to compute different +properties with chunk commands. + +Compute chunk/atom command: :h5 + +This compute can assign atoms to chunks of various styles. Only atoms +in the specified group and optional specified region are assigned to a +chunk. Here are some possible chunk definitions: + +atoms in same molecule | chunk ID = molecule ID | +atoms of same atom type | chunk ID = atom type | +all atoms with same atom property (charge, radius, etc) | chunk ID = output of compute property/atom | +atoms in same cluster | chunk ID = output of "compute cluster/atom"_compute_cluster_atom.html command | +atoms in same spatial bin | chunk ID = bin ID | +atoms in same rigid body | chunk ID = molecule ID used to define rigid bodies | +atoms with similar potential energy | chunk ID = output of "compute pe/atom"_compute_pe_atom.html | +atoms with same local defect structure | chunk ID = output of "compute centro/atom"_compute_centro_atom.html or "compute coord/atom"_compute_coord_atom.html command :tb(s=|,c=2) + +Note that chunk IDs are integer values, so for atom properties or +computes that produce a floating point value, they will be truncated +to an integer. You could also use the compute in a variable that +scales the floating point value to spread it across multiple intergers. + +Spatial bins can be of various kinds, e.g. 1d bins = slabs, 2d bins = +pencils, 3d bins = boxes, spherical bins, cylindrical bins. + +This compute also calculates the number of chunks {Nchunk}, which is +used by other commands to tally per-chunk data. {Nchunk} can be a +static value or change over time (e.g. the number of clusters). The +chunk ID for an individual atom can also be static (e.g. a molecule +ID), or dynamic (e.g. what spatial bin an atom is in as it moves). + +Note that this compute allows the per-atom output of other +"computes"_compute.html, "fixes"_fix.html, and +"variables"_variable.html to be used to define chunk IDs for each +atom. This means you can write your own compute or fix to output a +per-atom quantity to use as chunk ID. See +"Section_modify"_Section_modify.html of the documentation for how to +do this. You can also define a "per-atom variable"_variable.html in +the input script that uses a formula to generate a chunk ID for each +atom. + +Fix ave/chunk command: :h5 + +This fix takes the ID of a "compute +chunk/atom"_compute_chunk_atom.html command as input. For each chunk, +it then sums one or more specified per-atom values over the atoms in +each chunk. The per-atom values can be any atom property, such as +velocity, force, charge, potential energy, kinetic energy, stress, +etc. Additional keywords are defined for per-chunk properties like +density and temperature. More generally any per-atom value generated +by other "computes"_compute.html, "fixes"_fix.html, and "per-atom +variables"_variable.html, can be summed over atoms in each chunk. + +Similar to other averaging fixes, this fix allows the summed per-chunk +values to be time-averaged in various ways, and output to a file. The +fix produces a global array as output with one row of values per +chunk. + +Compute */chunk commands: :h5 + +Currently the following computes operate on chunks of atoms to produce +per-chunk values. + +"compute com/chunk"_compute_com_chunk.html +"compute gyration/chunk"_compute_gyration_chunk.html +"compute inertia/chunk"_compute_inertia_chunk.html +"compute msd/chunk"_compute_msd_chunk.html +"compute property/chunk"_compute_property_chunk.html +"compute temp/chunk"_compute_temp_chunk.html +"compute torque/chunk"_compute_vcm_chunk.html +"compute vcm/chunk"_compute_vcm_chunk.html :ul + +They each take the ID of a "compute +chunk/atom"_compute_chunk_atom.html command as input. As their names +indicate, they calculate the center-of-mass, radius of gyration, +moments of inertia, mean-squared displacement, temperature, torque, +and velocity of center-of-mass for each chunk of atoms. The "compute +property/chunk"_compute_property_chunk.html command can tally the +count of atoms in each chunk and extract other per-chunk properties. + +The reason these various calculations are not part of the "fix +ave/chunk command"_fix_ave_chunk.html, is that each requires a more +complicated operation than simply summing and averaging over per-atom +values in each chunk. For example, many of them require calculation +of a center of mass, which requires summing mass*position over the +atoms and then dividing by summed mass. + +All of these computes produce a global vector or global array as +output, wih one or more values per chunk. They can be used +in various ways: + +As input to the "fix ave/time"_fix_ave_time.html command, which can +write the values to a file and optionally time average them. :ulb,l + +As input to the "fix ave/histo"_fix_ave_histo.html command to +histogram values across chunks. E.g. a histogram of cluster sizes or +molecule diffusion rates. :l + +As input to special functions of "equal-style +variables"_variable.html, like sum() and max(). E.g. to find the +largest cluster or fastest diffusing molecule. :l,ule + +Example calculations with chunks :h5 + +Here are eaxmples using chunk commands to calculate various +properties: + +(1) Average velocity in each of 1000 2d spatial bins: + +compute cc1 all chunk/atom bin/2d x 0.0 0.1 y lower 0.01 units reduced +fix 1 all ave/chunk 100 10 1000 cc1 vx vy file tmp.out :pre + +(2) Temperature in each spatial bin, after subtracting a flow +velocity: + +compute cc1 all chunk/atom bin/2d x 0.0 0.1 y lower 0.1 units reduced +compute vbias all temp/profile 1 0 0 y 10 +fix 1 all ave/chunk 100 10 1000 cc1 temp bias vbias file tmp.out :pre + +(3) Center of mass of each molecule: + +compute cc1 all chunk/atom molecule +compute myChunk all com/chunk cc1 +fix 1 all ave/time 100 1 100 c_myChunk file tmp.out mode vector :pre + +(4) Total force on each molecule and ave/max across all molecules: + +compute cc1 all chunk/atom molecule +fix 1 all ave/chunk 1000 1 1000 cc1 fx fy fz file tmp.out +variable xave equal ave(f_1[2]) +variable xmax equal max(f_1[2]) +thermo 1000 +thermo_style custom step temp v_xave v_xmax :pre + +(5) Histogram of cluster sizes: + +compute cluster all cluster/atom 1.0 +compute cc1 all chunk/atom c_cluster compress yes +compute size all property/chunk cc1 count +fix 1 all ave/histo 100 1 100 0 20 20 c_size mode vector ave running beyond ignore file tmp.histo :pre + +:line + +6.24 Setting parameters for the "kspace_style pppm/disp"_kspace_style.html command :link(howto_24),h4 + +The PPPM method computes interactions by splitting the pair potential +into two parts, one of which is computed in a normal pairwise fashion, +the so-called real-space part, and one of which is computed using the +Fourier transform, the so called reciprocal-space or kspace part. For +both parts, the potential is not computed exactly but is approximated. +Thus, there is an error in both parts of the computation, the +real-space and the kspace error. The just mentioned facts are true +both for the PPPM for Coulomb as well as dispersion interactions. The +deciding difference - and also the reason why the parameters for +pppm/disp have to be selected with more care - is the impact of the +errors on the results: The kspace error of the PPPM for Coulomb and +dispersion interaction and the real-space error of the PPPM for +Coulomb interaction have the character of noise. In contrast, the +real-space error of the PPPM for dispersion has a clear physical +interpretation: the underprediction of cohesion. As a consequence, the +real-space error has a much stronger effect than the kspace error on +simulation results for pppm/disp. Parameters must thus be chosen in a +way that this error is much smaller than the kspace error. + +When using pppm/disp and not making any specifications on the PPPM +parameters via the kspace modify command, parameters will be tuned +such that the real-space error and the kspace error are equal. This +will result in simulations that are either inaccurate or slow, both of +which is not desirable. For selecting parameters for the pppm/disp +that provide fast and accurate simulations, there are two approaches, +which both have their up- and downsides. + +The first approach is to set desired real-space an kspace accuracies +via the {kspace_modify force/disp/real} and {kspace_modify +force/disp/kspace} commands. Note that the accuracies have to be +specified in force units and are thus dependend on the chosen unit +settings. For real units, 0.0001 and 0.002 seem to provide reasonable +accurate and efficient computations for the real-space and kspace +accuracies. 0.002 and 0.05 work well for most systems using lj +units. PPPM parameters will be generated based on the desired +accuracies. The upside of this approach is that it usually provides a +good set of parameters and will work for both the {kspace_modify diff +ad} and {kspace_modify diff ik} options. The downside of the method +is that setting the PPPM parameters will take some time during the +initialization of the simulation. + +The second approach is to set the parameters for the pppm/disp +explicitly using the {kspace_modify mesh/disp}, {kspace_modify +order/disp}, and {kspace_modify gewald/disp} commands. This approach +requires a more experienced user who understands well the impact of +the choice of parameters on the simulation accuracy and +performance. This approach provides a fast initialization of the +simulation. However, it is sensitive to errors: A combination of +parameters that will perform well for one system might result in +far-from-optimal conditions for other simulations. For example, +parametes that provide accurate and fast computations for +all-atomistic force fields can provide insufficient accuracy or +united-atomistic force fields (which is related to that the latter +typically have larger dispersion coefficients). + +To avoid inaccurate or inefficient simulations, the pppm/disp stops +simulations with an error message if no action is taken to control the +PPPM parameters. If the automatic parameter generation is desired and +real-space and kspace accuracies are desired to be equal, this error +message can be suppressed using the {kspace_modify disp/auto yes} +command. + +A reasonable approach that combines the upsides of both methods is to +make the first run using the {kspace_modify force/disp/real} and +{kspace_modify force/disp/kspace} commands, write down the PPPM +parameters from the outut, and specify these parameters using the +second approach in subsequent runs (which have the same composition, +force field, and approximately the same volume). + +Concerning the performance of the pppm/disp there are two more things +to consider. The first is that when using the pppm/disp, the cutoff +parameter does no longer affect the accuracy of the simulation +(subject to that gewald/disp is adjusted when changing the cutoff). +The performance can thus be increased by examining different values +for the cutoff parameter. A lower bound for the cutoff is only set by +the truncation error of the repulsive term of pair potentials. + +The second is that the mixing rule of the pair style has an impact on +the computation time when using the pppm/disp. Fastest computations +are achieved when using the geometric mixing rule. Using the +arithmetic mixing rule substantially increases the computational cost. +The computational overhead can be reduced using the {kspace_modify +mix/disp geom} and {kspace_modify splittol} commands. The first +command simply enforces geometric mixing of the dispersion +coeffiecients in kspace computations. This introduces some error in +the computations but will also significantly speed-up the +simulations. The second keyword sets the accuracy with which the +dispersion coefficients are approximated using a matrix factorization +approach. This may result in better accuracy then using the first +command, but will usually also not provide an equally good increase of +efficiency. + +Finally, pppm/disp can also be used when no mixing rules apply. +This can be achieved using the {kspace_modify mix/disp none} command. +Note that the code does not check automatically whether any mixing +rule is fulfilled. If mixing rules do not apply, the user will have +to specify this command explicitly. + +:line + +6.25 Adiabatic core/shell model :link(howto_25),h4 + +The adiabatic core-shell model by "Mitchell and +Finchham"_#MitchellFinchham is a simple method for adding +polarizability to a system. In order to mimic the electron shell of +an ion, a ghost atom is attached to it. This way the ions are split +into a core and a shell where the latter is meant to react to the +electrostatic environment inducing polarizability. + +Technically, shells are attached to the cores by a spring force f = +k*r where k is a parametrized spring constant and r is the distance +between the core and the shell. The charges of the core and the shell +add up to the ion charge, thus q(ion) = q(core) + q(shell). In a +similar fashion the mass of the ion is distributed on the core and the +shell with the core having the larger mass. + +To run this model in LAMMPS, "atom_style"_atom_style.html {full} can +be used since atom charge and bonds are needed. Each kind of +core/shell pair requires two atom types and a bond type. The core and +shell of a core/shell pair should be bonded to each other with a +harmonic bond that provides the spring force. For example, a data file +for NaCl, as found in examples/coreshell, has this format: + +432 atoms # core and shell atoms +216 bonds # number of core/shell springs :pre + +4 atom types # 2 cores and 2 shells for Na and Cl +2 bond types :pre + +0.0 24.09597 xlo xhi +0.0 24.09597 ylo yhi +0.0 24.09597 zlo zhi :pre + +Masses # core/shell mass ratio = 0.1 :pre + +1 20.690784 # Na core +2 31.90500 # Cl core +3 2.298976 # Na shell +4 3.54500 # Cl shell :pre + +Atoms :pre + +1 1 2 1.5005 0.00000000 0.00000000 0.00000000 # core of core/shell pair 1 +2 1 4 -2.5005 0.00000000 0.00000000 0.00000000 # shell of core/shell pair 1 +3 2 1 1.5056 4.01599500 4.01599500 4.01599500 # core of core/shell pair 2 +4 2 3 -0.5056 4.01599500 4.01599500 4.01599500 # shell of core/shell pair 2 +(...) :pre + +Bonds # Bond topology for spring forces :pre + +1 2 1 2 # spring for core/shell pair 1 +2 2 3 4 # spring for core/shell pair 2 +(...) :pre + +Non-Coulombic (e.g. Lennard-Jones) pairwise interactions are only +defined between the shells. Coulombic interactions are defined +between all cores and shells. If desired, additional bonds can be +specified between cores. + +The "special_bonds"_special_bonds.html command should be used to +turn-off the Coulombic interaction within core/shell pairs, since that +interaction is set by the bond spring. This is done using the +"special_bonds"_special_bonds.html command with a 1-2 weight = 0.0, +which is the default value. + +Since the core/shell model permits distances of r = 0.0 between the +core and shell, a pair style with a "cs" suffix needs to be used to +implement a valid long-range Coulombic correction. Several such pair +styles are provided in the CORESHELL package. See "this doc +page"_pair_cs.html for details. All of the core/shell enabled pair +styles require the use of a long-range Coulombic solver, as specified +by the "kspace_style"_kspace_style.html command. Either the PPPM or +Ewald solvers can be used. + +For the NaCL example problem, these pair style and bond style settings +are used: + +pair_style born/coul/long/cs 20.0 20.0 +pair_coeff * * 0.0 1.000 0.00 0.00 0.00 +pair_coeff 3 3 487.0 0.23768 0.00 1.05 0.50 #Na-Na +pair_coeff 3 4 145134.0 0.23768 0.00 6.99 8.70 #Na-Cl +pair_coeff 4 4 405774.0 0.23768 0.00 72.40 145.40 #Cl-Cl :pre + +bond_style harmonic +bond_coeff 1 63.014 0.0 +bond_coeff 2 25.724 0.0 :pre + +When running dynamics with the adiabatic core/shell model, the +following issues should be considered. Since the relative motion of +the core and shell particles corresponds to the polarization, typical +thermostats can alter the polarization behaviour, meaining the shell +will not react freely to its electrostatic environment. Therefore +it's typically desirable to decouple the relative motion of the +core/shell pair, which is an imaginary degree of freedom, from the +real physical system. To do that, the "compute +temp/cs"_compute_temp_cs.html command can be used, in conjunction with +any of the thermostat fixes, such as "fix nvt"_fix_nh.html or "fix +langevin"_fix_langevin. This compute uses the center-of-mass velocity +of the core/shell pairs to calculate a temperature, and insures that +velocity is what is rescaled for thermostatting purposes. The +"compute temp/cs"_compute_temp_cs.html command requires input of two +groups, one for the core atoms, another for the shell atoms. These +can be defined using the "group {type}"_group.html command. Note that +to perform thermostatting using this definition of temperature, the +"fix modify temp"_fix_modify.html command should be used to assign the +comptue to the thermostat fix. Likewise the "thermo_modify +temp"_thermo_modify.html command can be used to make this temperature +be output for the overall system. + +For the NaCl example, this can be done as follows: + +group cores type 1 2 +group shells type 3 4 +compute CSequ all temp/cs cores shells +fix thermoberendsen all temp/berendsen 1427 1427 0.4 # thermostat for the true physical system +fix thermostatequ all nve # integrator as needed for the berendsen thermostat +fix_modify thermoberendsen temp CSequ +thermo_modify temp CSequ # output of center-of-mass derived temperature :pre + +When intializing the velocities of a system with core/shell pairs, it +is also desirable to not introduce energy into the relative motion of +the core/shell particles, but only assign a center-of-mass velocity to +the pairs. This can be done by using the {bias} keyword of the +"velocity create"_velocity.html command and assigning the "compute +temp/cs"_compute_temp_cs.html command to the {temp} keyword of the +"velocity"_velocity.html commmand, e.g. + +velocity all create 1427 134 bias yes temp CSequ +velocity all scale 1427 temp CSequ :pre + +It is important to note that the polarizability of the core/shell +pairs is based on their relative motion. Therefore the choice of +spring force and mass ratio need to ensure much faster relative motion +of the 2 atoms within the core/shell pair than their center-of-mass +velocity. This allow the shells to effectively react instantaneously +to the electrostatic environment. This fast movement also limits the +timestep size that can be used. + +Additionally, the mass mismatch of the core and shell particles means +that only a small amount of energy is transfered to the decoupled +imaginary degrees of freedom. However, this transfer will typically +lead to a a small drift in total energy over time. This internal +energy can be monitored using the "compute +chunk/atom"_compute_chunk_atom.html and "compute +temp/chunk"_compute_temp_chunk.html commands. The internal kinetic +energies of each core/shell pair can then be summed using the sum() +special functino of the "variable"_variable.html command. Or they can +be time/averaged and output using the "fix ave/time"_fix_ave_time.html +command. To use these commands, each core/shell pair must be defined +as a "chunk". If each core/shell pair is defined as its own molecule, +the molecule ID can be used to define the chunks. If cores are bonded +to each other to form larger molecules, then another way to define the +chunks is to use the "fix property/atom"_fix_property_atom.html to +assign a core/shell ID to each atom via a special field in the data +file read by the "read_data"_read_data.html command. This field can +then be accessed by the "compute +property/atom"_compute_property_atom.html command, to use as input to +the "compute chunk/atom"_compute_chunk_atom.html command to define the +core/shell pairs as chunks. + +For example, + +fix csinfo all property/atom i_CSID # property/atom command +read_data NaCl_CS_x0.1_prop.data fix csinfo NULL CS-Info # atom property added in the data-file +compute prop all property/atom i_CSID +compute cs_chunk all chunk/atom c_prop +compute cstherm all temp/chunk cs_chunk temp internal com yes cdof 3.0 # note the chosen degrees of freedom for the core/shell pairs +fix ave_chunk all ave/time 10 1 10 c_cstherm file chunk.dump mode vector :pre + +The additional section in the date file would be formatted like this: + +CS-Info # header of additional section :pre + +1 1 # column 1 = atom ID, column 2 = core/shell ID +2 1 +3 2 +4 2 +5 3 +6 3 +7 4 +8 4 +(...) :pre + :line :line @@ -2167,3 +2626,7 @@ Phys, 79, 926 (1983). :link(Shinoda) [(Shinoda)] Shinoda, Shiga, and Mikami, Phys Rev B, 69, 134103 (2004). + +:link(MitchellFinchham) +[(Mitchell and Finchham)] Mitchell, Finchham, J Phys Condensed Matter, +5, 1031-1038 (1993). diff --git a/doc/Section_intro.html b/doc/Section_intro.html index de104b5a2e14c936cf9243a36a334db842b44450..9b8d624556d6ff9020d0d05786a4e27b00810b14 100644 --- a/doc/Section_intro.html +++ b/doc/Section_intro.html @@ -144,7 +144,7 @@ commands)

    Examples: 

    fix 2 gas gcmc 10 1000 1000 2 29494 298.0 -0.5 0.01
-fix 3 water gcmc 10 100 100 0 3456543 3.0 -2.5 0.1 mol my_one_water maxangle 180
+fix 3 water gcmc 10 100 100 0 3456543 3.0 -2.5 0.1 mol my_one_water maxangle 180 full_energy
 fix 4 my_gas gcmc 1 10 10 1 123456543 300.0 -12.5 1.0 region disk

    Description: @@ -63,41 +65,45 @@ fix 4 my_gas gcmc 1 10 10 1 123456543 300.0 -12.5 1.0 region disk atoms or molecules of the given type with an imaginary ideal gas reservoir at the specified T and chemical potential (mu) as discussed in (Frenkel). If used with the fix nvt command, -simulations in the grand canonical enemble (muVT, constant chemical +simulations in the grand canonical ensemble (muVT, constant chemical potential, constant volume, and constant temperature) can be performed. Specific uses include computing isotherms in microporous materials, or computing vapor-liquid coexistence curves.

    -

    Perform up to X exchanges (on average) of gas atoms or molecules of the -given type between the simulation domain and the imaginary reservoir every N -timesteps. Also perform M (on average) Monte Carlo displacements or rotations -(for molecules) of gas of the given type within the simulation domain. -M should typically be chosen to be approximately equal to the expected -number of gas atoms or molecules of the given type within the domain, -which will result in roughly one MC translation per atom or molecule -per MC cycle. -

    -

    For MC moves of molecular gasses, rotations and translations are each -attempted with 50% probability. For MC moves of atomic gasses, -translations are attempted 100% of the time. For MC exchanges of either -molecular or atomic gasses, deletions and insertions are each attempted -with 50% probability. -

    -

    If inserted particles are individual atoms, they are assigned the -specified atom type. If they are molecules, the type of each atom in -the inserted molecule is specified in the file read by the -molecule command, and those values are added to the -specified atom type. E.g. if type = 2, and the file specifies atom -types 1,2,3, then the inserted molecule will have atom types 3,4,5. +

    Perform up to X exchanges (on average) of gas atoms or molecules of +the given type between the simulation domain and the imaginary +reservoir every N timesteps. Also perform M (on average) Monte Carlo +displacements or rotations (for molecules) of gas of the given type +within the simulation domain. M should typically be chosen to be +approximately equal to the expected number of gas atoms or molecules +of the given type within the domain, which will result in roughly one +MC translation per atom or molecule per MC cycle. +

    +

    For MC moves of molecular gasses, rotations and translations are each +attempted with 50% probability. For MC moves of atomic gasses, +translations are attempted 100% of the time. For MC exchanges of +either molecular or atomic gasses, deletions and insertions are each +attempted with 50% probability. +

    +

    All inserted particles are assigned to two groups: the default group +"all" and the group specified in the fix gcmc command (which can also +be "all"). If inserted particles are individual atoms, they are +assigned the specified atom type. If they are molecules, the type of +each atom in the inserted molecule is specified in the file read by +the molecule command, and those values are added to +the specified atom type. E.g. if type = 2, and the file specifies +atom types 1,2,3, then the inserted molecule will have atom types +3,4,5.

    This fix cannot be used to perform MC insertions of gas atoms or -molecules other than the exchanged type, but MC deletions, translations, -and rotations can be performed on any atom/molecule in the fix group. -All atoms in the simulation domain can be moved using regular time -integration displacements, e.g. via fix_nvt, resulting -in a hybrid GCMC+MD simulation. A smaller-than-usual timestep size -may be needed when running such a hybrid simulation, especially if -the inserted molecules are not well equilibrated. +molecules other than the exchanged type, but MC deletions, +translations, and rotations can be performed on any atom/molecule in +the fix group. All atoms in the simulation domain can be moved using +regular time integration displacements, e.g. via +fix_nvt, resulting in a hybrid GCMC+MD simulation. A +smaller-than-usual timestep size may be needed when running such a +hybrid simulation, especially if the inserted molecules are not well +equilibrated.

    This command may optionally use the region keyword to define an exchange and move volume. The specified region must have been @@ -107,8 +113,8 @@ specified region. Move and deletion attempt candidates are selected from gas atoms or molecules within the region. If no candidate can be found within the specified region after randomly selecting candidates 1000 times, the move or deletion attempt is considered a failure. Moves -must start within the specified region, but may move the atom or molecule -slightly outside of the region. +must start and end with the atom or molecule center-of-mass within the +specified region. Moves are not otherwise attempted.

    If used with fix_nvt, the temperature of the imaginary reservoir, T, should be set to be equivalent to the target temperature @@ -122,13 +128,13 @@ interactions. Specifically, avoid performing so many MC displacements per timestep that atoms can move beyond the neighbor list skin distance. See the neighbor command for details.

    -

    When an atom or molecule is to be inserted, its center-of-mass -coordinates are chosen as a random position within the current -simulation domain, and new atom velocities are randomly chosen -from the specified temperature distribution given by T. Relative +

    When an atom or molecule is to be inserted, its center-of-mass +coordinates are chosen as a random position within the current +simulation domain, and new atom velocities are randomly chosen from +the specified temperature distribution given by T. Relative coordinates for atoms in a molecule are taken from the template -molecule provided by the user. A random initial rotation is used in the -case of molecule insertions. +molecule provided by the user. A random initial rotation is used in +the case of molecule insertions.

    Individual atoms are inserted, unless the mol keyword is used. It specifies a template-ID previously defined using the @@ -139,12 +145,11 @@ be specified in the molecule file. See the molecule -

    When not using the mol keyword, you should ensure you do not -delete only a portion of a molecule (only some of its atoms), or -LAMMPS will soon generate an error when it tries to find those atoms. -LAMMPS will warn you if any of the atoms eligible for deletion have a -non-zero molecule ID, but does not check for this at the time of -deletion. +

    When not using the mol keyword, you should ensure you do not delete +only a portion of a molecule (only some of its atoms), or LAMMPS will +soon generate an error when it tries to find those atoms. LAMMPS will +warn you if any of the atoms eligible for deletion have a non-zero +molecule ID, but does not check for this at the time of deletion.

    If you wish to insert molecules via the mol keyword, that will have their bonds or angles constrained via SHAKE, use the shake keyword, @@ -157,7 +162,10 @@ the angle in degrees. The specified angle will apply to all three Euler angles used internally to define the rotation matrix for molecular rotations. The max angle can be set to zero, but rotations will be pointless. Note that the default is ten degrees for each -Euler angle. +Euler angle. Also note that fix GCMC does not do configurational bias +MC. In other words, while inserted molecules have different rotations, +they all have the same molecular configuration, which was specified +in the molecule command input.

    For atomic gasses, inserted atoms have the specified atom type, but deleted atoms are any atoms that have been inserted or that belong @@ -173,6 +181,42 @@ keyword, in which case the user-specified chemical potential is ignored. For non-ideal gas reservoirs, the user may also specify the fugacity coefficient using the fugacity_coeff keyword.

    +

    The full_energy option means that fix GCMC will compute the total +potential energy of the entire simulated system. The total system +energy before and after the proposed GCMC move is then used in the +Metropolis criterion to determine whether or not to accept the +proposed GCMC move. By default, this option is off, in which case +only partial energies are computed to determine the difference in +energy that would be caused by the proposed GCMC move. +

    +

    The full_energy option is needed for systems with complicated +potential energy calculations, including the following: +

    +
    • long-range electrostatics (kspace) +
    • many body pair styles +
    • hybrid pair styles +
    • eam pair styles +
    • triclinic systems +
    • need to include potential energy contributions from other fixes +
    +

    Some fixes have an associated potential energy. Examples of such fixes +include: efield, gravity, +addforce, langevin, +restrain, temp/berendsen, +temp/rescale, and wall fixes. +For that energy to be included in the total potential energy of the +system (the quantity used when performing GCMC moves), +you MUST enable the fix_modify energy option for +that fix. The doc pages for individual fix commands +specify if this should be done. +

    +

    Use the charge option to insert atoms with a user-specified point +charge. Note that doing so will cause the system to become non-neutral. +LAMMPS issues a warning when using long-range electrostatics (kspace) +with non-neutral systems. See the +compute_group_group documentation for more +details about simulating non-neutral systems with kspace on. +

    Use of this fix typically will cause the number of atoms to fluctuate, therefore, you will want to use the compute_modify command to insure that the @@ -189,7 +233,7 @@ mass = 39.948 amu.

    Restart, fix_modify, output, run start/stop, minimize info:

    -

    This fix writes the state of the deposition to binary restart +

    This fix writes the state of the fix to binary restart files. This includes information about the random number generator seed, the next timestep for MC exchanges, etc. See the read_restart command for info on how to @@ -199,9 +243,9 @@ the operation of the fix continues in an uninterrupted fashion.

    None of the fix_modify options are relevant to this fix.

    -

    This fix computes a global vector of length 6, which can be accessed +

    This fix computes a global vector of length 8, which can be accessed by various output commands. The vector -values are the following global cummulative quantities: +values are the following global cumulative quantities:

    For mass, com, and inertia, the default is for LAMMPS to calculate this quantity itself if needed, assuming the molecules -consists of a set of point particles. You typically only need to -specify these values for a rigid body consisting of overlapping -finite-size particles. +consists of a set of point particles or finite-size particles (with a +non-zero diameter) that do not overlap. If finite-size particles in +the molecule do overlap, LAMMPS will not account for the overlap +effects when calculating any of these 3 quantities, so you should +pre-compute them yourself and list the values in the file.

    The mass and center-of-mass coordinates (Xc,Yc,Zc) are self-explanatory. The 6 moments of inertia (ixx,iyy,izz,ixy,ixz,iyz) diff --git a/doc/molecule.txt b/doc/molecule.txt index f4372228514e2391770eefdda7f800bf387bff36..1d1e7545f24a13ee091ad87f3051a77738660909 100644 --- a/doc/molecule.txt +++ b/doc/molecule.txt @@ -1,4 +1,4 @@ -"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c +<"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c :link(lws,http://lammps.sandia.gov) :link(ld,Manual.html) @@ -94,9 +94,11 @@ Ixx Iyy Izz Ixy Ixz Iyz {inertia} = 6 components of inertia tensor of molecule : For {mass}, {com}, and {inertia}, the default is for LAMMPS to calculate this quantity itself if needed, assuming the molecules -consists of a set of point particles. You typically only need to -specify these values for a rigid body consisting of overlapping -finite-size particles. +consists of a set of point particles or finite-size particles (with a +non-zero diameter) that do not overlap. If finite-size particles in +the molecule do overlap, LAMMPS will not account for the overlap +effects when calculating any of these 3 quantities, so you should +pre-compute them yourself and list the values in the file. The mass and center-of-mass coordinates (Xc,Yc,Zc) are self-explanatory. The 6 moments of inertia (ixx,iyy,izz,ixy,ixz,iyz) diff --git a/doc/neigh_modify.html b/doc/neigh_modify.html index 93d77bcd9053e7a140779d963d92381a733db753..c2e60a0acae695205a31a709d9f43d58c37d7ac1 100644 --- a/doc/neigh_modify.html +++ b/doc/neigh_modify.html @@ -62,23 +62,31 @@ neigh_modify exclude molecule rigid

    Description:

    This command sets parameters that affect the building and use of -pairwise neighbor lists. +pairwise neighbor lists. Depending on what pair interactions and +other commands are defined, a simulation may require one or more +neighbor lists.

    The every, delay, check, and once options affect how often lists are built as a simulation runs. The delay setting means never -build a new list until at least N steps after the previous build. The -every setting means build the list every M steps (after the delay -has passed). If the check setting is no, the list is built on the -1st step that satisfies the delay and every settings. If the -check setting is yes, then the list is only built on a particular -step if some atom has moved more than half the skin distance +build new lists until at least N steps after the previous build. The +every setting means build lists every M steps (after the delay has +passed). If the check setting is no, the lists are built on the +first step that satisfies the delay and every settings. If the +check setting is yes, then the every and delay settings +determine when a build may possibly be performed, but an actual build +only occurs if some atom has moved more than half the skin distance (specified in the neighbor command) since the last -build. If the once setting is yes, then the neighbor list is only -built once at the beginning of each run, and never rebuilt. This -should only be done if you are certain atoms will not move far enough -that the list should be rebuilt. E.g. running a simulation of a cold -crystal. Note that it is not that expensive to check if neighbor -lists should be rebuilt. +build. +

    +

    If the once setting is yes, then the neighbor list is only built +once at the beginning of each run, and never rebuilt, except on steps +when a restart file is written, or steps when a fix forces a rebuild +to occur (e.g. fixes that create or delete atoms, such as fix +deposit or fix evaporate). +This setting should only be made if you are certain atoms will not +move far enough that the neighbor list should be rebuilt, e.g. running +a simulation of a cold crystal. Note that it is not that expensive to +check if neighbor lists should be rebuilt.

    When the rRESPA integrator is used (see the run_style command), the every and delay parameters refer to the longest diff --git a/doc/neigh_modify.txt b/doc/neigh_modify.txt index 204f1ef3c0689a0b1f8042055491d8af60ee125f..42aade146bf01e1f95df74cad2068dafc8f02756 100644 --- a/doc/neigh_modify.txt +++ b/doc/neigh_modify.txt @@ -57,23 +57,31 @@ neigh_modify exclude molecule rigid :pre [Description:] This command sets parameters that affect the building and use of -pairwise neighbor lists. +pairwise neighbor lists. Depending on what pair interactions and +other commands are defined, a simulation may require one or more +neighbor lists. The {every}, {delay}, {check}, and {once} options affect how often lists are built as a simulation runs. The {delay} setting means never -build a new list until at least N steps after the previous build. The -{every} setting means build the list every M steps (after the delay -has passed). If the {check} setting is {no}, the list is built on the -1st step that satisfies the {delay} and {every} settings. If the -{check} setting is {yes}, then the list is only built on a particular -step if some atom has moved more than half the skin distance +build new lists until at least N steps after the previous build. The +{every} setting means build lists every M steps (after the delay has +passed). If the {check} setting is {no}, the lists are built on the +first step that satisfies the {delay} and {every} settings. If the +{check} setting is {yes}, then the {every} and {delay} settings +determine when a build may possibly be performed, but an actual build +only occurs if some atom has moved more than half the skin distance (specified in the "neighbor"_neighbor.html command) since the last -build. If the {once} setting is yes, then the neighbor list is only -built once at the beginning of each run, and never rebuilt. This -should only be done if you are certain atoms will not move far enough -that the list should be rebuilt. E.g. running a simulation of a cold -crystal. Note that it is not that expensive to check if neighbor -lists should be rebuilt. +build. + +If the {once} setting is yes, then the neighbor list is only built +once at the beginning of each run, and never rebuilt, except on steps +when a restart file is written, or steps when a fix forces a rebuild +to occur (e.g. fixes that create or delete atoms, such as "fix +deposit"_fix_deposit.html or "fix evaporate"_fix_evaporate.html). +This setting should only be made if you are certain atoms will not +move far enough that the neighbor list should be rebuilt, e.g. running +a simulation of a cold crystal. Note that it is not that expensive to +check if neighbor lists should be rebuilt. When the rRESPA integrator is used (see the "run_style"_run_style.html command), the {every} and {delay} parameters refer to the longest diff --git a/doc/package.html b/doc/package.html index 87e49a5c8fa1a1e475ed144403fd4652ff44bcba..5c0dd866d86e48ec0b0754375fe486444f2107bc 100644 --- a/doc/package.html +++ b/doc/package.html @@ -59,7 +59,7 @@ intel args = NPhi keyword value ... Nphi = # of coprocessors per node zero or more keyword/value pairs may be appended - keywords = omp or mode or balance or ghost or tpc or tptask + keywords = omp or mode or balance or ghost or tpc or tptask or no_affinity omp value = Nthreads Nthreads = number of OpenMP threads to use on CPU (default = 0) mode value = single or mixed or double @@ -75,6 +75,7 @@ Ntpc = max number of coprocessor threads per coprocessor core (default = 4) tptask value = Ntptask Ntptask = max number of coprocessor threads per MPI task (default = 240) + no_affinity values = none kokkos args = keyword value ... zero or more keyword/value pairs may be appended keywords = neigh or newton or binsize or comm or comm/exchange or comm/forward @@ -427,6 +428,13 @@ with 16 threads, for a total of 128.

    Note that the default settings for tpc and tptask are fine for most problems, regardless of how many MPI tasks you assign to a Phi.

    +

    The no_affinity keyword will turn off automatic setting of core +affinity for MPI tasks and OpenMP threads on the host when using +offload to a coprocessor. Affinity settings are used when possible +to prevent MPI tasks and OpenMP threads from being on separate NUMA +domains and to prevent offload threads from interfering with other +processes/threads used for LAMMPS. +

    The kokkos style invokes settings associated with the use of the diff --git a/doc/package.txt b/doc/package.txt index 51f485f411e6f822f0e1e67208508794f65dd234..d3f8a51c17804ab8bb025f111de82cd0aff41457 100644 --- a/doc/package.txt +++ b/doc/package.txt @@ -54,7 +54,7 @@ args = arguments specific to the style :l {intel} args = NPhi keyword value ... Nphi = # of coprocessors per node zero or more keyword/value pairs may be appended - keywords = {omp} or {mode} or {balance} or {ghost} or {tpc} or {tptask} + keywords = {omp} or {mode} or {balance} or {ghost} or {tpc} or {tptask} or {no_affinity} {omp} value = Nthreads Nthreads = number of OpenMP threads to use on CPU (default = 0) {mode} value = {single} or {mixed} or {double} @@ -70,6 +70,7 @@ args = arguments specific to the style :l Ntpc = max number of coprocessor threads per coprocessor core (default = 4) {tptask} value = Ntptask Ntptask = max number of coprocessor threads per MPI task (default = 240) + {no_affinity} values = none {kokkos} args = keyword value ... zero or more keyword/value pairs may be appended keywords = {neigh} or {newton} or {binsize} or {comm} or {comm/exchange} or {comm/forward} @@ -421,6 +422,13 @@ with 16 threads, for a total of 128. Note that the default settings for {tpc} and {tptask} are fine for most problems, regardless of how many MPI tasks you assign to a Phi. +The {no_affinity} keyword will turn off automatic setting of core +affinity for MPI tasks and OpenMP threads on the host when using +offload to a coprocessor. Affinity settings are used when possible +to prevent MPI tasks and OpenMP threads from being on separate NUMA +domains and to prevent offload threads from interfering with other +processes/threads used for LAMMPS. + :line The {kokkos} style invokes settings associated with the use of the diff --git a/doc/pair_buck.html b/doc/pair_buck.html index 9dc9c33828fab344793cf3a40587b6365437eb43..1e14667251f74b2708eb14c0ac60cd174e8a7bce 100644 --- a/doc/pair_buck.html +++ b/doc/pair_buck.html @@ -15,6 +15,8 @@

    pair_style buck/gpu command

    +

    pair_style buck/kk command +

    pair_style buck/omp command

    pair_style buck/coul/cut command @@ -23,6 +25,8 @@

    pair_style buck/coul/cut/gpu command

    +

    pair_style buck/coul/cut/kk command +

    pair_style buck/coul/cut/omp command

    pair_style buck/coul/long command @@ -31,6 +35,8 @@

    pair_style buck/coul/long/gpu command

    +

    pair_style buck/coul/long/kk command +

    pair_style buck/coul/long/omp command

    pair_style buck/coul/msm command diff --git a/doc/pair_buck.txt b/doc/pair_buck.txt index 3bda6e6f2e8f30076eab93217a075ac8f6383bed..2409c24ee9facbc5a9875b9b53fd06c97e818af7 100644 --- a/doc/pair_buck.txt +++ b/doc/pair_buck.txt @@ -9,14 +9,17 @@ pair_style buck command :h3 pair_style buck/cuda command :h3 pair_style buck/gpu command :h3 +pair_style buck/kk command :h3 pair_style buck/omp command :h3 pair_style buck/coul/cut command :h3 pair_style buck/coul/cut/cuda command :h3 pair_style buck/coul/cut/gpu command :h3 +pair_style buck/coul/cut/kk command :h3 pair_style buck/coul/cut/omp command :h3 pair_style buck/coul/long command :h3 pair_style buck/coul/long/cuda command :h3 pair_style buck/coul/long/gpu command :h3 +pair_style buck/coul/long/kk command :h3 pair_style buck/coul/long/omp command :h3 pair_style buck/coul/msm command :h3 pair_style buck/coul/msm/omp command :h3 diff --git a/doc/pair_buck_long.html b/doc/pair_buck_long.html index 0bad4188ee4bffb93c2ee1ef5784f09b533fcc37..77c8a3884b141a90480885d8864662c4b5559c4e 100644 --- a/doc/pair_buck_long.html +++ b/doc/pair_buck_long.html @@ -61,21 +61,23 @@ appropriate to include long-range 1/r^6 interactions, using this potential.

    If flag_buck is set to long, no cutoff is used on the Buckingham -1/r^6 dispersion term. The long-range portion is calculated by using -the kspace_style ewald/n command. The specified -Buckingham cutoff then determines which portion of the Buckingham -interactions are computed directly by the pair potential versus which -part is computed in reciprocal space via the Kspace style. If -flag_buck is set to cut, the Buckingham interactions are simply -cutoff, as with pair_style buck. +1/r^6 dispersion term. The long-range portion can be calculated by +using the kspace_style ewald/disp or pppm/disp +commands. The specified Buckingham cutoff then determines which +portion of the Buckingham interactions are computed directly by the +pair potential versus which part is computed in reciprocal space via +the Kspace style. If flag_buck is set to cut, the Buckingham +interactions are simply cutoff, as with pair_style +buck.

    If flag_coul is set to long, no cutoff is used on the Coulombic -interactions. The long-range portion is calculated by using any -style, including ewald/n of the kspace_style -command. Note that if flag_buck is also set to long, then only the -ewald/n Kspace style can perform the long-range calculations for -both the Buckingham and Coulombic interactions. If flag_coul is set -to off, Coulombic interactions are not computed. +interactions. The long-range portion can calculated by using any of +several kspace_style command options such as +pppm or ewald. Note that if flag_buck is also set to long, then +the ewald/disp or pppm/disp Kspace style needs to be used to +perform the long-range calculations for both the Buckingham and +Coulombic interactions. If flag_coul is set to off, Coulombic +interactions are not computed.

    The following coefficients must be defined for each pair of atoms types via the pair_coeff command as in the examples diff --git a/doc/pair_buck_long.txt b/doc/pair_buck_long.txt index 3daa546c4f7d336d1f75b126f0b195206d896d3f..3a527474160c9f658c033376144605d5482a77c5 100644 --- a/doc/pair_buck_long.txt +++ b/doc/pair_buck_long.txt @@ -52,21 +52,23 @@ appropriate to include long-range 1/r^6 interactions, using this potential. If {flag_buck} is set to {long}, no cutoff is used on the Buckingham -1/r^6 dispersion term. The long-range portion is calculated by using -the "kspace_style ewald/n"_kspace_style.html command. The specified -Buckingham cutoff then determines which portion of the Buckingham -interactions are computed directly by the pair potential versus which -part is computed in reciprocal space via the Kspace style. If -{flag_buck} is set to {cut}, the Buckingham interactions are simply -cutoff, as with "pair_style buck"_pair_buck.html. +1/r^6 dispersion term. The long-range portion can be calculated by +using the "kspace_style ewald/disp or pppm/disp"_kspace_style.html +commands. The specified Buckingham cutoff then determines which +portion of the Buckingham interactions are computed directly by the +pair potential versus which part is computed in reciprocal space via +the Kspace style. If {flag_buck} is set to {cut}, the Buckingham +interactions are simply cutoff, as with "pair_style +buck"_pair_buck.html. If {flag_coul} is set to {long}, no cutoff is used on the Coulombic -interactions. The long-range portion is calculated by using any -style, including {ewald/n} of the "kspace_style"_kspace_style.html -command. Note that if {flag_buck} is also set to long, then only the -{ewald/n} Kspace style can perform the long-range calculations for -both the Buckingham and Coulombic interactions. If {flag_coul} is set -to {off}, Coulombic interactions are not computed. +interactions. The long-range portion can calculated by using any of +several "kspace_style"_kspace_style.html command options such as +{pppm} or {ewald}. Note that if {flag_buck} is also set to long, then +the {ewald/disp} or {pppm/disp} Kspace style needs to be used to +perform the long-range calculations for both the Buckingham and +Coulombic interactions. If {flag_coul} is set to {off}, Coulombic +interactions are not computed. The following coefficients must be defined for each pair of atoms types via the "pair_coeff"_pair_coeff.html command as in the examples diff --git a/doc/pair_class2.html b/doc/pair_class2.html index e461829e5b6119815f2e38cd11dbcc5307400347..58c66b927c833783fa356934dafc652051cf6625 100644 --- a/doc/pair_class2.html +++ b/doc/pair_class2.html @@ -15,12 +15,16 @@

    pair_style lj/class2/gpu command

    +

    pair_style lj/class2/kk command +

    pair_style lj/class2/omp command

    pair_style lj/class2/coul/cut command

    pair_style lj/class2/coul/cut/cuda command

    +

    pair_style lj/class2/coul/cut/kk command +

    pair_style lj/class2/coul/cut/omp command

    pair_style lj/class2/coul/long command @@ -29,6 +33,8 @@

    pair_style lj/class2/coul/long/gpu command

    +

    pair_style lj/class2/coul/long/kk command +

    pair_style lj/class2/coul/long/omp command

    Syntax: diff --git a/doc/pair_class2.txt b/doc/pair_class2.txt index 906e25f63e981e2edd88807d41e8445b377277ad..66ba2b7f3031b11f789029ab117dc7c77f3cef75 100644 --- a/doc/pair_class2.txt +++ b/doc/pair_class2.txt @@ -9,13 +9,16 @@ pair_style lj/class2 command :h3 pair_style lj/class2/cuda command :h3 pair_style lj/class2/gpu command :h3 +pair_style lj/class2/kk command :h3 pair_style lj/class2/omp command :h3 pair_style lj/class2/coul/cut command :h3 pair_style lj/class2/coul/cut/cuda command :h3 +pair_style lj/class2/coul/cut/kk command :h3 pair_style lj/class2/coul/cut/omp command :h3 pair_style lj/class2/coul/long command :h3 pair_style lj/class2/coul/long/cuda command :h3 pair_style lj/class2/coul/long/gpu command :h3 +pair_style lj/class2/coul/long/kk command :h3 pair_style lj/class2/coul/long/omp command :h3 [Syntax:] diff --git a/doc/pair_coul.html b/doc/pair_coul.html index 84449902870b17a574dee3392cb58618f5800337..176e331f890c038fa8685cc806590cccfde762cc 100644 --- a/doc/pair_coul.html +++ b/doc/pair_coul.html @@ -13,18 +13,24 @@

    pair_style coul/cut/gpu command

    +

    pair_style coul/cut/kk command +

    pair_style coul/cut/omp command

    pair_style coul/debye command

    pair_style coul/debye/gpu command

    +

    pair_style coul/debye/kk command +

    pair_style coul/debye/omp command

    pair_style coul/dsf command

    pair_style coul/dsf/gpu command

    +

    pair_style coul/dsf/kk command +

    pair_style coul/dsf/omp command

    pair_style coul/long command @@ -33,12 +39,18 @@

    pair_style coul/long/gpu command

    +

    pair_style coul/long/kk command +

    pair_style coul/msm command

    pair_style coul/msm/omp command

    +

    pair_style coul/streitz command +

    pair_style coul/wolf command

    +

    pair_style coul/wolf/kk command +

    pair_style coul/wolf/omp command

    pair_style tip4p/cut command @@ -57,6 +69,7 @@ pair_style coul/dsf alpha cutoff pair_style coul/long cutoff pair_style coul/long/gpu cutoff pair_style coul/wolf alpha cutoff +pair_style coul/streitz cutoff keyword alpha pair_style tip4p/cut otype htype btype atype qdist cutoff pair_style tip4p/long otype htype btype atype qdist cutoff @@ -86,6 +99,10 @@ pair_coeff * * 
    pair_style coul/wolf 0.2 9.0
 pair_coeff * *
    +
    pair_style coul/streitz 12.0 ewald
+pair_style coul/streitz 12.0 wolf 0.30
+pair_coeff * * AlO.streitz Al O 
+
    pair_style tip4p/cut 1 2 7 8 0.15 12.0
 pair_coeff * *
    @@ -104,6 +121,8 @@ the 2 atoms, and epsilon is the dielectric constant which can be set by the dielectric command. The cutoff Rc truncates the interaction distance.

    +
    +

    Style coul/debye adds an additional exp() damping factor to the Coulombic term, given by

    @@ -112,6 +131,8 @@ Coulombic term, given by

    where kappa is the Debye length. This potential is another way to mimic the screening effect of a polar solvent.

    +
    +

    Style coul/dsf computes Coulombic interactions via the damped shifted force model described in Fennell, given by:

    @@ -123,6 +144,8 @@ Wolf model (described below) to provide consistent forces and energies (the Wolf potential is not differentiable at the cutoff) and smooth decay to zero.

    +
    +

    Style coul/wolf computes Coulombic interactions via the Wolf summation method, described in Wolf, given by:

    @@ -141,6 +164,59 @@ forces calcluated by the Wolf summation method approach those of the Ewald sum. So it is a means of getting effective long-range interactions with a short-range potential.

    +
    + +

    Style coul/streitz is the Coulomb pair interaction defined as part +of the Streitz-Mintmire potential, as described in this +paper, in which charge distribution about an atom is modeled +as a Slater 1s orbital. More details can be found in the referenced +paper. To fully reproduce the published Streitz-Mintmire potential, +which is a variable charge potential, style coul/streitz must be +used with pair_style eam/alloy (or some other +short-range potential that has been parameterized appropriately) via +the pair_style hybrid/overlay command. Likewise, +charge equilibration must be performed via the fix +qeq/slater command. For example: +

    +
    pair_style hybrid/overlay coul/streitz 12.0 wolf 0.31 eam/alloy
+pair_coeff * * coul/streitz AlO.streitz Al O
+pair_coeff * * eam/alloy AlO.eam.alloy Al O
+fix 1 all qeq/slater 1 12.0 1.0e-6 100 coul/streitz 
+
    +

    The keyword wolf in the coul/streitz command denotes computing +Coulombic interactions via Wolf summation. An additional damping +parameter is required for the Wolf summation, as described for the +coul/wolf potential above. Alternatively, Coulombic interactions can +be computed via an Ewald summation. For example: +

    +
    pair_style hybrid/overlay coul/streitz 12.0 ewald eam/alloy
+kspace_style ewald 1e-6 
+
    +

    Keyword ewald does not need a damping parameter, but a +kspace_style must be defined, which can be style +ewald or pppm. The Ewald method was used in Streitz and +Mintmire's original paper, but a Wolf summation offers a speed-up in +some cases. +

    +

    For the fix qeq/slater command, the qfile can be a filename that +contains QEq parameters as discussed on the fix qeq +command doc page. Alternatively qfile can be replaced by +"coul/streitz", in which case the fix will extract QEq parameters from +the coul/streitz pair style itself. +

    +

    See the examples/strietz directory for an example input script that +uses the Streitz-Mintmire potential. The potentials directory has the +AlO.eam.alloy and AlO.streitz potential files used by the example. +

    +

    Note that the Streiz-Mintmire potential is generally used for oxides, +but there is no conceptual problem with extending it to nitrides and +carbides (such as SiC, TiN). Pair coul/strietz used by itself or with +any other pair style such as EAM, MEAM, Tersoff, or LJ in +hybrid/overlay mode. To do this, you would need to provide a +Streitz-Mintmire parameterizaion for the material being modeled. +

    +
    +

    Styles coul/long and coul/msm compute the same Coulombic interactions as style coul/cut except that an additional damping factor is applied so it can be used in conjunction with the @@ -176,11 +252,14 @@ cutoff + 2*qdist, to shrink the size of the neighbor list. This leads to slightly larger cost for the long-range calculation, so you can test the trade-off for your model.

    -

    These potentials are designed to be combined with other pair +

    + +

    Note that these potentials are designed to be combined with other pair potentials via the pair_style hybrid/overlay command. This is because they have no repulsive core. Hence if they are used by themselves, there will be no repulsion to keep two -oppositely charged particles from overlapping each other. +oppositely charged particles from moving arbitrarily close to each +other.

    The following coefficients must be defined for each pair of atoms types via the pair_coeff command as in the examples @@ -279,4 +358,9 @@ Phys, 110, 8254 (1999).

    (Fennell) C. J. Fennell, J. D. Gezelter, J Chem Phys, 124, 234104 (2006).

    + + +

    (Streitz) F. H. Streitz, J. W. Mintmire, Phys Rev B, 50, 11996-12003 +(1994). +

    diff --git a/doc/pair_coul.txt b/doc/pair_coul.txt index a7bda947ca0e0353674a352213702fef1111a55d..a6fbda3785d19c0d009fed900bc0c18c5378e4b1 100644 --- a/doc/pair_coul.txt +++ b/doc/pair_coul.txt @@ -8,19 +8,25 @@ pair_style coul/cut command :h3 pair_style coul/cut/gpu command :h3 +pair_style coul/cut/kk command :h3 pair_style coul/cut/omp command :h3 pair_style coul/debye command :h3 pair_style coul/debye/gpu command :h3 +pair_style coul/debye/kk command :h3 pair_style coul/debye/omp command :h3 pair_style coul/dsf command :h3 pair_style coul/dsf/gpu command :h3 +pair_style coul/dsf/kk command :h3 pair_style coul/dsf/omp command :h3 pair_style coul/long command :h3 pair_style coul/long/omp command :h3 pair_style coul/long/gpu command :h3 +pair_style coul/long/kk command :h3 pair_style coul/msm command :h3 pair_style coul/msm/omp command :h3 +pair_style coul/streitz command :h3 pair_style coul/wolf command :h3 +pair_style coul/wolf/kk command :h3 pair_style coul/wolf/omp command :h3 pair_style tip4p/cut command :h3 pair_style tip4p/long command :h3 @@ -35,6 +41,7 @@ pair_style coul/dsf alpha cutoff pair_style coul/long cutoff pair_style coul/long/gpu cutoff pair_style coul/wolf alpha cutoff +pair_style coul/streitz cutoff keyword alpha pair_style tip4p/cut otype htype btype atype qdist cutoff pair_style tip4p/long otype htype btype atype qdist cutoff :pre @@ -64,6 +71,10 @@ pair_coeff * * :pre pair_style coul/wolf 0.2 9.0 pair_coeff * * :pre +pair_style coul/streitz 12.0 ewald +pair_style coul/streitz 12.0 wolf 0.30 +pair_coeff * * AlO.streitz Al O :pre + pair_style tip4p/cut 1 2 7 8 0.15 12.0 pair_coeff * * :pre @@ -82,6 +93,8 @@ the 2 atoms, and epsilon is the dielectric constant which can be set by the "dielectric"_dielectric.html command. The cutoff Rc truncates the interaction distance. +:line + Style {coul/debye} adds an additional exp() damping factor to the Coulombic term, given by @@ -90,6 +103,8 @@ Coulombic term, given by where kappa is the Debye length. This potential is another way to mimic the screening effect of a polar solvent. +:line + Style {coul/dsf} computes Coulombic interactions via the damped shifted force model described in "Fennell"_#Fennell, given by: @@ -101,6 +116,8 @@ Wolf model (described below) to provide consistent forces and energies (the Wolf potential is not differentiable at the cutoff) and smooth decay to zero. +:line + Style {coul/wolf} computes Coulombic interactions via the Wolf summation method, described in "Wolf"_#Wolf, given by: @@ -119,6 +136,59 @@ forces calcluated by the Wolf summation method approach those of the Ewald sum. So it is a means of getting effective long-range interactions with a short-range potential. +:line + +Style {coul/streitz} is the Coulomb pair interaction defined as part +of the Streitz-Mintmire potential, as described in "this +paper"_#Streitz, in which charge distribution about an atom is modeled +as a Slater 1{s} orbital. More details can be found in the referenced +paper. To fully reproduce the published Streitz-Mintmire potential, +which is a variable charge potential, style {coul/streitz} must be +used with "pair_style eam/alloy"_pair_eam.html (or some other +short-range potential that has been parameterized appropriately) via +the "pair_style hybrid/overlay"_pair_hybrid.html command. Likewise, +charge equilibration must be performed via the "fix +qeq/slater"_fix_qeq.html command. For example: + +pair_style hybrid/overlay coul/streitz 12.0 wolf 0.31 eam/alloy +pair_coeff * * coul/streitz AlO.streitz Al O +pair_coeff * * eam/alloy AlO.eam.alloy Al O +fix 1 all qeq/slater 1 12.0 1.0e-6 100 coul/streitz :pre + +The keyword {wolf} in the coul/streitz command denotes computing +Coulombic interactions via Wolf summation. An additional damping +parameter is required for the Wolf summation, as described for the +coul/wolf potential above. Alternatively, Coulombic interactions can +be computed via an Ewald summation. For example: + +pair_style hybrid/overlay coul/streitz 12.0 ewald eam/alloy +kspace_style ewald 1e-6 :pre + +Keyword {ewald} does not need a damping parameter, but a +"kspace_style"_kspace_style.html must be defined, which can be style +{ewald} or {pppm}. The Ewald method was used in Streitz and +Mintmire's original paper, but a Wolf summation offers a speed-up in +some cases. + +For the fix qeq/slater command, the {qfile} can be a filename that +contains QEq parameters as discussed on the "fix qeq"_fix_qeq.html +command doc page. Alternatively {qfile} can be replaced by +"coul/streitz", in which case the fix will extract QEq parameters from +the coul/streitz pair style itself. + +See the examples/strietz directory for an example input script that +uses the Streitz-Mintmire potential. The potentials directory has the +AlO.eam.alloy and AlO.streitz potential files used by the example. + +Note that the Streiz-Mintmire potential is generally used for oxides, +but there is no conceptual problem with extending it to nitrides and +carbides (such as SiC, TiN). Pair coul/strietz used by itself or with +any other pair style such as EAM, MEAM, Tersoff, or LJ in +hybrid/overlay mode. To do this, you would need to provide a +Streitz-Mintmire parameterizaion for the material being modeled. + +:line + Styles {coul/long} and {coul/msm} compute the same Coulombic interactions as style {coul/cut} except that an additional damping factor is applied so it can be used in conjunction with the @@ -154,11 +224,14 @@ cutoff + 2*qdist, to shrink the size of the neighbor list. This leads to slightly larger cost for the long-range calculation, so you can test the trade-off for your model. -These potentials are designed to be combined with other pair +:line + +Note that these potentials are designed to be combined with other pair potentials via the "pair_style hybrid/overlay"_pair_hybrid.html command. This is because they have no repulsive core. Hence if they are used by themselves, there will be no repulsion to keep two -oppositely charged particles from overlapping each other. +oppositely charged particles from moving arbitrarily close to each +other. The following coefficients must be defined for each pair of atoms types via the "pair_coeff"_pair_coeff.html command as in the examples @@ -254,3 +327,7 @@ Phys, 110, 8254 (1999). :link(Fennell) [(Fennell)] C. J. Fennell, J. D. Gezelter, J Chem Phys, 124, 234104 (2006). + +:link(Streitz) +[(Streitz)] F. H. Streitz, J. W. Mintmire, Phys Rev B, 50, 11996-12003 +(1994). diff --git a/doc/pair_cs.html b/doc/pair_cs.html new file mode 100644 index 0000000000000000000000000000000000000000..8cc7b4f0911cb9bc8b8272fae0135cebb4f07242 --- /dev/null +++ b/doc/pair_cs.html @@ -0,0 +1,91 @@ + +
    LAMMPS WWW Site - LAMMPS Documentation - LAMMPS Commands +
    + + + + + + +
    + +

    pair_style born/coul/long/cs command +

    +

    pair_style buck/coul/long/cs command +

    +

    Syntax: +

    +
    pair_style style args 
+
    + +
      born/coul/long/cs args = cutoff (cutoff2)
+    cutoff = global cutoff for non-Coulombic (and Coulombic if only 1 arg) (distance units)
+    cutoff2 = global cutoff for Coulombic (optional) (distance units)
+  buck/coul/long/cs args = cutoff (cutoff2)
+    cutoff = global cutoff for Buckingham (and Coulombic if only 1 arg) (distance units)
+    cutoff2 = global cutoff for Coulombic (optional) (distance units) 
+
    +

    Examples: +

    +
    pair_style born/coul/long/cs 10.0 8.0
+pair_coeff 1 1 6.08 0.317 2.340 24.18 11.51 
+
    +
    pair_style buck/coul/long/cs 10.0
+pair_style buck/coul/long/cs 10.0 8.0
+pair_coeff * * 100.0 1.5 200.0
+pair_coeff 1 1 100.0 1.5 200.0 9.0 
+
    +

    Description: +

    +

    These pair styles are designed to be used with the adiabatic +core/shell model of (Mitchell and Finchham). See +Section_howto 25 of the manual for an +overview of the model as implemented in LAMMPS. +

    +

    These pair styles are identical to the pair_style +born/coul/long and pair_style +buck/coul/long styles, except they correctly treat the +special case where the distance between two charged core and shell +atoms in the same core/shell pair approach r = 0.0. This needs +special treatment when a long-range solver for Coulombic interactions +is also used, i.e. via the kspace_style command. +

    +

    More specifically, the short-range Coulomb interaction between a core +and its shell should be turned off using the +special_bonds command by setting the 1-2 weight +to 0.0, which works because the core and shell atoms are bonded to +each other. This induces a long-range correction approximation which +fails at small distances (~< 10e-8). Therefore, the Coulomb term which +is used to calculate the correction factor is extended by a minimal +distance (r_min = 1.0-6) when the interaction between a core/shell +pair is treated, as follows +

    +
    +
    +

    where C is an energy-conversion constant, Qi and Qj are the charges on +the core and shell, epsilon is the dielectric constant and r_min is the +minimal distance. +

    +

    Restrictions: +

    +

    These pair styles are part of the CORESHELL package. They are only +enabled if LAMMPS was built with that package. See the Making +LAMMPS section for more info. +

    +

    Related commands: +

    +

    pair_coeff, pair_style born, +pair_style buck +

    +

    Default: none +

    +
    + + + +

    (Mitchell and Finchham) Mitchell, Finchham, J Phys Condensed Matter, +5, 1031-1038 (1993). +

    + diff --git a/doc/pair_cs.txt b/doc/pair_cs.txt new file mode 100644 index 0000000000000000000000000000000000000000..9b9d78e17fef3db1fa571ec4055a583455e3899a --- /dev/null +++ b/doc/pair_cs.txt @@ -0,0 +1,83 @@ +"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c + +:link(lws,http://lammps.sandia.gov) +:link(ld,Manual.html) +:link(lc,Section_commands.html#comm) + +:line + +pair_style born/coul/long/cs command :h3 +pair_style buck/coul/long/cs command :h3 + +[Syntax:] + +pair_style style args :pre + +style = {born/coul/long/cs} or {buck/coul/long/cs} +args = list of arguments for a particular style :ul + {born/coul/long/cs} args = cutoff (cutoff2) + cutoff = global cutoff for non-Coulombic (and Coulombic if only 1 arg) (distance units) + cutoff2 = global cutoff for Coulombic (optional) (distance units) + {buck/coul/long/cs} args = cutoff (cutoff2) + cutoff = global cutoff for Buckingham (and Coulombic if only 1 arg) (distance units) + cutoff2 = global cutoff for Coulombic (optional) (distance units) :pre + +[Examples:] + +pair_style born/coul/long/cs 10.0 8.0 +pair_coeff 1 1 6.08 0.317 2.340 24.18 11.51 :pre + +pair_style buck/coul/long/cs 10.0 +pair_style buck/coul/long/cs 10.0 8.0 +pair_coeff * * 100.0 1.5 200.0 +pair_coeff 1 1 100.0 1.5 200.0 9.0 :pre + +[Description:] + +These pair styles are designed to be used with the adiabatic +core/shell model of "(Mitchell and Finchham)"_#MitchellFinchham. See +"Section_howto 25"_Section_howto.html#howto_25 of the manual for an +overview of the model as implemented in LAMMPS. + +These pair styles are identical to the "pair_style +born/coul/long"_pair_born.html and "pair_style +buck/coul/long"_pair_buck.html styles, except they correctly treat the +special case where the distance between two charged core and shell +atoms in the same core/shell pair approach r = 0.0. This needs +special treatment when a long-range solver for Coulombic interactions +is also used, i.e. via the "kspace_style"_kspace_style.html command. + +More specifically, the short-range Coulomb interaction between a core +and its shell should be turned off using the +"special_bonds"_special_bonds.html command by setting the 1-2 weight +to 0.0, which works because the core and shell atoms are bonded to +each other. This induces a long-range correction approximation which +fails at small distances (~< 10e-8). Therefore, the Coulomb term which +is used to calculate the correction factor is extended by a minimal +distance (r_min = 1.0-6) when the interaction between a core/shell +pair is treated, as follows + +:c,image(Eqs/pair_cs.jpg) + +where C is an energy-conversion constant, Qi and Qj are the charges on +the core and shell, epsilon is the dielectric constant and r_min is the +minimal distance. + +[Restrictions:] + +These pair styles are part of the CORESHELL package. They are only +enabled if LAMMPS was built with that package. See the "Making +LAMMPS"_Section_start.html#start_3 section for more info. + +[Related commands:] + +"pair_coeff"_pair_coeff.html, "pair_style born"_pair_born.html, +"pair_style buck"_pair_buck.html + +[Default:] none + +:line + +:link(MitchellFinchham) +[(Mitchell and Finchham)] Mitchell, Finchham, J Phys Condensed Matter, +5, 1031-1038 (1993). diff --git a/doc/pair_dpd.html b/doc/pair_dpd.html index 4fe2e5ab4f44ccdc19b97063d59b8b9d042cb47a..91d610c71a4784b6f7a5d8b40f871e450940403a 100644 --- a/doc/pair_dpd.html +++ b/doc/pair_dpd.html @@ -108,6 +108,10 @@ to use the pair_style srp command in conjuction wi these pair styles. It is a soft segmental repulsive potential (SRP) that can prevent DPD polymer chains from crossing each other.

    +

    IMPORTANT NOTE: The virial calculation for pressure when using this +pair style includes all the components of force listed above, +including the random force. +

    Styles with a cuda, gpu, intel, kk, omp, or opt suffix are diff --git a/doc/pair_dpd.txt b/doc/pair_dpd.txt index 1ebffdea2abf58f1cddd658bd09333806f724ff7..445d3ebc58feb9b1e624ca2f202bc635a6159add 100644 --- a/doc/pair_dpd.txt +++ b/doc/pair_dpd.txt @@ -100,6 +100,10 @@ to use the "pair_style srp"_pair_srp.html command in conjuction with these pair styles. It is a soft segmental repulsive potential (SRP) that can prevent DPD polymer chains from crossing each other. +IMPORTANT NOTE: The virial calculation for pressure when using this +pair style includes all the components of force listed above, +including the random force. + :line Styles with a {cuda}, {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are diff --git a/doc/pair_eam.html b/doc/pair_eam.html index 9b861197cad135b3052683f54694b638040f139a..9c8ef97aa8c29af8936eac1fa3720ca95f5b0396 100644 --- a/doc/pair_eam.html +++ b/doc/pair_eam.html @@ -15,6 +15,8 @@

    pair_style eam/gpu command

    +

    pair_style eam/kk command +

    pair_style eam/omp command

    pair_style eam/opt command diff --git a/doc/pair_eam.txt b/doc/pair_eam.txt index 07a369d27b7924b65d71e4bdf5bfac6b03d540a8..5a90e0780b2d7f3c2d5e8a568b5333fadaabb0d6 100644 --- a/doc/pair_eam.txt +++ b/doc/pair_eam.txt @@ -9,6 +9,7 @@ pair_style eam command :h3 pair_style eam/cuda command :h3 pair_style eam/gpu command :h3 +pair_style eam/kk command :h3 pair_style eam/omp command :h3 pair_style eam/opt command :h3 pair_style eam/alloy command :h3 diff --git a/doc/pair_hybrid.html b/doc/pair_hybrid.html index 25b8e9b6d2591fe13831a96d96e89165e357897e..a00eef8e143f5530ddfcc2018ea4ac08f77cc191 100644 --- a/doc/pair_hybrid.html +++ b/doc/pair_hybrid.html @@ -106,7 +106,7 @@ simulation with 2 atom types. Type 1 is Si, type 2 is C. The following commands would model the Si atoms with Tersoff, the C atoms with Tersoff, and the cross-interactions with Lennard-Jones:

    -
    pair_style hybrid lj/cut tersoff tersoff
+
    pair_style hybrid lj/cut 2.5 tersoff tersoff
 pair_coeff * * tersoff 1 Si.tersoff Si NULL 
 pair_coeff * * tersoff 2 C.tersoff NULL C
 pair_coeff 1 2 lj/cut 1.0 1.5 
@@ -302,12 +302,13 @@ sub-styles of the hybrid potential.
 and J,J is the same, and if the sub-style allows for mixing, then the
 coefficients for I,J can be mixed.  This means you do not have to
 specify a pair_coeff command for I,J since the I,J type pair will be
-assigned automatically to the I,I sub-style and its coefficients
-generated by the mixing rule used by that sub-style.  For the
-hybrid/overlay style, there is an additional requirement that both
-the I,I and J,J pairs are assigned to a single sub-style.  See the
-"pair_modify" command for details of mixing rules.  See the See the
-doc page for the sub-style to see if allows for mixing.
+assigned automatically to the sub-style defined for both I,I and J,J
+and its coefficients generated by the mixing rule used by that
+sub-style.  For the hybrid/overlay style, there is an additional
+requirement that both the I,I and J,J pairs are assigned to a single
+sub-style.  See the "pair_modify" command for details of mixing rules.
+See the See the doc page for the sub-style to see if allows for
+mixing.
 
    
 
    The hybrid pair styles supports the pair_modify
 shift, table, and tail options for an I,J pair interaction, if the
diff --git a/doc/pair_hybrid.txt b/doc/pair_hybrid.txt
index 685d84e64651dc647287808ff8b18c3a2e6680ed..8692d4a20e70fd33f03fa859296c44039e81556c 100644
--- a/doc/pair_hybrid.txt
+++ b/doc/pair_hybrid.txt
@@ -100,7 +100,7 @@ simulation with 2 atom types.  Type 1 is Si, type 2 is C.  The
 following commands would model the Si atoms with Tersoff, the C atoms
 with Tersoff, and the cross-interactions with Lennard-Jones:
 
-pair_style hybrid lj/cut tersoff tersoff
+pair_style hybrid lj/cut 2.5 tersoff tersoff
 pair_coeff * * tersoff 1 Si.tersoff Si NULL 
 pair_coeff * * tersoff 2 C.tersoff NULL C
 pair_coeff 1 2 lj/cut 1.0 1.5 :pre
@@ -296,12 +296,13 @@ For atom type pairs I,J and I != J, if the sub-style assigned to I,I
 and J,J is the same, and if the sub-style allows for mixing, then the
 coefficients for I,J can be mixed.  This means you do not have to
 specify a pair_coeff command for I,J since the I,J type pair will be
-assigned automatically to the I,I sub-style and its coefficients
-generated by the mixing rule used by that sub-style.  For the
-{hybrid/overlay} style, there is an additional requirement that both
-the I,I and J,J pairs are assigned to a single sub-style.  See the
-"pair_modify" command for details of mixing rules.  See the See the
-doc page for the sub-style to see if allows for mixing.
+assigned automatically to the sub-style defined for both I,I and J,J
+and its coefficients generated by the mixing rule used by that
+sub-style.  For the {hybrid/overlay} style, there is an additional
+requirement that both the I,I and J,J pairs are assigned to a single
+sub-style.  See the "pair_modify" command for details of mixing rules.
+See the See the doc page for the sub-style to see if allows for
+mixing.
 
 The hybrid pair styles supports the "pair_modify"_pair_modify.html
 shift, table, and tail options for an I,J pair interaction, if the
diff --git a/doc/pair_kim.html b/doc/pair_kim.html
index 41a1bcef4f01b1be9ae0c01dfde3021d403f936c..56aabf5b4f7a6d8ef5176899ac134387fe2dc0a3 100644
--- a/doc/pair_kim.html
+++ b/doc/pair_kim.html
@@ -74,105 +74,11 @@ case it is also useful to check the kim.log file for additional error
 information.  This file kim.log should be generated in the same
 directory where LAMMPS is running.
 
    
-
    
-
-
    Here is information on how to build KIM for use with LAMMPS.
-
    
-
    The KIM API is available for download from this
-site, namely https://openkim.org.  The tarball
-you download is "kim-api-vX.X.X.tgz", which can be unpacked via
-
    
-
    tar xvfz kim*tgz 
-
    
-
    The kim-api-vX.X.X/docs/ directory has further documentation.  In
-order to compile and install the KIM API follow the instructions found
-in the file kim-api-vX.X.X/INSTALL.  (Don't forget to download and
-compile any Model Drivers and Models that you want to use.)
-
    
-
    Once you have successfully compiled and installed the KIM API, you
-need to make sure the utility kim-api-build-config is on your PATH
-so that the LAMMPS build system can properly work with the KIM API.
-
    
-
    The following is an example of how to download, compile, and run
-LAMMPS with the KIM API:
+
    To download, build, and install the KIM library on your system, see
+the lib/kim/README file.  Once you have done this and built LAMMPS
+with the KIM package installed you can run the example input scripts
+in examples/kim.
 
    
-
    -mkdir lammps-kim
-cd lammps-kim 
-
-#
-# download lammps and the KIM API
-# 
-
-wget http://lammps.sandia.gov/tars/lammps-DDMMMYY.tar.gz  # replace DDMMMYY as appropriate here and below
-wget http://s3.openkim.org/kim-api/kim-api-vX.X.X.tgz     # replace X.X.X as appropriate here and below
-tar zxvf kim-api-vX.X.X.tgz 
-
-#
-# Get OpenKIM models, setup and compile
-# 
-
-cd kim-api-vX.X.X
-cp Makefile.KIM_Config.example Makefile.KIM_Config
-vi Makefile.KIM_Config  # edit file as appropriate following the instructions given in the INSTALL file
-make add-EAM_Dynamo_Angelo_Moody_NiAlH__MO_418978237058_001
-make
-make install
-make install-set-default-to-vX  # replace X with the KIM API major version number 
-
-#
-# setup and compile lammps
-# 
-
-tar zxvf lammps-DDMMMYY.tar.gz
-cd lammps-DDMMMYY/src
-make yes-kim
-cd STUBS
-make
-cd ../
-make serial 
-
-#
-# run simple example with KIM model
-# 
-
-cd ../../
-vi al-input  # create file with the following content
-#----------------------------------------------------------------------------------------
-variable        x index 1
-variable        y index 1
-variable        z index 1 
-
-variable        xx equal 20*$x
-variable        yy equal 20*$y
-variable        zz equal 20*$z 
-
-units           metal
-atom_style      atomic 
-
-lattice         fcc 4.0500
-region          box block 0.0 ${xx} 0.0 ${yy} 0.0 ${zz}
-create_box      1 box
-create_atoms    1 box 
-
-pair_style      kim KIMvirial EAM_Dynamo_Angelo_Moody_NiAlH__MO_418978237058_001
-pair_coeff      * * Al 
-
-mass            1 26.98
-velocity        all create 200.0 232345 loop geom 
-
-neighbor        0.3 bin
-neigh_modify    delay 0 every 1 check yes 
-
-fix             1 all nve 
-
-run             100
-#---------------------------------------------------------------------------------------- 
-
-./lammps-DDMMYY/src/lmp_serial -in al-input 
-
-
    
-
 
    
 
 
    Mixing, shift, table, tail correction, restart, rRESPA info:
diff --git a/doc/pair_kim.txt b/doc/pair_kim.txt
index 3ecfce9683c3d8f1c4e79a5bb53cec722142d977..d0eef0b8b2dce5d668bf3f4133c0a50cba15e601 100644
--- a/doc/pair_kim.txt
+++ b/doc/pair_kim.txt
@@ -71,104 +71,10 @@ case it is also useful to check the kim.log file for additional error
 information.  This file kim.log should be generated in the same
 directory where LAMMPS is running.
 
-:line
-
-Here is information on how to build KIM for use with LAMMPS.
-
-The KIM API is available for download from "this
-site"_https://openkim.org, namely https://openkim.org.  The tarball
-you download is "kim-api-vX.X.X.tgz", which can be unpacked via
-
-tar xvfz kim*tgz :pre
-
-The kim-api-vX.X.X/docs/ directory has further documentation.  In
-order to compile and install the KIM API follow the instructions found
-in the file kim-api-vX.X.X/INSTALL.  (Don't forget to download and
-compile any Model Drivers and Models that you want to use.)
-
-Once you have successfully compiled and installed the KIM API, you
-need to make sure the utility kim-api-build-config is on your PATH
-so that the LAMMPS build system can properly work with the KIM API.
-
-
-The following is an example of how to download, compile, and run
-LAMMPS with the KIM API:
-
-
    -mkdir lammps-kim
-cd lammps-kim :
-
-#
-# download lammps and the KIM API
-# :
-
-wget http://lammps.sandia.gov/tars/lammps-DDMMMYY.tar.gz  # replace DDMMMYY as appropriate here and below
-wget http://s3.openkim.org/kim-api/kim-api-vX.X.X.tgz     # replace X.X.X as appropriate here and below
-tar zxvf kim-api-vX.X.X.tgz :
-
-#
-# Get OpenKIM models, setup and compile
-# :
-
-cd kim-api-vX.X.X
-cp Makefile.KIM_Config.example Makefile.KIM_Config
-vi Makefile.KIM_Config  # edit file as appropriate following the instructions given in the INSTALL file
-make add-EAM_Dynamo_Angelo_Moody_NiAlH__MO_418978237058_001
-make
-make install
-make install-set-default-to-vX  # replace X with the KIM API major version number :
-
-#
-# setup and compile lammps
-# :
-
-tar zxvf lammps-DDMMMYY.tar.gz
-cd lammps-DDMMMYY/src
-make yes-kim
-cd STUBS
-make
-cd ../
-make serial :
-
-#
-# run simple example with KIM model
-# :
-
-cd ../../
-vi al-input  # create file with the following content
-#----------------------------------------------------------------------------------------
-variable        x index 1
-variable        y index 1
-variable        z index 1 :
-
-variable        xx equal 20*$x
-variable        yy equal 20*$y
-variable        zz equal 20*$z :
-
-units           metal
-atom_style      atomic :
-
-lattice         fcc 4.0500
-region          box block 0.0 $\{xx\} 0.0 $\{yy\} 0.0 $\{zz\}
-create_box      1 box
-create_atoms    1 box :
-
-pair_style      kim KIMvirial EAM_Dynamo_Angelo_Moody_NiAlH__MO_418978237058_001
-pair_coeff      * * Al :
-
-mass            1 26.98
-velocity        all create 200.0 232345 loop geom :
-
-neighbor        0.3 bin
-neigh_modify    delay 0 every 1 check yes :
-
-fix             1 all nve :
-
-run             100
-#---------------------------------------------------------------------------------------- :
-
-./lammps-DDMMYY/src/lmp_serial -in al-input :
-
    
+To download, build, and install the KIM library on your system, see
+the lib/kim/README file.  Once you have done this and built LAMMPS
+with the KIM package installed you can run the example input scripts
+in examples/kim.
 
 :line
 
diff --git a/doc/pair_lj.html b/doc/pair_lj.html
index bcdf8e56d168e1aeb34ca5c1022ec6f76e22c0fb..1a8c57f73abd45af67eee7197a24439a283b71f9 100644
--- a/doc/pair_lj.html
+++ b/doc/pair_lj.html
@@ -37,12 +37,16 @@

    pair_style lj/cut/coul/debye/gpu command

    +

    pair_style lj/cut/coul/debye/kk command +

    pair_style lj/cut/coul/debye/omp command

    pair_style lj/cut/coul/dsf command

    pair_style lj/cut/coul/dsf/gpu command

    +

    pair_style lj/cut/coul/dsf/kk command +

    pair_style lj/cut/coul/dsf/omp command

    pair_style lj/cut/coul/long command diff --git a/doc/pair_lj.txt b/doc/pair_lj.txt index a308d81f8c831b2fa462ef40b554519fdadf9a5d..1a9fea5eef66b10bd89afdaac214a4a9f3724734 100644 --- a/doc/pair_lj.txt +++ b/doc/pair_lj.txt @@ -20,9 +20,11 @@ pair_style lj/cut/coul/cut/omp command :h3 pair_style lj/cut/coul/debye command :h3 pair_style lj/cut/coul/debye/cuda command :h3 pair_style lj/cut/coul/debye/gpu command :h3 +pair_style lj/cut/coul/debye/kk command :h3 pair_style lj/cut/coul/debye/omp command :h3 pair_style lj/cut/coul/dsf command :h3 pair_style lj/cut/coul/dsf/gpu command :h3 +pair_style lj/cut/coul/dsf/kk command :h3 pair_style lj/cut/coul/dsf/omp command :h3 pair_style lj/cut/coul/long command :h3 pair_style lj/cut/coul/long/cuda command :h3 diff --git a/doc/pair_lj_long.html b/doc/pair_lj_long.html index 779ab24544922366e780724dec615b4517cecdc8..5b7455771be1a2364040494ff1dd2b35ce89c13d 100644 --- a/doc/pair_lj_long.html +++ b/doc/pair_lj_long.html @@ -107,22 +107,22 @@ neighbor list. This leads to slightly larger cost for the long-range calculation, so you can test the trade-off for your model.

    If flag_lj is set to long, no cutoff is used on the LJ 1/r^6 -dispersion term. The long-range portion is calculated by using the -kspace_style ewald/n command. The specified LJ -cutoff then determines which portion of the LJ interactions are -computed directly by the pair potential versus which part is computed -in reciprocal space via the Kspace style. If flag_lj is set to -cut, the LJ interactions are simply cutoff, as with pair_style -lj/cut. If flag_lj is set to -off, LJ interactions are not computed at all. +dispersion term. The long-range portion can be calculated by using +the kspace_style ewald/disp or pppm/disp commands. +The specified LJ cutoff then determines which portion of the LJ +interactions are computed directly by the pair potential versus which +part is computed in reciprocal space via the Kspace style. If +flag_lj is set to cut, the LJ interactions are simply cutoff, as +with pair_style lj/cut.

    If flag_coul is set to long, no cutoff is used on the Coulombic -interactions. The long-range portion is calculated by using any -style, including ewald/n of the kspace_style -command. Note that if flag_lj is also set to long, then only the -ewald/n KSpace style can perform the long-range calculations for -both the LJ and Coulombic interactions. If flag_coul is set to -off, Coulombic interactions are not computed at all. +interactions. The long-range portion can calculated by using any of +several kspace_style command options such as +pppm or ewald. Note that if flag_lj is also set to long, then +the ewald/disp or pppm/disp Kspace style needs to be used to +perform the long-range calculations for both the LJ and Coulombic +interactions. If flag_coul is set to off, Coulombic interactions +are not computed.

    The following coefficients must be defined for each pair of atoms types via the pair_coeff command as in the examples diff --git a/doc/pair_lj_long.txt b/doc/pair_lj_long.txt index 320c9476c9f6a5aa8fb60de1b6198915b5ebe7df..5da530f1680b9a0ff528baffe0026885c9cfc0cf 100644 --- a/doc/pair_lj_long.txt +++ b/doc/pair_lj_long.txt @@ -100,22 +100,22 @@ neighbor list. This leads to slightly larger cost for the long-range calculation, so you can test the trade-off for your model. If {flag_lj} is set to {long}, no cutoff is used on the LJ 1/r^6 -dispersion term. The long-range portion is calculated by using the -"kspace_style ewald/n"_kspace_style.html command. The specified LJ -cutoff then determines which portion of the LJ interactions are -computed directly by the pair potential versus which part is computed -in reciprocal space via the Kspace style. If {flag_lj} is set to -{cut}, the LJ interactions are simply cutoff, as with "pair_style -lj/cut"_pair_lj.html. If {flag_lj} is set to -{off}, LJ interactions are not computed at all. +dispersion term. The long-range portion can be calculated by using +the "kspace_style ewald/disp or pppm/disp"_kspace_style.html commands. +The specified LJ cutoff then determines which portion of the LJ +interactions are computed directly by the pair potential versus which +part is computed in reciprocal space via the Kspace style. If +{flag_lj} is set to {cut}, the LJ interactions are simply cutoff, as +with "pair_style lj/cut"_pair_lj.html. If {flag_coul} is set to {long}, no cutoff is used on the Coulombic -interactions. The long-range portion is calculated by using any -style, including {ewald/n} of the "kspace_style"_kspace_style.html -command. Note that if {flag_lj} is also set to long, then only the -{ewald/n} KSpace style can perform the long-range calculations for -both the LJ and Coulombic interactions. If {flag_coul} is set to -{off}, Coulombic interactions are not computed at all. +interactions. The long-range portion can calculated by using any of +several "kspace_style"_kspace_style.html command options such as +{pppm} or {ewald}. Note that if {flag_lj} is also set to long, then +the {ewald/disp} or {pppm/disp} Kspace style needs to be used to +perform the long-range calculations for both the LJ and Coulombic +interactions. If {flag_coul} is set to {off}, Coulombic interactions +are not computed. The following coefficients must be defined for each pair of atoms types via the "pair_coeff"_pair_coeff.html command as in the examples diff --git a/doc/pair_modify.html b/doc/pair_modify.html index a5aa4a20254584c988d0e06ca63da65249327559..0366343f1fa7701b6329800d927d1c65e95d4e83 100644 --- a/doc/pair_modify.html +++ b/doc/pair_modify.html @@ -138,18 +138,27 @@ with "real" units, but some close pairs may be computed directly

    When the tail keyword is set to yes, certain pair styles will add a long-range VanderWaals tail "correction" to the energy and pressure. -See the doc page for individual styles to see which support this -option. These corrections are included in the calculation and -printing of thermodynamic quantities (see the -thermo_style command). Their effect will also be -included in constant NPT or NPH simulations where the pressure -influences the simulation box dimensions (e.g. the fix -npt and fix nph commands). The formulas -used for the long-range corrections come from equation 5 of -(Sun). -

    -

    Several assumptions are inherent in using tail corrections, including -the following: +These corrections are bookkeeping terms which do not affect dynamics, +unless a constant-pressure simulation is being performed. See the doc +page for individual styles to see which support this option. These +corrections are included in the calculation and printing of +thermodynamic quantities (see the thermo_style +command). Their effect will also be included in constant NPT or NPH +simulations where the pressure influences the simulation box +dimensions (e.g. the fix npt and fix nph +commands). The formulas used for the long-range corrections come from +equation 5 of (Sun). +

    +

    IMPORTANT NOTE: The tail correction terms are computed at the +beginning of each run, using the current atom counts of each atom +type. If atoms are deleted (or lost) or created during a simulation, +e.g. via the fix gcmc command, the correction factors +are not re-computed. If you expect the counts to change dramatically, +you can break a run into a series of shorter runs so that the +correction factors are re-computed more frequently. +

    +

    Several additional assumptions are inherent in using tail corrections, +including the following:

    • The simulated system is a 3d bulk homogeneous liquid. This option should not be used for systems that are non-liquid, 2d, have a slab @@ -162,6 +171,14 @@ checking the rdf. The rdf is not exactly unity beyond the cutoff for each pair of interaction types, so the tail correction is necessarily an approximation. +

      The tail corrections are computed at the beginning of each simulation +run. If the number of atoms changes during the run, e.g. due to atoms +leaving the simulation domain, or use of the fix gcmc +command, then the corrections are not updates to relect the changed +atom count. If this is a large effect in your simulation, you should +break the long run into several short runs, so that the correction +factors are re-computed multiple times. +

    • Thermophysical properties obtained from calculations with this option enabled will not be thermodynamically consistent with the truncated force-field that was used. In other words, atoms do not feel any LJ diff --git a/doc/pair_modify.txt b/doc/pair_modify.txt index af00c3a59307ed4b5600e23cadcd6bd081ace3b0..a9bc403e4a8ff5d46d597e978bd688d8865382b1 100644 --- a/doc/pair_modify.txt +++ b/doc/pair_modify.txt @@ -132,18 +132,27 @@ with "real" units, but some close pairs may be computed directly When the {tail} keyword is set to {yes}, certain pair styles will add a long-range VanderWaals tail "correction" to the energy and pressure. -See the doc page for individual styles to see which support this -option. These corrections are included in the calculation and -printing of thermodynamic quantities (see the -"thermo_style"_thermo_style.html command). Their effect will also be -included in constant NPT or NPH simulations where the pressure -influences the simulation box dimensions (e.g. the "fix -npt"_fix_nh.html and "fix nph"_fix_nh.html commands). The formulas -used for the long-range corrections come from equation 5 of -"(Sun)"_#Sun. - -Several assumptions are inherent in using tail corrections, including -the following: +These corrections are bookkeeping terms which do not affect dynamics, +unless a constant-pressure simulation is being performed. See the doc +page for individual styles to see which support this option. These +corrections are included in the calculation and printing of +thermodynamic quantities (see the "thermo_style"_thermo_style.html +command). Their effect will also be included in constant NPT or NPH +simulations where the pressure influences the simulation box +dimensions (e.g. the "fix npt"_fix_nh.html and "fix nph"_fix_nh.html +commands). The formulas used for the long-range corrections come from +equation 5 of "(Sun)"_#Sun. + +IMPORTANT NOTE: The tail correction terms are computed at the +beginning of each run, using the current atom counts of each atom +type. If atoms are deleted (or lost) or created during a simulation, +e.g. via the "fix gcmc"_fix_gcmc.html command, the correction factors +are not re-computed. If you expect the counts to change dramatically, +you can break a run into a series of shorter runs so that the +correction factors are re-computed more frequently. + +Several additional assumptions are inherent in using tail corrections, +including the following: The simulated system is a 3d bulk homogeneous liquid. This option should not be used for systems that are non-liquid, 2d, have a slab @@ -156,6 +165,14 @@ checking the rdf. The rdf is not exactly unity beyond the cutoff for each pair of interaction types, so the tail correction is necessarily an approximation. :l +The tail corrections are computed at the beginning of each simulation +run. If the number of atoms changes during the run, e.g. due to atoms +leaving the simulation domain, or use of the "fix gcmc"_fix_gcmc.html +command, then the corrections are not updates to relect the changed +atom count. If this is a large effect in your simulation, you should +break the long run into several short runs, so that the correction +factors are re-computed multiple times. + Thermophysical properties obtained from calculations with this option enabled will not be thermodynamically consistent with the truncated force-field that was used. In other words, atoms do not feel any LJ diff --git a/doc/pair_quip.html b/doc/pair_quip.html new file mode 100644 index 0000000000000000000000000000000000000000..93096fca1942b9d256334fffdc53586527948080 --- /dev/null +++ b/doc/pair_quip.html @@ -0,0 +1,102 @@ + +
      LAMMPS WWW Site - LAMMPS Documentation - LAMMPS Commands +
      + + + + + + +
      + +

      pair_style quip command +

      +

      Syntax: +

      +
      pair_style quip 
+
      +

      Examples: +

      +
      pair_style      quip
+pair_coeff      * * gap_example.xml "Potential xml_label=GAP_2014_5_8_60_17_10_38_466" 14
+pair_coeff      * * sw_example.xml "IP SW" 14 
+
      +

      Description: +

      +

      Style quip provides an interface for calling potential routines from +the QUIP package. QUIP is built separately, and then linked to +LAMMPS. The most recent version of the QUIP package can be downloaded +from GitHub: +https://github.com/libAtoms/QUIP. The +interface is chiefly intended to be used to run Gaussian Approximation +Potentials (GAP), which are described in the following publications: +(Bartok et al) and (PhD thesis of +Bartok). +

      +

      Only a single pair_coeff command is used with the quip style that +specifies a QUIP potential file containing the parameters of the +potential for all needed elements in XML format. This is followed by a +QUIP initialization string. Finally, the QUIP elements are mapped to +LAMMPS atom types by specifying N atomic numbers, where N is the +number of LAMMPS atom types: +

      +
      • QUIP filename +
      • QUIP initialization string +
      • N atomic numbers = mapping of QUIP elements to atom types +
      +

      See the pair_coeff doc page for alternate ways +to specify the path for the potential file. +

      +

      A QUIP potential is fully specified by the filename which contains the +parameters of the potential in XML format, the initialisation string, +and the map of atomic numbers. +

      +

      GAP potentials can be obtained from the Data repository section of +http://www.libatoms.org, where the +appropriate initialisation strings are also advised. The list of +atomic numbers must be matched to the LAMMPS atom types specified in +the LAMMPS data file or elsewhere. +

      +

      Two examples input scripts are provided in the examples/USER/quip +directory. +

      +

      Mixing, shift, table, tail correction, restart, rRESPA info: +

      +

      This pair style does not support the pair_modify +mix, shift, table, and tail options. +

      +

      This pair style does not write its information to binary restart +files, since it is stored in potential files. Thus, you +need to re-specify the pair_style and pair_coeff commands in an input +script that reads a restart file. +

      +

      This pair style can only be used via the pair keyword of the +run_style respa command. It does not support the +inner, middle, outer keywords. +

      +

      Restrictions: +

      +

      This pair style is part of the USER-QUIP package. It is only enabled +if LAMMPS was built with that package. See the Making +LAMMPS section for more info. +

      +

      QUIP potentials are parametrized in electron-volts and Angstroms and +therefore should be used with LAMMPS metal units. +

      +

      Related commands: +

      +

      pair_coeff +

      +
      + + + +

      (Bartok_2010) AP Bartok, MC Payne, R Kondor, and G Csanyi, Physical +Review Letters 104, 136403 (2010). +

      + + +

      (Bartok_PhD) A Bartok-Partay, PhD Thesis, University of Cambridge, +(2010). +

      + diff --git a/doc/pair_quip.txt b/doc/pair_quip.txt new file mode 100644 index 0000000000000000000000000000000000000000..1dadca1971e2d7acafef07787edb34fc456b3004 --- /dev/null +++ b/doc/pair_quip.txt @@ -0,0 +1,96 @@ +"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c + +:link(lws,http://lammps.sandia.gov) +:link(ld,Manual.html) +:link(lc,Section_commands.html#comm) + +:line + +pair_style quip command :h3 + +[Syntax:] + +pair_style quip :pre + +[Examples:] + +pair_style quip +pair_coeff * * gap_example.xml "Potential xml_label=GAP_2014_5_8_60_17_10_38_466" 14 +pair_coeff * * sw_example.xml "IP SW" 14 :pre + +[Description:] + +Style {quip} provides an interface for calling potential routines from +the QUIP package. QUIP is built separately, and then linked to +LAMMPS. The most recent version of the QUIP package can be downloaded +from GitHub: +"https://github.com/libAtoms/QUIP"_https://github.com/libAtoms/QUIP. The +interface is chiefly intended to be used to run Gaussian Approximation +Potentials (GAP), which are described in the following publications: +"(Bartok et al)"_#Bartok_2010 and "(PhD thesis of +Bartok)"_#Bartok_PhD. + +Only a single pair_coeff command is used with the {quip} style that +specifies a QUIP potential file containing the parameters of the +potential for all needed elements in XML format. This is followed by a +QUIP initialization string. Finally, the QUIP elements are mapped to +LAMMPS atom types by specifying N atomic numbers, where N is the +number of LAMMPS atom types: + +QUIP filename +QUIP initialization string +N atomic numbers = mapping of QUIP elements to atom types :ul + +See the "pair_coeff"_pair_coeff.html doc page for alternate ways +to specify the path for the potential file. + +A QUIP potential is fully specified by the filename which contains the +parameters of the potential in XML format, the initialisation string, +and the map of atomic numbers. + +GAP potentials can be obtained from the Data repository section of +"http://www.libatoms.org"_http://www.libatoms.org, where the +appropriate initialisation strings are also advised. The list of +atomic numbers must be matched to the LAMMPS atom types specified in +the LAMMPS data file or elsewhere. + +Two examples input scripts are provided in the examples/USER/quip +directory. + +[Mixing, shift, table, tail correction, restart, rRESPA info]: + +This pair style does not support the "pair_modify"_pair_modify.html +mix, shift, table, and tail options. + +This pair style does not write its information to "binary restart +files"_restart.html, since it is stored in potential files. Thus, you +need to re-specify the pair_style and pair_coeff commands in an input +script that reads a restart file. + +This pair style can only be used via the {pair} keyword of the +"run_style respa"_run_style.html command. It does not support the +{inner}, {middle}, {outer} keywords. + +[Restrictions:] + +This pair style is part of the USER-QUIP package. It is only enabled +if LAMMPS was built with that package. See the "Making +LAMMPS"_Section_start.html#start_3 section for more info. + +QUIP potentials are parametrized in electron-volts and Angstroms and +therefore should be used with LAMMPS metal "units"_units.html. + +[Related commands:] + +"pair_coeff"_pair_coeff.html + +:line + +:link(Bartok_2010) + +[(Bartok_2010)] AP Bartok, MC Payne, R Kondor, and G Csanyi, Physical +Review Letters 104, 136403 (2010). + +:link(Bartok_PhD) +[(Bartok_PhD)] A Bartok-Partay, PhD Thesis, University of Cambridge, +(2010). diff --git a/doc/pair_sdk.html b/doc/pair_sdk.html index 9115446438daa495f2da2d46ca64dd3bf6487538..edfb1d2202290a2893462934c774dee6364b3c0a 100644 --- a/doc/pair_sdk.html +++ b/doc/pair_sdk.html @@ -13,6 +13,8 @@

    pair_style lj/sdk/gpu command

    +

    pair_style lj/sdk/kk command +

    pair_style lj/sdk/omp command

    pair_style lj/sdk/coul/long command diff --git a/doc/pair_sdk.txt b/doc/pair_sdk.txt index 6bc180fc6e8757eda5fc59791f9466d35ad8e2db..75b6bf0efd54998760c82738c2b03fbe3f78d294 100644 --- a/doc/pair_sdk.txt +++ b/doc/pair_sdk.txt @@ -8,6 +8,7 @@ pair_style lj/sdk command :h3 pair_style lj/sdk/gpu command :h3 +pair_style lj/sdk/kk command :h3 pair_style lj/sdk/omp command :h3 pair_style lj/sdk/coul/long command :h3 pair_style lj/sdk/coul/long/gpu command :h3 diff --git a/doc/pair_srp.html b/doc/pair_srp.html index af2a3218c1638a91df59de95093056a07c43c40f..7761a0bfd315a82744aee75159615c7b0809eeee 100644 --- a/doc/pair_srp.html +++ b/doc/pair_srp.html @@ -19,7 +19,7 @@
  • bond_type = bond type to apply SRP interactions -
  • dist = min or mid +
  • distance = min or mid
  • zero or more keyword/value pairs may be appended @@ -36,7 +36,12 @@ pair_coeff 1 1 dpd 60.0 4.5 1.0 pair_coeff 1 2 none pair_coeff 2 2 srp 100.0 0.8 -
    pair_style hybrid srp 0.8 1 mid exclude yes
+
    pair_style hybrid dpd 1.0 1.0 12345 srp 0.8 1 min exclude yes
+pair_coeff 1 1 dpd 60.0 50 1.0 
+pair_coeff 1 2 none 
+pair_coeff 2 2 srp 40.0 
+
    
+
    pair_style hybrid srp 0.8 2 mid 
 pair_coeff 1 1 none 
 pair_coeff 1 2 none 
 pair_coeff 2 2 srp 100.0 0.8 
@@ -74,7 +79,7 @@ the data file or restart file read by the read_dataread_restart commands:
 
    
 
    • C (force units)
-
    • Rc (distance units) 
+
    • rc (distance units) 
 
    
 
    The last coefficient is optional. If not specified, the global cutoff
 is used.
@@ -95,15 +100,16 @@ there are no regular atoms of bptype.
 
    
 
    The optional exclude keyword determines if forces are computed
 between first neighbor (directly connected) bonds.  For a setting of
-yes they are, for no they are not.
+no, first neighbor forces are computed; for yes they are not computed. A setting of no
+cannot be used with the min option for distance calculation because the the minimum distance between 
+directly connected bonds is zero.
 
    
 
    Pair style srp turns off normalization of thermodynamic properties
 by particle number, as if the command thermo_modify norm
-no had been issued.  A warning will be given if
-this setting is overridden in the input script.
+no had been issued.  
 
    
 
    The pairwise energy associated with style srp is shifted to be zero
-at the cutoff distance Rc.
+at the cutoff distance rc.
 
    
 
    
 
@@ -158,7 +164,7 @@ for non-bonded interactions.
 
 
 
-
    (Sirk) Sirk TW, Slizoberg YR, Brennan JK, Lisal M, Andzelm JW, J
+
    (Sirk) Sirk TW, Sliozberg YR, Brennan JK, Lisal M, Andzelm JW, J
 Chem Phys, 136 (13) 134903, 2012.
 
    
 
diff --git a/doc/pair_srp.txt b/doc/pair_srp.txt
index 26eb921b18ed2a8278816053e104240dc62a6f99..2944979a72fcade0d9835ef0af9d0710e31c4ee5 100644
--- a/doc/pair_srp.txt
+++ b/doc/pair_srp.txt
@@ -14,7 +14,7 @@ pair_style srp cutoff bond_type dist keyword value ...
 
 cutoff = global cutoff for SRP interactions (distance units) :ulb,l
 bond_type = bond type to apply SRP interactions :l
-dist = {min} or {mid} :l
+distance = {min} or {mid} :l
 zero or more keyword/value pairs may be appended :l
 keyword = {exclude} :l
   {exclude} value = {yes} or {no} :pre
@@ -27,7 +27,12 @@ pair_coeff 1 1 dpd 60.0 4.5 1.0
 pair_coeff 1 2 none 
 pair_coeff 2 2 srp 100.0 0.8 :pre
 
-pair_style hybrid srp 0.8 1 mid exclude yes
+pair_style hybrid dpd 1.0 1.0 12345 srp 0.8 1 min exclude yes
+pair_coeff 1 1 dpd 60.0 50 1.0 
+pair_coeff 1 2 none 
+pair_coeff 2 2 srp 40.0 :pre 
+
+pair_style hybrid srp 0.8 2 mid 
 pair_coeff 1 1 none 
 pair_coeff 1 2 none 
 pair_coeff 2 2 srp 100.0 0.8 :pre 
@@ -65,7 +70,7 @@ the data file or restart file read by the "read_data"_read_data.html
 or "read_restart"_read_restart.html commands:
 
 {C} (force units)
-{Rc} (distance units) :ul
+{rc} (distance units) :ul
 
 The last coefficient is optional. If not specified, the global cutoff
 is used.
@@ -86,15 +91,16 @@ there are no regular atoms of {bptype}.
 
 The optional {exclude} keyword determines if forces are computed
 between first neighbor (directly connected) bonds.  For a setting of
-{yes} they are, for {no} they are not.
+{no}, first neighbor forces are computed; for {yes} they are not computed. A setting of {no}
+cannot be used with the {min} option for distance calculation because the the minimum distance between 
+directly connected bonds is zero.
 
 Pair style {srp} turns off normalization of thermodynamic properties
 by particle number, as if the command "thermo_modify norm
-no"_thermo_modify.html had been issued.  A warning will be given if
-this setting is overridden in the input script.
+no"_thermo_modify.html had been issued.  
 
 The pairwise energy associated with style {srp} is shifted to be zero
-at the cutoff distance {Rc}.
+at the cutoff distance {rc}.
 
 :line
 
@@ -148,5 +154,5 @@ The default keyword value is exclude = yes.
 :line
 
 :link(Sirk)
-[(Sirk)] Sirk TW, Slizoberg YR, Brennan JK, Lisal M, Andzelm JW, J
+[(Sirk)] Sirk TW, Sliozberg YR, Brennan JK, Lisal M, Andzelm JW, J
 Chem Phys, 136 (13) 134903, 2012.
diff --git a/doc/pair_sw.html b/doc/pair_sw.html
index 040b4166ea4bf85baa360cdfb09cc6a41c9fb512..70611a532841e993702971d0778d46893f17ce23 100644
--- a/doc/pair_sw.html
+++ b/doc/pair_sw.html
@@ -15,6 +15,8 @@

    • pair_style sw/gpu command

    +

    pair_style sw/intel command +

    pair_style sw/omp command

    Syntax: @@ -164,6 +166,11 @@ by including their suffix, or you can use the suffix command in your input script.

    +

    When using the USER-INTEL package with this style, there is an +additional 5 to 10 percent performance improvement when the +Stillinger-Weber parameters p and q are set to 4 and 0 respectively. +These parameters are common for modeling silicon and water. +

    See Section_accelerate of the manual for more instructions on how to use the accelerated styles effectively.

    diff --git a/doc/pair_sw.txt b/doc/pair_sw.txt index 40f86682d3ee1783a6d0e5a25be70ff812192404..b2f9f8a5f28d6814a134bc43f4754f6218642cd0 100644 --- a/doc/pair_sw.txt +++ b/doc/pair_sw.txt @@ -9,6 +9,7 @@ pair_style sw command :h3 pair_style sw/cuda command :h3 pair_style sw/gpu command :h3 +pair_style sw/intel command :h3 pair_style sw/omp command :h3 [Syntax:] @@ -158,6 +159,11 @@ by including their suffix, or you can use the "-suffix command-line switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can use the "suffix"_suffix.html command in your input script. +When using the USER-INTEL package with this style, there is an +additional 5 to 10 percent performance improvement when the +Stillinger-Weber parameters p and q are set to 4 and 0 respectively. +These parameters are common for modeling silicon and water. + See "Section_accelerate"_Section_accelerate.html of the manual for more instructions on how to use the accelerated styles effectively. diff --git a/doc/print.html b/doc/print.html index 3b868c860a38b7d1f06db49672d4fad4410289c3..e97b5e2188d2bdcdae62fa49d6582ee5647339a4 100644 --- a/doc/print.html +++ b/doc/print.html @@ -13,8 +13,8 @@

    Syntax:

    -

    print string keyword value:pre -

    +
    print string keyword value 
+