Interesting bug

[JohnNichols]

!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

[JohnNichols]

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? 

[dboggs]

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.

[JohnNichols]

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

[Andreas_Z_]

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

[jimdempseyatthecove]

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