Math Error

[Intel_C_Intel]

I am porting a fairly large and complex Fortran code on to PC platform. This program used to run on VAX VMS machines. The problem I encountered is that some variables became undefined (NaN) for some unknown reasons, and it occurred randomly. Here is a sample.

complex rsum(100)

t1=real(rsum(i))
write (6,100) rsum(i),t1
100 format (2f15.3, f15.3)

The output prints out rsum(i) correctly, but followed by a NaN for t1.

It also happened at a statement as simple as

par=0.5
write (6,100) par
100 format (f15.3)

It prints out NaN!

As I said earlier, these samples are buried inside a fairly large and complex Fortran code.

Any suggestion is greatly appreciated.

[Steven_L_Intel1]

Without seeing the actual program, it's difficult to speculate as to what the problem might be. I doubt it's a "math errorquot;. More likely, you have an uninitialized variable or some other coding error. If you'd like our help, send a description of the problem along with a ZIP file of the project to us at vf-support@compaq.com, and we'll take a look.

You may want to try turning on /fpe:0 (Project..Settings..Fortran..Floating Point) which should give an error as soon as a NaN would be generated.

Steve

Steve

[sabalan]

This kind of NaNs happen very often becuse of the data type confusion. Are your "t1" and "par" declared correctly? It was a bad programing habbit for many VMS-Fortran programmers not to declare all variables. I would suggest using "IMPLICIT NONE" and declaring all variables while porting from VMS to CVF.
Regards,
Sabalan.

[Intel_C_Intel]

Thanks for the suggestioins.

I like to explore a little bit more on the idea of "variable type confusion" raised by Sabalan.

It is true that integer arrays are used to store a mixture of character data, integer data, real data and complex data in this FORTRAN program I am porting. Could this be the reason that causes so called "variable type confusion"? Or could this practice causes the data to collapse unexpectly and randomly?

[sabalan]

The answer to your first question is yes. This is exactly what I meant. And the answer to your second question is also, I believe, yes, depending on how complicated and deeply nested your code is, which may cause such behavior after optimizing for "Release" version.

Steve suggested once to comment a large part of the code writing !DEC$ IF (.FALSE.) before and !DEC$ END IF after it, run and test the program, then make the commented part smaller and smaller to localize where the problem occurs.

Sabalan.

[hbell]

I also am having trouble tracing a NaN floating point value. I'm thinking of writing out the real numbers to an internal file then using a text editor to scan the file for the string "NaN". This seems crude. However, I would think this is the type of thing that Compaq could facilitate for the user. One also could write an assembly language subroutine to check the FPU flag register for whether a real number is a NaN value. In the old days there was a lot of overlaying of types so getting random NaN results when types are overlaid could be a major portability headache.

[Steven_L_Intel1]

Do you know about the ISNAN intrinsic?

Steve

[hbell]

Sorry, I did not know about the ISNAN intrinsic function. This would be the thing to use checking for NaNs. Thanks, Steve.