topic RE post #1 in Intel® Fortran Compiler

Interesting bug

JohnNichols — Mon, 20 Apr 2020 17:02:02 GMT

!do 190 iC = 1, ModelA%FFTNumber

    ModelA%FFTDaTA = ZERO

--------------------------------------------------------------------------------------------------------------

So in Modela I store the FFTDATA before it is sent to the FFT Routine.

I used a do loop to set the vector to all zeros, but a while ago I thought I can just use a

vector assignment as above, but I got it wrong and had

ModelA%FFTDaTA(i) = ZERO

it worked up until last night when the latest stuff came in and the plotting did not work, so I looked and there was random crap in FFTDATA instead of the zeros.

Took a few minutes to track and fix the error -- but I cannot see why it worked!

Any ideas?

John

Second interesting

JohnNichols — Mon, 20 Apr 2020 17:06:54 GMT

Second interesting observation

When I was looking for the cause of the bug, I noticed in stepping through the code that the creation of arrays occurred in reverse order

    REAL , allocatable :: XDATA(:)
    REAL , allocatable :: YDATA(:)
    REAL , allocatable :: ZDATA(:)
    REAL , allocatable :: DDATA(:)

any ideas why that would occur?

Is this not a simple

dboggs — Mon, 20 Apr 2020 17:45:04 GMT

Is this not a simple manifestation of the general problem of trying to use uninitialized variables?

It's a common problem because in some languages, and in the old days, you could use y = 1 + x and you would get 1, because x would be zero. Today, setting an uninitialized variable is not the default behavior. Indeed, x may often be zero--in fact is usually zero--but you cannot rely on it; it depends on what recently-used software has been doing with memory storage locations in areas that your program is now using.

So I would suspect that your (mis) statement Data(i) = ZERO is not setting the entire array to ZERO, but only the ith element, and all of the other elements are left uninitialized.

Quote:dboggs wrote:

JohnNichols — Mon, 20 Apr 2020 17:59:14 GMT

dboggs wrote:
Is this not a simple manifestation of the general problem of trying to use uninitialized variables?
It's a common problem because in some languages, and in the old days, you could use y = 1 + x and you would get 1, because x would be zero. Today, setting an uninitialized variable is not the default behavior. Indeed, x may often be zero--in fact is usually zero--but you cannot rely on it; it depends on what recently-used software has been doing with memory storage locations in areas that your program is now using.
So I would suspect that your (mis) statement Data(i) = ZERO is not setting the entire array to ZERO, but only the ith element, and all of the other elements are left uninitialized.

But why did it work perfectly for a month and then suddenly stop -- I did not change the code -- I know in reality it is just dumb luck -- but dumb luck for a whole month.

I checked you are correct on the ith value was set to 0.00 - the rest ranged to infinity

Thanks

Since issues like the one

Andreas_Z_ — Mon, 20 Apr 2020 19:16:41 GMT

Since issues like the one mentioned can go unnoticed for some time, I like the "initialize variables to signaling NaN" switch during code debugging. That is, use the /Qinit:snan /Qinit:arrays command line switches (in VS via the Project Properties > Fortran > Data menu). With those switches, you will typically find such mistakes quickly.

Andi

RE post #1

jimdempseyatthecove — Mon, 20 Apr 2020 20:11:44 GMT

RE post #1

When you used the DO loop, ModelA%FFTNumber may not necessarily been the same as UBOUND(ModelA%FFTDaTA).
And thus the DO loop and ModelA%FFTDaTA = 0.0 are not necessarily the same thing.

I assume (possibly incorrectly) that ModelA%FFTDaTA was allocated.

Jim Dempsey