Merge branch 'lammps:develop' into ml-uf3

.github/CODEOWNERS

@@ -84,7 +84,7 @@ src/bond.*                @sjplimp
 src/comm*.*               @sjplimp
 src/compute.*             @sjplimp
 src/dihedral.*            @sjplimp
-src/domain.*              @sjplimp
+src/domain.*              @sjplimp @stanmoore1
 src/dump*.*               @sjplimp
 src/error.*               @sjplimp
 src/finish.*              @sjplimp

cmake/Modules/Packages/KOKKOS.cmake

@@ -45,8 +45,8 @@ if(DOWNLOAD_KOKKOS)
   list(APPEND KOKKOS_LIB_BUILD_ARGS "-DCMAKE_CXX_EXTENSIONS=${CMAKE_CXX_EXTENSIONS}")
   list(APPEND KOKKOS_LIB_BUILD_ARGS "-DCMAKE_TOOLCHAIN_FILE=${CMAKE_TOOLCHAIN_FILE}")
   include(ExternalProject)
-  set(KOKKOS_URL "https://github.com/kokkos/kokkos/archive/4.2.01.tar.gz" CACHE STRING "URL for KOKKOS tarball")
-  set(KOKKOS_MD5 "16b9b09ae947d434dfb58fc5c87c2b76" CACHE STRING "MD5 checksum of KOKKOS tarball")
+  set(KOKKOS_URL "https://github.com/kokkos/kokkos/archive/4.3.00.tar.gz" CACHE STRING "URL for KOKKOS tarball")
+  set(KOKKOS_MD5 "889dcea2b5ced3debdc5b0820044bdc4" CACHE STRING "MD5 checksum of KOKKOS tarball")
   mark_as_advanced(KOKKOS_URL)
   mark_as_advanced(KOKKOS_MD5)
   GetFallbackURL(KOKKOS_URL KOKKOS_FALLBACK)
@@ -71,7 +71,7 @@ if(DOWNLOAD_KOKKOS)
   add_dependencies(LAMMPS::KOKKOSCORE kokkos_build)
   add_dependencies(LAMMPS::KOKKOSCONTAINERS kokkos_build)
 elseif(EXTERNAL_KOKKOS)
-  find_package(Kokkos 4.2.01 REQUIRED CONFIG)
+  find_package(Kokkos 4.3.00 REQUIRED CONFIG)
   target_link_libraries(lammps PRIVATE Kokkos::kokkos)
 else()
   set(LAMMPS_LIB_KOKKOS_SRC_DIR ${LAMMPS_LIB_SOURCE_DIR}/kokkos)

doc/src/Build_extras.rst

@@ -533,9 +533,6 @@ They must be specified in uppercase.
    *  - A64FX
       - HOST
       - ARMv8.2 with SVE Support
-   *  - WSM
-      - HOST
-      - Intel Westmere CPU (SSE 4.2)
    *  - SNB
       - HOST
       - Intel Sandy/Ivy Bridge CPU (AVX 1)
@@ -566,18 +563,15 @@ They must be specified in uppercase.
    *  - KNL
       - HOST
       - Intel Knights Landing Xeon Phi
-   *  - BGQ
-      - HOST
-      - IBM Blue Gene/Q CPU
-   *  - POWER7
-      - HOST
-      - IBM POWER7 CPU
    *  - POWER8
       - HOST
       - IBM POWER8 CPU
    *  - POWER9
       - HOST
       - IBM POWER9 CPU
+   *  - RISCV_SG2042
+      - HOST
+      - SG2042 (RISC-V) CPU
    *  - KEPLER30
       - GPU
       - NVIDIA Kepler generation CC 3.0 GPU
@@ -666,7 +660,7 @@ They must be specified in uppercase.
       - GPU
       - Intel GPU Ponte Vecchio
 
-This list was last updated for version 4.2 of the Kokkos library.
+This list was last updated for version 4.3.0 of the Kokkos library.
 
 .. tabs::
 

doc/src/Commands_pair.rst

@@ -245,6 +245,7 @@ OPT.
    * :doc:`oxrna2/coaxstk <pair_oxrna2>`
    * :doc:`pace (k) <pair_pace>`
    * :doc:`pace/extrapolation (k) <pair_pace>`
+   * :doc:`pedone (o) <pair_pedone>`
    * :doc:`pod <pair_pod>`
    * :doc:`peri/eps <pair_peri>`
    * :doc:`peri/lps (o) <pair_peri>`

doc/src/Developer_utils.rst

@@ -635,10 +635,10 @@ Tohoku University (under MIT license)
 
 ----------
 
-.. doxygenfunction:: MathEigen::jacobi3(double const *const *mat, double *eval, double **evec)
+.. doxygenfunction:: MathEigen::jacobi3(double const *const *mat, double *eval, double **evec, int sort)
    :project: progguide
 
-.. doxygenfunction:: MathEigen::jacobi3(double const mat[3][3], double *eval, double evec[3][3])
+.. doxygenfunction:: MathEigen::jacobi3(double const mat[3][3], double *eval, double evec[3][3], int sort)
    :project: progguide
 
 ---------------------------

doc/src/Errors_details.rst

@@ -13,15 +13,44 @@ discussions of such cases.
 Unknown identifier in data file
 -------------------------------
 
-This error happens when LAMMPS encounters a line of text in an unexpected format
-while reading a data file. This is most commonly cause by inconsistent header and
-section data.  The header section informs LAMMPS how many entries or lines are expected in the
-various sections (like Atoms, Masses, Pair Coeffs, *etc.*\ ) of the data file.
-If there is a mismatch, LAMMPS will either keep reading beyond the end of a section
-or stop reading before the section has ended.
-
-Such a mismatch can happen unexpectedly when the first line of the data
-is *not* a comment as required by the format.  That would result in
-LAMMPS expecting, for instance, 0 atoms because the "atoms" header line
-is treated as a comment.
+This error happens when LAMMPS encounters a line of text with an
+unexpected keyword while :doc:`reading a data file <read_data>`.  This
+would be either header keywords or section header keywords.  This is
+most commonly due to a mistyped keyword or due to a keyword that is
+inconsistent with the :doc:`atom style <atom_style>` used.
 
+The header section informs LAMMPS how many entries or lines are expected
+in the various sections (like Atoms, Masses, Pair Coeffs, *etc.*\ ) of
+the data file.  If there is a mismatch, LAMMPS will either keep reading
+beyond the end of a section or stop reading before the section has
+ended.  In that case the next line will not contain a recognized keyword.
+
+Such a mismatch can also happen when the first line of the data
+is *not* a comment as required by the format, but a line with a valid
+header keyword.  That would result in LAMMPS expecting, for instance,
+0 atoms because the "atoms" header line is the first line and thus
+treated as a comment.
+
+Another possibility to trigger this error is to have a keyword in the
+data file that corresponds to a fix (e.g. :doc:`fix cmap <fix_cmap>`)
+but the :doc:`read_data <read_data>` command is missing the (optional)
+arguments that identify the fix and the header keyword and section
+keyword or those arguments are inconsistent with the keywords in the
+data file.
+
+.. _err0002:
+
+Incorrect format in ... section of data file
+--------------------------------------------
+
+This error happens when LAMMPS reads the contents of a section of a
+:doc:`data file <read_data>` and the number of parameters in the line
+differs from what is expected.  This most commonly happens, when the
+atom style is different from what is expected for a specific data file
+since changing the atom style usually changes the format of the line.
+
+This error can also happen when the number of entries indicated in the
+header of a data file (e.g. the number of atoms) is larger than the
+number of lines provided (e.g. in the corresponding Atoms section)
+and then LAMMPS will continue reading into the next section and that
+would have a completely different format.

doc/src/fix_ave_correlate.rst

@@ -65,7 +65,6 @@ Examples
    fix 1 all ave/correlate 1 50 10000 &
              c_thermo_press[1] c_thermo_press[2] c_thermo_press[3] &
              type upper ave running title1 "My correlation data"
-
    fix 1 all ave/correlate 1 50 10000 c_thermo_press[*]
 
 Description

doc/src/fix_ave_correlate_long.rst

@@ -20,11 +20,11 @@ Syntax
   .. parsed-literal::
 
        c_ID = global scalar calculated by a compute with ID
-       c_ID[I] = Ith component of global vector calculated by a compute with ID
+       c_ID[I] = Ith component of global vector calculated by a compute with ID, I can include wildcard (see below)
        f_ID = global scalar calculated by a fix with ID
-       f_ID[I] = Ith component of global vector calculated by a fix with ID
+       f_ID[I] = Ith component of global vector calculated by a fix with ID, I can include wildcard (see below)
        v_name = global value calculated by an equal-style variable with name
-       v_name[I] = Ith component of global vector calculated by a vector-style variable with name
+       v_name[I] = Ith component of a vector-style variable with name, I can include wildcard (see below)
 
 * zero or more keyword/arg pairs may be appended
 * keyword = *type* or *start* or *file* or *overwrite* or *title1* or *title2* or *ncorr* or *nlen* or *ncount*
@@ -63,6 +63,7 @@ Examples
    fix 1 all ave/correlate/long 1 10000 &
              c_thermo_press[1] c_thermo_press[2] c_thermo_press[3] &
              type upper title1 "My correlation data" nlen 15 ncount 3
+   fix 1 all ave/correlate/long 1 10000 c_thermo_press[*]
 
 Description
 """""""""""
@@ -80,8 +81,10 @@ specified values may represent calculations performed by computes and
 fixes which store their own "group" definitions.
 
 Each listed value can be the result of a compute or fix or the
-evaluation of an equal-style variable. See the
-:doc:`fix ave/correlate <fix_ave_correlate>` page for details.
+evaluation of an equal-style or vector-style variable.  For
+vector-style variables, the specified indices can include a wildcard
+character.  See the :doc:`fix ave/correlate <fix_ave_correlate>` page
+for details.
 
 The *Nevery* and *Nfreq* arguments specify on what time steps the input
 values will be used to calculate correlation data and the frequency

doc/src/fix_ttm.rst

@@ -136,23 +136,23 @@ transfer between the subsystems:
   \bigtriangledown (\kappa_e \bigtriangledown T_e) -
   g_p (T_e - T_a) + g_s T_a'
 
-where C_e is the specific heat, rho_e is the density, kappa_e is the
-thermal conductivity, T is temperature, the "e" and "a" subscripts
-represent electronic and atomic subsystems respectively, g_p is the
-coupling constant for the electron-ion interaction, and g_s is the
-electron stopping coupling parameter.  C_e, rho_e, and kappa_e are
-specified as parameters to the fix.  The other quantities are derived.
-The form of the heat diffusion equation used here is almost the same
-as that in equation 6 of :ref:`(Duffy) <Duffy>`, with the exception that the
-electronic density is explicitly represented, rather than being part
-of the specific heat parameter.
+where :math:`C_e` is the specific heat, :math:`\rho_e` is the density,
+:math:`\kappa_e` is the thermal conductivity, *T* is temperature, the
+"e" and "a" subscripts represent electronic and atomic subsystems
+respectively, :math:`g_p` is the coupling constant for the electron-ion
+interaction, and :math:`g_s` is the electron stopping coupling
+parameter.  :math:`C_e`, :math:`\rho_e`, and :math:`\kappa_e` are
+specified as parameters to the fix *ttm* or *ttm/grid*.  The other
+quantities are derived.  The form of the heat diffusion equation used
+here is almost the same as that in equation 6 of :ref:`(Duffy) <Duffy>`,
+with the exception that the electronic density is explicitly
+represented, rather than being part of the specific heat parameter.
 
 Currently, the TTM fixes assume that none of the user-supplied
-parameters will vary with temperature. Note that :ref:`(Duffy)
-<Duffy>` used a tanh() functional form for the temperature dependence
-of the electronic specific heat, but ignored temperature dependencies
-of any of the other parameters.  See more discussion below for fix
-ttm/mod.
+parameters will vary with temperature. Note that :ref:`(Duffy) <Duffy>`
+used a tanh() functional form for the temperature dependence of the
+electronic specific heat, but ignored temperature dependencies of any of
+the other parameters.  See more discussion below for fix *ttm/mod*.
 
 .. note::
 
@@ -265,41 +265,42 @@ heat sources (e.g. laser heating in ablation simulations):
   \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})
 
-where theta is the Heaviside step function, I_0 is the (absorbed)
-laser pulse intensity for ablation simulations, l_skin is the depth
-of skin-layer, and all other designations have the same meaning as in
-the former equation. The duration of the pulse is set by the parameter
-*tau* in the *init_file*.
+where :math:`\theta` is the Heaviside step function, :math:`I_0` is the
+(absorbed) laser pulse intensity for ablation simulations,
+:math:`l_{skin}` is the depth of the skin-layer, and all other
+designations have the same meaning as in the former equation. The
+duration of the pulse is set by the parameter *tau* in the *init_file*.
 
-Fix ttm/mod also allows users to specify the dependencies of C_e and
-kappa_e on the electronic temperature. The specific heat is expressed
-as
+Fix *ttm/mod* also allows users to specify the dependencies of
+:math:`C_e` and :math:`\kappa_e` on the electronic temperature. The
+specific heat is expressed as
 
 .. math::
 
   C_e = C_0 + (a_0 + a_1 X + a_2 X^2 + a_3 X^3 + a_4 X^4) \exp (-(AX)^2)
 
-where *X* = T_e/1000, and the thermal conductivity is defined as
-kappa_e = D_e\*rho_e\*C_e, where D_e is the thermal diffusion
-coefficient.
+where :math:`X = \frac{T_e}{1000}`, and the thermal conductivity is
+defined as :math:`\kappa_e = D_e \cdot rho_e \cdot C_e`, where
+:math:`D_e` is the thermal diffusion coefficient.
 
-Electronic pressure effects are included in the TTM model to account
-for the blast force acting on ions because of electronic pressure
-gradient (see :ref:`(Chen) <Chen>`, :ref:`(Norman) <Norman>`).  The total force
+Electronic pressure effects are included in the TTM model to account for
+the blast force acting on ions because of electronic pressure gradient
+(see :ref:`(Chen) <Chen>`, :ref:`(Norman) <Norman>`).  The total force
 acting on an ion is:
 
 .. math::
 
   {\vec F}_i = - \partial U / \partial {\vec r}_i + {\vec
   F}_{langevin} - \nabla P_e/n_{ion}
 
-where F_langevin is a force from Langevin thermostat simulating
-electron-phonon coupling, and nabla P_e/n_ion is the electron blast
-force.
+where :math:`F_{langevin}` is a force from Langevin thermostat
+simulating electron-phonon coupling, and :math:`\nabla P_e/n_{ion}` is
+the electron blast force.
 
-The electronic pressure is taken to be P_e = B\*rho_e\*C_e\*T_e
+The electronic pressure is taken to be :math:`P_e = B \cdot rho_e \cdot
+C_e \cdot T_e`
 
-The current fix ttm/mod implementation allows TTM simulations with a
+The current fix *ttm/mod* implementation allows TTM simulations with a
 vacuum. The vacuum region is defined as the grid cells with zero
 electronic temperature. The numerical scheme does not allow energy
 exchange with such cells. Since the material can expand to previously
@@ -319,10 +320,10 @@ electronic pressure gradient is calculated as
   \frac{x}{x+\lambda}\frac{(C_e{}T_e)_{x+\Delta
   x}-(C_e{}T_e)_{x}}{\Delta x} \right]
 
-where lambda is the electron mean free path (see :ref:`(Norman) <Norman>`,
-:ref:`(Pisarev) <Pisarev>`)
+where :math:`\lambda` is the electron mean free path (see :ref:`(Norman)
+<Norman>`, :ref:`(Pisarev) <Pisarev>`)
 
-The fix ttm/mod parameter file *init_file* has the following syntax.
+The fix *ttm/mod* parameter file *init_file* has the following syntax.
 Every line with an odd number is considered as a comment and
 ignored. The lines with the even numbers are treated as follows: