# [gmx-developers] stuff in double precision

hessb at mpip-mainz.mpg.de hessb at mpip-mainz.mpg.de
Mon Feb 5 19:30:38 CET 2007

```> Erik Lindahl wrote:
>> Hi,
>>
>> On Feb 5, 2007, at 5:08 PM, Berk Hess wrote:
>>
>>> Hi,
>>>
>>> This difference can be avoided by having all energy terms in double
>>> precision. In general this is for free, but it might need recoding
>>> of the assembly loops.
>>> We should consider making most/all variables double precision,
>>> except for the natoms sized arrays.
>>
>> One problem I can see is that single/double conversions are not free,
>> and you would do extra operations to sum in double (SSE is 2-way for
>> double 4-way for single).
>>
>> A possible intermediary approach could be to introduce a handful of
>> extra single precision variables that we zero in the outer loop, and
>> after each inner loop we convert the sum to double and add it to a
>> double precision summation.
>>
>> I've started to go more in the direction of "double unless it's an
>> array" recently, but for the innermost loop it would mean sacrificing
>> performance.
>>
>> In principle I could also recode the loops to enable a solution with
>> "double for all summation variables", but then we might want to have
>> that as a third option besides all-double and all-single. Before doing
>> that for ASM I'd like to see hard result that it solves the problem when
>> done for the C loops, though :-)
>
> If you do an operation in C in which a double is involved, then as far
> as I know everything is converted to double, possibly unless you use
> brackets.
>
> The problem David experienced is just due to an in a sense ill-posed
> problem, since looking for 1 in 10^6 energy differences (i.e.
> subtracting large numbers) is asking for trouble (think diverging
> trajectories due to round off with different average energies). This is
> why people generally shy away from absolute free energies.
>
> A very simple workaround would be to always use the free energy loops,
> also for "reference no-free energy simulations", then you are running
> the same code twice.

The relative energy difference is indeed quite small,
but the method itself could work.
The best and most efficient solution is the one we have discussed
before, where the difference taken for the perturbed interactions
only.

But if we can gain accuracy without sacrificing any performance,
we should do so.
I will test the conversion of energies to double precision
(outside the inner loops).

Berk.

```