Convergence problems when migratinf from CFV to Intel Fortran

[Isabela_Z_]

I'm working on a program developed on CFV and now I have Visual Studio 2008 with Intel(R) Visual Fortran Compiler Integration for Microsoft Visual Studio* 2008, 11.1.3468.2008. I have followed all steps described on http://software.intel.com/en-us/articles/migrating-from-compaq-visual-fortran but when I run the program on Intel Fortran it does not converge. I still have Compaq Fortran in an old computer and when I run the same program there, it converges. Please help me!!!!

[Steven_L_Intel1]

One major difference is that Intel Fortran uses modern SSE instructions and vectorization where CVF did not. Your program may be depending on unpredictable "extra precision" in calculations that were possible with CVF. Perhaps you need to use double precision or refine the convergence criteria.

If you can provide an example program showing the problem, perhaps we can help more.

[bmchenry]

as per Steve, a sample might help.

some questions which arise are:

1. converge to where from where?
2. Are you running in debug or release? if release, Any optimization?
3. are you using Qsave?
4. /fltconsistency?
5. which options are you using to try to match the previous behavior of Compaq?
6. Are you running 32 or 64?
7. /Qfp-speculation=strict?
8. etc, etc etc

Probably as a minimum go to project->Properties->Fortran->Command Line and provide ALL compiler Options you used in the compliation as it may provide a clue if it is related to compiler options. Then next step is to look at the actual code for possible answers as to why it is different and does not converge.

[John_Campbell]

If you require 80 bit precision to converge, while 64 bit does not converge, then you have a poorly designed numerical algorithm.
I would expect that the problem is elsewhere and you should look for some other incompatibility.
Did your CVF implementation assume default zero and save for all local variables ?

John

[Isabela_Z_]

Hi everybody,

I'm using Windows 7 64 bits 4Gb RAM. I'm already using double precision on both CVF and Intel Fortran. I’m running Debug mode. On project ->properties I have:

Configuration= Active (debug)

Platform=Active (Win32)

Is there a platform option Win64? I haven’t find it…

On project->Properties->Fortran->Command Line I have:

 /nologo /debug:full /Od /Qsave /iface:cvf /module:"Debug/" /object:"Debug/" /traceback /check:bounds /libs:static /threads /dbglibs /c

I'm sending you a sample program that has the same issue. The first problem is that when I call the routine "Inicializa”, that sets some variables equals to zero and later print the max value and the min value of a vector I get a minimum value different from zero… I can’t understand why.

After when my iteration procedure starts I get some NaN errors and the program exit the loop without obeying the loop rules… With a number of iterations less the 20 and a convergence value greater than the allowable value. 

When I run the same program on CVF none of these happen...

If I create a new project on Intel Fortran using the same source files, I get some declaration errors and after solving them, a stack overflow error during execution. 

Attached follows the project created by the migrating procedure that has the convergence issues.

Thank you all for the help.

Regards

[jimdempseyatthecove]

[fortran]
ALLOCATE(uaux(NX+1,NY,NZ))
...
DO k=1,NZ    v--------------- i=2 not i=1
 DO i=2,NX+1
  DO j=1,NY
   uaux(i,j,k)=0.d0
   uantes(i,j,k)=0.d0
   u0(i,j,k)=0.d0
  END DO
 END DO
END DO
[/fortran]

Jim Dempsey

[Steven_L_Intel1]

To get at the 64-bit platform, which Microsoft refers to as "x64", select Build > Configuration Manager. In the right-hand "Active solution platform" pulldown, select "<New...>" and then choose x64 as the new platform.

[Isabela_Z_]

Steve, which option do I choose for "copy settings from"? It only appears Win32 or empty to me...

[Isabela_Z_]

Jim, thank you very much for the help!

[Isabela_Z_]

Isabela Z. wrote:

Steve, which option do I choose for "copy settings from"? It only appears Win32 or empty to me...

If I choose "empty", a message appears informing that x64 is not installed...

[John_Campbell]

I looked at the problem.

In TDMAU, you call ERROFUNC with a 4th argument RES which has not always been defined.
There are many calls to ERROFUNC where res = 0.

This may be a case of RES previously being a static variable, while now it's previous value is not retained.

You might also like to consider the following changes to CGSTAB, to reduce the stack usage:
Shound NX,NY,NZ be parameters ?
[fortran]SUBROUTINE CGSTAB (VET,app,a,b,RSM,RESMAX,iter,N1,N2,N3)

IMPLICIT DOUBLE PRECISION (A-H,O-Z)

DIMENSION VET(N1,N2,N3),app(N1,N2,N3),a(N1,N2,N3,6),b(N1,N2,N3)

PARAMETER (NX=71,NY=71,NZ=210,NXYZ=NX*NY*NZ)
DIMENSION LI(NX),LK(NZ)
DIMENSION X(NX),Y(NY),Z(NZ)

REAL*8, ALLOCATABLE, DIMENSION(:) :: FI,RES,RESO,             &
                                     AE,AW,AN,AS,AT,AB,AP,Q,  &
                                     PK,UK,ZK,VK,D
!
! DIMENSION AE(NXYZ),AW(NXYZ),AN(NXYZ),AS(NXYZ),AT(NXYZ),AB(NXYZ),AP(NXYZ),Q(NXYZ)
! dimension FI(NXYZ),RES(NXYZ),RESO(NXYZ)
! DIMENSION PK(NXYZ),UK(NXYZ),ZK(NXYZ),VK(NXYZ),D(NXYZ)

integer :: num_call = 0

num_call = num_call + 1
WRITE (*,*) 'Allocating arrays in CGSTAB : RESMAX =',resmax, num_call
allocate (  AE(NXYZ)  )
allocate (  AW(NXYZ)  )
allocate (  AN(NXYZ)  )
allocate (  AS(NXYZ)  )
allocate (  AT(NXYZ)  )
allocate (  AB(NXYZ)  )
allocate (  AP(NXYZ)  )
allocate (  Q(NXYZ)  )
allocate (  FI(NXYZ)  )
allocate (  RES(NXYZ)  )
allocate (  RESO(NXYZ)  )
allocate (  PK(NXYZ)  )
allocate (  UK(NXYZ)  )
allocate (  ZK(NXYZ)  )
allocate (  VK(NXYZ)  )
allocate (  D(NXYZ)  )

MAXIT=10000
[/fortran]

After this review, I can still reproduce the divergence problem in CGSTAB you origionally reported. You should write out RESL and REM for each itteration in CGSTAB and compare this to the results from the same run with CFV. I suspect your algorithm has a new error introduced during your conversion or it is not stable. The following write statement shows some convergence then a divergence.
     write (*,*) iter,' Sweep, RESL = ', RESL,' RSM = ',RSM

John

[jimdempseyatthecove]

I think I found one of the sources of your problems.

[fortran]
DO WHILE (ertran>transtol)
  convB=1.d0
...
DO WHILE (convB>eps2.AND.ncount<20)
[/fortran]

convB is not declared before the above statement. You do not use IMPLICIT NONE, therefore convB is implicitly REAL(4).

You could consider changing default real kind to 8, though this may introduce other issues.

Jim Dempsey

[jimdempseyatthecove]

Steve,

You might want to look at Isabela's project.

(edit line 17 of INICIALIZA to use i=1)

Using w_fcompxe_2011.9.30, default real kind=8 (from vs IDE)

[fortran]

SUBROUTINE TDMAu(uaux,ap,a,b,erro,eps,iter,N1,N2,N3)
    
IMPLICIT DOUBLE PRECISION (A-H,O-Z)

REAL(8) ap(N1,N2,N3),a(N1,N2,N3,6),b(N1,N2,N3),uaux(NX+1,NY,NZ)
REAL(8) fi(N1+2,N2+2,N3+2),fi0(N1+2,N2+2,N3+2)
REAL(8) Clj(N1,N2,N3),Aj(N1,N2,N3)

COMMON /Ns/ NX, NY, NZ

erro=1.d0
[/fortran]

erro when viewed in the debugger is single precision?!?!???

Jim Dempsey

[Steven_L_Intel1]

Isabela Z. wrote:

Steve, which option do I choose for "copy settings from"? It only appears Win32 or empty to me...

You want to copy from Win32. What this means is that all of the existing project information and settings will be copied to the new configiuration.

[Steven_L_Intel1]

Jim, it shows as REAL(8) for me.

[jimdempseyatthecove]

Steve, options:

/nologo /debug:full /Od /real_size:64 /Qsave /iface:cvf /module:"Debug/" /object:"Debug/" /Fd"Debug\vc100.pdb" /traceback /check:bounds /libs:static /threads /dbglibs /c

As Win32

Jim Dempsey

[Steven_L_Intel1]

Jim, I still see it as REAL(8) with those settings. Which compiler and VS version are you using? Can you show me a screenshot similar to what I showed?

[John_Campbell]

Isabela z,

I have looked more closely at your CGSTAB.F90 code and I note a few potential problems.
There is certainly a problem of divergence in this routine, which I think is not related to the CFV compiler.

You have examples where you use D and ZK when updating their values. I am confused as to if these should be on both sides of the equation.
I have introduced a map of active IJK and simplified the loops, but I am not sure of the loop order as to if old or new values of D or ZK should be used. eg,
[fortran]!DO K=2,NKM
! DO I=2,NIM
!  DO J=2,NJM
!            IJK = LK(K)+LI(I)+J
DO IJK = 1,MIJK                                                      !  cycle forward to use new D on RHS   ??????
  IF (USE_IJK(IJK)==0) CYCLE
  D(IJK) = one / (AP(IJK) - AW(IJK)*D(IJK-NJ) *AE(IJK-NJ)    &       !  should D_old or D_new be used here ???????
                          - AS(IJK)*D(IJK-1)  *AN(IJK-1)     &
                          - AB(IJK)*D(IJK-NIJ)*AT(IJK-NIJ) )
END DO
! END DO
!END DO
[/fortran]

I am attaching the updated version, which you could review and address the areas I have questioned.
Changing the order of DO IJK = 1,max to DO IJK = max,1,-1 would change between old and new values.

Divergence occurs after a large number of itterations, so there may be a problem with the available precision in one of the calculations.

John

[Isabela_Z_]

Steve Lionel (Intel) wrote:

Quote:

Isabela Z.wrote:

Steve, which option do I choose for "copy settings from"? It only appears Win32 or empty to me...

You want to copy from Win32. What this means is that all of the existing project information and settings will be copied to the new configiuration.

Steve, 

even if I copy win32 options, will the X64 platform be different from Win32?

Regards, Isabela

[Isabela_Z_]

Steve, John and Jim,

do you think that if I use implicit none and declare all real variables as real (8), this can help me solving the divergence?

Regards, Isabela

[Isabela_Z_]

Steve, Jim and John,

do you think that if I use IMPLICIT NONE and declare all real variables as real (8) this can help solving the divergence???