Re: Overflow in LJcorrection?

From: Jason Swails (jason.swails_at_gmail.com)
Date: Thu Dec 03 2015 - 15:55:30 CST

On Thu, Dec 3, 2015 at 4:45 PM, Brian Radak <bradak_at_anl.gov> 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
https://github.com/pandegroup/openmm/pull/352 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

-- 
Jason M. Swails
BioMaPS,
Rutgers University
Postdoctoral Researcher

This archive was generated by hypermail 2.1.6 : Thu Dec 31 2015 - 23:22:17 CST