topic Re: IFC 7.1 vs. CVF 6.5 in Intel® Fortran Compiler

IFC 7.1 vs. CVF 6.5

hazlett — Wed, 08 Jun 2005 00:19:17 GMT

I have some code that runs fine when compiled by IFC, yet blows up when compiled by CVF.
I get about three iterations, fluctuating result to larger and larger numbers, positive and negative, and then it goes off to -Infinity and then NaN.
I suspect floating point error, but can't track it down.
Any ideas?

Re: IFC 7.1 vs. CVF 6.5

onkelhotte — Thu, 09 Jun 2005 19:35:04 GMT

When you provide "some code" it would be very helpful for us...

Message Edited by OnkelHotte on 06-09-2005 05:35 AM

Re: IFC 7.1 vs. CVF 6.5

hazlett — Thu, 09 Jun 2005 20:20:01 GMT

Here is an arcive of code and input data file.
Thanx

OnkelHotte wrote:

When you provide "some code" it would be very helpful for us...
Message Edited by OnkelHotte on 06-09-2005 05:35 AM

Re: IFC 7.1 vs. CVF 6.5

Steven_L_Intel1 — Thu, 09 Jun 2005 20:41:01 GMT

Your code builds fine with CVF 6.6C and Intel Fortran 8.1. You didn't say what the error messages were when compiled with CVF 6.5. I will note that CVF 6.5 is 4-5 years old at this point.

Re: IFC 7.1 vs. CVF 6.5

hazlett — Thu, 09 Jun 2005 20:48:16 GMT

It blows up in runtime for me, producing NaN output in the final set of output.

sblionel wrote:
Your code builds fine with CVF 6.6C and Intel Fortran 8.1. You didn't say what the error messages were when compiled with CVF 6.5. I will note that CVF 6.5 is 4-5 years old at this point.

Re: IFC 7.1 vs. CVF 6.5

Steven_L_Intel1 — Thu, 09 Jun 2005 21:23:44 GMT

Ah - ok.

You have at least one coding error - perhaps more. You're missing a comma in the next to last line of:

real(8) :: pi,dtmp,mass,oldmass,D,N,diff,psum,oldpsum,frict,
/ p1,p2,p3,L1,L2,L3,FBAR,f1,f2,f3,P0,time,dt,Tshift,
/ perm,S,Qdot1,Qdot2,Qdot3,newmass,springmass,Q0
/ ,localflowsum,sum,sumhead,xm,ym,viscosity,
/ Rconduit,omega,Tchar,permeability,porosity,RA
/ ,headC1,headC2,headC3,dheadE
/ Allocation1,Allocation2,Allocation3,sumAlloc

Compile with /warn:declarations and look at the warnings you get. The program goes further if I fix this one error above.

Re: IFC 7.1 vs. CVF 6.5

hazlett — Thu, 09 Jun 2005 22:05:39 GMT

I fixed all of the warnings and the code does go farther than before.
Any ideas why the solution diverges?
As I mentioned, it runs just fine on IFC 7.1.

Re: IFC 7.1 vs. CVF 6.5

Steven_L_Intel1 — Thu, 09 Jun 2005 22:52:44 GMT

I would have to follow the calculations to see what changes. Looking at the code briefly, it does seem the sort that is very sensitive to small differences in calculations which could be introduced by different sequences of instructions or changes to math libraries.

What I usually do in these situations is add code to dump to a file the intermediate values per iteration and compare runs with the two compilers and see where things start to diverge.

Re: IFC 7.1 vs. CVF 6.5

anthonyrichards — Thu, 09 Jun 2005 23:48:26 GMT

Adding IMPLICIT NONE to the main program and the subroutines throws up several variables that have not been defined. Some of them are REAL and I think these will default to single precision. If you require double precision throughout, then this could affect your answers.

Variable LC, beginning with 'L' will default to integer, I think! Also, I would have expected that NT should be specified as INTEGER before being used in the DIMENSION statement in the subroutines.HEre is the compiler output (CVF 6.6c)

Code:

Transient.f
Transient.f(441) : Error: This name does not have a type, and must have an explicit type.   [AREAMASS]
 areamass = sum(area*R)
--------^
Transient.f(551) : Error: This name does not have a type, and must have an explicit type.   [LC]
        LC=1.0e+2             ! m
--------^
Transient.f(559) : Error: This name does not have a type, and must have an explicit type.   [TEMPSUM]
        tempsum=0
--------^
Transient.f(630) : Error: This name does not have a type, and must have an explicit type.   [ALLOCATION1]
           Allocation1=permeability/Tchar*(headE(jt,ie)-headC1)
-----------^
Transient.f(636) : Error: This name does not have a type, and must have an explicit type.   [DHEADE]
           dheadE=dt/porosity*Recharge(jt)
-----------^
Transient.f(672) : Error: This name does not have a type, and must have an explicit type.   [NT]
   real(8), DIMENSION(NT)::CSb,CSe
^
Transient.f(672) : Error: A specification expression is invalid.   [NT]
   real(8), DIMENSION(NT)::CSb,CSe
^
Transient.f(688) : Error: This name does not have a type, and must have an explicit type.   [NT]
       real (8), DIMENSION(NT)::CS
---------------------------^
Transient.f(688) : Error: A specification expression is invalid.   [NT]
       real (8), DIMENSION(NT)::CS
---------------------------^
Error executing df.exe.

Transient.obj - 9 error(s), 0 warning(s)

Try putting these right, and use 1.0D+00 etc. if you want double precision real constants. HTH

Message Edited by anthonyrichards on 06-09-2005 09:54 AM

Re: IFC 7.1 vs. CVF 6.5

hazlett — Fri, 10 Jun 2005 00:45:59 GMT

I made all of the changes you all have suggested so far.
The solution goes further, but still blows up.
An updated code is attached.

Re: IFC 7.1 vs. CVF 6.5

anthonyrichards — Fri, 10 Jun 2005 15:08:49 GMT

I think you should ensure that all your allocated arrays are initialised to zeros (0.0d+00 for reals). You are either dividing by a small number to get your large numbers, or multiplying by a large number (such as -6.277438562204192E+066, which is what the REAL*8 arrays are initialised to in my CVF 6.6C version), or sum of large numbers, so this is a strong possibility.

You may be using an array element value that you have not directly changed during your computation. This may have no consequences if it defaults to zero on allocation, but it may find you out on CVF. You should run in debug mode aand set break points to investigate values as they are generated.