Variable suddenly NaN

[onkelhotte]

Hi there,
Ive encountered a strange problem which only occurs in debug, not in release mode. A variable xnue that is being calculated within a function is suddenly NaN. I call that functionvery oftenbefore and the result isvalid. Even stranger is, that xnue is sometimes NaN, sometimes valid even when temp (which is the only variable xnue depends on) has the same value (see attached file).

To avoid this NaN situation, I rewrote that line using ** instead of splitting the term where ** was not being used. In that second line I have no NaN at all.

Im using IVF 10.1.011 IA-32 with VS2003 on WinXP SP2.

!
!
! **********************************************************************real*4 function alphaRohr (d,v,xl,temp)
! ----------------------------------------------------------------------implicit nonereal*4 d,v,xl,temp,x,xnue,pr,re,xLambda
! produces NaN from time to timexnue=1./(558886.+temp*(19828.3+temp*(129.206-temp*.405816)))
write(21,*) 'temp;',temp,';xnue;',xnue
! produces a valid expression every timexnue=1./(-0.405816*temp**3+129.206*temp**2+19828.3*temp+558886.)xLambda=.571018+temp*(.173896e-2-temp*.639792e-5)pr=1./(.771483e-1+temp*(.268392e-2+temp*(.34274e-4-temp*.109952e-6))) 
!if (xl.gt.0.) thenx=min(1.,d/xl**.6666667)elsex=0.endif re=v/xnue*dxnue=.037*(re**.75-180.)*pr**.42*(1.+x)alphaRohr = xnue * xLambda / dreturnend function alphaRohr

Thanks in advance,
Markus

[onkelhotte]

Update:
After deleting the first line of xnue, pr is suddenly NaN at the same point of run-time when xnue was NaN before. Some work to do for Premier Support?

And I found out that it doesnt matter if I rewrite the statement or not. Calculating it twice works too.

!
!
! **********************************************************************real*4 function alphaRohr (d,v,xl,temp)
! **********************************************************************implicit nonereal*4 d,v,xl,temp,x,xnue,pr,re,xLambda
! xnue=1./(558886.+temp*(19828.3+temp*(129.206-temp*.405816)))xnue=1./(-0.405816*temp**3+129.206*temp**2+19828.3*temp+558886.)xLambda=.571018+temp*(.173896e-2-temp*.639792e-5)!pr becomes NaNpr=1./(.771483e-1+temp*(.268392e-2+temp*(.34274e-4-temp*.109952e-6))) write(21,*) 'temp;',temp,';xnue;',xnue,';pr;',pr!pr becomes a valid expression with the same codepr=1./(.771483e-1+temp*(.268392e-2+temp*(.34274e-4-temp*.109952e-6))) 
!if (xl.gt.0.) thenx=min(1.,d/xl**.6666667)elsex=0.endif re=v/xnue*dxnue=.037*(re**.75-180.)*pr**.42*(1.+x)alphaRohr = xnue * xLambda / dreturnend function alphaRohr

Markus

[Steven_L_Intel1]

If you can supply a complete program that demonstrates this behavior, sure, send it to Intel Premier Support. Usually this sort of thing is the result of a coding error, but the error may be distant from the location where the NaN surfaces.

Let me suggest you try one thing - turn on the Run Time setting "Enable Floating Point Stack Check", rebuild and rerun the application. Does it now get an access violation? If so, you have corrupted the floating point stack at that point - usually by calling a function as a subroutine or the other way around.

[TimP]

Is your point is that you want expression evaluation in debug mode to be identical to release mode, regardless of which architecture options you choose? That would greatly restrict the scope of optimization, and perhaps also restrict the functionality of debug mode.
ifort gives you the option of setting the same options (e.g. -O2 -QxW) in debug mode as in release mode. As you didn't discuss this, my guess would be you used default options in debug mode, so you must expect such differences.
You could promote the whole expression to double precision by as small a change as

.405816d0 

thus enforcing wider range, and perhaps less dependency on evaluation order.
It seems that you have collected data on which values seem problematic, 
but have chosen not to divulge this information.
You may know more than we about the origin of this formula.  My guess would 
be it came from curve fitting data with a limited range, and your numerical
problems may indicate an attempt to use the formula well outside the
range of validity.

[onkelhotte]

Hi Steve,
Floating Point Stack Check offered a lot of access violations in the code. So the rest of this year wont be boring at work :-)

Markus

[Steven_L_Intel1]

If it's not already enabled, turn on "Generate interface blocks" and "Check routine interfaces" under Fortran > Diagnostics and rebuild. You may also get some benefit out of the Static Verifier - see the documentation for details on that.

[jimdempseyatthecove]

>> usually by calling a function as a subroutine or the other way around.

Wouldn't gen interfaces/check interfaces detect this faux pas?

Jim

[Steven_L_Intel1]

Yes, if it's enabled (a project created prior to 10.0 would not have it enabled by default) and if both routines were Fortran.

[onkelhotte]

With Generate Interface Blocks enabled I foundmy error. I declared an often used logical function as a real variable in the code. So I got problems later at run time.

Now its gonna be a stress free last week 2007.

Thanks for the help,
Markus

[NH_Veldhuijzen]

Dear all,

This is very interesting. I ran into exactly the same problem after I updated my IVF compiler. The compiler options discussed in this thread are very useful to me, too. I could never have found out the meaning of these options myself. Understanding the meanings of the options in the help screens is sometimes difficult for someone like me who just writes applications, but does not know much about system behaviour. Is there a source somewhere which can help me in fathoming the meanings of the options?

Kind regards,

Niels H. Veldhuijzen

Cito, Arnhem, The Netherlands

[jimdempseyatthecove]

Niels,

Very good point. In the Help file for IVF V10.1.013 on Windows under VS 2005

Help | "Intel Fortran Compiler Help"

Index | command line | using with Intel Fortran

From here the contents of the index is sorely lacking. Cannot find anything directly. The best you do is get information to tell you to do "ifort /help". i.e. following the links from the page on the above click sequence

Compiler Options | Alphabetical compiler options

You find "This section describes all the current Linux*, Mac OS* X, and Windows* compiler options in alphabetical order." which sounds promising. But on the bottom of the page you are instructed "To see a list of all the compiler options, specify option help on the command line.". Hardly what I would call a comprehensive alphabetical listing of the options.

If you go back two pages back to Compiler Options the link "Cross references of compiler options" provides a better source of information but still incomplete.

The gripe here is the "Index of alphabetical order of compiler options" is hidden from access by way of the Index in the "Intel Visual Fortran Compiler Documentation".

The way to obtain the Index is not by Index (tab) but by Contents (tab)

Contents | Intel Visual Fortran Documentation | Compiler Options | Alphabetical Compiler Options

Writing technical documentation is an artform. Unfortunately most of the indexing done nowis by automated index generation. No art and little thought results in poor index.

This is a minor gripe of an otherwise exceptionally good product.

Jim Dempsey

[Steven_L_Intel1]

As far as I know, index entries are manually set by our writing team, but as you note, creating a good index is very difficult work. If you have suggestions for improvement, let us know.

[onkelhotte]

I ran into a compile error since I compile my project with /warn:interfaces
Then my subroutine to find the greates common divisor (gcd) fails:

Error: The same named entity from different modules and/or program unit cannot be referenced. [GGT] (ggt is the german translation for gcd)
Error: This name has already been used as an external function name. [GGT]

recursive integer*4 function ggt(a,b)implicit noneinteger*4 a,bif(b.gt.a) ggt=ggt(b,a)if(b.ne.0) thenggt=ggt(b,mod(a,b))elseggt=aend ifreturnend function ggt

[TimP]

recursive is not permitted without RESULT keyword:
http://www.docs.hp.com/en/B3908-90001/ch10s42.html
If you consider this a deficiency of the error reporting, file a documentation bug report on premier.intel.com.

[Paul_Curtis]

The important documentation note from the reference is:

"A recursive function that calls itself directly must also have the RESULT keyword specified".

Otherwise (ie, functions which need to be recursive so they can be called from multiple threads) RESULT is not mandatory.

[Steven_L_Intel1]

This is all true, but adding the RESULT specifier does not make the problem go away. Intel Fortran allows the code as specified but will give a standards warning if requested.

I have reported this problem to the developers - last week I saw a similar case with a recursive subroutine. It is an error in the generated interface checking. If you want to submit this as an issue to Intel Premier Support, please reference T82170-CP.