FORTRAN Code Migration from SGI to Windows

[loverain]

i am migrating FORTRAN code with Nag numerical library in Unix SGI machine to Intel FORTRAN 10.1 with IMSL and MKL numerical library in Windows 32 bits machine. the new code in Windows can be compiled, built and ran without any problem. For most of the cases, the results in Windows agree well with what in SGI. but for some cases with extremely numerical difficulty, the results are suite different. Why?

I verified that all the source codes were written in double precision. is there any possible answers?

[TimP]

Quoting - loverain

i am migrating FORTRAN code with Nag numerical library in Unix SGI machine to Intel FORTRAN 10.1 with IMSL and MKL numerical library in Windows 32 bits machine. the new code in Windows can be compiled, built and ran without any problem. For most of the cases, the results in Windows agree well with what in SGI. but for some cases with extremely numerical difficulty, the results are suite different. Why?

I verified that all the source codes were written in double precision. is there any possible answers?

I can't offer more than suggestions. You didn't mention your ifort options. In my experience, /assume:protect_parens should be set always. For diagnostic purposes, I would suggest more conservative than default release options, either /fp:source (or /fp:precise), or /Qprec-div /Qprec-sqrt. The latter options have relatively little adverse impact on performance on the CPUs introduced over the last year (Penryn and i7).

If your SGI machine ran with gradual underflow, /Qftz- should be set ;it's included in those /fp options.

IPO options (probably on by default in VS release builds) have a habit of surfacing latent bugs in source code, so you will want to try setting that off.

For cases with numerical issues, it may not be possible to get the same answers, and it may take a lot of digging to determine whether one result is more accurate than another. Sometimes, a case run with all x87 code (no /Qx options) and PC80 set may be more accurate.

None of these compile options will have much effect, if the critical numerical stuff is in the pre-compiled libraries.

[Steven_L_Intel1]

In addition to Tim's suggestions, I'll note that in version 10.1 the 32-bit compiler defaults to generating x87 floating point code. This can cause numerical inconsistencies when compared to another platform that doesn't have extended-precision registers. Version 11 will default to using SSE2 instructions. I suggest trying the /Qx option appropriate for your CPU.