Strange bug: need to duplicate lines of code. Help?

[remkoduursma]

Hello,

I have a problem in my code, and have no idea what to look for. The program compiles fine, but at runtime gives NaN for some calculations. I tracked these down to the source, and found 3 instances where all variables going into the calculation are fine (using the debugger), but the result is NaN anyway. I copied the bit of code where this happens to immediately below it, so now it is in there twice. And now it works fine!

What kind of problem should I be looking for?

All of the code has the fixed format, it has evolved from fortran77 code. There are many subroutines and functions, but no other 'fancy' stuff. It just reads text files, does lots of computations, and writes output text files.

thanks for your help,

Remko

Compiler version:
Intel Fortran Compiler Integration for Microsoft Visual Studio 2005, 10.1.4156.2005

System:
OS Name Microsoft Windows XP Professional
Version 5.1.2600 Service Pack 2 Build 2600
System Type X86-based PC
Processor x86 Family 6 Model 15 Stepping 11 GenuineIntel ~2194 Mhz
Processor x86 Family 6 Model 15 Stepping 11 GenuineIntel ~2194 Mhz

[jimdempseyatthecove]

Remko,

Could you copy and paste the calculations for us to look at?

I've had similar cases where IMPLICIT NONE was not used and where the source line was too large causing a symbol to straddle the end of line column. The result being the debugger using the whole word (symbol) but the compiler using the truncated symbol (which is undefined). Check your line lengths.

Jim Dempsey

[jarvusluntatintel]

Jim

I never used IMPLICIT NONE and your comment is a little worrying. Could this cause a difference in runtime behavior between a release version and debug version (something I have had a lot of trouble with)? Could you explain a little bit more. Thanks.

[remkoduursma]

I checked the line lengths, they are fine. The calculations are also trivial - and they used to work fine before the program got expanded.

Do you in general recommend strongly to use IMPLICIT NONE?
Right now, we don't use any IMPLICIT statement.

Anyway here they are:

1:
EPSIL = (23.452294- (1.30125E-2+ (1.64E-6-5.03E-7*T)*T)*T)*PID180

2:
SOILTEMP_NPLUS1(I) = (D / (1 + 2*BETA*D))
& * (BETA*(SOILTEMP_NPLUS1(I+1)
& + SOILTEMP_NPLUS1(I-1))
& + (1-BETA) * (SOILTEMP(I+1)
& - 2*SOILTEMP(I) + SOILTEMP(I-1)))
& + SOILTEMP(I)/(1+2*BETA*D)

3:
V1 = PI*RX1*RY1*(HUP-(HUP**2/RZ1)+(HUP**3)/(3*RZ1**2))

[jimdempseyatthecove]

>>difference in runtime behavior between a release version and debug version

Depending on option switches - yes.

Debug can initialized un-initialized to 0.0 or to NaN to detect uninitialized variable use.

Release, generally does no implicit initialization. So if you read a variable before you write to it then behavior will be different.

Jim Dempsey

[jimdempseyatthecove]

For 2:

What happens when I=1 (or lowest index) for the value of SOILTEMP(I-1)?

Are you indexing before the beginning of the array?

Jim Dempsey

[jimdempseyatthecove]

And for 2:

And you may have a similar problem when referencing I=Last Index

Unless your arrays have pre-initialized padds (before and after the initialized data) your first and last iteration will be incorporating JUNK into the expression (rather than perhaps an assumed 0.0)

And for 3:

Is PI one of your variables? Are you assuming it is an intrinsic variable of 3.14159....?

I suggest a debug run with runtime checks for array index out of bounds and un-initialized variable tests.

Jim Dempsey

[remkoduursma]

Thanks for the tips.

I am now debugging it with all the options, as you suggest, and I already found a number of problems with array sizes being passed between subroutines (luckily most of these problems were not due to my own programming!).

Thanks for pointing out that this is likely due to initialization problems, I now finally understand that the debugger inits to 0.0, while the Release version does not. This is very helpful.

The questions you asked about code bit #2 are all OK, by the way. The indexing (I-1) starts at I=2, and PI is a constant declared in an INCLUDE file.