Minor patches to BPM, multi, and rigid

doc/src/bond_bpm_rotational.rst

@@ -10,7 +10,7 @@ Syntax
 
    bond_style bpm/rotational keyword value attribute1 attribute2 ...
 
-* optional keyword = *overlay/pair* or *store/local* or *smooth*
+* optional keyword = *overlay/pair* or *store/local* or *smooth* or *break/no*
 
   .. parsed-literal::
 
@@ -30,6 +30,9 @@ Syntax
        *smooth* value = *yes* or *no*
           smooths bond forces near the breaking point
 
+       *break/no*
+          indicates that bonds should not break during a run
+
 Examples
 """"""""
 
@@ -138,6 +141,10 @@ the *overlay/pair* keyword. These settings require specific
 restrictions.  Further details can be found in the `:doc: how to
 <Howto_BPM>` page on BPMs.
 
+If the *break/no* keyword is used, then LAMMPS assumes bonds should not break
+during a simulation run. This will prevent some unnecessary calculation.
+However, if a bond does break, it will trigger an error.
+
 If the *store/local* keyword is used, an internal fix will track bonds that
 break during the simulation. Whenever a bond breaks, data is processed
 and transferred to an internal fix labeled *fix_ID*. This allows the

doc/src/bond_bpm_spring.rst

@@ -10,7 +10,7 @@ Syntax
 
    bond_style bpm/spring keyword value attribute1 attribute2 ...
 
-* optional keyword = *overlay/pair* or *store/local* or *smooth*
+* optional keyword = *overlay/pair* or *store/local* or *smooth* or *break/no*
 
   .. parsed-literal::
 
@@ -30,6 +30,9 @@ Syntax
        *smooth* value = *yes* or *no*
           smooths bond forces near the breaking point
 
+       *break/no*
+          indicates that bonds should not break during a run
+
 Examples
 """"""""
 
@@ -45,16 +48,17 @@ Examples
 Description
 """""""""""
 
-The *bpm/spring* bond style computes forces and torques based on
-deviations from the initial reference state of the two atoms.  The
-reference state is stored by each bond when it is first computed in
-the setup of a run. Data is then preserved across run commands and is
-written to :doc:`binary restart files <restart>` such that restarting
-the system will not reset the reference state of a bond.
+The *bpm/spring* bond style computes forces based on deviations from
+the initial reference state of the two atoms.  The reference state is
+stored by each bond when it is first computed in the setup of a run.
+Data is then preserved across run commands and is written to
+:doc:`binary restart files <restart>` such that restarting the system
+will not reset the reference state of a bond.
 
 This bond style only applies central-body forces which conserve the
 translational and rotational degrees of freedom of a bonded set of
-particles. The force has a magnitude of
+particles based on a model described by Clemmer and Robbins
+:ref:`(Clemmer) <fragment-Clemmer>`. The force has a magnitude of
 
 .. math::
 
@@ -103,6 +107,10 @@ the *overlay/pair* keyword. These settings require specific
 restrictions.  Further details can be found in the `:doc: how to
 <Howto_BPM>` page on BPMs.
 
+If the *break/no* keyword is used, then LAMMPS assumes bonds should not break
+during a simulation run. This will prevent some unnecessary calculation.
+However, if a bond does break, it will trigger an error.
+
 If the *store/local* keyword is used, an internal fix will track bonds that
 break during the simulation. Whenever a bond breaks, data is processed
 and transferred to an internal fix labeled *fix_ID*. This allows the
@@ -198,6 +206,10 @@ The option defaults are *smooth* = *yes*
 
 ----------
 
+.. _fragment-Clemmer:
+
+**(Clemmer)** Clemmer and Robbins, Phys. Rev. Lett. (2022).
+
 .. _Groot4:
 
 **(Groot)** Groot and Warren, J Chem Phys, 107, 4423-35 (1997).

doc/src/comm_modify.rst

@@ -69,6 +69,7 @@ For many systems this is an efficient algorithm, but for systems with
 widely varying cutoffs for different type pairs, the *multi* or *multi/old* mode can
 be faster.  In *multi*, each atom is assigned to a collection which should
 correspond to a set of atoms with similar interaction cutoffs.
+See the :doc:`neighbor <neighbor>` command for a detailed description of collections.
 In this case, each atom collection is assigned its own distance
 cutoff for communication purposes, and fewer atoms will be
 communicated. in *multi/old*, a similar technique is used but atoms

doc/src/neighbor.rst

@@ -59,9 +59,16 @@ long cutoff, but other type pairs have a much shorter cutoff. The
 sized particles, where "size" may mean the physical size of the particle
 or its cutoff distance for interacting with other particles. Different
 sets of bins are then used to construct the neighbor lists as as further
-described by Shire, Hanley, and Stratford :ref:`(Shire) <bytype-Shire>`.
-This imposes some extra setup overhead, but the searches themselves may
-be much faster. By default, each atom type defines a separate collection
+described by Shire, Hanley, and Stratford :ref:`(Shire) <multi-Shire>`
+and Monti et al. :ref:`(Monti) <multi-Monti>`. This imposes some extra
+setup overhead, but the searches themselves may be much faster. For
+instance in a dense binary system with a ratio of the size of the largest
+to smallest collection bin :math:`\lamda`, the computational costs of
+building a default neighbor list grows as :math:`\lamda^6` while the costs
+for *multi* grows as :math:`\lamda^3`, equivalent to the cost of force
+evaluations, as identified in Monti et al. :ref:`(Monti) <multi-Monti>`.
+
+By default in *multi*, each atom type defines a separate collection
 of particles. For systems where two or more atom types have the same
 size (either physical size or cutoff distance), the definition of
 collections can be customized, which can result in less overhead and
@@ -118,6 +125,10 @@ Default
 
 ----------
 
-.. _bytype-Shire:
+.. _multi-Shire:
 
-**(Shire)** Shire, Hanley and Stratford, Comp Part Mech, (2020).
+**(Shire)** Shire, Hanley and Stratford, Comp. Part. Mech., (2020).
+
+.. _multi-Monti:
+
+**(Monti)** Monti, Clemmer, Srivastava, Silbert, Grest, and Lechman, Phys. Rev. E, (2022).