
<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; ">Hi,<DIV><BR><DIV><DIV>On Aug 22, 2006, at 3:36 PM, Mathias PUETZ wrote:</DIV><BLOCKQUOTE type="cite"><BR><FONT size="2" face="sans-serif">So it essentially boils down two these four choices:</FONT> <BR> <BR><FONT size="2" face="sans-serif"> 1. get better force accuracy and keep the current accuracy for the potential, but you have to pay for it with quintic splines</FONT> <BR><FONT size="2" face="sans-serif"> 2. have either accurate potentials and inaccurate forces (the way it is right now)</FONT> <BR><FONT size="2" face="sans-serif"> 3. improve force accuracy at the expense of some potential accuracy (what I proposed)</FONT> <BR><FONT size="2" face="sans-serif"> 4. approximate potentials and forces using separate cubic spline polynomials</FONT> <BR></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>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.</DIV><DIV><BR class="khtml-block-placeholder"></DIV>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.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>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.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>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).</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Cheers,</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Erik</DIV><DIV><BR class="khtml-block-placeholder"></DIV><BR></DIV></BODY></HTML>