Re: Overflow in LJcorrection?

From: Jason Swails (
Date: Thu Dec 03 2015 - 15:55:30 CST

On Thu, Dec 3, 2015 at 4:45 PM, Brian Radak <> wrote:

> I've been debugging/testing alchemical corrections to the LJcorrection
> when I stumbled upon this weird behavior:
> For largish systems (I just threw and asp in a big box, 163737 atoms), the
> average A and B coefficients comes back *negative*. This seems to go away
> (sometimes?) if I zero out the hydrogen LJ epsilon parameter in the
> parameter file. Some strategic print statements seem to suggest that the
> "sumOfAs" and "sumOfBs" counters go negative when the next increment is
> above ~1e12?
> Here is output for vdw type 60 (OT from TIP3P) and the counters for
> sumOfAs and sumOfBs when it first goes negative.
> The increments should be (54469-1)*54469*A/B
> pair : 60/60 : A = 581924 : B = 595.015 | counts : 54469/54469
> 5.0349e+13-->-7.22533e+14
> 5.86584e+10-->-7.3161e+11
> The second column should be: 2.229940435e+14 and 1.8239593e+12
> Does this look like overflow? I can't imagine a double precision value
> having trouble here, although the atom counts are 32 bit signed integers
> (or whatever the compiler understands "int" to be).

‚ÄčI saw this exact behavior in OpenMM ~1.5 years ago. Integer overflow was
the culprit. Symptoms were exactly the same. See for the discussion and diff
of the fix.

The end result is that densities come out too small (because instead of
being *attractive*, the long-range correction is repulsive and increases
the resulting virial more for smaller box sizes). And it's statistically
significant (at least in my tests).

All the best,

Jason M. Swails
Rutgers University
Postdoctoral Researcher

This archive was generated by hypermail 2.1.6 : Tue Dec 27 2016 - 23:21:36 CST