topic Antonio, in Intel® Fortran Compiler

From PowerStation 4.0 to Intel Fortran 12

Antonio_R_1 — Thu, 18 Dec 2014 02:03:30 GMT

Hello, At our laboratory we have some old Fortran code which has always been compiled by Power Station 4.0. Now, we want to migrate to Intel Fortran 12, but we are facing some problems. When we create a dynamic link library using Intel Fortran, the subroutines compiled seem overall to work fine, but we have detected that for some problems, the accuracy of the Intel Fortran library is much lower (algorithms converge to looser tolerance) and sometimes, for complex models, it does not even work. Our code has many subroutines, so, in principle, we cannot analyze them one by one. I would really appreciate it if someone could give me some ideas on what to look at to solve this problem. I have unsuccessfully looked into some of compiler compatibility options. I know this is a general problem, but I would be really grateful if I can get some feedback. Thank you.

PowerStation used the old x87

Steven_L_Intel1 — Thu, 18 Dec 2014 02:20:54 GMT

PowerStation used the old x87 instructions which often carried precision beyond what you declared. Intel Fortran uses the newer (and faster) SSE instructions which operate in the precision you declared, but this sometimes means that calculations are somewhat less precise because PowerStation was giving you "extra" precision, unpredictably.

Another difference is that Intel Fortran defaults to a "fast" floating point model where it may do some calculations in ways that give slightly different results. The first thing I suggest you try is setting the option Fortran > Floating Point Model to Source. A second thing to try, though I don't recommend it as it will significantly reduce performance, is Code Generation > Enable Enhanced Instruction Set > No enhanced instruction sets. This controls what the compiler uses, but not the math library.

See where these get you. Keep in mind that if you have unstable algorithms the answers you were getting before might not have been valid.

Antonio,

jimdempseyatthecove — Thu, 18 Dec 2014 17:16:48 GMT

Antonio,

In my limited experience, many convergence routines derived the convergence epsilon by hand on a specific machine. These convergence routines will be problematic when you migrate to different machine architectures. Results are not the same, the routine never converges, the routine diverges. To complicate matters, if you are in an organization that has test data and "certified" results data you may find it difficult, if not impossible to get the code to pass. Additionally, the QA department, verifying your results, typically are administrative and do not have a clue as to floating point approximations. This may require you to not only revise your algorithms, but also to prove results are accurate to the degree necessary, and then produce a new set of certified results data. So your problem may be much larger than fixing a few convergence routines.

Jim Dempsey

Good afternoon,

Antonio_R_1 — Thu, 18 Dec 2014 21:12:55 GMT

Good afternoon,

I have tried the options "Fortran > Floating Point Model to Source" and "Code Generation > Enable Enhanced Instruction Set > No enhanced instruction sets". But there is still no luck. I noticed that there are a few compatibility options in Fortran>Compatibility. I enabled I/O compatibility (Use Power Station I/O Format), as we are reading from files, but I am getting the same behavior.

Unfortunately, there was no luck by modifying the value of some convergence epsilons in some key subroutines. However, it really looks like there are a subset of subroutines behaving poorly (some algorithms behave better than others), so precision seems to be playing a role in one way or the other.

We have had a number of benchmark models which have been run over the years to test new developments. With the Intel Fortran library, there is a need to loosen the tolerances in a couple of orders of magnitude. In the past we did not notice instabilities, which does not mean they are not showing up now. It may well be that there are a few subroutines producing this problem.

Thank you very much Steve and Jim for your help. If you come up with any other suggestion, your ideas would be very appreciated!

Antonio