[gmx-users] Electrostatic forces
dommert at icp.uni-stuttgart.de
Wed Jun 17 14:22:00 CEST 2009
the point why I ask all this questions is that my final goal is to
enhance the SPME algorithm in Gromacs. As it is well know, that SPME is
not momentum conserving in case the forces are derived with analytical
differentiation, that means the reciprocal forces stem from the
derivative of the reciprocal sum after performing the FFTs in
reciprocal space and back again. This just requires 2FFTs per step.
In contrast the ik differentiation allows to obtain forces that
conserve the momentum. However in this case 4FFT are required: 1 into
reciprocal space and 3 back to gather every component of the force.
We have tested this two implementations of the SPME and realized that
under the condition of a certain accuracy, the analytical
differentiation is not always the cheaper one as expected due to the less
number of FFTs. Sometimes the higher number of FFTs is balanced out by
the smaller interpolation order or
reciprocal space cut-off required to reach the accuracy the same
accuracy as in case of analytical differentiation.
It is also sad, that the PPPM algorithm is not working correctly,
because this would be the "best" way of calculation electrostatic
forces. The authors showed that the Green
Function that is determined by the interpolation scheme and used
for their derivation of the PPPM is mathematically the
optimal one. So I also would like to correct the implementation of the
PPPM algorithm to provide a correct implementation of the virial
And by the way, the error of the RMSF depens on the charge density,
beta, interpolation order and cutoffs in real and reciprocal space.
This means as soon as you have the optimal set for a given charge
density. So you can apply this parameters to all systems with the
same charge density independent of its actual size and charge
distribution, only the charge density has to match.
* Mark Abraham <Mark.Abraham at anu.edu.au> [2009-06-17 16:11:14 +1000]:
> Florian Dommert wrote:
>> * Mark Abraham <Mark.Abraham at anu.edu.au> [2009-06-17 15:31:43 +1000]:
>>> Florian Dommert wrote:
>>>> * Mark Abraham <Mark.Abraham at anu.edu.au> [2009-06-17 14:14:22 +1000]:
>>>>> Florian Dommert wrote:
>>>>>> However I am very confident and in case of success, that there will be
>>>>>> soon an error estimate for the Ewald Sum available, which will
>>>>>> be the first
>>>>>> step to the an implementation a tuning routine for the SPME
>>>>>> paramters to achieve optimal
>>>>>> balance between performance and accuracy ;)
>>>>> I've already implemented a version of mdrun that actually
>>>>> computes the RMS error in the force components under PME, and
>>>>> am planning to release it soon.
>>>> That is very nice to hear, how do you compute the error ? By
>>>> comparing to an
>>>> Ewald Sum ?
>>> Holding beta fixed, I compare force components with those from a
>>> converged real-space summation and high Fourier grid density &
>>> interpolation order.
>> So you have to perform a very costly simulation for every system, when
>> you gather the reference force ?
> Actually, both the reference force run and the parameter scan runs are
> invocations of "mdrun -rerun". I haven't notice the former to be very
> costly, but there's a trade-off involved. To converge the components to
> machine precision might indeed be very costly, but one doesn't need to
> go to that extreme to estimate that the average RMS force error over the
> test trajectory is 1e-4 (or whatever).
>> And which beta do you choose, because
>> if you take the right choice you can decrease the computational cost
> Yep. Having chosen a desired accuracy, you have to scan beta (with
> ewald_rtol and rcoulomb) and then scan the grid densities to find
> point(s) with acceptable accuracy and minimal cost. This is not such an
> extreme problem once you have some guidance from previous optimizations.
>> So theoretically at first you have to find the right beta by
>> sampling through the corresponding parameter space with a fixed
>> Interpolation order and grid size. In the optimal range a change of beta
>> within 0.1 will yield a difference in the error of about 10-1 this trend
>> continues around +/- 0.5 of the optimal value for beta.
> OK, I'll have to take your word for that, since I haven't looked at the
> maths in that detail. It's certainly well-known (e.g. original PME
> papers) that a correct choice of parameters can swing orders of
> magnitude of computational cost for given accuracy, or vice-versa.
> gmx-users mailing list gmx-users at gromacs.org
> Please search the archive at http://www.gromacs.org/search before posting!
> Please don't post (un)subscribe requests to the list. Use the www
> interface or send it to gmx-users-request at gromacs.org.
> Can't post? Read http://www.gromacs.org/mailing_lists/users.php
Institute for Computational Physics
Tel: +49 - 711 / 6856-3613
Fax: +49 - 711 / 6856-3658
EMail: dommert at icp.uni-stuttgart.de
!! PGP-ENCODED emails preferred !!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 194 bytes
Desc: not available
More information about the gromacs.org_gmx-users