Wrong solutions by Intel Fortran Compiler

Wrong solutions by Intel Fortran Compiler

Hi,

I have a code which works fine with Compaq Fortran, and now we shift to Intel Fortran Compiler (version XE 2011, with VS 2008 under WIN7 and 64bit operting system). All the precedures to get the solution for a specific problem work very well, except that the final solution is not correct in XE 2011.

Any ideas to solve this problem? 

8 Beiträge / 0 neu
Letzter Beitrag
Nähere Informationen zur Compiler-Optimierung finden Sie in unserem Optimierungshinweis.

This is an FAQ. See http://software.intel.com/en-us/articles/migrating-from-compaq-visual-fo... . In particular, check whether there are some local variables in subprograms that need to be SAVEd, and check for consistency in subroutine declarations and invocations.

Thanks Mecej4, and tried the procedures outlined in the forum, and still have the same problem.

For some cases, the code works fine (getting the same solution), however it gets wrong for others. Reall want to have some clues for this performance.

The data file looks like below:

DATA NFMAX,NP,NGAM,NMAX/10,11,12,16/
DATA LSTOP,LSOLVE,LPRINT/.FALSE.,10*.FALSE.,16*.FALSE./
DATA LBLK/10*.TRUE./
DATA MODE,LAST,TIME,ITER/1,5,0.,0/
DATA RELAX,NTIMES/15*1.,10*1/
DATA DT,IPREF,JPREF,RHOCON,VISCOSITY/1.E+10,1,1,1.2,18.E-6/
DATA SCHEME/'P'/
DATA MAXIT,RESMAX,PR,PRT/10,1.0E-8,0.7,0.9/
DATA PRK,PRD,CMU,CAPPA,C1,C2,ELOG/1.,1.3,0.09,0.42,1.44,1.92,9.8/
DATA STEADY,TURB/.TRUE.,.FALSE./
DATA N_X,N_Y/1,1/
DATA F_X,F_Y/20*1.000001/
Data GREAT,SMALL/1.E+20,1.E-20/

Can't say much without seeing a working example code (and associated data, if any) that exhibits the described behavior.

The DATA statements are of little use by themselves.

I am assuming you are referring to a Debug solution, as it may be unrealistic to expect Release/optimized code to behave the same between compilers, OS and potentially architectures. What are your fp-model settings? Please read this:
https://secure-software.intel.com/sites/default/files/article/326703/fp-...

you may need to set fp-model:precise if your code is numerically sensitive.

ron

Thanks very much for you kind response.

After some tests, I found that some parameters specified in the old version worked in CVF do not wrok in Intel Fortran Compiler, such as Great=1.e+20 and Small=1.e-10 (see the data block in my last post). I changed Great=10000000. and Small=0.000000001, for example, and the case works now.

I am not sure but I think I need change the settings somewhere in the Fortran configuration to make it work.

By the way, when I shift to release model, wrong solution is obtained for the similar cases.

Any experience and comments are most welcome!1

If the results are so sensitive to algorithm parameters such as "great" and "small" as you state, in your position I would suspect the presence of one or more bugs in the program. Even if there are no bugs, this kind of sensitivity would cause me to view the results with suspicion unless other corroborating evidence were available.

In making this conversion myself in a number of legacy codes, I've been bitten by some of the differences noted in the "Behavior Differences" section of "/migrating-from-compaq-visual-fortran" linked in the initial response. That the change from 1.E+20 to 10000000. made the difference noted suggests to me that some other variable is not being properly initialized. In my codes I found cases where the CVF version only worked because CVF effectively initialized variables to 0. With IVF these were uninitialized and could have any value and the code no longer worked. There were other cases where a subroutine was called repeatedly that were written assuming that all local variables were preserved between calls, which was true for CVF but false for IVF.

My suggestion is to pay close attention to the differences in behavior; make sure any of your variables that need initialized are explicitly initialized, any that need saved between calls are declared with the save attribute.

Kommentar hinterlassen

Bitte anmelden, um einen Kommentar hinzuzufügen. Sie sind noch nicht Mitglied? Jetzt teilnehmen