[gmx-developers] Re: Cubic splines - again

Erik Lindahl lindahl at cbr.su.se
Tue Aug 22 15:46:06 CEST 2006


On Aug 22, 2006, at 3:36 PM, Mathias PUETZ wrote:
> So it essentially boils down two these four choices:
>  1. get better force accuracy and keep the current accuracy for the  
> potential, but you have to pay for it with quintic splines
>  2. have either accurate potentials and inaccurate forces (the way  
> it is right now)
>  3. improve force accuracy at the expense of some potential  
> accuracy (what I proposed)
>  4. approximate potentials and forces using separate cubic spline  
> polynomials

I really don't think (1) is necessary since I've never seen anybody  
advocate quintic splines for "normal" simulation stuff, but if  
somebody points me to data showing real practical advantages (i.e.,  
better free energies or whatever) we would consider implementing it.

We've considered (4) before, but since it involves loading twice the  
amount of data from memory it hurts performance quite a bit. And,  
just as you, I would prefer a solution where the forces are the real  
derivatives of an approximation to the potential.

However, the good news is that we can probably both have the cake and  
eat it in this case. Since our user-table format specification  
already includes the first derivative of the potential we can simply  
have it as an option in the mdp file, and just optionally use a  
different version of the table generation code.

It is easier (and relatively cheap computationally) to improve the  
potential accuracy by increasing the number of table points, even in  
single precision, so the best option would probably be to change the  
table generation code to achieve continuous derivatives by default,  
and retain the "more accurate potential" as an option (since we  
already have that code anyway).



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20060822/afc064bc/attachment.html>

More information about the gromacs.org_gmx-developers mailing list