[gmx-users] Electrostatic forces

Florian Dommert dommert at icp.uni-stuttgart.de
Wed Jun 17 14:22:00 CEST 2009 

Hello Mark,

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

  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. 

Flo

* 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
>> extremely.
>
> 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.
>
> Mark
> _______________________________________________
> gmx-users mailing list    gmx-users at gromacs.org
> http://lists.gromacs.org/mailman/listinfo/gmx-users
> 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

-- 
Florian Dommert
Dipl.-Phys.

Institute for Computational Physics
University Stuttgart

Pfaffenwaldring 27
70569 Stuttgart

Tel: +49 - 711 / 6856-3613
Fax: +49 - 711 / 6856-3658

EMail: dommert at icp.uni-stuttgart.de
Home: http://www.icp.uni-stuttgart.de/~icp/Florian_Dommert

!! PGP-ENCODED emails preferred !!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-users/attachments/20090617/1dc62c1b/attachment.sig>

More information about the gromacs.org_gmx-users mailing list