[gmx-users] confused about rcoulomb<=rlist

[Berk Hess]

>From: "Michael Shirts" <mrshirts at gmail.com>
>Reply-To: Discussion list for GROMACS users <gmx-users at gromacs.org>
>To: gmx-users at gromacs.org
>Subject: Re: [gmx-users] confused about rcoulomb<=rlist
>Date: Sat, 15 Jul 2006 11:37:52 -0400
>
>>For studying effects of cut-off and integration setup on the results
>>I can see that one would to be able to set rcoulomb < rlist.
>>This is, however, not easy to implement exactly.
>>An exact cut-off would produce an infinit force at the cut-off.
>
>Perhaps I'm a little confused here.  Right now, isn't there an abrupt
>cutoff at rlist anyway?  So the abrupt cutoff is just being moved
>inward?  I suppose there's some technicality of the splines used to
>generate the real space part, however. . .

No, there are two different types of abrupt cut-offs.

The standard Gromcs cut-off treatment is that rlist
is used to put charge group pairs in the neighborlist.
These pairs stay in the list for nstlist steps.
Thus for some atom pair the actual cut-off for some configuration
at some time step can be slightly smaller or larger than rlist.
Also the algorithm is non-reversible when nstlist>1.

For an exact cut-off with charge groups or nstlist>1 one needs
an rlist that is slightly larger than the cut-off and then the interaction
tables should be filled in such a way that they corresponds to a
cut-off at the required distance.

>
>>But since we use spline interpolated tables, there will always
>>be some smoothing of this cut-off.
>>I think that with the current table setup there is no way to
>>have exact cut-offs.
>>Another option would be to apply a switch function to the PME
>>real space interactions.
>>Addionally one would want to set beta independent of rlist.
>
>Right, one should be able to tune this independent of your
>neighborlist cutoff for various reasons that David discussed.
>
>>So the only reasonable option I can think of is to implement
>>a new coulombtype = PME-switch, but with a note that this
>>is mainly useful for testing purposes and the normal PME
>>will give more accurate results.
>
>Actually, I can imagine situations where extremely good energy
>conservation (for multi ns runs) is important, and this option might
>be useful -- you would trade a bit of accuracy for better energy
>conservation.

I agree.

So I will implement this for Gromacs 4.0.

The only, technical, detail is if one would want to determine
beta with rcoulomb or with rcoulomb_switch,
as the real space part will start deviating from rcoulomb_switch.
But I would prefer rcoulomb for consistency reasons.


Berk.