[gmx-users] Speed up my jobs with PME and grid spacing?

[Mark Abraham]

On 30/12/2010 1:58 AM, Florian Dommert wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 12/29/2010 12:56 AM, Mark Abraham wrote:
>> On 29/12/2010 7:44 AM, Justin A. Lemkul wrote:
>>>
>>> TJ Mustard wrote:
>>>>
>>>> Hi,
>>>>
>>>>
>>>>
>>>> I am trying to speed up my parallel processor Gromacs jobs and was
>>>> wondering what were the known settings for PME cut-off and PME grid
>>>> spacing? As of now I am running with a PME cutoff of 0.8 and a
>>>> fourierspacing of 0.12.
>> There are a great many factors that contribute to the speed and accuracy
>> of the GROMACS PME implementation. However, if you've used the default
>> ewald_rtol of 1e-5, then I think your rcoulomb is much too small.
>>
>>> What do you mean by "known settings"?  The cutoff (rcoulomb) can be
>>> dictated by the force field used, although with PME I think the
>>> results are relatively insensitive to small changes.  The grid spacing
>>> affects accuracy - larger spacing implies less grid points and faster
>>> speed, but lower accuracy.  I do not know if there has been any
>>> systematic investigation into these effects, though.
>> There hasn't been an investigation of the influence of PME accuracy on
>> simulation results. I have a manuscript that should be in press shortly,
>> which deals with many of the considerations in choosing these
>> parameters. In it, I observed that "typical" GROMACS parameters values
>> of rcoulomb=1.0, fourierspacing=0.10 and ewald_rtol=1e-5 in 4.5.3 led to
>> a relative RMS error in the electrostatic forces around 2e-4. That error
>> was well balanced between real and reciprocal space, but with 24 PME
>> nodes out of 64, the PME nodes did 8.1% too much work. The problem is
>> that we don't know whether this is sufficiently accurate for any purpose.
>>
>> Mark
>>
> You can estimate the error of SPME with the tool g_pme_error and also
> determine the optimal ewald_rtol to distribute the error equally over
> real and fourier space. As Justin mention the real space cutoff is often
> given by the force field

To my knowledge, the only (GROMACS) force field that was parameterized 
with PME in mind is AMBER03, and IIRC that paper does not fully describe 
the PME regime used during parameterization. So, while all the 
forcefields had a real-space cut-off, it was for a different 
electrostatics model. Thus, so long as the PME error is at worst 
comparable to that introduced by the parametrization method, there is no 
reason why rcoulomb cannot be varied from the parameterization value. 
Caveat: since rcoulomb == rvdw, for a given ewald_rtol, you don't want 
to make rcoulomb so small that the VDW error now dominates the 
non-bonded error.

Mark

> so you just have to decrease the fourierspacing
> and/or the interpolation order to obtain the desired accuracy, but be
> aware that the error estimate is just valid for even interpolation
> orders. The tool g_tune_pme allows to find the optimal number of PME
> nodes and perhaps suggest small changes of the cutoff and/or the
> gridspacing. Though the tuning can consume some time you will save much
> more time for your production run and g_pme_error is even MPI capable to
> speed up the error estimate.
>
> /Flo
>
> - -- 
> Florian Dommert
> Dipl.-Phys.
>
> Institute for Computational Physics
>
> University Stuttgart
>
> Pfaffenwaldring 27
> 70569 Stuttgart
>
> Phone: +49(0)711/685-6-3613
> Fax:   +49-(0)711/685-6-3658
>
> EMail: dommert at icp.uni-stuttgart.de
> Home: http://www.icp.uni-stuttgart.de/~icp/Florian_Dommert
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk0bTKIACgkQLpNNBb9GiPnKzwCeJVEHMHq9NlDQ29dFifKHSk14
> oSgAoJriuf49nHArA3/HZFkPFqYy448S
> =q/31
> -----END PGP SIGNATURE-----