[gmx-users] Question about cut-off values with respect to the neighbor list

Justin Lemkul jalemkul at vt.edu
Sun Aug 19 02:27:16 CEST 2012

On 8/18/12 5:59 PM, Andrew DeYoung wrote:
> Hi,
> If you have time, I have some questions about the neighbor list and cut-off
> values.
> I am running NVT simulations with coulombtype = PME and vdwtype = cut-off.
> I have specified equal neighbor search, vdw, and Coulomb cut-offs: rlist =
> 1.5 nm, rvdw = 1.5 nm, rcoulomb = 1.5 nm.  Is it a good idea to use rlist =
> rvdw = rcoulomb?  (I typically use the default value of nstlist: nstlist =
> 10.)
> According to the manual
> (http://manual.gromacs.org/current/online/mdp_opt.html#vdw), using vdwtype =
> cut-off means that neighbor searching will be performed using a twin-range
> approach.  rvdw must be greater than or equal to rlist, rvdw >= rlist; in my
> case, I am using rvdw = rlist.  Is this a good idea?

Refer to the PDF manual for greater detail.  Since a single interaction range 
neighbor searching method is a special case of the twin-range method, one is, in 
a sense, always using a twin-range method.  The online manual leaves this 
somewhat ambiguous but the print manual contains a much better explanation.

The cutoff values should be dictated by the force field you're applying.  I've 
never seen a force field in Gromacs that should be used with 1.5-nm cutoffs, but 
perhaps you're using something that is non-standard.

> Section 4.6.3 of the manual describes.  Of course, in the neighbor list,
> "all interaction pairs within rlist are stored."  But "interactions between
> pairs that do not fall within rlist but do fall within max(rcoulomb,rvdw)
> are computed during neighbor searching."  Does this statement imply that I
> should use rvdw > rlist, rather than rvdw = rlist?

Again, this is dictated by the parameterization of the force field.  You're 
presupposing a solution to a problem that does not necessarily exist.

> However, there is no "grace distance" in Gromacs
> (http://lists.gromacs.org/pipermail/gmx-users/2004-January/008831.html).
> According to Berk Hess:
> "There is no 'grace distance' in Gromacs. A pair of atoms is put in the
> neighborlist if the centers of geometry of the charge groups they belong to
> are inside the cut-off distance. Thus some atom pairs might not interact
> while they are inside the cut-off distance, while other atom pairs might
> interact while they are outside the cut-off distance. These charge groups
> are important for simulations with cut-off electrostatics as they reduce the
> cut-off noise significantly. With shiftted electrostatics or PME charge
> groups are only important for performance reasons."
> The above paragraph seems to imply that I should use rvdw = rlist.  The
> above paragraph seems to say that since, unlike other MD codes that do not
> use charge groups, in Gromacs there is really no need for a "grace distance"
> -- because the use of charge groups, rather than atoms, in a sense has a
> "bult-in" grace distance.  The charge groups are unlikely to move much
> between neighbor list updates every nstlist steps.

Most force fields use single-atom charge groups, so the distinction between 
"charge group pair" and "atom pair" is dependent upon the force field.

> So, my question is, am I at risk for artifacts if I use rvdw = rlist?
> Should I instead use rvdw >= rlist?

Again, it's up to the force field parameterization.  If you're using settings 
for which your parameter set was derived, then you're not introducing any *new* 
artifacts, but any that exist within the original derivation would be preserved. 
  Whether or not that's acceptable is up to you and anyone who critiques the 
work.  Without more information about the force field you're using, it's hard to 
say whether anything you're doing is inherently "right" or not, because, as 
stated above, 1.5-nm cutoffs are incorrect for any of the standard force fields 
that come with Gromacs.



Justin A. Lemkul, Ph.D.
Research Scientist
Department of Biochemistry
Virginia Tech
Blacksburg, VA
jalemkul[at]vt.edu | (540) 231-9080


More information about the gromacs.org_gmx-users mailing list