From badfd0bc40072d2da1a4de14eb0c098682b360bb Mon Sep 17 00:00:00 2001 From: jtclemm Date: Mon, 20 Mar 2023 15:34:52 -0600 Subject: [PATCH] Specifying dimensions, lamda->lambda --- doc/src/neighbor.rst | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/doc/src/neighbor.rst b/doc/src/neighbor.rst index b5ca4d15a8..c4a2caac81 100644 --- a/doc/src/neighbor.rst +++ b/doc/src/neighbor.rst @@ -62,11 +62,11 @@ sets of bins are then used to construct the neighbor lists as as further described by Shire, Hanley, and Stratford :ref:`(Shire) ` and Monti et al. :ref:`(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 argued in Monti et al. :ref:`(Monti) `. +instance in a dense binary system in d-dimensions with a ratio of the size +of the largest to smallest collection bin :math:`\lambda`, the computational +costs of building a default neighbor list grows as :math:`\lambda^d` while +the costs for *multi* grows as :math:`\lambda^d`, equivalent to the cost +of force evaluations, as argued in Monti et al. :ref:`(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