Thank you all. Much appreciated.
Ross I’m using a PowerMac OSX 10.11.1. I recently compiled Amber on this machine using gcc49.
Best regards
George
> On 10 Jan 2016, at 19:20, Ross Walker <ross.rosswalker.co.uk> wrote:
>
> 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
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Sun Jan 10 2016 - 13:00:04 PST
