Merge branch 'lammps:develop' into develop

doc/src/Howto_github.rst

@@ -141,7 +141,8 @@ unrelated feature, you should switch branches!
    Committing changes to the *develop*, *release*, or *stable* branches
    is strongly discouraged.  While it may be convenient initially, it
    will create more work in the long run.  Various texts and tutorials
-   on using git effectively discuss the motivation for this.
+   on using git effectively discuss the motivation for using feature
+   branches instead.
 
 **After changes are made**
 

doc/src/Install_git.rst

@@ -28,8 +28,9 @@ provides `limited support for subversion clients <svn_>`_.
 
 You can follow the LAMMPS development on 3 different git branches:
 
-* **stable**   :  this branch is updated with every stable release;
-  updates are always "fast forward" merges from *develop*
+* **stable**   :  this branch is updated from the *release* branch with
+  every stable release version and also has selected bug fixes and updates
+  back-ported from the *develop* branch
 * **release**  :  this branch is updated with every patch release;
   updates are always "fast forward" merges from *develop*
 * **develop**  :  this branch follows the ongoing development and
@@ -47,20 +48,22 @@ your machine and "release" is one of the 3 branches listed above.
 (Note that you actually download all 3 branches; you can switch
 between them at any time using "git checkout <branch name>".)
 
-.. note::
+.. admonition:: Saving time and disk space when using ``git clone``
 
    The complete git history of the LAMMPS project is quite large because
    it contains the entire commit history of the project since fall 2006,
-   which includes the time when LAMMPS was managed with subversion. This
-   also includes commits that have added and removed some large files
-   (mostly by accident).  If you do not need access to the entire commit
-   history, you can speed up the "cloning" process and reduce local disk
-   space requirements by using the *--depth* git command line flag thus
-   create a "shallow clone" of the repository that contains only a
-   subset of the git history. Using a depth of 1000 is usually sufficient
-   to include the head commits of the *develop* and the *release* branches.
-   To include the head commit of the *stable* branch you may need a depth
-   of up to 10000.
+   which includes the time when LAMMPS was managed with subversion.
+   This includes a few commits that have added and removed some large
+   files (mostly by accident).  If you do not need access to the entire
+   commit history (most people don't), you can speed up the "cloning"
+   process and reduce local disk space requirements by using the
+   *--depth* git command line flag.  That will create a "shallow clone"
+   of the repository containing only a subset of the git history.  Using
+   a depth of 1000 is usually sufficient to include the head commits of
+   the *develop* and the *release* branches.  To include the head commit
+   of the *stable* branch you may need a depth of up to 10000.  If you
+   later need more of the git history, you can always convert the
+   shallow clone into a "full clone".
 
 Once the command completes, your directory will contain the same files
 as if you unpacked a current LAMMPS tarball, with the exception, that

doc/src/Manual_version.rst

@@ -10,23 +10,31 @@ Whenever we fix a bug or update or add a feature, it will be merged into
 the *develop* branch of the git repository.  When a sufficient number of
 changes have accumulated *and* the software passes a set of automated
 tests, we release it in the next *patch* release, which are made every
-few weeks.  Info on patch releases are on `this website page
+few weeks.  The *release* branch of the git repository is updated with
+every such release.  Info on patch releases are on `this website page
 <https://www.lammps.org/bug.html>`_.
 
-Once or twice a year, only bug fixes and small, non-intrusive changes are
-included for a period of time, and the code is subjected to more detailed
+Once or twice a year, we apply only bug fixes and small, non-intrusive
+changes to the *develop* branch and the code is subjected to more detailed
 and thorough testing than the default automated testing.  The latest
-patch release after such a period is then labeled as a *stable* version.
+patch release after such a period is then also labeled as a *stable* version
+and the *stable* branch is updated with it.  Between stable releases
+we occasionally release some updates to the stable release containing
+only bug fixes and updates back-ported from *develop* but no new features
+and update the *stable* branch accordingly.
 
-Each version of LAMMPS contains all the features and bug-fixes up to
-and including its version date.
+Each version of LAMMPS contains all the documented features up to and
+including its version date.
 
 The version date is printed to the screen and logfile every time you
 run LAMMPS. It is also in the file src/version.h and in the LAMMPS
 directory name created when you unpack a tarball.  And it is on the
 first page of the :doc:`manual <Manual>`.
 
-* If you browse the HTML pages on the LAMMPS WWW site, they always
-  describe the most current patch release of LAMMPS.
+* If you browse the HTML pages on the LAMMPS WWW site, they will by
+  default describe the most current patch release version of LAMMPS.
+  In the navigation bar on the bottom left, there is the option to
+  view instead the documentation for the most recent *stable* version
+  or the latest version from the current development branch.
 * If you browse the HTML pages included in your tarball, they
   describe the version you have, which may be older.

doc/src/dump_modify.rst

@@ -710,7 +710,9 @@ default and it can be disabled with the :code:`checksum` keyword.
 
 Restrictions
 """"""""""""
- none
+
+Not all *dump_modify* options can be applied to all dump styles.
+Details are in the discussions of the individual options.
 
 Related commands
 """"""""""""""""

doc/src/pair_granular.rst

@@ -205,7 +205,7 @@ For *damping mass_velocity*, the normal damping is given by:
    \eta_n = \eta_{n0} m_{eff}
 
 Here, :math:`\eta_{n0}` is the damping coefficient specified for the normal
-contact model, in units of *mass*\ /\ *time* and
+contact model, in units of 1/\ *time* and
 :math:`m_{eff} = m_i m_j/(m_i + m_j)` is the effective mass.
 Use *damping mass_velocity* to reproduce the damping behavior of
 *pair gran/hooke/\**.

doc/src/pair_lebedeva_z.rst

@@ -26,15 +26,29 @@ Examples
 Description
 """""""""""
 
-The *lebedeva/z* style computes the Lebedeva interaction
-potential as described in :ref:`(Lebedeva et al.) <Leb01>`. An important simplification is made,
-which is to take all normals along the z-axis.
+The *lebedeva/z* pair style computes the Lebedeva interaction potential
+as described in :ref:`(Lebedeva1) <Leb01>` and :ref:`(Lebedeva2)
+<Leb02>`.  An important simplification is made, which is to take all
+normals along the z-axis.
+
+The Lebedeva potential is intended for the description of the interlayer
+interaction between graphene layers.  To perform a realistic simulation,
+this potential must be used in combination with an intralayer potential
+such as :doc:`AIREBO <pair_airebo>` or :doc:`Tersoff <pair_tersoff>`
+facilitated by using pair style :doc:`hybrid/overlay <pair_hybrid>`.  To
+keep the intralayer properties unaffected, the interlayer interaction
+within the same layers should be avoided.  This can be achieved by
+assigning different atom types to atoms of different layers (e.g. 1 and
+2 in the examples above).
+
+Other interactions can be set to zero using pair_style *none*\ .
+
 
 .. math::
 
-   E       = & \frac{1}{2} \sum_i \sum_{i \neq j} V_{ij}\\
+   E       = & \frac{1}{2} \sum_i \sum_{j \neq i} V_{ij}\\
    V_{ij}  = & B e^{-\alpha(r_{ij} - z_0)} \\
-             & + C(1 + D_1\rho^2_{ij} + D_2\rho^4_{ij} e^{-\lambda_1\rho^2_{ij}} e^{-\lambda_2 (z^2_{ij} - z^2_0)} \\
+             & + C(1 + D_1\rho^2_{ij} + D_2\rho^4_{ij}) e^{-\lambda_1\rho^2_{ij}} e^{-\lambda_2 (z^2_{ij} - z^2_0)} \\
              & - A \left(\frac{z_0}{r_ij}\right)^6 + A \left( \frac{z_0}{r_c} \right)^6 \\
    \rho^2_{ij} = & x^2_{ij} + y^2_{ij} \qquad (\mathbf{n_i} \equiv \mathbf{\hat{z}})
 
@@ -43,12 +57,15 @@ Energies are shifted so that they go continuously to zero at the cutoff assuming
 that the exponential part of :math:`V_{ij}` (first term) decays sufficiently fast.
 This shift is achieved by the last term in the equation for :math:`V_{ij}` above.
 
-The parameter file (e.g. CC.Lebedeva), is intended for use with metal
-:doc:`units <units>`, with energies in meV. An additional parameter, *S*,
-is available to facilitate scaling of energies.
+The provided parameter file (CC.Lebedeva) contains two sets of parameters.
 
-This potential must be used in combination with hybrid/overlay.
-Other interactions can be set to zero using pair_style *none*\ .
+- The first set (element name "C") is suitable for normal conditions and
+  is taken from :ref:`(Popov1) <Popov>`
+- The second set (element name "C1") is suitable for high-pressure
+  conditions and is taken from :ref:`(Koziol1) <Koziol>`
+
+Both sets contain an additional parameter, *S*, that can be used to
+facilitate scaling of energies and is set to 1.0 by default.
 
 Restrictions
 """"""""""""
@@ -77,4 +94,16 @@ none
 
 .. _Leb01:
 
-**(Lebedeva et al.)** I. V. Lebedeva, A. A. Knizhnik, A. M. Popov, Y. E. Lozovik, B. V. Potapkin, Phys. Rev. B, 84, 245437 (2011)
+**(Lebedeva1)** I. V. Lebedeva, A. A. Knizhnik, A. M. Popov, Y. E. Lozovik, B. V. Potapkin, Phys. Rev. B, 84, 245437 (2011)
+
+.. _Leb02:
+
+**(Lebedeva2)** I. V. Lebedeva, A. A. Knizhnik, A. M. Popov, Y. E. Lozovik, B. V. Potapkin, Physica E: 44, 949-954 (2012)
+
+.. _Popov:
+
+**(Popov1)** A.M. Popov, I. V. Lebedeva, A. A. Knizhnik, Y. E. Lozovik and B. V. Potapkin, Chem. Phys. Lett. 536, 82-86 (2012).
+
+.. _Koziol:
+
+**(Koziol1)** Z. Koziol, G. Gawlik and J. Jagielski, Chinese Phys. B 28, 096101 (2019).