[gmx-users] confused about rcoulomb<=rlist

Berk Hess gmx3 at hotmail.com
Thu Jul 13 09:18:46 CEST 2006




>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: Wed, 12 Jul 2006 12:25:05 -0400
>
>Hi, all-
>
>I admit I've been wondering about this as well -- I was involved in
>some of the previous discussions.  It seems like the simplest thing is
>to have the real space cutoff be at rcoulomb, and if one wants the
>real space cutoff to go out to rlist, then one sets rcoulomb = rlist.
>But one is not forced to.    Am I missing something?
>
>I think part of the previous discussion was how to get the best energy
>conservation -- Berk argued (correctly, I think -- at least it appears
>in agreement with simulations I ran) that setting the real space
>cutoff = rlist gives the best energy conservation.  But this is
>independent of the question of user control -- I think the user should
>be able to choose real space cutoff < rlist, for the reasons David
>Mobley lists above.

So I guess that we agree that for production simulations there is
not much use for having rcouloumb != rlist with PME.

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.
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.

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.

Berk.





More information about the gromacs.org_gmx-users mailing list