Different results with F90 higher level optimization

[Vefa Kucukboyaci]

We have a large (and old) code that performs heavy floating-point operations (thermal-hydraulic transient analysis). We have been compiling the code with +O1 optimization and with some other options, which yield identical results as the debug version. When we tried higher level of optimization, +O2 or +O3, we noticed that some problems yield different numerical results relative to the +O1 or debug version and sometimes even crash. I used the following options for conservative optimization to no avail.

+Ofltacc=strict +Onomoveflops +Oparmsoverlap +DAportable +Ofenvaccess

I would like to know if there are other options that can be used to avoid this much numerical sensitivity when going to higher level compiler optimization.

The operating system is:
HP-UX B.11.11 U 9000/785
Fortran version:
HP F90 v2.8.2

Thanks very much,

-Vefa Kucukboyaci

[Dennis Handly · Accepted solution]

>I used the following options for conservative optimization to no avail.
+Ofltacc=strict +Onomoveflops +Oparmsoverlap +DAportable +Ofenvaccess

(You may want to remove +DAportable.)
You seem to have used all of the PA options that control accuracy.

>sometimes even crash.

Any particular signal?
You should contact the Response Center to have them look into your issues.

[Vefa Kucukboyaci]

Thanks very much for your response.

Removing +DAportable has helped somewhat; now results are closer but still not identical.

I might have misled you by using the word "crash". I realized it was the code that was stopping because the transient calculations were going to a different and unacceptable physical state (i.e., below some limits etc..). It is actually really bothering to see how sensitive the FP operations in this code are.

Anyways, I will keep trying few other things, and most likely we will keep running the code with O1 optimization, which is slow but at least consistent with the debug version.

Thanks again...

-Vefa

[Dennis Handly]

>I will keep trying few other things, and most likely we will keep running the code with O1 optimization, which is slow but at least consistent with the debug version.

I talked with our IPF expert and said this shouldn't happen on our Integrity compilers. With the right options, increasing the opt level should provide the same answers.

If you have a support contract you could contact the Response Center to see if this is a bug with the PA-RISC optimizer.

Have you looked at the "HP-UX Floating-Point Guide: HP 9000 Computers"?
http://docs.hp.com/en/B3906-90006/index.html