Comparison of calculations with different units of measurement

[Mikhail-Vaganov]

@dextorious , have a look at this figures for SI and OpenMM units usage. I tested simulation of 216 particles of liquid argon for 15 ps with timestep at 0.5 fs without thermostating.

I didn't try to set the same initial velocities for both tests, though it is worth to do so for an unbiased experiment/test.

Can you suggest other test systems with already implemented features for comparison calculations in different units? Berendsen thermostat can be used, for example, because it is deterministic.
Well, at least, I can repeat such calculations for water systems.

[dextorious]

Right, the comparison has to be deterministic (the alternative would be running a statistically representative number of simulations, which would be prohibitively expensive at the moment). That pretty much just leaves liquid argon / water with identical initial conditions and either no thermostat or the Berendsen thermostat. I would also suggest noting down the times of each computation just in case - NaNs/Infs can lead to slower performance, though hopefully we'll never see it happen.

Also, the units issue will become much more important when we eventually do any form of GPU acceleration, since in that case trying to survive on Float32s becomes critical for performance on most hardware. Using OpenMM / Gromacs / AMBER units can be partly seen as future proofing for that scenario as well.

[Mikhail-Vaganov]

And here are results for the water SPC/Fw simulations.

I used initial coordinates from the file dextorious provided me once (output_4.pdb). 3 ps at 0.5 fs step. 216 molecules without thermostating. Total time of calculations at both kinds of units is almost the same.

[ChrisRackauckas]

Catastrophic cancellation is probably not happening because of a lot of the coefficient multiplications. Significance loss is really when you add/subtract values on different scales. OTOH, Multiplication/division is a safe operation. So the units must be fine enough because everything gets roughly scaled before the linear combinations of the integrator.

But @dextorious does bring up a good point that the scaling would have a bigger effect on Float32 and GPUs, where multiplication/division by 6.022e23 could definitely hit the Float32 limits:

julia> 2.5f38
2.5f38

julia> 2.5f39
ERROR: syntax: overflow in numeric constant "2.5f39"

[dextorious]

Yeah, it looks like double precision is enough at least in this particular case, so this is about future proofing for Float32s as well as abiding by the conventions of the field for simplicity. I do think the future proofing part is fairly important in this case, since practical MD work is virtually always done on accelerators nowadays, most of which benefit hugely from reducing floating point precision.