Hi All,
Yes that was the original intention - i.e. if a dihedral that should never get used gets used you would get a NAN. Not really needed outside of debugging though but never caused harm in the past. Although it could be coming from other places as well.
I believe the warning is compiler version specific. Normally checking for exceptions cost performance so one doesn't want to bother with it and I thought most compilers at -O3 turned off such exception checking but maybe some specific versions don't do this. George what compiler and version are you using?
A little (30 secs) of digging looks like it might got added in some newer versions of gfortran:
https://gcc.gnu.org/ml/fortran/2013-06/msg00072.html
Note there is this option --fno-underflow-warning. Jason perhaps we should include this in the build flags. Although that probably means checking compiler versions for compatibility with the sign. Sigh...
Note my trusty Gfortran 4.4.7 from Centos 6.7 does not have this flag and neither does 4.8.3 from Centos 7.1 but they do have this:
-Wunderflow
Produce a warning when numerical constant expressions are encountered, which yield an UNDERFLOW during
compilation.
So my guess is someone may have enabled this warning by default in newer gfortran versions :-( (don't have any to test unfortunately).
All the best
Ross
> On Jan 10, 2016, at 08:43, Jason Swails <jason.swails.gmail.com> wrote:
>
> I think it occurs because dihedral terms that are omitted in end-group (1-4) interactions have scaling factors set to 0. Since they are inverted upon reading, you get a divide by zero. Since they are never used, they have no effect.
>
> The original explanation I heard was that this would immediately indicate whether there was a bug in excluding the 1-4s that should have been excluded.
>
> I'm not sure if this has been adjusted, or when it was changed. But I know it used to behave that way.
>
> All the best,
> Jason
>
> --
> Jason M. Swails
> BioMaPS,
> Rutgers University
> Postdoctoral Researcher
>
>> On Jan 10, 2016, at 8:45 AM, David A Case <david.case.rutgers.edu> wrote:
>>
>>> On Sun, Jan 10, 2016, George Tzotzos wrote:
>>>
>>>
>>> Note: The following floating-point exceptions are signalling: IEEE_DIVIDE_BY_ZERO
>>
>> One would think you ought to be worried about this, but I've seen these and
>> ignored them....never finding the origin.
>>
>> If you can create a short run that illustrates the problem, you could post the
>> files and we will try to reproduce it. (We'd need to know compiler details,
>> etc.) Alternatively, compile a debug version of whatever program it is you
>> are running (sander? pmemd?) and see if that gives you more detailed
>> information.
>>
>> ....dac
>>
>>
>> _______________________________________________
>> AMBER mailing list
>> AMBER.ambermd.org
>> http://lists.ambermd.org/mailman/listinfo/amber
>
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Sun Jan 10 2016 - 10:30:03 PST
