Convergence problems when migratinf from CFV to Intel Fortran

Convergence problems when migratinf from CFV to Intel Fortran

Ritratto di 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!!!!

28 post / 0 new
Ultimo contenuto
Per informazioni complete sulle ottimizzazioni del compilatore, consultare l'Avviso sull'ottimizzazione
Ritratto di Steve Lionel (Intel)

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.

Steve
Ritratto di 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.

Ritratto di 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

Ritratto di 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

Allegati: 

AllegatoDimensione
Scarica intel-sample.zip4.27 MB
Ritratto di jimdempseyatthecove

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

Jim Dempsey

www.quickthreadprogramming.com
Ritratto di Steve Lionel (Intel)

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.

Steve
Ritratto di Isabela Z.

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

Allegati: 

AllegatoDimensione
Scarica option.jpg72.86 KB
Ritratto di Isabela Z.

Jim, thank you very much for the help!

Ritratto di Isabela Z.

Quote:

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...

Ritratto di 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 ?

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

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

 

Ritratto di jimdempseyatthecove

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

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

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

www.quickthreadprogramming.com
Ritratto di 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)

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

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

Jim Dempsey

www.quickthreadprogramming.com
Ritratto di Steve Lionel (Intel)

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
Ritratto di Steve Lionel (Intel)

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

Steve
Ritratto di 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

www.quickthreadprogramming.com
Ritratto di Steve Lionel (Intel)

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?

Steve
Ritratto di 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,

!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 

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

Allegati: 

AllegatoDimensione
Scarica cgstab.f9012.91 KB
Ritratto di Isabela Z.

Quote:

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

Ritratto di 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

Ritratto di 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???

Ritratto di jimdempseyatthecove

Steve, I guess I need some more coffee

ERRO 1.00000000000000            REAL(8) 
EPS  1.000000000000000D-004      REAL(8) 

Not reading the type column, my mind saw the ERRO without the "D-000" next to EPS with "D-004". (blush)

Jim Dempsey

www.quickthreadprogramming.com
Ritratto di jimdempseyatthecove

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

I would first check if setting default real kind 8 induces the variables in your convergence code to REAL(8). It should, but verify, as you may have explicitly a REAL(4) declared. With 1000's of files, making the change will be time consuming.

I would though, make a debug run with the uninitialized variable check enabled. Implicitly declared variables permit typographical errors to compile without error (generally introducing an error).

Jim Dempsey

www.quickthreadprogramming.com
Ritratto di jimdempseyatthecove

John,

Your code to use your map is wrong. I think you intended to use:

!DO K=2,NKM 
! DO I=2,NIM 
!  DO J=2,NJM 
!            IJK = LK(K)+LI(I)+J
 DO IJKindex = 1,MIJK                                                      !  cycle forward to use new D on RHS   ??????
   IJK = USE_IJK(IJKindex)
   IF (IJK==0) CYCLE
...

Also, if the map contains a goodly number of 0's, then construct the map with the 0's squished out, and when not full, insert a 0 to be used as loop termination indicator.

Jim Dempsey

www.quickthreadprogramming.com
Ritratto di John Campbell

Jim,

USE_IJK has values 0 or 1, so acts like a logical vector. I hope it works as I coded.
Your idea of compacting USE_IJK so that IJK = USE_IJK(ijk_count) would be an improvement.

Isabela,

I did a print of the convergence at each cycle and noticed it stalled after about 50 cycles then exploded after about 1500. It might be a good change to apply a relaxation_factor to the itteration and see if that improves the convergence. I don't know the set of equations being solved to see how to apply a relaxation factor to the itterative change. It would be good if the adjustment to the key variables (RES, FI, PK, ZK & VK ??) was computed as a seperate arrays so that a factor of the change could be applied. ( Is it solving for ZK only or are the others FI,PK and VK also converging ?)

I'd recommend that you look at calculating delta_FI, delta_PK etc and then try applying a factor of the change. This might identify the divergence problem. (RES appears to be calculated for the updated solution state ?)

John

Ritratto di Steve Lionel (Intel)

Isabella,

When you copy the settings from another configuration, you are copying things such as the various compiler options you selected. All that will change is that you are building a 64-bit application in the new configuration.

Steve
Ritratto di Isabela Z.

Quote:

Steve Lionel (Intel) wrote:

Isabella,

When you copy the settings from another configuration, you are copying things such as the various compiler options you selected. All that will change is that you are building a 64-bit application in the new configuration.

Steve, 

After doing that and compiling the program, the following message appears:

"Intel(R) Visual Fortran Compiler for 'x64' not installed"

What does it mean? Do I heve to reinstall Fortran compiler?

Regards, Isabela

Ritratto di Steve Lionel (Intel)

There are two possibilities. One, you are using VS2008 and did not add in the VS support for x64 - the Fortran release notes explain how to do this. Two, you chose the 32-bit only Fortran install. We did away with that in the Composer XE 2013 SP1 release - but regardless, go back to the Intel Registration Center and, if you're using an older version, download the "full" product that includes both "IA-32 and Intel 64" support, then install that. You don't need to uninstall anything.

Steve

Accedere per lasciare un commento.