Re: Overflow in LJcorrection?

From: Brian Radak (
Date: Thu Dec 03 2015 - 15:59:27 CST

Ah yes, that clarification is relevant.

No, this always happens. If it is any comfort, the error is exactly
reproduced by the current corrections if alchemy is on.

Oddly enough, naively switching "count" from an "int" to "unsigned long
int" /does not/ fix the problem.

On 12/03/2015 03:55 PM, Peter Freddolino wrote:
> Hi Brian,
> Out of curiosity, is this dependent on having FEP or related settings on, or no?
> Thanks,
> Peter
>> On 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).

Brian Radak
Theta Early Science Program Postdoctoral Appointee
Leadership Computing Facility
Argonne National Laboratory
9700 South Cass Avenue
Building 240, 1.D.16
Lemont, IL 60439-4871
Tel: 630/252-8643

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