<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; ">Hi,<DIV><DIV><BLOCKQUOTE type="cite"><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Why not remove this big source of error (BSOE), especially when</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Ewald/PME/PPPM is used. (Or maybe add a mdp option for the user to</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">choose, but I doubt anyone would like to choose the BSOE :-) I imagine</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">this change just requires a few line of code.</DIV></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Well, it's trivial to change yourself in the topology or rtp file :-)</DIV><DIV><BR class="khtml-block-placeholder"></DIV>There are a couple of reasons why we don't do it by default:</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>1. Several force fields are designed with charge groups, and have been used that way for years. Regardless of whether we like that or we want results to be reproducible. </DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>2. Neighborsearching can be pretty expensive with our fast innerloops, sometimes 30-40% of the total runtime. Group-based NS is faster.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><BLOCKQUOTE type="cite"><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">I love to hear this. Many people still consider achieving (nearly)</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">perfect energy conservation (for an isolated system) in single precision</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">will be a big advantage. And I believe performing the integration and/or</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">constraints in double precision will have negligible overhead, so I</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">would love to see this "hacking" can be made default inside Gromacs.</DIV></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>The overhead would probably be insignificant on a standard x86 CPU, but Gromacs is also used on hardware where double precision has to be simulated and is insanely expensive (embedded CPUs, graphics cards, etc.).</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>If at all possible I'd rather like to understand exactly _where_ we loose the accuracy and perform only that step on double, instead of converting entire arrays to double (Using bonds instead of constraints will conserve energy).</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>We do realize that some users really want energy conservation and will try to make it easier to achieve "by default", but our rationale has been that per se it doesn't tell you anything about accuracy (imagine a switched cutoff at 1A, or changing sign of the coulomb term) - and remember that we are usually distorting the interaction form to achieve the conservative potential with cutoffs! </DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Cheers,</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Erik</DIV></DIV><FONT class="Apple-style-span" color="#0000DD"><BR></FONT><DIV> <SPAN class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><DIV>-----------------------------------------------------------</DIV><DIV>Erik Lindahl  &lt;<A href="mailto:lindahl@sbc.su.se">lindahl@sbc.su.se</A>&gt;</DIV><DIV>Assistant Professor, Stockholm Bioinformatics Center</DIV><DIV>Stockholm University, SE 106 91 Stockholm</DIV><DIV>Phone: +46 8 5537 8564     Fax: +46 8 5537 8214</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><BR class="khtml-block-placeholder"></DIV><BR class="Apple-interchange-newline"></SPAN> </DIV><BR></DIV></BODY></HTML>