Different Results when Compiling on Different PC's

[dtetley]

Hi All,

I have just commenced my first foray into Fortran programming. I have recently inherited some Fortran code, which I am about to start working with.

Prior to getting started on any code modifications, I tried to re-build the code provided to ensure it gave the correct results. I found that it did not when I built it on my PC.

After battling away with various compiler options, I could not get the resulting EXE's to generate the correct results. Therefore, I visited the guy who provided the original code and found that the EXE's when compiled on his PC worked fine.

I have tried compiling on a few different PCs with different operating system, but these haven't proven to be successful.

I am running Windows Vista Professional (32-bit) using Intel Fortran Compiler v11.1. The code was succesfully compiled on a 32-bit PC running Windows XP SP3 with Intel Fortran Compiler v11.0X (can't quite recall which build number).

The Fortran code typically uses fairly small floating point variables throughout the calculations. Not sure if this may be the cause of the issues?

Has anyone encountered this type of behaviour before?

I realise I haven't provided a great deal of specifics, but I wasn't really sure where to start. If you would like additional information, please let me know and I will provide it.

Any guidance you can provide is greatly appreciated.

Thanks,

David

[abhimodak]

Hi David

I think a good starting point would be to provide a sample program (test case) that shows the results you are talking about. In this specific case, you can give such sample program and tell what "different" results you get.

A typical issue associated with floating point operations is maintaining/declaring correct precision. But there can be (m)any other issues for your specific case. So a sample program will help.

Abhi

[bmchenry]

two items:

1) search for 'floating point options' in the forum. There were discussions of various options and the defaults and a number of other things related to precision.

2) might this be an enhanced instruction set issue? see inforamtion on /arch:SSE2 or /arch:SSE3 or or /arch:IA32. I believe using /arch:IA32 is what you want/need.

[dtetley]

Thanks for your replies.

I completed a search of the forums and have experimented with a few different switches. Initially I tried the '/arch:IA32' swtich but I found that this didn't fix the problem in isolation.

I then trialled a few floating point switches. I ultimately found that the '/fp:fast=2' switch generated the correct results (this was originally set to the default 'fast' setting).

So while I'm happy that the code is now compiling correctly, I was wondering what the difference between 'fast' and 'fast=2' is and why it may have caused the differences in results?

Thanks again,

David

[bmchenry]

i suggest exploring the floating point switches a bit more. when you say 'generated the correct results' you really are saying that it generated results equivalent to your prior compiler/cpu/etc configuration.

From the user/reference guide (under fp-model, fp):
the /fp:fast=2 'may produce faster and less accurate results'

So the question becomes: how do you judge what is the correct results?

Just a caution that although the code generates results which appear equivalent to your prior implementation for a selected test case that does not necessarily mean that it is the 'best' or 'most correct' results.

Take a look at/fp:strict as an alternative to fast.

[peterklaver]

I second the use of /fp:strict, along with carefully checking the results to see that they actually are correct, rather than simply the same as previous results.

I too have had the experience of migrating older code to IVF, using the fast floating point model and having computations become divergent. Using /fp:strict made the problem go away, but I found it unsatisfying to just apply a compiler switch without truly understanding what it did. In combing through the code (which I had written originally) I realized there was a potential problem with system condition, in this case involving small differences between large numbers. I was able to apply a transformation to address the condition problem, and after that I could use the fast floating point model without any problems.

I tell this story because you may be dealing with something similar; you mention "fairly small floating point variables". An ill-conditioned problem is unavoidable in some cases, and you may have to resort to /fp:strict. But if there's an opportunity to improve your code that will serve better in the long run.